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.

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..."

Ant and Maven, a brief comparison

I've been working for the last three years and during this period of time the projects I've been involved with have the same discussion:

which build tool should I use?...and the most common answers were...Ant and Maven

You can check some statistics to see which one is going to rule the market, honestly I think Ant will never leave.

But I must say that there's a very important difference between Ant and Maven, Ant is task-oriented with the possibility of handling project-related configurations. And Maven is project-oriented with the possibility of handling task-related configurations.

Considering that, I have these questions that might help you to decide between the right tool:

Maven

1. Do you need to keep standard project structures?
2. Do you want to avoid manual tasks/steps?
3. Do your projects have dependencies to another projects/libraries/frameworks?
4. Do you have a fairly good Internet connection?
5. Do you like to follow the Convention over configuration way?

Ant

1. Do your projects are very different one from another?
2. Do your projects have very different structures?
3. Do you customize your projects so they behave in a very specific way?
4. Do you already have a tight workspace structure that doesn't fit in the Maven world?
5. Do you need to have full control over what your projects do?

Some of these questions might be incorrect, but those are the ones coming to my head right now, so feel free to use them or not.

When you don't need a framework

I've been developing applications for a short time, from small to medium size codebases with many different features, requirements and environments. For all these applications I've always found the issue about the frameworks, sometimes this discussion takes days, or even weeks if the people involved is very passionate about Rails, Hibernate, JSF, CDI, and some others.

Mostly the discussions tend to be related to the benefits a framework can give us: speed, conventions, less coding, design improvements, being cool....

And for some projects the right frameworks have been a blessing, improving the developer experience and reducing development effort. But that's not always the case, because sometimes the frameworks can lead you to think that 'their' way to do it is the 'right' way.

'Their' way to do it can be 'right' for their intentions, but your application is not meant to be based on their intentions, but your customer ones. A framework should not define how your application is structured, how your business logic is wired, and not even how your tests are written.

I've always struggled with testing on a framework, because most of the times the requirements for its setup are so large, that makes you feel sick. And it's even worse if you are tied to certain technology because your customer has bought the 'sweetest' license in the market.

But well, here's my summary about frameworks:

Advantages

• Speed, not always, but a lot of frameworks are performance-oriented.
• Support, if it's open source, you will have a lot of it.
• DRY, yeah, you don't reinvent the wheel.
• Convention over configuration, very powerful, and saves lots of efforts.

Disadvantages

• With bad design decisions, you can marry your code with a framework, and that marriage is an ugly one
• Performance, as said, not all frameworks are performance-oriented.
• Test difficulty, you mean that I have to setup the entire framework stack in order to test a single operation?

When to use them

•  It's rare to find a reason not to use a framework, I would say that the question is not 'when to use a framework?', but 'how my application should be designed in order to be framework-agnostic?'.

When not to use them, or at least think twice before using them

• When its usage doesn't give you any advantages
• When you have a 'contractual' boundary with it
• When your team dislikes it
• When your tests take more than 10 seconds to setup its environment
• When the framework itself is untestable

Based on: Architecture, the lost years - Robert C. Martin

Liquibase: Database change management

When you are developing an application, is almost sure that you will have to deal with a relational database system. And if you are developing with a 'refactoring' point of view, your database structure will change from time to time.

In many situations these changes have to be tracked and automatically applied for the different environments (development, integration, production) and I bet you are currently doing that manually, updating scripts and wiping databases back and forth.

This is no longer the case for me, a while ago I started using DBUnit for managing my database data changes, but as the development moved forward, the database structure changed as well. So we started looking for a tool that could simplify our lives.

Guess where we found it, in the DBUnit FAQ page, they even recommend it!. The tool is Liquibase, a java-based application that uses XML changesets to handle the database modifications, it works smoothly and support almost all productive database systems. It might be a little bit hard in the beginning, but it is worth it.

Library management with Ivy

Back in the day, when I was a child, I used to manage all my project's libraries by hand, copying and moving everything I needed for a project into its respective folder.

I was happy with this for some time, but then I had to scale, handle several projects with a mixed set of dependencies. My original idea was to use a grown up tool like Maven, but its XML-hell led me out of it.

The alternative I chose is Apache Ivy, a dependency management tool that only does dependency management, and it's highly configurable (if you do it right).

In this way you can keep several projects linking a common libraries repository that is entirely handled by Ivy, you just configure it.

I recently updated some of my projects to this, the configuration files are quite simple and do all the work, including the Ivy-ant task installation if not available.

Ivy configurations for my Paginator-project

• build-ivy.xml
• ivy.xml
• ivysettings.xml
• metrics.xml

References

• http://www.beilers.com/2010/06/ivy-dependency-management-lessons-learned-and-ant-1-8-mapped-resources/
• http://blogs.steeplesoft.com/2008/01/dependency-management-with-ant-and-ivy/