I don’t think I have to spend too many words on Git. Every programmer who was not on the moon in the last 5 years should already be a proficient Git user. Git is an amazing, flexible and powerful version control system. Sure, as Mercury fans often claim, its command’s syntax is often really unclear (git reset HEAD \<file\> anyone?) and some operation are really unintuitive and hard to remember (e.g., remove a remote branch?). But Git is the most popular, successful and probably powerful tools available for VCS. That’s a fact.

Many of you use Git daily, I’m sure of this. You are using it for managing projects, tracking version of your software, personal documents or to collaborate with other colleagues and open source softwares. But I’m pretty sure that many of you don’t know that you can use Git for debug! Yes, Git can be one of your debugging tools too! Let’s see how!

To be productive, you have to be constant. To be constant, you have to be organized. To be organized, you have to be happy about what are you doing. This are three simple rules that I try to apply to my work. The first two are quite straightforward and they don’t really need explanations. The third one, however, is more delicate. What do we mean with “to be happy about what we are doing”? Why this is connected with “to be organized”? Well, the answer is positive feedback. When I’m happy with what I’m doing I’m able to stick to the workflow I’m using. At the same time, a good workflow means less time spent debugging, less trivial bugs committed, less troubles during deployment, in other words: an happier developer!

This positive feedback loop can really increase your productivity. The real problem is, how can we find this magic smooth workflow? I don’t know. I cannot tell you the magic solution to every developer problems. You have to find this by yourselves. The only thing I can do now is telling you my actual workflow. This may be a good starting point for some of you. :)

The last week I spent some time build a small tool for abstracting  an image into a mosaic, for fun. To do this I’ve used Haskell, of course. However, this is my first “complete” program I’ve written in Haskell. Before that, I’ve read a lot about Haskell and used it for solving tons of ProjectEulers’s problems. However writing  program that performs real stuff, such as loading an image, do stuff and write a new image is a completely different things. Using Haskell for the Project Euler problem is almost like cheating, using Haskell for a _side-effect-full _application can be a pain in the neck if you are not prepared.

So the idea was to do this trying to be as much idiomatic as possible so that this code could be used by new haskellers in order to learn something on the language. It is still not really idiomatic, but I’m working on that.

Yesterday, while my working machine was crunching tons of numbers, graphs and maps to produce some (hopefully) meaningful data for a research work, I was looking for a simple guide to build a simple web page with ClojureScript. Unfortunately, I was not able to find something that was at the same time straightforward, simple, minimal and explained! So, I decided to write something by myself to avoid my pain to some future young clojurist. The main problem with the guides I’ve found online were:

People who know me already know: I’m a tool maniac. I can spend hours searching for the perfect configuration of keys, plugins, colors, themes, debugging tools and so on, and unfortunately this is how I waste a lot of time every now and then. Text editors and IDE are one of these big tools that I cannot stop searching for the perfect one. The real problem, though, is that I cannot find satisfaction for more than a month on a particular editor, so, during my life as a coder I used with a certain degree of experience tons of editors such as Vim, Emacs, Sublime Text, GEdit and much more. Honestly! Look at this! If  I had spent less time on tweaking my editors and more on coding, now I would have more side projects completed for sure. Anyway…

I have a certain envy for those developers that are able to stick on, for instance, Vim for more than 20 years. They are happy and enthusiastic of their editor! Lucky them! But I’m not in this way. Maybe I find the exploration more rewarding. I don’t know.

So, coming back to the topic, when I used Linux I was happy too and my favourite editor was by far Vim. Yes, the learning curve is steep as hell but this thing has never scared me (I try to learn too many newborn and cryptic programming languages to be scared by a text editor, complex or not that may be. Then, a couple of years ago, I moved back to Windows and I started to work on bigger project. For some reason, my pleasure and muscle memory in using Vim began to disappear.

Now, there is a long story made of IDE and text editors but I don’t want to spend too much time talking about my evolution (or devolution, your call) in the world of programming editors. The real goal of this article is to explain why, for now, I’m happily landed on Atom, the text editor mad in GitHub.

UPDATE: There is a new version of this article for 2016!

At the very beginning of a new year, it is customary to try to predict what will happen in the future. That is the selling point of each big astrology book which pollute bookstores and newsstands in this part of the year.

Personally I’m not a fortune teller, but I think that can be interesting to try to set the route of the new year on the basis of the one just past. Obviously, I do not pretend to talk on every possible kind of events, but for the one I’m interested in, I think I can say something interesting or, at least, start a discussion.

So, let’s try to spend some words on the trends regarding programming languages and software development.

You are finally back home. During your work day your mind was totally a volcano of creativity. You have so many cool ideas to implement (or at least to sketch). You go to your machine and you start to thing to the technical details. Many questions reach your mind. Maybe too many. Is it better to use Python or Haskell, or maybe C++? I have to start implementing my game prototype with Unity or with some other engine? What if in the future I want to add “feature X” after “feature Y”? So you start crawling the web for resources, opinions and more information on your problem. And this will generate more questions. You spend two hours in this way and you are still full of doubts. Then it becomes late. You are tired. You will check out this problems tomorrow. But tomorrow you will find others problem and not even a solution. And so on. Until every project loses its momentum.

In search of the Philosopher’s Code. A small manifest on my actual thoughts and interests in programming.