Okidoke, I had meant to update more often but I'm a forgetful lass and this is how it is. Anyways, I have done many things!

I have made it possible to assign people to issues. This means that they're the people supposed to be doing work. Using the Rules module I also made it so that if you were assigned you would be sent an email.

I added in calendar functionality. These can only be seen on group pages as they are group specific.

Probably some other stuff but I forget.

So today my boyfriend linked me to http://1morechapter.com/1percent/ and we have decided to undertake the challenge. Except that! I have read 26 of the 1001 books in the free (I am too poor to fork out for the huger list) excel spreadsheet downloadable here. 26 is 2% of the total 1294 books to read before you die (or whatever) so I have decided to undertake a new challenge.

We have decided to read 5% of the full 1294 "books to read before you die". That is 65 books in total. So I pledge to have read the remaining 40 books before April 2011. Should be a fun year... My boyfriend has his corresponding blog post and book list here and will be reviewing books as he goes along.

Anyways. The list of books I shall read is as follows:

• Breakfast at Tiffany's
• The Hunchback of Notre Dame
• A Farewell to Arms
• American Psycho
• Atonement
• Captain Corelli's Mandolin
• Cold Comfort Farm
• Dirk Gently's Holistic Detective Agency
• Doctor Faustus
• Dr. Jekyll and Mr. Hyde
• Far From the Madding Crowd
• Frankenstein
• Gone With the Wind
• The Bell Jar
• Great Expectations
• Gulliver's Travels
• Life of Pi
• Lord of the Flies
• Love in the time of Cholera
• Middlemarch
• Oliver Twist
• One Flew Over the Cuckoo's Nest
• Tarzan
• The 39 steps
• The Cider House Rules
• The Count of Monte-Cristo
• The English Patient
• The Fall of the House of Usher
• The Handmaid's Tale
• The Maltese Falcon
• The Reader
• The Satanic Verses
• The Shining
• The Talented Mr. Ripley
• The Tenant of Wildfell Hall
• The Thousand and One Nights
• The Three Musketeers
• The Time Machine
• The Wasp Factory
• Wild Swans

These are from a cut down list of roughly 80 and included books that I've heard of, been told I ought to read, know I ought to read, know I ought to have read and plain old books that are already on my bookshelf.

Wish me luck. I reckon I ought to be reading a book every two weeks to finish by next April and I shall endeavour to review each book before starting the next.

Tarrah xx

P.S. Due to being poor I'm only reading books on the 1001 book list, not the 1294 one ;)

In an attempt to force me to work more I have decided to make available to the world: my dissertation word count. It's unorthodox, unheard of but, it just might work. To this end I have a cute little widget on the left. Every time I do a major piece of writing I am allowed to update the counter. It will be updated at the least at the end of every day but also if, like now, I have written 1000 words and am about to go to lunch!

Happy Ada Lovelace Day!

For those of you who don't know who Ada Lovelace is, or would like to know more: http://en.wikipedia.org/wiki/Ada_lovelace

As part of Ada Lovelace Day people all over the world are being encouraged to write about inspirational women in science, engineering and technology. These unsung heroines are due their arias and today is the day for that.

Anyways, what aria should I sing? It seems to me that there are "unsung heroines" and there are just women. Women who work hard, love what they do and are unacknowledged. I don't know their names, their colleagues do, their bosses should but I don't. They are just people, doing their job. And they are also brilliant.

I am a very bad woman in technology because it seems to me that, partly, the reason there are so few women in this field is because they don't want to be. It's not entirely about gender imbalance, prejudice or whatnot. It's just 'cos they're not interested. I think it's important to raise awareness and try and entice women to join the dark side but we shouldn't be too disheartened if we don't succeed.

I feel that the women who are already here, working with technology, are the ones who care. If the prejudice scares them off that much then they don't care enough to battle it. Now, I'm young, naive and haven't had to deal with much prejudice or issues so maybe I don't understand what it's like. Feel free to tell me.

Anyways, so, the women who care enough to ignore prejudice, to succeed through the gender imbalance, to change the ratio of men to women by one teeny tiny percent, these are the unsung heroines. Yes, we should try to encourage women into this area but we shouldn't forget those who are here already. Some are young and naive like myself. Some have been around for years, when there was *more* prejudice. Perhaps they're even complaining that we have it easy, that everything is so open, that stereotypes are changing and they're right. So we should sing them a song about how brilliant they are; changing the world a percent at a time.

In the last six months - or since I started back at university - I have discovered a war about which I had no prior knowledge. In fact it is a war that many people don't know about. It is the methodology war...

During the last few years it has come more to the fore - in the eyes of a lowly, new, software engineer or computer science student yet I'm told the feud has been raging for many more years than that.

What has prompted this change? What has made more people aware of it? Blogging, that's what. Blogs are a used by a multitude of people to catalogue their daily exploits, to share their love of foodstuffs or books, to share their musings or to add their two cents to the war. For blogs are propaganda - the ones dedicated to a specific subject greater than the self that is. Obviously talking about last night's dinner party is probably just a blog about last night's dinner party. But opinion blogs are the propaganda of the wars raging today.

And this war is of a different nature. Every (wo)man is fighting for themselves. They may share a banner with others, they may have friendships with opposites numbers. But essentially, every person is an army, their size dictated by their number of followers. And no person is neutral. We have no Switzerland in this war. Everyone has an opinion, even if they don't share it. They know who they do and don't believe. The opinion war covers many topics - especially in software - but the Methodology War is most interesting I think.

A little background then:
Disclaimer: This is not a historically researched blog, this is just a musing á la title ;)
The original way to develop software was brought over from other engineering disciplines. At that time not many people thought about a different way to write/create software. We took methods from known sources. And we saw that it was good ;)

However, later on, many people saw that is was not good and sat down and thought about what would make it better. The most cited example of how it was not good is the bridge example:

• "Agile"
• XP
• Scrum
• Lean
• Formal methodologies

There are many more - if you can think of any biggies I've left out do comment and I'll add them in - but these are the really big ones. I've lumped all the formal methodologies in one thing because they're not the subject of today's post. But there are armies who dislike all this Agile nonsense I am sure.

To the propaganda then! Most people these days have a blog. Even if it's just one that's got four posts (like mine) or they started it years ago and haven't posted in ages (like mine) or if it's one that's updated everyday and has a thousand posts. Many people have them. And in software these blogs are used to impart wisdom, share opinions and - often - to rant. And a subject beloved of many is Agile. Why Scrum is wrong, why XP is too harsh, why Lean is too lean, why Kate's-super-cool-methodology is the only way to go (more on that in a later post ;). And bloggers tell everyone their opinions on this matter, waxing lyrical about the methodology of choice and creating a propaganda machine that the less knowledgeable learn from.

What are their weapons you ask? You can't have a war without weapons (sadly). At least here they're not very violent. Unless you're having your daily retrospective and someone is too honest and another coder is... anyway, a story for another time! Weapons! Well, the propaganda is the most important weapon. But the Principles are important too. Ahhhh the Principles. Every methodology must have them. Otherwise how do you know if you might win? How else do you calculate superiority? And of course the Methods themselves.

Interestingly, in this war, the weapons can be used against the army from which they originate. Not only can a proponent of an opposing army detail their excellent experience with Principle X (on their blog) they can bemoan their horrible experience with Principle Y. Thus people are turned off by this methodology. Or people can merely be turned off by experiencing the Principle or Method for themselves.

As my friend @azafred said to me the other day; perhaps the DDOS attack is the Atomic Bomb of the Software World. He may just be right. There *are* other ways to attack an army other than slander and flamewars. And these weapons are far more personal than a gun. Often soldiers in a war are drafted, not knowing about the subject, merely attacking those on the other side. When every man is an army they all know what they are fighting for and when they decide *your* army should go down they will attack you personally. Sad but true. Obviously this sort of attack is reserved for the fanatics, the evangelists and the downright mean.

Anyways, I fear this a war that will rage as long as there are software developers. So think wisely before you create your army. Read *all* the propaganda, be aware of the weapons of the opposition and decide which banner around which you wish to rally. And just have fun!

This article is a draft for the external web site. All examples are in Java or using Java jargon.

So how is baking like programming? What are the similarities? Are there any? I think so and this article is to show you what they are.

Similarities:

• They both have an overall plan - what should happen
• They both have an ultimate goal
• A time frame
• Variables
• Methods
• Correct timing and interaction
• Testing

Differences:

• Baking has an oven period

Let me elaborate. The overall plan and ultimate goal are self-explanatory so I will start with the time frame. The time frame is important, it lets you know how long you will be working on the product.

Time Frame

With baking this time frame is more concrete if you are using tried and tested methods but depending on the chef's experience and skill and the quality of his tools and ingredients it is still open to variation. Exactly the same considerations apply to programming though the time frame is based solely on these details rather than adjusted accordingly. Of course the time frame is also often a made up figure you tell your superior to ensure you get some leisure time!

Variables

We have variables. We have ones whose value never changes and we have ones that are open for adjustment. In baking a constant variable could be, for example, the amount of flour used, I've found that it's best not to deviate from the given amount!
Eggs, sugar and butter are somewhat unchangeable though a little variation won't affect the product too much. And the variables that change would be spices, the amount of fruit or chocolate chips added.

{code}
final int flour = 200;
final int eggs = 3; // Three large eggs
int chocolateChips = 200;
// All values will be in grams unless otherwise stated.
{code}

Methods

And then we have methods, these may take the results from previous methods or they may start with all new ingredients. They are incredibly important and their order is crucial. You can't miss out step two - it just won't work just as you can't add melted chocolate to flour. Likewise the wrong variable can mess up the whole method and perhaps even the whole program.

Though the ingredients are important it is the methods that actually get us to the final product, without them we'd have a gooey mess. The methods need to have exactly the right variables and be run at the right time otherwise things will go wrong. As you can see the melt() method needs to be passed butter and it needs to return meltedButter before the butter gets passed to the cream() method. What would be more sensible would be to add some checks - if() statements - to ensure that we didn't pass null variables. Otherwise we'd have NullPointerExceptions all over the place.

{code}
public ChocolateCake extends Cake {
public ChocolateCake makeCake() {
// All int units refer to grams unless otherwise stated
long minutes = 1000*60;
public Butter butter = 43;
MeltedButter meltedButter = melt(butter);
final int flour = 230;
final int sugar = 230;
int eggs = 2; // 2 large eggs
int cocoa = 45;
int milk = 115;
int vanilla = 5;
long duration = 3*minutes;
long bakingTime = 50*minutes;
float temperature = 175;
CakeBatter batter = cream(meltedButter, flour, sugar, eggs, cocoa, milk, vanilla, duration);

ChocolateCake chocolateCake = batter.bake(temperature, bakingTime)
return chocolateCake;
}
}
{code}

Well sort of. Obviously if we were doing this properly we'd have a CakeFactory that returned Cake Objects. We'd have better inheritance and perhaps an interface. Maybe the variables would be objects that had units of quantities that we could change.

Testing

The testing. Of course people will be more eager to test the result of a cake than a program! If we consider an important occasion to be similar to deployment we can see how testing is essential to both areas. In baking for an occasion you would not make a cake that you had never made before. Just as you wouldn't just write a program and deploy it immediately would you? We have two kinds of testing in software (that I'm going to compare anyway) We have unit testing and we have integration testing.

Unit testing would be ensuring that each part works, you're testing the individual sections of code or the different steps in a recipe. Provided each of these steps goes according to plan then the final product should be fine.

But we also do integration testing. This is the testing of the final product, to make sure that each of the operations did interact correctly and ensure that we didn't leave anything out. It also tests whether third party intervention has made a difference. Though you may set the the oven to the right temperature it may not actually work properly which affects your cake. Other outside influences can affect your final program. In these situations you review what you did, work out what went wrong and where and try to fix the problems. If it still just doesn't work after multiple attempts then you consider the possibility that due to your skills/variables/tools this is simply not the right way for you to proceed and you try something else.

Broader comparisons

There are similarities beyond the individual recipe or program. There are as many different chefs as programmers. People might start producing food or code from a young age or in the comfort of their own home. Even those who specialise in the same areas may add their own personal touches or have rules that they believe everyone should follow.

There is also the concept of different specialties: some people make cakes, some make pastry, some write C, some write ruby. Despite this it is often true that once you fully grasp the process in your own area it is easier to follow the recipes of others. People who are just beginning can improve incredibly, plateau at decent or remain awful (poor guys).

People can be interested in new things, experiment and dabble in other areas. Once this playing around begins they may stay within their own area having learnt from the experience or the might decide that this new area is superior or more interesting than their own. Some people have a knack for certain subjects and become experts while still others are jacks of all trades. And of course there are the people in between.

Conclusion

I think we can see that the similarities far outweigh the differences and I hope that the next time you stare at your computer you think, even for just a moment, about cakes - I know I do. Or when you are waiting for your crumble to turn golden brown you are inspired to write some code. Or maybe you are just amused. That works for me.

Related Articles

Some articles that compare programming to other art forms.

Magic As Programming
Hackers and Painters

Is baking like programming?
Update: Um updated version.

So how is baking like programming? What are the similarities? Are there any? I think so and this article is to show you what they are.

Similarities:

* They both have an overall plan - what should happen
* They both have an ultimate goal
* A time frame
* Variables
* Methods
* Correct timing and interaction
* Testing

Differences:

* Baking has an oven period

Let me elaborate. The overall plan and ultimate goal are self-explanatory so I will start with the time frame. The time frame is important, it lets you know how long you will be working on the product.

h2. Time Frame
With baking this time frame is more concrete if you are using tried and tested methods but depending on the chef's experience and skill and the quality of his tools and ingredients it is still open to variation. Exactly the same considerations apply to programming though the time frame is based solely on these details rather than adjusted accordingly. Of course the time frame is also often a made up figure you tell your superior to ensure you get some leisure time!

h2. Variables
We have variables. We have ones whose value never changes and we have ones that are open for adjustment. In baking a constant variable could be, for example, the amount of flour used, I've found that it's best not to deviate from the given amount!
Eggs, sugar and butter are somewhat unchangeable though a little variation won't affect the product too much. And the variables that change would be spices, the amount of fruit or chocolate chips added.

{code}
final int flour = 200;
final int eggs = 3; // Three large eggs
int chocolateChips = 200;
// All values will be in grams unless otherwise stated.
{code}

h2. Methods
And then we have methods, these may take the results from previous methods or they may start with all new ingredients. They are incredibly important and their order is crucial. You can't miss out step two - it just won't work and you can't add melted chocolate to flour for the same reason. Likewise the wrong variable can mess up the whole method and perhaps even the whole program. Though the ingredients are important it is the methods that actually get us to the final product, without them we'd have a gooey mess. The methods need to have exactly the right variables and be run at the right time otherwise things will go wrong. As you can see the melt() method needs to be passed butter and it needs to return meltedButter before the butter gets passed to the cream() method. What would be more sensible would be to add some checks - if() statements - to ensure that we didn't pass null variables. Otherwise we'd have {color:red}NullPointerException{color}s all over the place.

{code}
public ChocolateCake extends Cake {
public ChocolateCake makeCake() {
// All int units refer to grams unless otherwise stated
long minutes = 1000*60;
public Butter butter = 43;
MeltedButter meltedButter = melt(butter);
final int flour = 230;
final int sugar = 230;
int eggs = 2; // 2 large eggs
int cocoa = 45;
int milk = 115;
int vanilla = 5;
long duration = 3*minutes;
long bakingTime = 50*minutes;
float temperature = 175;
CakeBatter batter = cream(meltedButter, flour, sugar, eggs, cocoa, milk, vanilla, duration);

ChocolateCake chocolateCake = batter.bake(temperature, bakingTime)
}
}

{code}

Well sort of. Obviously we'd have a CakeFactory that passed back Cake Objects if we were going to do this properly. We'd have better inheritance and perhaps some interfaces. Maybe the variables would be objects that had units of quantities that we could change.

h2. Testing
The testing. Of course people will be more eager to test the result of a cake than a program! If we consider an important occasion to be similar to deployment we can see how testing is essential to both areas. In baking for an occasion you would not make a cake that you had never made before. Just as you wouldn't just write a program and deploy it immediately would you? We have two kinds of testing in software (that I'm going to compare anyway) We have unit testing and we have integration testing. Unit testing would be ensuring that each part works, you're testing the individual sections of code or the different steps in a recipe. Provided each of these steps goes according to plan then the final product should be fine. But we also do integration testing. This is the testing of the final product, to make sure that each of the operations did interact correctly and ensure that we didn't leave anything out. It also tests whether third party intervention has made a difference. Though you may set the the oven to the right temperature it may not actually work properly which affects your cake. Other outside influences can affect your final program. In these situations you review what you did, work out what went wrong and where and try to fix the problems. If it still just doesn't work after multiple attempts then you consider the possibility that due to your skills/variables/tools this is simply not the correct recipe for you and you try something else.

h2. Broader comparisons
There are similarities beyond the individual recipe or program. There are as many different chefs as programmers. People might start producing food or code from a young age or in the comfort of their own home. Even those who specialise in the same areas may add their own personal touches or have rules that they believe everyone should follow. There is also the concept of different specialties: some people make cakes, some make pastry, some write C, some write ruby. Despite this it is often true that once you fully grasp the process in your own area it is easier to follow the recipes of others. People who are just beginning can improve incredibly, plateau at decent or remain awful (poor guys). People can be interested in new things, experiment and dabble in other areas. Once this playing around begins they may stay within their own area having learnt from the experience or the might decide that this new area is superior or more interesting than their own. Some people have a knack for certain subjects and become experts while still others are jacks of all trades. And of course there are the people in between.

h2. Conclusion

I think we can see that the similarities far outweigh the differences and I hope that the next time you stare at your computer you think, even for just a moment, about cakes - I know I do. Or when you are waiting for your crumble to turn golden brown you are inspired to write some code. Or maybe you are just amused. That works for me.

h2. Related Articles

Some articles that compare programming to other art forms.

http://www.terminally-incoherent.com/blog/2008/10/29/magic-as-programming/
http://paulgraham.com/hp.html