Jul 21, 2013

So, I've done it. I've been to my first hackathon. HACKED took place (well, it's still running now and I'm blogging from there!) and it's been an exciting experience, that left me with some doubts.

An hackathon it's all about creativity and skills. Some companies offer their devices to play with during the day - for example I've been sitting next to a bunch of guys that have created a small cool game with Philips HUE lightning (check it out on GitHub here). Ideas here come often before than quality, and that's not necessarily a bad thing. You have 24 hours to build something, and that something comes completely out of your mind. Devices may inspire you, but after all it's YOU deciding what to do. People code, hack, share their knowledge and socialise, in some cases all night long (I have to say I passed on staying all night long, I don't live too far from the venue), and the next day they present what they've done to judges and the crowd. Some pretty cool ideas evolved from hackathons, and I'm pretty sure it will be the same case here.

My day was more about learning, rather than building. I've never been in such an environment and I acted more like an observer (OK, I took the opportunity to hack a bit with Scala, but on some studying stuff!), but I grasped lots of positive attitude.

Talking with Chris we discussed how it's not easy to have the skills to be a great hacker and a great craftsman all together. Sometimes you can be focused more on creativity rather than methodology, and build up something very cool - but which can be a nightmare to maintain, or to expand. Sometimes you can end up working applying lots of methodology, but lack that creativity bit that will allow you to come up with ideas that worth some changes.

In my opinion, practicing and observing is one of the keys to achieve this. Observe, and you can grasp ideas. Practice, and you know how to make things better.

I'm definitely doing another hackathon - probably sleeping over there as well as I feel it's part of the culture. And hopefully next time by observing and practicing I'll be able to actually build something :)

Jun 19, 2013

Everybody at LSCC has been busy and we're quite excited to announce SoCraTes UK, an international software craftsmanship gathering, which is taking place between the 19th and the 22nd of September 2013, at the Farncombe Estate.

SoCraTes will be an opportunity for fellow craftsmen around the UK (and not only!) to gather together and have interesting discussions and practical session - and of course, to have some drinks and fun at nights! The event will be run as an Unconference, as we'll self organise and decide topics that we want to discuss.

It's the first time I attend such an event (shame on me!), and I'm quite excited to see that happens. I'm sure there will be lots of learning involved, and I'm proud of helping with the organisation.

If you're interested, check the website or on Twitter - registration will open shortly.

Jun 6, 2013

Every computer science student heard about design patterns. A design pattern is a general solution to a problem that repeatedly occurs in software implementation. Correct use of patterns, where appropriate, lead to code that can be easily reused for different situations.

Patterns are very useful. There are situations in which applying a pattern will not only allow you to reuse  your code, but also to solve your problem more elegantly. As a downside, there are many situations in which applying a pattern may be like shooting mice with a bazooka. Think about a small component of your system which is not gonna be reused anywhere else.

One of the mantras of XP - and of course one of the foundations of TDD - is to keep your implementation as simple as possible. The YAGNI principle (You Aren't Gonna Need It) forces us to be focused on what's really needed by our solution, and to not bloat the code with unnecessary logic. To some extent, this may be seen as discouraging the use of patterns. After all, sometimes when implementing a pattern we are implementing some logic that we don't need or we foresee we need (but we're not sure after all).

Is this real? Does TDD clash with the concept of design patterns?

When thinking about patterns, we should keep in mind that in the Gang of Four design patterns are seen as a target to which our refactoring should aim. Hence, design patterns are naturally linked with refactoring, which of course is one of the foundations of TDD (you don't skip the refactor phase while doing TDD, do you...). When you refactor your code, common behaviour and smells need to be identified and moved towards a cleaner and better implementation - which may very well be a pattern.

A very interesting book I'm reading at the moment is Refactoring to Patterns by Joshua Kerievsky - it's a practical and pragmatic approach on how to identify common situations while refactoring your code, and how to move to, towards or away from design patterns. I haven't finished it yet, but from what I've read I bet it's gonna be on my desk whenever I write some code.

And you, have you ever refactored to patterns?

May 30, 2013

Me and Robert ran a hands-on session for the London Software Craftsmanship Community about TDD an how it helps when you're facing requirement changes. The exercise was too long to be completed during the two 30-mins Pomodoro we gave, and some people asked for the slides for the exercise. You can find them here - Red Pencil Kata.

Thanks everybody for the feedback, we'll make sure every session takes into account your suggestions!