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:

• Janus distribution: Great default-environment setup with lots of goodies.
• Vim awesome: The place to check plugins and extensions.
• VimCasts: Great learning resource.

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.

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.

Weekly log - August - week 1

This week has been very entertaining due to the huge amount of issues I had to dealt with, here a short summary:

• I learned about the evilness about Global State, had to fix several issues related to it.
• I got very interested (yet again) in the Dependency Inversion Principle and finally understood it.
• Started working on a very interesting project regarding a bunch of new technologies and concepts that are really exciting, some of them are REST, Maven, Spring, Scala and AOP.
• Watched this great lecture on Biology provided by UCBerkeley.
• Got more and more interested in Ruby with Sinatra.
• I learn about the difference between Leadership and Authoritarianism.
• Scala seems to be the way to go beyond Java, I really like its nature and it's been defined.
• Learned about real Object-Oriented development with DCI in Practice.

Is not about the tool

Over and over I keep listening and reading in software development forums about certain types of questions:

• What is the best tool to do ?
• What is the perfect IDE for ?
• What can I use for modelling in ?

I know this because I started with those questions as well when I started a few years ago, but when dealing with different things during my short experience I have learned that the answers were never going to be enough, because the questions never were the correct ones in first place.

Let me explain that, the questions I (and some other developer folks) was asking during those initial years in my experience could be translated to other contexts in this way:

• What is the best hummer to build a chair?
• What is the best brand for office furniture?
• What pencil can I use to draw amazing designs?

If you can read them well, you can understand how lame they are. I should have focused first in the concepts that enable those tools to be useful. The tools are just the medium to build something, the major part of the problem is to identify and understand what to build first.

Of course is very useful (and mandatory) to know about the tools, but the effort should be directed to understand how thinks do and should work. That's the reason why the Business Analyst title is so hot at the moment, we as developers have sent the system's business to the background of things, that's my advice, focus on the concepts, business and things that have value, the tools will come eventually.    

ATIX Libre - segundo artículo publicado

Tarde pero seguro, he reducido la frecuencia de publicaciones debido a mi pésima administración de tiempo, pero que hacer, solo yo puedo cambiar eso :-)

 Sin mas preámbulos, he aquí la segunda parte de los artículos que he venido escribiendo sobre este interesante framework para desarrollo web en entornos Java, Play! Web Framework.

Why I dislike the term 'Agile/Software/Practices Evangelist'

As software developers we often see these kind of adjectives on someone's profile, normally on LinkedIn or some resumes you get from time to time. I dislike this term, not because of the history behind it nor the intention it tries to give, but because of its meaning:

"the practice of relaying information about a particular set of beliefs to others with the object of conversion" - Wikipedia

The problem raises with the word 'beliefs', when working on systems and organizations, you shouldn't rely on beliefs, beliefs can or can't have proofs. You should rely in things that have a background or some basis that you can use in an argument.

If you are, let's say, an Agile Evangelist, you've already lost me. Because you described that you do what you do not because it is the best way you found of doing it, it is just because you believe it might be.

We, as people who work building reliable systems, should be careful about using something that doesn't have a valid argument beyond a belief, we should be able to say 'We chose this process because it has proven to be at least 50% more efficient'.

Argue about what you do, be critic of what you use, think and analyze, don't follow fashion, follow ideas with sustainable arguments.

Domain driven semantics

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

• RDBMS systems
• File systems
• Remote storage
• Just memory...

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:

• Data Access Objects
• Mappers
• Object Relational Mapping
• CQRS pattern

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! 

Development tips

I've worked in some projects so far and I learned some things that can save you a lot of time even if they sound very expensive. These tips are meant for small/medium size projects, perhaps you can apply them to big projects, but I'm not sure.

1. Revision control system from the beginning.
2. Define your goals and milestones, even without dates.
3. Define what you are going to build, with use cases or user stories, or just use whatever you feel comfortable with.
4. Define an architecture, don't go on without this. The architecture must define the form of the system, not the details.
5. Define the contexts you are going to be working on, this means that you have to separate your project into smaller micro-projects (if it applies).
6. Define your frameworks/libraries stack.
7. Define your project(s) structure, this involves folders and files.
8. Define your automated build scripts, something like Gradle would do it.
9. Think in the tests before the implementation, if it's testable, it's implementable.
10. Use continuous integration from the beginning.
11. Keep you source files small and readable.
12. Periodically check your system and update the architecture if some changes have been made.

I omitted several things, but I consider these the most important from a developer's perspective.

I didn't have this information at the beginning because I was too lazy to read about it, and had to learn it the hard way, by suffering the consequences...

My first component uploaded to Maven Central

A few years ago I gathered this pagination component logic from a co-worker and changed it a little bit, adding some desirable functionality and reducing some external dependencies.

I've used in several projects, web-oriented and desktop-based and it accomplishes its works, pagination.

Today I spent a couple of hours configuring it for Maven Central, just to check if I could do it.

So, here it is, my first component published on Maven Central that can be used if you want to. I really like it and I encourage anybody to check it, review it, criticize it and trash it.

• Project page on github
• Base code author - Rory Sandoval

Ruby disappointment

I have been trying to port some work I've done in Java to Ruby, to see how it looks and how much code it would take. But in the way I found out that Ruby might not be the best option for this kind of situations.

Let me explain it, this is my pseudo code:



As you can see, the OrderSet has a collection of Order classes, but classes!! Not instances, because in the real application I will have hundred of Orders and I don't want to instantiate a new object for each one of them.

So to keep the memory load very low I handle classes, in that way I can control them, instantiate them and destroy them as much as I want.

Now, I tried to write it in Ruby, but I found out that there's no easy way to add metadata at a class level!!
The closest approach to it that I could find is instance-oriented. I would need a new instance of every Order to make it work....sad.

• Annotations simulation in Ruby

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

Binary tree implementation on Ruby

I was having fun comparing the code I did in my early programming attempts in Java, and thought about how much would it take to rewrite it now, but in Ruby.

As an initial attempt, I took the widely known Binary tree, I started with the test cases and then implemented the code for them, here's the result.


I can say that it took at least ~50% less effort compared to the Java implementation, and it looks good :-)

Plan de administración de proyectos: Farmacia

Ultimamente no he publicado nada en mi idioma nativo, pero creo que ahora voy a empezar una ensalada de posts incluyendo todos los idiomas de mi preferencia :-)

En este post comparto un documento elaborado para un curso de maestría en Ingeniería del Software, no es tal vez mi mejor trabajo ni tampoco estoy de acuerdo con muchos de los elementos usados:

• Diagramas de Gantt ( algun dia morirán, ojalá ).
• Diagramas de Euler (deben ser mutilados junto al anterior)
• Plan de aversión.
• Estimaciones sobre la completitud del proyecto (nunca se cumple).

No es mi intención decir que estos documentos son inútiles, pero en mi corta experiencia he tenido mejores resultados con Extreme Programming y las metodologías/frameworks de desarrollo ágil.

Jogging for fun

As a software developer and avid reader, I tend to spend a lot of time sitting or laying down in a bed. And this is normal for my life, I would say that at least 10 hours in my normal day are based literally on my ass.

When I started working I noticed this, and I knew I had to do something to keep my body as trained as my hands and brain were. So I decided to go back to an old costume I adopted while I was writing my thesis... jogging.

Jogging is a very simple discipline where you set a target destination and run at a certain pace, fast enough to not be walking, slow enough to keep your stamina.

The benefits

These are personal facts, that might not apply to everybody:

• Relaxation, it keeps you away from your daily problems for some hours, clearing your thoughts and mind.
• Concentration, well... you need it, you have to control your legs, your breath, and your speed while checking what's in your way.
• Fitness, it keeps your middle-body in a good shape, if you do it regularly.
• Discipline, you need a lot of will to jog when it's raining, when it's cold, when it's hot. 

How much?

After some years of irregular practice, I have set my jogging sessions to 30-45 minutes, it could be longer, but definitively not shorter.

What about the speed?

It depends completely on you, when I haven't done anything for a while I have to recover the muscles and pace I start slowly and then increase the speed day by day. As a metric, use your breath, if you get too tired or just too agitated, you might need to slow it down.

How to keep it interesting?

It could get bored, specially if you follow the same route for several days in a row. What I enjoy doing is listening to some podcasts while running, or perhaps some music. For this situation a portable iPod is the best choice.

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.

Supporting short lived objects

While working on some projects with different environments and behaviors, I started liking the notion of short-lived objects. Besides, I read a lot in several threads from StackOverflow > http://stackoverflow.com/questions/631919/short-lived-objects.

I like this kind of objects because they are easy to control, debug, update, delete. The notion of having an long living object is state, but to keep that state among several instances and requests can be a real hell if you don't control it properly.

And as you may guess, concurrency is one of the things I don't like to deal with, I prefer to leave it to a framework or third-party concurrency manager.

Benefits:

• Easy to control
• Easy to code
• Easy to test
• Challenges your design skills
• Avoids singleton all over the place
• It enhances performance 

Drawbacks:

• If you don't control them, you can have an big object pool
• You have to take care of references and garbage collection
• If your design is bad, your objects will be bad as well.

Semantics and programming

After using the Play framework for a while, and reading several good articles, I started using some of the concepts that have been around the cloud for some time.

One of them took my attention, the one claiming:

"Never use strings in Java"

Initially I found this really stupid, how can you program without strings?

But after applying the concept for some months, it has showed me how wrong I was. Once you start coding with Objects, you are giving your operations a semantic meaning. This means that you can say by checking an operation identifier what it really does.

It also simplifies the API definition, because the object talk by themselves. You will not be able to pass a null string as a parameter, instead you will create a class wrapping it, then the wrapper class is in charge of checking if the data you are using is valid.

As I'm still digging into it, more posts will be written about the topic. Just as a suggestion, please take a look at it.

Resources:

• never-never-never-use-string-in-java-or-at-least-less-often
• New programming style

Software Architecture, lessons learned

There are very good developers, that can create great products out of nowhere without thinking too much. Well, I'm not one of those, it takes me a while to get the right idea, and several times I had to throw everything I've bee working on and start from scratch.

But even in situations like these, there are some things you learn from time to time.

Minimalism

This is something I learned from Robert Martin's Clean Code (but I think it just takes common sense). When your components are not meaningful and don't relate to each other in an almost 'natural' way, you need to refactor it. Your system might work beautifully, but your internal structure is a mess and it will create problems to future maintainers.

Keep it simple

Complex design leads to complex code, complex code leads to complex tests, and the mess has now started. The design has to be as simplest as possible, and your code has to be consequent to this. And by code I mean production code and the test units related, because that it's maintainable code too!. Check KISS Principle on Wikipedia.
 

Life time

System components and inner objects must follow the natural law, die. While shorter your objects live the better, are easier to handle, to test, and to refactor. Including memory usage improvements, as your objects are created and dropped as soon as they are used. This is something I find very useful, and I discovered by playing around with Google's Guice project.

Patterns

Check the patterns once a while, review your architecture, don't reinvent the wheel. There are several good references for it, but I tend to enjoy Martin Fowler's patterns (and the articles describing them). Have a look at the LMAX architecture.

Test Driven Development: Small tutorial

Some weeks ago I did a TDD presentation and for that matter I prepared a small tutorial of how to do it.
Details

1. I used Robert Martin's approach to TDD.
2. The example idea was taken from James Shore.
3. The QueryString(built in the tutorial) component is a simple HTTP parameters parser.

Http Parameters format: http://myhos.org/test?param1=value1&param2=value2

• HttpParser on github
• QueryStringTest.java

SE books you must read: Effective Java

Although this book is kind of old, is still valid. All its concepts and best practices are still being used and its author is an authority in the development world > Joshua Bloch.

This was the first book I read when I got into professional development, and believe when I say that is one of the mandatory books to read if you want to write something functional in Java.

Effective Java at Amazon

PS: I would like to share the ebook version of it, but I'm not sure about the licensing/copying policies.