September 16, 2012

Domain driven semantics

If you are a programmer, you have dealt with persistence layers in many senses:

And if you are a programmer, you know that all those persistence layers have to be abstracted from the application's business logic. There are several techniques to achieve this:
All those techniques wrap your data from the persistence source you are using, because your application should have its own 'language'.

Why?

Because each application is meant to solve a specific problem (or a set of problems), and that problem has a domain, and that domain will be used as basis during the development/maintenance phases. During these phases you might have different people working with the same code. So, the developers will need to understand what they are modifying in order to add/remove/fix specific parts of the system.

This is the point where documentation and comments become important, I also take a deep look at the context applied to the programming, I mean, class names, attribute identifiers, method names, etc.

All these things give the source code a meaning, what can you say from this?


and what about this?


which one is more verbose? which one has more meaning? which one would you prefer to have in your source code?

Even though the first chunk of code uses JPA, it is verbose enough, the second one really does its job, you don't need to know whether you are using a database or not and it is really easy to read, if you want to modify a condition or change the behavior you just go to the specific method, and that's it! 

September 9, 2012

User-safe system configurations



As a developer and Linux-user, I continuously change several configurations in my systems, some of the changes can include:
  • Port-based services: When you have several web servers working on the same machine, you have to configure ports and alias addresses.
  • Package sources: I just don't want to mess my apt-get and slapt-get sources configuration.
  • Security: External services configuration, security configurations and system restrictions.
  • Run levels: I like to have the services I use at system startup, the other ones can burn in hell...
  • Networks: I have some static configurations for some environments.
  • X11: For some custom modifications I made for several displays.
  • Databases: Sources, ports, users and some other configurations.
  • Cron: Some backup and maintenance jobs.
  • Revision control systems: Common filters, aliases, etc.
As you see, there are several configurations on my system, and I don't like to change them when a package gets updated, or when I upgrade my system. My usual alternative was to keep an .orig file for everything I was going to modify, but that didn't work very well, since I modified those files several times.

Because of the situation, I needed these things:
  1. Keep snapshots of my configuration files.
  2. Rollback changes.
  3. Restore old configurations.
  4. Check which files/lines where changed.
  5. Use it all from the shell.
So, long story short, I needed a Revision Control System. And as I needed it just my local machines, I reduced my choice to Git and Mercurial.

My choice? Git, it is obvious that its shell interfaces are superior compared with Mercurial, it's very well integrated with all UNIXes and I have been working with it for a long time.

So, whenever I want to check if a configuration has been changed:

#> git status

What about reverting a change?

#> git reset -HEAD

And if I want to restore it to its initial version?

#>git reset

I just modified a bunch of files, save a snapshot of them:

#> git ls-files --modified | xargs git add
#> git commit -m "Too much work and no fun makes Jack a dull boy..."