Week девет

Created on 20131201

The second sprint didn't go so well as the first one. Maybe because of the many assigments that are due really soon and (naturally) everyone does everything in the last possible or beyond last possible moment. Another reason may be because we had to learn a framework for a week in between all of that. Spring is not hard, in fact, it looks extremely nice framework (maybe except the fact that it relies a lot on Java annotations which IMHO make the already hard to follow nature of the Java code even more unreadable). But otherwise the tutorials on the webpage are easy enough the follow and I also attempted doing one of the long tutorials - really nice, easy as a song (as we like to say in my home country).

Anyway, we were able to finish the prototype and we didn't spend too much time on goldplating the code and making it look pretty. It was mentioned in the specifications that this is not an HCI so we didn't want to wrap it in bootstrap or whatever css library we stumbled upon. I personally usually have the tendency to make the code look pretty on the back and in the front, most of the time in useless scale, but I think this semester taught me out of it, which was something that I wanted to change in me anyway. I think we were able to quickly skim through the specifications of the Spring framework, make our way around it, quicly distribute tasks among people which I wouldn't have been able to do in the beginning of the year now that I look back at it.

Week Math.pow((this.Week\ 10), $(this.Week\ floor(pi)))

Created on 20131123

Quality assurance. Good. Now that we’ve done implementing in our first sprint, it’s good for fresh eyes to have a look at the code. We were pleased to hear the other group liked the code and the design decisions we had while implementing. We also received a great feedback as to what can be improved. For example - we will shorten the commands so that the user doesn’t need to type the whole long string but just one letter. We got several ideas in places where we got stuck. We didn’t discover any bugs that we didn’t already know about but we did mark them clearly in our trac system so that we can squash the ones we know about.

As to the lecture - standardization is a great idea. So great that not one but many organizations exist that do standardizations in different areas in our life. Sometimes however I am afraid this thing happens as noted by Mr. Randal Munroe (xkcd 927 Standards):

xkcd competing standards

Why does this happen? Why can’t we choose just a single way to do something? Actually, I notice lately that if there is even the possibility of doing something in more than one way, no matter how logical and ubiquitous the first one is - someone, somewhere will be the stubborn child of the world that will do the things differently. And will standardize it, and will preach it and teach it and will use it no matter what. Examples?

Dates...

xkcd iso 8601

... Daylight Saving Time (look at 5:08) ...

... Driving on the left/right (2 possibilities, yet no agreement)...

map of the world - driving on the left vs driving on the right

... the Universal Serial Bus... UNIVERSAL!!!

usb connectors types

... Measurements... map of the world - different measurements

Let me not even start on languages...

Week ^G

Created on 20131115

The first sprint week looks really good now that it's its last day. We did manage to comunicate everyday with the team and hold standups - either through Google+ or live. We identified problems, assigned tasks to people and implemented our original idea with slight modifications which resolved issues found in the process. The course work seems good enough to be tested with the new (in our minds) agile scrum method of doing things. In theory agile sounds good, in practice it's even better. There is no more weeks of wondering if anyone did something and the frustration when someone didn't - everyday you have the chance to see what happened and help if there are any associated problems.

We decided to implement the course work in Python with data stored in a MySQL database so that we can brush up that good language that we learnt in first year and revise our database knowledge. We'll definitely need it in the second semester. In the first year we didn't do object orientation but now that I know the principles I saw its real power. I immediatly run to an object oriented approach to solve the problem and now I must say it looks really good - not just a bunch of lines, trying to do the prototype and get over with it. It's modular, extensible, with appropriate comments. We were also able to separate our tasks working on different files as to avoid merge conflicts. Using git as a version control system, we didn't run into any problems with it (which is always a big success, see Week floor(pi) post for example).

As of writing of this post we still haven't finished it completely as we need to populate our database and test it, but I feel positive about it. Back to work now!

Week ------rw-

Created on 20131108

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

Created on 20131103

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.