At the moment I’m writing this, the official Ubuntu guide to installing PS3 Media Server suggests doing the following:
1 2 3 | |
Unfortunately, the second step of this process fails, because the happy-neko/ps3mediaserver repository does not have the packages for trusty yet. Luckily, we can still use the packages for raring:
1 2 3 4 | |
Et voilà! PS3 Media Server is installed.
A few days ago a tweet reminded me about a talk I gave on the 6th of August on KRUG:
One trend I'm observing is a lot of rubyists being fed up with messy ruby ecosystem are getting excited or even switch to clojure.
— Piotr Solnica (@_solnic_) October 15, 2013
I have been programming in Ruby professionally for over four years now. When I was starting out, there were probably mere dozens of Ruby programmers in Kraków. Compared being one of the thousands of Java developers, programming Ruby felt almost exotic.
Not that long ago, being a Ruby programmer meant being on the bleeding edge of web development. You had to deal with immature and unstable libraries, crappy deployment options and IDEs that didn’t offer much more than syntax highlighting. On the other hand, it also meant working with smarter than average people, who were drawn to this technology not just because it was new, but also because it was in many ways superior to the other options out there. I loved it.
A couple of years have passed and I still love Ruby. I actually love it so much, that I called my dog Ruby. However, the times have changed. Rubyland is no longer the domain of adventurous and industrious early adopters. Ruby is now mature, stable and “enterprise-ready”. Somewhere along the way Ruby has become the responsible choice of a language for building web apps.
Let’s face it: Ruby is a good language to know right now. The jobs are plentiful and well-payed, and the technology is still relatively modern, but progressively more safe and boring. The days of exciting and unpredictable Ruby are almost over, and soon I’ll only be able to like it as a friend.
I have come across this LISP on the JVM quite a while ago, but having had pretty bad experiences with Common LISP at my university, I never had much interest in it until in May of 2012 I came across a presentation given at RailsConf by Clojure’s creator, Rich Hickey.
I am a huge believer in Single Responsibility Principle. Most of my classes have one public method. I tend to avoid inheritance and heavily favor composition and delegation. Unfortunately, a language like Ruby punishes you for coding in this style - your small classes end up being split amongst hundreds of files and often wrapping a function in a class seems like an overhead.
Watching that video made me realize that maybe I should look into functional programming languages. After all, functions are smaller units of composition, and they are easier to combine. I watched a bunch of other Hickey’s presentations and I got hooked on Clojure.
Compared to other functional languages like Scala or Haskell, Clojure, as a dynamically typed language, was much more up my alley (in the dispute between static typing vs TDD, I stand strongly behind TDD). It also appealed to me more than Erlang, since I mostly work on web apps, and Clojure seems to do better with those.
I read a couple of books about Clojure, started playing with the language and I fell in love with it.
Let’s start with the fact, that Clojure is perfectly capable of expressing pretty much everything that Ruby can, most of the time just as concisely. This in itself is not much of an achievement, but factor into that the syntax of both languages. Even I could write a parser for Clojure. Do you know anyone who could write a parser for Ruby? Clojure’s syntax is the perfect marriage of power and simplicity.
Clojure has real namespaces, where Ruby only has modules. Clojure’s keywords can be namespaced as well. It avoids Ruby’s method naming problems (like when two libraries adding a method with the same name to a class like String of Array). Clojure has ClojureScript. Clojure is well suited for multithreaded programming. Clojure has macros. Clojure is faster…
I believe that this is a great time to get into Clojure programming. The ecosystem is mature enough that you can find libraries to do pretty much everything you need (even if they are not overly polished). The people in the community are above the average, because they have learned Clojure, not because Clojure programmers are in demand, but because they wanted to. There are also plenty of books, screencasts and other resources to learn Clojure from.
Uncle Bob called Clojure “The Last Programming Language”. I would settle for “The Next Big Thing”. Dig in while it’s hot:)
Unfortunately the presentation was not recorded, so all I have are these slides:
On the 9th of July this year I gave a talk about Ping-Pong Pomodoro Pair Programming on KRUG.
I always wanted to do pair programming, but every time I tried, I failed to get much benefit out of it and I walked away tired and frustrated. I didn’t really know what I was doing wrong. Every time I raised questions at conferences about how to succeed at pair programming I didn’t get any good answers.
The problem is that pair programming is not that easy to get right. If you want to be successful doing it, you need to be at least twice as performant (for some definition of performance) as a single person. You also need to avoid burnout that comes with working harder than you would by yourself.
Thankfully I kept trying and at one point when programming with Rudy we started doing Pomodoro Technique in addition to pair programming.
Pomodoro is a personal productivity technique that says you should concentrate on a single task for 25 minutes and than take a 5 minute break afterwards, with a longer, 20 minute break every 4 pomodoros.
It turned out that by using Pomodoro we not only got all the advantages of that technique (focus, work rythm, daily planning) but also we avoided the burnout that has followed pair programming for me before.
Once we realized that frequent switching during coding keeps us both fully concentrated, we also added Ping-Pong pair switching technique to the mix.
Ping-pong is a natural extension of TDD to pair programming. You switch at the keyboard for every part of the red-green-refactor cycle, with the first person writing a failing test, the second making it pass and the first person refactoring.
In traditional pair programming you switch at the keyboard every couple of minutes, but what I’ve found is that it is very easy for one person to keep typing for much longer than that. What I’ve also found is that after being away from the keyboard for about ten minutes your mind starts to drift away and you lose your focus on the code being written. With ping-pong we make sure that both of us are fully engaged and focused on the code that we are writing.
If you want to learn more about PPPPP, I recommend that you check out the full presentation below: