August 30, 2016

DCI: Data Context and Interaction Architecture playlist

It's been a while since I've heard about DCI, and still to this day I'm thrilled with the approach and the concept behind it.

It still lacks lots for experimentation in my case, but I find the paradigm really but really interesting.
So in that matter, here a list of resources that can introduce the paradigm in a better way:

Coplien: A good introduction

James Coplien - The DCI Architecture: Supporting the Agile Agenda from Øredev Conference on Vimeo.

Coplien: A good interview

Coplien: Another great interview

Reenskaug: A great overall view and history

Trygve Reenskaug - Object Orientation Revisited. Simplicity and power with DCI. from NDC Conferences on Vimeo.

And finally a thick (in content) book, a great read in general.

August 13, 2016

An advice towards Mercurial

This is not a rant, really, just a some few things I would like to write down.


When I started into development I've got the great suggestion to use revision control systems, the first one that I ever used was CVS, it really worked well for my own purposes, just had some issues with the sharing-between multiple machines.

Then Subversion was the hot-thing and it was a bit better that Subversion, but still had some of the things that I disliked from CVS.

Then GIT showed up, the projects I was working on required CVS, so I got an early non-official version of git-svn and started working with it, it was great, so many of my problems went away, but it was still under a SVN server.

After that , Github, Bitbucket, Kiln, and the tipping point, everybody switched to the reasonable choice, distributed revision control systems, and I think the best summary for why this approach is better than others, is described by Joel.

My point

My point is not to tell which tool is technically better, my point is more subjective, I think that Git is still technically the most advanced approach you can have for revision control systems, but it might not be the most simple one to use.

I have used a lot of tools, and among all of them the one that still holds my thumbs up is Mercurial, here some few reasons:
  • Simple and concise user interface (commands)
  • Better merging strategies
  • No automatic commits on merge
  • Good performance
  • Simple to explain
  • Gentle learning curve
  • Consistent tooling 
 Not too many reasons, rights? that's why I like it, because it just works, no porcelain/plumbing, just the tool. The other tool that goes beyond this is Fossil SCM, but it still needs adoption.

So in the end, my suggestion, if you are using revision control systems and you are unhappy with Git, or you don't know any other tool, give Mercurial a try.

July 18, 2016

Personal current trends on software development

Most productive development environment (server-side):
Most productive web development environment (single-page applications):
 Most productive mobile development environment:
Most interesting programming model:
Most useful getting-things-done tool:

March 11, 2016

A personal wiki

A while ago I read in many places that you should write down what you learn, and that the best way to do it is by having a personal wiki.

So I started doing that, but at the time the options I had were:
  • Install a local server and then use MediaWiki or something similar
  • Install a standalone application that worked as a wiki
  • Use a public service to create a personal wiki
But no matter how hard I tried, I couldn't get use to it, I worked most of the time offline, and I didn't like to be doing configurations over and over (since I still use a variety of OSes).

But during the last year I've been working on personal projects with Fossil SCM, which is a great-scm created by the mind behind SQLite, the great Dr. Richard Hipp, you should listen to his talks, he's quite something.

And with this standalone SCM that comes with an embedded wiki, I started creating content, of everything I had in mind:
  • Vim shortcuts
  • Daily logs
  • Small shell tweaks
  • Docker commands

And I'm having fun, this is great, the full-scm is a single binary, I don't need an environment, and is all versioned. I can rewind some things I did and restore old things. It's immensely useful for writing, fun for reading, and really concise.

If you are thinking on starting a personal wiki, I would strongly suggest you to consider Fossil-SCM, you won't regret it.

January 15, 2016

A new perspective

From time to time you get used to the environment you work with, you feel confident about what you do and you think that your approaches are kind of safe an standard.

That is something really naive for someone who is a developer, I have been/I am that person. During my first programming years I was exposed to Java and C++, these were the door-openers for my to the entire programming world.

I have set my expectations around the way these environments, and for a long time I thought that I was right in investing time and effort into making myself an expert on them. But then after a while, after some rough corners and rusted code I have thought to myself 'there must be a different way'.

And of course we have the Internet of things to ask for opinions, and that I did, and what a wonderful world I have found after that.

In my point of view, programming is much more like carpentry, there are tools to do the work, there are different kinds of wood, there are different kinds of furniture, and you can do many things with a different combinations.

As you might know carpenters have different styles and tools depending on how they learned to do their job, and I think of programming in a similar way, we do have really different ways to do things. And we should better know the most we can in order to make a decision.

So, to make it short, here are some programming languages that I would suggest you to learn (but learn, not just try, learn to the core by doing something with them):
  • Ruby: You will get a whole new mindset about programming and problem solving, it combines metadata-based programming, imperative programming and functional programming.
  • Go-lang: This is more than a language, is a whole environment that provides a practical and really simple programming experience.
  • Clojure: Still learning this, but is so much different to what I normally use that I'm really having my brain twisted backwards.

January 6, 2016

A strange path in development

During the time I've being a software developer there are many things that I noticed in my personal growth as a programmer, I can quickly list the following phases/periods:
  • Beginner: You do have notions for programming, but write awful code.
  • User: You start writting better code, you also see your previous mistakes.
  • Experienced: You know the ground, and you are comfortable with it.
And the interesting thing about these phases is that are technology/language/paradigm based. What I mean with this is that you cycle through these phases every time you learn something new (at least in programming, in my personal case).

First I learned structured programming, then object-oriented programming, then aspect-oriented programming, then functional-programming, then DCI. All of them in a different set of technologies and tools that completely changed what I thought I knew about programming. This is a learning pattern of mine that I know it works, every time I try to learn something new I know that these phases are going to be in the way.

I kind of know now how I learn, and I can do something about it. Now it's simpler to learn something new, and at the moment this new thing is LISP via Clojure, not sure what is gonna happen, but I can tell you that my brain is breaking old rules every week.

I think that's the message for this post, know how you learn, then kick the shit out of your brain.