Back in February I wrote about Atom. At the time, I felt Atom showed promise, but was still a bit lacking. After Github announced that Atom is now completely open source in May, I decided to take another look. Most of what I use every day for development is open source, especially the tools with which I make my living: Linux, zsh, Ruby, Rails, etc that I find the idea of my editor being open source very appealing.
Atom uses ctags, as does other Unix-y editors. Support for jumping back from declarations has now been added, wich was crucial for my workflow. Another issue I had was the lack of context when multiple symbols were listed when navigating, but I managed to wrestle my way through coffeescript to fix that. Now, it works just like I expect it to.
Atom has much better performance now and it is clear that the development team consider this a priority. Overall, I find that the speed while working in the editor (opening files, editing files, jumping between files, searching) is acceptable and I do not notice and lag. Opening the editor, however is another matter. It is very sluggish, even when opening directories that are not deep and with a small number of files. For example, I enjoy using Atom for my git commit messages since I am already familiar with the navigation and it has a nice syntax formatting. However, some times it takes several seconds to open and makes me want to tear my hair out.
I have been using Atom as my main editor for the last 3 months. For being a beta version, I find the editor more than usable. Sublime Text 2 is a great editor and a lot of Atom is modeled after it (just as Sublime is modeled after TextMate). However, I believe Atom is here to stay and is my main editor for the foreseeable future.
I love watching the World Cup: It’s more soccer than you could hope for, mixed with national rivalries. What could be better. Now that I am older than most of the players, it dawned on me the intense pressure that they are under, to perform for their country and a question came to me: Just how old are this kids? Let’s find out.
With a quick google search, I came up with what seemed like a good source of data for the task at hand. I simply copy and pasted the data from my browser into a text editor to get a file that looks like this:
Alan PULIDO Mexico 08/03/1991 5 4
Adam TAGGART Australia 02/06/1993 4 3
Reza GHOOCHANNEJAD Iran 20/09/1987 13 9
NEYMAR Brazil 05/02/1992 48 31
Didier DROGBA Ivory Coast 11/03/1978 100 61
David VILLA Spain 03/12/1981 95 56
Abel HERNANDEZ Uruguay 08/08/1990 12 7
Javier HERNANDEZ Mexico 01/06/1988 61 35
Islam SLIMANI Algeria 18/06/1988 19 10
Shinji OKAZAKI Japan 16/04/1986 75 38
Cutting and Slicing
Using the power of unix pipes, we can easily extract the data we want from the data. Let’s start by getting all birthdates:
In this case, we are cutting again, this time using / as a delimiter. Now we have a list of all the players' birth years.
I searched around for some quick utilities that would generate a histogram and the most promising seemed a python utility called data hacks. Unfortunetly, I did not install for me and I didn’t have the inclination to mess with my python installation. I did however, find something similar to what I needed in a blog post about visualizing your shell history. After adapting it a bit to my purposes, I created a small bash function that now lives in my profile:
This function leverages awk very heavily. awk is a pattern-directed scanning and processing language. I am not very familiar with it, but after seeing how powerful it is, I am definitely want to get acquainted with it.
With this function, we can now get a full histogram:
Notice that the final sort is needed, because histogram returns the values ordered by the number of times it appeared in the data, but since we are talking about birth years, I believe the graph is more telling if it is in ascending order.
With all that in place, it is relatively easy to make a histogram of other data. I remember Malcom Gladwell’s theory in his book Outliers about how most professional hockey players are born in the first part of the year, because of how the developmental leagues work in Canada. With a database of 735 professional soccer players, chosen to be then best 23 of each country, I would expect 61.25 players to be born on each month. Let’s find out how many really are:
Notice that to arrive at this graph, the only thing we changed was the field we extracted from the data, in this case the month of the birthday. Is there a trend here? It does suggest that players born in the first part of the year are favored, but I do not know if it’s statistically significant.
Quick and dirty data analysis on the command line is pretty easy if you know a bit of unix and some awk!
Ruby’s blocks are one of the language features I like the most. The make iterating on collections extremely easy.
You can shorten the (already short!) syntax above, like so:
The above is implicitly calling to_proc on the symbol. This es extremely handy, when you are calling the same method
on each object. However, it can also be useful to call a method with each object as an argument:
Pollyanna Pixton, Paul Gibson and Niel Nickolaisen write a concise and practical book on how to foster an Agile culture inside your company. It is geared towards those responsible for leading teams of software developers and other IT professionals, although most of the material is applicable to any leader.
Agile, at its roots, is about delivering software that brings value to the company and ultimately to the customer. In order to achieve this, it proposes short iterations and embracing change. The authors thesis is centered around trust and ownership. Trust from the leader to the team to do their job professionally. Ownership by the team of the product they work on. If both are present, the team will flourish. Leadership is about giving your team the tools to do their work and protecting them, not about meticulous control. Innovation comes from a culture where risk can be taken and failures can be learned from, as opposed to fear of being blamed and possibly fired. In a way, a lot of what the authors talk about is about aligning incentives of each individual to those of the organization. Of course, clarifying the organization goals and priorities and communicating those to it’s members is required.
The book reads very easily and is reach with anecdotes that illustrate good and bad leadership alike. The advice is sensible and not at all process-heavy like some other so-called ‘Agile’ books that have meticulous schedules for stand-ups, backlog pruning, retrospectives, etc. The advise feels also real-wordly: For example, it recognizes that not everyone in your organization may embrace Agile and gives you tools to deal with difficult employees and managers.
If you are a team leader, there is a lot to learn from this book.
Uncle Bob writes about mocks, stubs, doubles, spies, etc. He explains the differences between them, how and when to use them. The examples are in Java, but are easily followed even with vague familiarity with the languge.
The fellows at thoughbot give a great primer on regular expressions in ruby. The examples are easy to follow and yet manage to explain a lot of more advanced concepts like capture groups, expression modifiers and lookarounds.
Back when Apple’s Goto Fail bug was news, my reaction to this was: How did the introduction of this bug pass the tests. At the time I thought about writing a test suite around it and running it with and without the duplicated line that causes the bug to demonstrate how test catch regression mistakes. I never got around to it, mainly because of my lack of familiarity with the language. Martin Fowler has written a lengthy and thoughtful post that expressess the feeling much better than I would have. It gives the same treatment to the [Heartbleed Bug] and explains why testing is so important in softare development.
I am lucky to work mainly in ruby, a community that is very test-oriented, even after the recent hoopla.