Posts

To follow my passion which is writing my own applications and running, I decide to leave Unboxed, where I had really great time. I was there almost 2 years and during that time I learn a lot, met lot of interesting people and work on lot of different types of projects. This is list of my projects that I was working on and my role.

Skype New Year Eve

To bring in 2011 Skype launched an HTML5 site that tracked NYE as it happened around the world. Users uploaded videos to YouTube via the site which, in turn, were displayed on an interactive timezone map of the world. The site was designed to work across multiple platforms in including mobile and tablet optimisations. Responsibilities included:

Lead Back-end developer and Technical Architect

YouTube API integration with download performance optimisation

Skype Theme

Skype Theme is site where Skype Apple users can upload themes for Skype UI. Responsibilities included:

improvement of unsecured parts of application. Based on Security report from independent agency.

The ExtraSpecial Trust is charity that offers small personal grants towards some of life’s important extras to help make a wish come true. Responsibilities included:

finishing of html templates

deployment set up for Heroku

Amazon S3 integration

Edna (Channel 5)

The Edna is programme database. It has been design to streamline the working processes of the Digital Media team. It provides sources programme, series, episode, cast and VOD availability data from a variety of sources for different sites. Responsibilities included:

integration with Movida (programme database)

export dat in XML and JSON – contained information are based on type if requested player or platfiorm

If you are interested to work with me you can sand me an email to petr(at)zaparka(dot)cz or if you are just interested what am I up to just follow me on twitter @zaparka

I’m big fan of good and interesting presentations, especially if they make you think or change your life. Today I was browsing Mixergy talks (btw Andrew Warner is doing great job, although I’m missing that giant book shelf that he had behind in earlier episodes) and I saw talk The Presentation Secrets Of Steve Jobs – with Carmine Gallo. As the title says in this talk Andrew and Carmine are talking lot about Steve’s presentation skills and why he is the best presenter. I made couple of notes, so if you don’t want to spent 1 hour watching interview on mixergy, here are couple of bullet points.

Tell a story – most of presenters are presenting just facts like dry numbers, graphs, long list of bullet points, … etc. You should start your presentation by telling a story. You should say, why the subject that you are talking about matter.

Educate your listeners – when Marrisa Mayer had a presentation at SF Museum of Modern Art, she did’t start talking about what news she have. She start talking about search evolution. She said that in 1935 it would have taken you day and a half to find information on certain painting. Because you would have to travel to get to the library. Than she went through every decade, describing how search evolve. Her point was that what took you day and a half takes now 3 seconds.

10 minutes rule – you will notice that every great presenter will take a ‘brake’ around 10 th minute of his/her talk. Reason is that human mind loose focus after 10 minutes and it doesn’t matter how good presenter you are.

Intermezzo – is kind of brake that your brain need to re-focus on presentation. You should change interaction with your listeners by playing video or showing demo of your ‘thing’.

Twitter friendly headlines – did you notice that great presenters are not using slides with lot of texts on them ? The reason is, if you can’t formulate your idea in short twitter friendly headlines, your audience could misunderstood you or get quickly bored.

Numbers as equivalent of … – when Steve Jobs has been presenting iPod he says that device has 5GB big storage capacity which is equivalent of 1000 songs in your pocket. There was also ad called iPod 1000 songs in your pocket. If you saw that presentation did you remember that iPod had 5GB or that you can download 1000 songs to it? :)

Presentation are not just powerpoint/keynote – when you start working on presentation, to sit infront of your laptop and opening keynote should be the last thing that you should do. Start with sketches, draw a timeline, be creative and don’t be afraid to do something new and original.

During the interview Carmine mentioned couple of times Steve Jobs iPhone presentation in 1997. Carmine also write a book called “The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience”.

To be honest, I like Steve Jobs presentation but my number one presentation is Identity 2.0 by Dick Hardt, you can watch it on youtube too.

When I joined the world of Ruby on Rails development and testing I was quite happy with all the tools and testing frameworks available, I was using a lot of them during development process. Words like Rspec and Cucumber quickly became part of my vocabulary, along with other ‘magic’ words like Kanban and Scrum. BDD, or ‘Behaviour Driven Development‘ became a permanent part of my life!

It’s crucial for a project, that the features that a customer would like to have implemented into the finished product are captured as well defined stories early on. We’ll eventually use these stories as a template for our tests. Cucumber is an especially good tool for using these stories as templates for testing. So what is Cucumber and what does it look like?

Cucumber is a tool that executes plain-text functional descriptions as automated tests. The language that Cucumber understands is called Gherkin.

Here is an example:

As you can see, Cucumber allows you to easily describe the behaviour of your new feature. In fact, it’s that good that some of our customers are using Cucumber descriptions as the acceptance criteria on their project’s stories. So where’s the catch? Well, not everything in cucumber is as easy as it may look. Even though cucumber has lot of pre-defined “phrases” to describe the behaviour of an application, you soon find out that sometimes it can be really tricky to preserve the readability of stories that are more complex than just: “And I should see ‘a yellow box” for example. When it gets tricky it gets really time consuming. And even if you know that implementing the related functionality is really easy – writing the proper, readable cucumber test that makes sense is sometimes very hard. I’m not complaining about writing tests in general. I’m complaining about how hard it is sometimes to achieve basic readability of tests! Does the average customer really have to understand the tests we use? If they do, then ok – I’m here and I’m prepared to write those nice, readable tests for them. But what if they don’t care? Well there is another way around: the solution is called Steak. So what is Steak? Steak is an Acceptance BDD solution (like Cucumber) but in plain ol’ Ruby. This is how an acceptance spec looks in Steak…

As you can see, there is a Feature description and a Scenario description, but the rest is Ruby language with Capybara syntax. But why do I think this is so special, and why do I think you should use it? Well it’s much, much faster to write those complex, yet readable tests, and it’s easy to maintain.

Recently, I was working on a tough project where I was the only back-end developer and there was one front-end developer; let’s call him Tom. At the start of this project we were using Cucumber. It took such a long time to write some of the tests, and because there were a lot of front end changes, we had to fix and re-write a lot of these Cucumber tests. Tom found he wasn’t that comfortable writing Cucumber scenarios, so it took him longer to fix them. At the start of the new iteration, I decided to use Steak instead of Cucumber. I discussed with Tom how Steak works, and he preferred it immediately. We started implementing new stories and development suddenly went really well and much quicker. I was writing Steak stories much faster, and Tom was faster too. So, by the end of the iteration there was no complaining about fixing Cucumber stories, and there was a lot more delivered functionality; them were some good times.

Is it Steak final solution?

Maybe, maybe not. It really depends on you and your customer’s needs, but what you really should do is to try it out yourself. You will see how much faster your development process can became.

I recently listened to a podcast called ‘Developers Life’ where a couple of developers and project managers talked about some rotton projects they’d worked on and how it’s sometimes hard to get perspective and realise that some projects are so bad they’re more bother than they’re worth.

When you’re a developer or project manager working in a framework like Scrum, Kanban or Agile, you can usually look over at the wall and see a big white board with the name of all the projects, and all the stories pertinant to them. The stories will all be in different states: ready for dev, in development, in testing etc.

From a success point of you, you and your team might be cracking the project and delivering the code to the client; but there is another issue you may need to consider. Can you remember how long the project has gone on for? Did you notice that customer or product owner keeps changing their mind all the time, or do you feel they’re doing other things to unwittingly sabotage your work? Did you find out yourself implementing the same functionality again and again?

I know it’s the client’s money, and I know it’s the money that pays your wages and enables you and your team to buy all the fancy toys for you want or need. However even though money is good in the short term, in the long term the happiness of you and your team is much more important. Bad, negative projects are out there all the time and what’s even worse is that you could be working on one right now and you haven’t even noticed! If you are, than I am sorry to say – you could be victim of Stockholm Syndrome!

Stockholm Syndrome, as many of you probably know was observed in Stockholm, when, “bank robbers held bank employees hostage for 6 days. The victims became emotionally attached to their captors, and even defended them after they were freed.” (source: http://en.wikipedia.org/wiki/Stockholm_syndrome).

Imagine that, 6 days in a terrible environment with violent people. Could this make you lose your “common sense” ? Now, how long have you worked on these bad projects? They last for longer than 6 days don’t they? You might be working in great environment with great people, which this actually could be much worse, because the beast is out there and you didn’t notice. You are a victim, and you should be freed, but how you can tell if this is really the situation you’re in?

Don’t worry, there is a way to recognise what’s happening. One solution could be found in doing retrospectives. It’s good practice to do retrospectives because it allows you to improve your process and you’re taking an active role in solving any problems with the project or the team. It’s about upfront communication. That means if you notice there are repeating complaints about the customer or project’s craziness, you can let everyone know and solve the problem quickly and for good.

Another way to realise that there’s something wrong is Pareto principle (http://en.wikipedia.org/wiki/Pareto_principle) also known as 80/20 rule. In short, roughly 80% of the effects come from 20% of the causes. That means you can spend so much time and effort to keep going on a nightmare project, but the income and achievement just doesn’t match up. The last way is outside observation by somebody who is working in your company or for your company, but not on the same project. This person could give you proper insight.

Do you have any other suggestions of how to be aware of Stockholm Syndrome in your project ? If yes, then share it with us please :).

It’s 7 month since I joined the ubxd crowd and I think it has been the most productive 7 month in my life. I asked my self why. What drives me, challenges or motivates me ?

I think that you have already heard about companies like Zappos, Goretex, Ikea…. These companies are trying to create best work environment that motivate people to work harder with enthusiasm and happiness. What they are doing for this? Is that they don’t separate directors from “normal” employees? They have really great company culture and they motivate people to be creative.

You are maybe asking how do they motivate people to be creative? Do they offer bigger salaries or bonuses? The answer is not exactly.

There is scientific study that proves that money is motivational but only to the certain level (and for a certain type of job). This level is different for everybody. It’s a level where person feel comfortable and don’t has to think about salary all the time. If the employees reach this level you are unable motivate them by increasing salary so you have to find another motivation factor which is happiness.

Happiness in company

I believe in fun and feeling of satisfaction in the work. I’m expecting that the company that I’m working for, to try to offer this kind of environment or the company culture, if you wish.

Every company is different and there is a saying that company culture reflects the personality of the founder. To be honest I’m not sure if you can apply this in big companies, but it certainly works in medium and small companies.

Just look at the randomly selected startup. Firstly, who is in the company? It is the founder. As company grows he hires people with a similar personality because he needs to communicate with them and it’s better to sit every day in same office with somebody who you like than somebody who drives you crazy.

You can look at the Zappos or Hash rocket. First they find somebody who is good for the job position and then they chat with him and make sure that he fit in to the company as a person.

Agile + Rails + Ubxd => Happiness

One part of the Agile Manifesto says “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Satisfy => to make happy. So yes Agile helps us make our customers happy. But a happy customer is only one part of equation. There are also programmers (like me), and we deserve to be happy too, so we work with Ruby on Rails which help us a lot. So those two things packaged by Unboxed’s company culture (with great people around me) make me happy and productive.

I was working on project recently, where I had to use CKeditor with paperclip and amazon s3 as the storage. This all is running on Heroku. The solution is really easy. You have the paperclip in you model

My last post was about pair programming. Recently I start working on a small project where I can’t pair with anyone. So I started thinking “what could I use from pairing even When I’m not ? “.

My first thought was to act as if I was, so I would have to act as 2 different people. I should change my t-shirt and wear a hat or just put on glasses and change my hairstyle every time I change from one persona to another, but this could look really strange and potentially have detrimental consequences.

Another thought was, “Hey what are the advantages of pair programming which don’t depend on the other person directly” ? The answer is a better understanding of code, cleaner code and faster development. But how exactly would I achieve this? Let’s find out!

Better understanding of code

Better understanding of code is based on the fact that you explain your implementation to your partner. You can still do this, and very often you are actually doing it without noticing.

If you are speaking or just mumbling to yourself out loud then your brain is using different parts then if you were just “thinking” about the problem. So if you ask yourself out loud “Why doesn’t this work?” or “Ok this points to that if the value is….” then it is same as if you were speaking to someone else. Even if you ask yourself “What would Mr X do?”. Than you force yourself to look at the problem from a different perspective it would also help you.

Faster development

In pair programming you usually switch between each other for short time periods or small problems. This could be easy implemented and the answer is sprint. Pick small timeframe (10 minutes) in which you can implement some functionality. Then you set your watch or phone or some tools that you can download and start. You will see that you are trying to finish your code in the time limit (including your tests of course ;-) ) which will speed up your programming.

Cleaner code

Cleaner code is basically only about you, and because nobody is watching, you tend to not care that much about sanity of your code.

When I start programming in Ruby my friend who taught was really strict about code sanity. Every time when I paired with him, he would point out every small thing e.g. end of the line, space between operators etc.. So I was forced to care. Since then even when I’m not pairing I always make sure my code is clean enough to satisfy his sanity check. So imagine somebody who’s got your respect and is really anal about clean code. Try to not disappoint him.

These three rules will help you in your “virtual pair programming”. If you have another technique feel free to leave a comment!

I was wondering why lot of people still don’t want to pair program. So I wrote down my most important reasons why you should pair program. Btw if you don’t know what is pair programming, here is explanation.

Faster learning – if you pair program with more experienced developer you will learn more faster than you would learn alone.

Faster development – Even thought sometimes pair programming may be slower (pair senior / junior), in general it’s faster. Two people working on same issue have different ideas how to solve the problem or they can suggest better and faster solutions.

Learn new things – It doesn’t matter if you pair with skilled or beginner developer. Every person thinks differently so you will learn new techniques or just different approaches on how to solve the problem.

Better understanding of code – If you pair program you have to explain what are you writing and why. That will help you think more about problems and their solutions.

Cleaner code – Pair programming usually forces you to write cleaner code, because you are watched and you don’t want to look like bad programmer, do you?

Bus factor – Pair programming help you increase the number of people that could be “hit by a bus” without affecting productivity, ie more people have knowledge of code base. (Bus factor explanation)

Eyes will rest – Yes this is good reason too. If you pair program you usually don’t stare at the monitor for long intervals (which help you eyes), because you have discussions with your co-worker, about the issue, that you are solving.

As a programmer working with other programmers, I’m usually contributing to an already existing code base and basically just adding new functions or extending their functionality and because I’m person who could be influenced by others opinions, I also could be influenced by others code and code formatting.

For a moment try to remember what your code looks like if you are writing brand new project and how, after a couple of weeks, this code is still nice and shiny even if you are working with 2 other programmers. Now back to reality where you working at old project where is lots of ugly code. Do you think that project start with ugly code? No, usually it doesn’t. So what changed that nice code to ugly one? Why even if all of programmers are good and writing nice code does, this happened? The reason is what’s called the broken windows theory.

Broken windows theory as the name suggests is about broken windows(not the MS Windows though). Imagine a street with nice houses and white fences. One day, somebody brakes the window of one of the houses. After few days, nobody has fixed the window because the house is empty, even though it looks very nice. One of your’s neighbours kids then brokes another window and because there is already one broken, nobody cares that much and time goes by. After couple of months the house has a broken fence, a couple of windows and garbage all around it. Soon this ugly house will affect the behaviour of your neighbours as the surrounding area deteriorates. You may start to care about cleaning sidewalk, but by then, the whole street has started getting ugly and uglier.

This story represent exactly what happen to you brand new nice code if somebody brakes the window and nobody fixes it.

So behave to your code as a good neighbour and try to leave your code in cleaner state than was before your changes, the whole area will be nicer as a result.