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

https://www.infoq.com/interviews/coplien-dci-architecture

Coplien: Another great interview

http://devnology.nl/podcasts/devnology-podcast-020-james-coplien-on-lean-architecture

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.

History

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
snapshot

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:

Emilia

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 ;-)

June 21, 2014

Simple editing with JED

A while ago when I was giving Slackware Linux the first tries I came across this tiny, very functional and very powerful text editor, JED.



JED is a minimalistic text editor for the shell that emulates Emacs in most of its useful functionality, is not as powerful as Emacs itself but it has just enough for me.

  • Syntax highlighting 
  • Key bindings
  • Buffers for edition
  • Contextual shell menus
  • Very lightweight 
  • And some other features
It might not be an IDE, but it's my favorite tool for editing text via SSH, or when I'm doing something small and I just want to do it as fast as I can. 

Give it a try, hopefully you will find it useful.

References

On Conventions

A while ago I listened about Ruby on Rails on a podcast (FLOSS Weekly-episode), in that conversation I heard many of the concepts that later on I would find in books, frameworks and projects.

But among all design decisions mentioned there, Convention Over Configuration was the one that triggered something in my head.

In a short summary COC is a principle that describe a work approach in which most decisions in are defined by conventions and not by manual setups, such as URL-mapping in a web application, see Rails RESTFul URLs.

Under my personal context (mainly Java and JVM-based development) over the years this trend has been used more and more, and I couldn't agree more. Frameworks are the main target for this, things like JEE-6/7, ORMs like Hibernate and Dependency Injection frameworks like Spring must define a 'default' way to work.

Although it is really useful to have more than one alternative to do something, it becomes really hard to start with any of those frameworks. The greatest advantage (in my opinion) of some of the more trending frameworks like Rails or Django is the learning curve, very easy to learn, very easy to start, very easy to be productive.

JEE in all its flavors and Hibernate are not the case for it (in my opinion), there is no standard nor default way of doing things. And because of that a big part of the development community has migrated to another option. It is very important for us as developers to be consistent, and the change has to start on the framework-makers, and JEE must be the starting point since there are so many applications based on it.

So, how would JEE become a better alternative?:
  • Define a default build tool and stick with it
  • Define proper libraries in the repositories, no more broken APIs
  • Create a non-extensive guide with the basics to do a web application
  • Define a default open source deployment server
  • Provide a default architecture such as MVC

Some progress on it has been achieved with Maven archetypes and things like AppFuse, but I think we are still a little behind Rails in that matter, although, it's improving.