Week ------rw-

The reason I love coding so much is that it's the immediate gratification of seeing something done so quickly after you learn it. Make the pixels move the way you want, when you want. Sometimes you are so excited of what you just learnt that you don't even read the whole documentation - just go and experiment... Sometimes? Well, usually.

And that brings us to prototyping. It involves experimenting with the technologies, trying to find the limits of the chosen framework, programming language or library and not caring how terribly things may break. It's like being an architect with infinite supply of free bricks and manpower. How good is that?

Of course, from serious SE point of view, it's lowering the risks as you go and try to experiment first before building the system. As Fred Brooks says in the Mythical Man Month, the first system never works. So here is the chance to throw away safely the first system and do the real work afterwards. Prototyping is cool, it brings you to those childhood days where you were not afraid of doing things, go as broad as your mind wishes and then see where the limits of the Universe are. It's fun.

I also rewrote another famous song. There is my weekly entry.

Let's Prototype

Hi - Hi! We're Glasgow CS students (Ah-huh)

And we've got neews for you (you better listen)!

*Get ready, all you lonely coders,

and get those pens and papers from home!

Meriment is rising - risks are getting low (oh-oh)

According to all the slides, the sandbox's the place to go

Cause tonight for the first time

We're gonna grab a black pen (grab a pen)

For the first time in PSD

We're gonna start prototype! (and rise the hype)

Let's Prototype! Hallelujah! - Let's prototype! A hype!

I'm gonna code now, I'm gonna make myself get

Straight into ideas' net!

Let's prototype! Hallelujah!

Let's prototype! Again and again!

Draw, spike, code - I like

Incremental prototype!

This is an evaluation, to which I'll say adieu

I took it to Boyd Orr seven... and I did what I had to do

I learnt every language and made myself apply

Because each and every program could be typed in vi!

Let's prototype! Hallelujah! - Let's prototype! A hype!

Let's prototype!! Hallelujah!

Let's prototype!! Hyyy----pe!

Week sqrt(25) - We had the GUTS

What a week! I organized my first Hackathon, a dream I had for so many years. Our Tech Society board had the right motivation and the guts to do it. This post is to thank everybody who contributed and made it a reality.

We had an amazing array of sponsors such as SIE, InformaticsVentures, MetaSwitch, Barclays and JP Morgan some of which provided our awards at the end of the competition. Challenges were provided by Skyscanner, SAS, Dynamically Loaded, Future Cities and SUMGroup. Special thanks to Dr. Matthew Chalmers - generous contributor both financially and in terms of challenges.We partnered with Dominos and Naked soup who provided the main meals for the event. Amazon and GitHub provided help with AWS instances and private repositories during the event which helped people collaborate and put the programs in production environment, using the power of the cloud. Of course, many thanks to The University of Glasgow and the School of Computing Science that helped us get the venue and supervise the whole event - thanks to Joe Sventek, Jeremy Singer and Tim Storer.

I can't count the people we need to thank that to happen. Big applauds to the team - Tomasz Sadowski, Josh McGhee, Adam Kurkiewicz, Iva Babukova from the GUTS board who were running all the time to get the things right. Thanks to our apprentices Milorad Felix, Iulia Popescu who will take over next year and have already contributed a lot this year; our communicator and social media - Magda Kowalska; our drivers Keir Smith and Stefan Balling which got our food supply; our photographer Ralitsa Kostova. Thanks to John, the janitor from Sir Awlyn Williams building who helped us in uncountable ways providing support at any moment.

Last but not least, thanks to all our participants. 11 teams, 50+ people, 5 challenges, 48 hours. 20 large pizzas, 50 sausage and bacon rolls, chips, sweets and fruits; unmeasurable amounts of liquids, cola, coffee, energy drinks. Many tweets, facebook pictures and status updates.

I think we showed our students had the guts to go through this amazing weekend producing ideas and solutions for the short time. And we are just getting started...

Now to my opinion about user stories - the weekly topic in PSD. I think they provide the final layer before actually coding, examples (not a 100% coverage) which are exactly specified. I am trying to summarize this in my head. So far: we have requirements - the endgame, the what needs to be done. We also have a plan of how we are going to do this - our tactics. Now we have the examples, the concrete final user experience that needs to be implemented but also the importance and thus now we can set when we should start implementing the stories. I particularly liked the MoSCoW (Must, Should, Could, Won’t have) method of prioritizing the importance to the stakeholders of each requirement.

In my mind, I see a bit of overlap between the requirements (the theory) and user stories (the examples) in a good way - I always learned things this way.

Week ceil(pi)

Requirements are better than planning. I know that probably I should embrace both as good strategy for work, but I just can't. I am more the strategy guy than tactics guy. I like to know that in chess the goal is to checkmate the opposite king. This is the requirement. Now how I'm going to do that - using pawns, bishops and knights - I want to have the flexibility to do that. I don't want to make my first move and define my whole game. I like the dynamics, dealing with unforeseen positions.

There is this big difference I see which makes me want to have good requirements but not necessary a strict plan to execute them (see rant about planning, pre-previous blog post). But the specifications are whole different world - I would like to know what is the final deliverable, what needs to be done.

Describing this with the help of the UML is best. One language to rule them all - standartization is good practice and it's of the rare case that UML was created. Drawing the diagrams, writing the use cases shows you a good picture of what the final thing will look like. It's so good that you can draw java class hierarchies and tiny actors and use the same universal approach. Good things.

To keep it rolling from the last week, I rewrote a famous song about the requirements.

We Will Require

At first, we were afraid, this was not defined.

Kept thinking, we could never write the specs we were assigned.

But then we read so many slides thinking how we did it wrong.

And we did what we shouldn't have prolonged.

And now we write, and ask and chase

proffessor Singer down the corridor, refining our case.

We should writte that good old doc.

We should made a guarantee.

that this will not impact, oh no, the mark on our degree!

Could, would, should, won't - the keywords are.

What do we need - we won't ponder anymore.

Who though of that? It just didn't ring a bell.

Who could know? ... We had to use the UML!

Oh, no, not we, we will require!

Oh, as long as we know how to trac, we'll keep a good attire.

We've got all specs to give, we've all got to get relief

And we'll require! We will require, hey, hey!

Week floor(pi)

I can't be more confused about git. I'm using it for about two years, pretty regularly, I get the point, I know it's good. But somehow I always manage to screw things up.

Every time I discover something new about git, I love it and I think "NOW I got it!". And after few minutes, git slaps me like a lemon tied on a brick (H2G2 ref). I wish I could work better with it. I went through so many tutorials, I worked with it, I asked for help from more proffesional users. And I still manually copy the directory just in case. Version control is good, the idea is great, I love it to be able to undo things, to see how a project evolved with history, to branch and play on a new feature. But does it have to be so complicated? Can't it be ala Google Docs solution? Future will show.

In the meantime - I decided to write a poem about git. It's rephrased very epic poem we have in Bulgaria called "The Rebels on Shipka" and it describes one of the last battles we had with the Ottoman empire back in the end of XIX century. I love it so much, I decided to take a spinoff of it. There it is:

Ode to Version Control

Oh, Version control!

Three weeks already the young and the brave

the code they manage - and not misbehave!

Github valleys eagerly repeat the roar of the battle.

Horrible pushes! For the dozen time the old merges rattle,

and fastforwards automatic clear some mess.

Commits after commits! Pushes after pulls!

The scrum master is pointing to the specs

and shouts "Branch it first! Perform all checks!"

And developers rebase, they talk and then agree.

But github answers with another shout: Permission denied (publickey)!

And with new rain of checkouts, statuses and logs,

everyone blames, and clones, and forks.

They code like lions, they compile like sheeps.

The last commit had broken the release.

And again git wins. The geeks disapointed, frustrated

just do in the bash:

rm -rf /

But the day will come,

trust me, I know,

where we will understand

how to use version control.

Week 10

This week - charts.

Almost. But not quite. We were talking about Gantt and PERT charts. Cool stuff that bussiness people talk all the time. They just love it - give them meetings, status reports, where is it going, how much is it gonna cost, who is working on what, what needs to be done in order to AAA! Just do IT!

To be honest - I hate planning (no way, you couldn't have guessed from the rant above). Not just the process of planing, the execution of it. I just can't work with a plan - it limits me or it pushes me - never with the right speed. The right speed depends on many factors including distance and time but in this context - my current mood, level of entropy in the Universe and amount of food around me. The bad thing is that it's a must do and not want to do - and that's all the difference for me. I'm the kind of person that just wants to do the work, not plan it.

But... some people need it. Some people need to know what is going on when and how. And because I must to work with other people, I will do my best to draw charts.