November 1, 2017

Review: Weekly Experiment: Standing desk

After a week trying this new setup for working, here the results.

The rules:
  • During mornings sitting will be the default
  • During afternoons standing will be the default
  • During lunch-time standing will be the default

The control:

  • Did it have any physical effect? 
    • A big physical effect, the body feels better, although there were some small pains after the first days
  • Did it have any food/drink related effect?
    • Clearly, I consumed much less sugared drinks, not even coffee, and the body didn't ask for it.
  • Did it have any sleep-related effect?
    • Not sure if related to this single event, but I've been sleeping better.
  • Did it affect in any way productivity and awareness?
    • This was the biggest effect, procrastination decreased, interactions increased, awareness increase, hence productivity increased as well.
Result:  This is a must-do practice, I'm going to extend it to full work-days and not only in the afternoons, the effects have been so noticeable that I can't avoid feeling weird by sitting down.

October 24, 2017

Weekly Experiment: Standing desk

After listening to some interesting thoughts from Linda Rising at Software Engineering Radio, I've started a periodical experiment, time-boxed to a week in order to check results.

So this weeks is related to standing desk, not really a standing desk, but a platform that allows me to work while standing up.

The rules:
  • During mornings sitting will be the default 
  • During afternoons standing will be the default
  • During lunch-time standing will be the default
The control:
  • Did it have any physical effect? 
  • Did it have any food/drink related effect?
  • Did it have any sleep-related effect?
  • Did it affect in any way productivity and awareness?

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.

November 19, 2015

Going back

Hi there, for a while I've been out through several things that kept me busy enough, now that things are slowly gaining a pace I'll start writing again, for me, and for her:


May 26, 2015

Switching to VIM as main editor

During a normal day of work one gets into a lot of different tasks related to programming, documenting, writing, reading and so on.

Multiple formats are handled by our fingers each day, and multiple things are done over and over and over. One of these things is editing, editing has been for a long time for me, essential.

Editing text in different kind of files has had a lot of testing from my side, my requirements are quite simple:

  • Multiple encoding support
  • dos-to-unix and viceversa editing 
  • multi-window/panel split features
  • snippets
  • auto-completion
  • formatting
  • visualization
  • file-tree navigation
You might say, these things are simple and you can fill them up with TextMate, Notepad++ or an IDE, and perhaps you're right, but not in my context.

My context is development, of different kinds and different programming languages, so here you have some considerations/notes/remarks for the editors I've used:
  • IDEs: these are great, fully integrated, but I'm not always with the possibility to delegate 1GB of memory just to edit a simple  YAML file.
  • High-end editors: Such as TextMate, SublimeText and others. I have used them, and I have been pleased with their simplicity and user-interface. But sadly it doesn't satisfy my mental model since from time to time I have to work over an SSH connection with scripts.
  • Emacs and derivatives:  I love Emacs, and I love JED, but sadly such environments need (from my point of view) lots of effort to configure, setup, and even to keep it working for in a productive way for my needs. I use them from time to time, but they're not my first choice.

So finally, I tried VIM, it's a great tool, I cannot say if it's better than Emacs or others, but one thing I can say, it has a great community, the Ruby and Open Source communities in general have chosen VIM and made a damn excellent environment out of it, this was not the case 5 years ago, things like:
And others make it my first choice right now, it's kind of confusing at time to get the edition modes, but once switching for some hours it gets natural, VIM is not only an editor, is a powerful edition environment that works really well, and it's mainly because of the community behind it. 

Got give it a try, or try Emacs, but as I was told by others, define your needs and pick the tool that applies to your context.

December 11, 2014

On the sometimes painful email-delivery process

Email is not dead, is not even a zombie. If something is well alive and working in all areas I can think of; given that, many of not all applications have to know how to (at least) send mails properly to all the different SMTP servers and providers there are.

Now in my current job we deal mainly with Java-based projects in which JavaMail is the major, sometimes we deal with legacy systems with old implementations, sometimes we deal with new projects that have to communicate to old SMTP servers.

In either case, the problem is how to do it, how to ensure that a mail is sent once the application you are working on is ready and running.

Among the many approaches we've tried there are mainly two issues than come from time to time:

  • How do I communicate with this particular SMTP server?
  • What's the best way to implement this functionality in my application?
Both questions can be easily answered now with little effort, but in some cases we have to dig deeper. This is my approach to answer these questions:

  • How do I communicate with this particular SMTP server?
    • Use tools, check with telnet, use a command-line application like mailsender (I wrote it ;-)) to see which setup works with your SMTP server.
    • Use a local and simple SMTP server to test with, something like MailCatcher.
  • What's the best way to implement this functionality in my application?
    • Take what is working, no matter how old it is, it's being tested and used in many environments and works as customers expect it.

September 15, 2014

Top ten shell commands for daily use

As software writers, we spend much time reading code, writing code, browsing it, searching things on it, breaking it, fixing it, etc. All for the sake of a good behavior in a component/module we try to build.

During this process there are several opportunities in which you need something, a tool, that helps you find and do things quickly, and perhaps an IDE is an overkill when you have several things opened. So there's the shell, and with it, a lot of applications.

Normally these are the tools I most use during my daily work:
  • find - Whenever you wanna search files by name and many other options, it's mandatory.
                     $> # I'm trying to get all build reports from the projects
                     $> find /opt/projects -iname *report.html 
  • grep - Excellent tool to search patterns and strings within files
                      $> # what if want to check for all logs containing the ERROR level?
                     4> grep -nHr --include="*.log" "ERROR" /opt/servers/logs/
  • tmux - Multiple SSH connections are not a problem anymore, just install tmux and create sessions within a single SSH connection.

  • tar - Mandatory tool for packaging and compressing data
                      $> tar cvfz db_dumps.tar.gz *.sql
  • watch - Lets you execute a command or script within a defined interval, helpful for monitoring things
                      $> watch -n 10 "du -hs /opt/packages"
  • xargs - Pipelines!!, who doesn't use them!? with this utility you can easily pass output data to another application
                      $> # delete all my missing files from the repo
                      $> hg missing | xargs hg rm
  • jed - Must have a simple shell editor, I prefer jed over all of them.
  • ssh - Server connections are a must have when deploying applications, learn how to use it.
  • scp - Copy files through an SSH connection without problems.
  • wget - Get those HTTP files easily, use wget.

September 10, 2014

This is where I work

Disclaimer: Draft from a long time ago.

Back in December of 2009 I was preparing my thesis work for my graduation, and somehow a very funny guy called me saying that we have talked a while ago about a job offer in a software development company.

At the beginning I was thrilled, I hadn't worked in a professional way by that moment, I couldn't talk nor understand English properly and I was very insecure about my skills against the European standards.

But then I found out something, these guys were really interested in personal values above all, they might need skillful people, but it wasn't (and I dare to say it still isn't) the most important thing.

We were a very small group, now a little bit larger, doing things I found challenging. There are several goals I have set for me in this workplace, I like working there, I enjoy the work I'm doing and the people whom I working with.

Perhaps you want to take a look at the website to know the company a little bit ;-)