Steak vs Cucumber as BDD tools

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?

Here’s the explanation on Cucumber’s own wiki.

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.

Are you victim of Stockholm syndrome?

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 :).

Happiness and motivation

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.

What makes you productive and happy?

Ckeditor with Amazon S3 and paperclip.

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…

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

has_attached_file :avatar,
 :styles => { :big => "180x180#", :medium => "140x140#" },
 :storage => :s3,
 :s3_credentials => "#{Rails.root}/config/s3.yml",
 :path => ":attachment/:id/:style.:extension",
 :url => ":s3_domain_url"
And you have something like this in the picture.rb and attachment_file.rb (app/model/ckeditor/)
has_attached_file :data,
     :url => "/ckeditor_assets/attachments/:id/:filename",
     :path => ":rails_root/public/ckeditor_assets/attachments/:id/:filename"

So solution is obvious now:

has_attached_file :data, :styles => { :big => "180x180#", :medium => "140x140#"},
 :storage => :s3,
 :s3_credentials => "#{Rails.root}/config/s3.yml",
 :path => ":attachment/:id/:style.:extension",
 :url => ":s3_domain_url"

That’s it.

Pair programming with your mind

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!

7 reasons why pair program

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.

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.

So are you finally convinced to pair program ?

How to tag SVN branch on the server from Git repository

Image the following situation:

You are using SVN on the server and to deploy on the server you have to TAG release. You are using Git on your local machine and you have following commits.

Image the following situation:

You are using SVN on the server and to deploy on the server you have to TAG release. You are using Git on your local machine and you have following commits:

Task is to create the SVN branch from first red dot and than add the another commit marked with the black dot.

Git version

To do that in Git  is what you would expect:

reset the master to last commit that you need (red),

1: git reset --hard SHA_code

than create and switch to new branch

2,3: git checkout -b name_of_the_branch

and cherry-pick the commit/s.

4: git cherry-pick -x SHA_code

Git SVN version

Reset master to red dot

1: git reset --hard SHA_code

create and switch to new branch

2: git svn branch name_of_the_branch (this create branch on the server)
3: git checkout -b local/name_of_the_branch name_of_the_branch

and cherry-pick the commit/s.

4: git cherry-pick -x SHA_code

and push changes on the server

5: git svn dcommit

to tag this branch on svn type

6: git svn tag tag_name

Note: if you did not checkout the branch in proper way (svn way – step 2) you will tag the master branch

Fix your broken window!

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.

I’m not working

Yes that’s right, despite the fact that I’m employed by Unboxed I’m not working anymore. I’m going to work every day, programming some stuff but it’s not work for me anymore. Really.

I have had this feeling since I start working with Rails and this feeling became stronger when I came to London and joined Unboxed. I had heard about Agile and Scrum and I had tried to practise TDD and BDD before, but it’s really different here and now.

I joined the real world of Agile. I was so excited (and scared) when I had my first standup and my first retrospective. I’m still excited, because everyday is different. One day we have to do standup without our Product Owner (PO) because he is stuck at the tube. On another day, I was alone since everyone else was on holiday. Is it still a standup if only one developer and the PO are present? I think that it is, because the important thing is that I can tell him what is going on and another day of excitement can start.

Of course there are days when I’m tired, but you can be tired even after sitting on the beach with a Mojito in one hand and great book in the other. At the end of a tiring day at the office I look back and discover that I’m tired because I experienced so many new and interesting things.

So what am I actually doing if I’m not working? I’m a little bit scared that I might be dreaming. I’m scared I will wake up in my cubicle with PHP code (without tests) on my screen and without any slight hint of Agile or Scrum and Waterfall knocking on my door. So please don’t wake me; I like it as it is!