December 28, 2012

My father was a professional - part 2

Sequel from My father was a professional - part 1

Things I'm ashamed I didn't learned from him

Even though I knew my father was really skillful in almost any kind of job, I learned very few things from his craftsmanship. He was a great mechanic, but I didn't learn anything related to cars from him (I'm still very ignorant in that subject). He was a great electrician, I learned some stuff of that from him, but I dare to say ...not enough.

Besides the technical skills I could have gotten during my childhood there were other things he did that I just realized were really productive and he did them without having read anything, he just realized it by himself:

  • Pomodoro, my father worked in that style during his entire life, measuring everything while working on it.
  • Design by Components, I'm making an analogy here with the technique used to design components, but he did it. I now see it clearly when he was working in several iron-related jobs, while he worked with other people he always knew what to expect from them and viceversa.
  • Agile, indeed he was agile, he adapted and progressed as soon as changes came, and they were quite a lot during his working hours.
I could list many more but mainly those are the things I can recognize now (a part 3 opening?). There are lots of things my father did write and did wrong, many things that have taught me not to concentrate too much in some things and leave others behind.

Even though my father was a great technician, he wasn't the best salesman. He built wonderful structures and products, but sadly that's not the only thing you need to sell a product. He failed in that for many years and when he finally realized how things should have been done, he ran out of time. 

Sadly for him his work depended on his body, his eyes, and mostly his hands. Health was never in my father's side, during his entire life he fell over and over sick and got involved in several accidents that reduced his capabilities as a craftsman, and the age didn't help neither.

As he became old we all knew he was an expert, but teaching or mentoring was not the best of his skills. He lived to be a great worker and leader, but when the time came and he needed to move to some other thing, he was blocked by his peers because he didn't have a degree or some paper to 'certify' that he really knew what everybody claimed. It's a shame to live in a society where papers and certifications are more valuable than empirical experience, where families and friends can make more than real skills and knowledge. Where it is more valuable to have influences than being the best at your work.

That's what I'm trying to avoid, if some papers and certifications are required, perfect, I'm gonna get them. I can get knowledge, I know that. I like to be an apprentice, to learn, but I also like to apply what I learned, that's why I would never look for a scholarship that bans me from working while studying, if it's not applicable it doesn't have value. Make whatever you do valuable, don't waste too much of your time.

Those are some lessons I learned from my father's life, I hope to be as good as he was, but the trip is long :-)

December 8, 2012

Coding journal - Scala's Hello world

I'm learning Scala as part of my masters thesis and every day I find something new that gets me more and more interested about this language.

As I'm a technical guy I enjoy seeing things working, so hands down on the keyboard. Obviously the first attempt I do for any programming language is the classic Hello World.



They both compile to Java bytecode and work exactly the same, but I have to add some remarks on the few code I wrote:
  • There are no static things in Scala, they've been replaced by Singleton objects.
  • No semicolons, even though they are optional, it's kind of verbose.
  • I'm passing a function as a parameter, wow, that's powerful and much less verbose.
  • Those loops are awesome....
  • Much, but much less verbose.
In summary, with this stupid code I've seen how powerful can Scala be without having to give up all the knowledge I have about Java, its compatible and they can coexist together.

So, give it a try...

November 27, 2012

LaTeX templates

Have you ever written a thesis document or an ACM-article using a WYSIWYG word processor?

If you are very experienced and use a single platform you might have done it several times, but when dealing with documents that have to consistent, self-corrected, dynamic and exported to different formats, word processors are a pain...

I'm not talking from a newbie-point-of-view, I've seen it, try it and realized that it is not worthy. Everything started when I became the Spanish translator for the Slackbasics book/guide, they had the following environment:

  • SGML-Docbook for contents
  • Chapters organized into separated files
  • Output formats are mainly HTML and PDF
  • The project is built in order to generate the output formats via Make.
At the beginning it was really hard for me to understand why they chose this way of working, but after some modifications and some collaboration with other editors it was clear that there's nothing better than plain text to write documentation, leave the styling, formatting and layouts aside, focus on the content.

I finished that translation and now is publicly available. But now I started writing my Masters thesis for the University and the nightmares of MS-Word problems I had two years ago came back to me.

Shall I use a WYSIWYG editor again for a thesis?.... nevermore...



So, long story short, I've found that LaTeX suites most of my needs and it's simple once you get the basics. In order to put it in the format my University (Universidad Autónoma Gabriel René Moreno) has, I created two base documents:
They are not both really 'templates', but example documents. It's handy when you want to start again and don't want to mess with the same problems over and over, and because of that I know I'm gonna use them over and over.

October 29, 2012

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.

October 28, 2012

My father was a professional - part 1

I recently spent some time at my hometown checking some old pictures and notebooks I've got from my childhood, and then spent some time thinking about all my father did for a living, for us, and for all the people around him during his life time. This is a short story of what I know about him that makes me declare that he was an engineer, in the best meaning of the word.


His childhood

First of all a little bit of background, his father was an empirical-mechanic that fought in the war, his mother a school teacher. During his childhood he had to work in order to help his family, so he used to make toys with empty cans: cars, dolls, tools, figures, etc.

Then sold that stuff or trade it for some groceries. During these years worked with his father fixing cars or doing maintenance, you have to understand that cars back didn't come with a manual, books were not accessible and knowledge about mechanics was almost impossible to get.

So he learned on his own, by inspecting, analyzing, figuring out about all the components and how they fit in this system. He learned a lot during this period and created a reputation around him, he could fix things that no one else could, and learned fast about new things.

Teenage years

While still working and studying, he started buying manuals and equipment from stores far away his town, everything by mail, making himself the only person able to get parts and also the only one capable of assemble them.

University

Eventually, he made it to the university, with the little resources he could save while he was working registered in one of the best universities in Bolivia, but his trip only lasted a few months since a military dictatorship closed all universities that were not complaining with their 'patriotic' vision.

Then came back to his town and got the chance to go study in a different country, but sadly he couldn't finish that course because he had to return to help his family, because his father fell into alcoholism and there was no point on trusting him any kind of job or money.

He came back and bought the equipment for a complete workshop, the first one in town. Then managed to avoid taxes on the equipment by making it look old or by splitting it into parts. And I'm talking about big machines, as they were in those days (60-70s in South America).

Professional career

Once in home, started working with his brother in the workshop, working with lots of people and doing everything on his own. He managed the budget, schedules, resources and planning. Planned everything and had a notebook registering all he did and how much he spent doing it, when something went wrong or outside the plan, he planned it again, updating the original plan according to the current scenario.

Among the things he did, these are ones I remember:

  • Adapted a car for a disabled men (his legs didn't work), so he could use only the wheel and the gear shift stick to accelerate, slow down, switch gears.
  • Designed and installed the electrical installation for his shop, as he needed different voltages for the machinery, and the electrical company didn't know how to do it, he did by himself.
  • Built all the infrastructure for a car washing shop, this structures needed to support a lot of weight and be generic enough in order to support several kind of cars.
  • Built his own sewer system, using reserve pools in order to improve water's use.
  • Designed a pressure-based water system for the car wash shop (using Bernoulli's principle), so he could use very few energy in order to make the water flow through a hose.
  • Created his own door-security system, not a big thing, but it managed to keep the doors closed in even with the strongest winds blowing.
  • Built a small car for us using and old washing machine, pretty cool.
  • Built a car for the family using parts of broken cars, pretty cool also.
  • Learned armory on his own, and fixed weapons for the military men that once tried to arrest him.
  • Adapted race cars, this was huge, because all racing cars were always in his garage, pretty cool.
  • There are more things....I'll be listing them in the future....

Practices I've learned from him

My father was very good in empirical situations, he knew a lot, and if he didn't know, he was really quick in learning. These are some things he did I really appreciate:

  • Planned everything, and kept planning if anything changed.
  • Made a budget for everything, scheduling everything based on the real time he needed.
  • Was truly honest about his work and progress, this didn't always was well taken.
  • Never worked overtime, he kept this discipline until his dead.
  • Treated his coworkers and employees with respect, and payed a fair salary, even when this meant that he wouldn't get any income.
  • Taught his workers, shared knowledge.
  • Checked for prior art about anything he involved into.
  • Kept his workplace always clean and ordered.

Things he did I disliked, or things he didn't do at all but should have

Even though I loved my father, he had some things that neither I nor my family liked that much.

  • He was hot-tempered when he failed.
  • He didn't like to read anything that wasn't technical.
  • If something went wrong, it took a while for him to recognize a mistake.
  • He made things for his coworkers if he knew that it will take them longer to do.
  • He avoided discussions and because of that, lost lots of deals.

Things I'm ashamed I didn't learned from him

This will come on part 2 (including my justification about the title)....

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

August 22, 2012

Create a JPA EntityManager programmatically

I've been using this kind of PersistenceUnit creation for some unit tests, because they had to run along with some integration tests, and because of that the persistence.xml files were messing between them.

So, how to create an EntityManager programmatically?

  • Solution link: http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html/configuration.html

August 5, 2012

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

July 12, 2012

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.

July 9, 2012

Projects worth looking at

For a while I've been reading about the term Software Archeology from different media channels and I find it very valuable. Especially if you are trying to do something interesting with your projects, in those cases is a very good idea to checkout some very well written applications.



Rails
If you want to see what Ruby can do, this is the project I recommend. It has several gems in it, including a very complete documentation.

Guava
Google has released several open source projects with high quality code and lots of functionality, this set of libraries are great tools when dealing with real-life applications.

Guice
A great CDI component that simplifies Spring into fine grained components that are extremely extensible. I use it whenever I can and it's really, but really cool.

Fitnesse
This is perhaps the application with more test coverage I've ever seen, a serious attempt to reduce the gap between user acceptance tests and testers.

You might have noticed that most of them are written in Java, I didn't have time to check some other languages, but for sure Scala and Clojure are my next target.

References

June 23, 2012

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.

June 15, 2012

Scrum basics

A short presentation I gave about Scrum, I've taken a lot of material from Jurgen Appelo's presentation.


June 14, 2012

Just for the joy of writting it down

I must admit that I'm being sleeping for a while, in my personal life, in my career and left behind the goals that inspired me just a year ago.



But some things changed during the last two months, I started doing things that changed my life. Small things that I thought were lame and not worth doing, here is a list of them:
  • I got high rates on my masters degree when I started losing interest on it.
  • Improved my jogging-resistance to 40 minutes just by practicing 3 times a week.
  • Solved very difficult (difficult for me) software-related problems at work, things that I never imagined that I could do.
  • Recover my reading-habit.
  • Found the way to drink enough not to get a killing-hangover, and also started enjoying these gathering events more and more.
  • Improved my personal relationships at all levels :-D
And many other things that are just too lame to list...seriously. But after all I'm just doing what I used to do back in 2009, somehow I got lost in the way without even noticing it. I got too much comfortable with my situation, I couldn't think on getting my life to that frenetic pace again.

But I was wrong, that frenetic pace kept me awake and living, I think now I recovered that energy that I always had.

I will try to do the best I can with my life, I will make mistakes and be a total fool sometimes, but I'll learn from it. Because that's the only thing I'm sure I'm capable of...learning.

I still have tons of things to do, to improve, to correct. So much things that I just started wrapping my mind around them, so expect more activity from now on.

May 23, 2012

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.

May 15, 2012

Generic actions model

Have you ever tried to install something in a Linux distribution and have struggled with a dependency manager? such as DEB, RPM, PACMAN?

Dependency graph


I have a love/hate relationship with these models, sometimes they save my day, but some others are really, but really hard to deal with.

In software development you will find such scenarios, where you have something to do, and that thing will require another thing... and so on.

I mapped this model about a generic rule-dependency model:


  • Action: Component doing some kind of work. All the dependencies are one-side oriente, and each dependency can have many other dependencies.
  • ActionsRepository: A collection of sorted actions by any kind of criteria. Normally not allowing duplicated actions.
  • ActionsExecutor: Component in charge of iterate and execute the actions.

May 12, 2012

TDD helps you find the way...when you are lost

There are times when you start a project, and you understand exactly what it has to do, you know the inputs, and the outputs. You might know even some of the inner logic in between, but you can't get your head around it.

That is, not to know how to do it. Not to know where to start from and where you are targeting to. This problem arises almost always you are dealing with something new, something you have never done before and perhaps have ever seen.

That's been the case for me in some projects I've worked on, some times it took me a while to get the right idea, after hours/days/weeks struggling with the logic and the results verification.

In my first days, I would do the verifications by hand, a tedious process where I would reply all the steps in order to verify that everything is working as expected. If something got broken, I would fix it and then start the tedious process again.

This was painful, and exhausting, that loop trapped me for months. I thought that someone else would have found a way to get this done without that much effort. Then I started reading about testing techniques, leading to best practices, disciplines....a hole world of professionalism and engineering is out there, you just have to seek it.

The concept that fit for my problems was TDD, it applied for the situations I experienced and its scope is what I was looking for, the cycle looks like this:



with automated tests and frameworks, and the most important....you know that you are done when you can't think on more tests to write!!!

I strongly suggest you to give it a try, it's a discipline that will make you a better, more responsible developer, and also will provide you a way of building targeted products in a safe way.

April 15, 2012

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

April 10, 2012

SE books you must read: Agile Principles, Patterns, and Practices in C#

As a disclaimer, I'm a Java developer, but this book can't be left aside. If you are a follower of the Clean Code movement this is the right book for you. Perhaps the most 'engineer-oriented' book written by Robert C. Martin and Micah Martin.

It covers several concepts about agile development, design patterns, programming, anti-patterns and some code katas to have fun with.


[ Agile Principles, Patterns, and Practices in C# ]

April 3, 2012

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.


March 30, 2012

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.

March 6, 2012

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.

March 2, 2012

Dead code evilness

Working on several projects at the same time is really exciting, you have to administer your time-sheet between tasks and work with different people. Hence the diversity, different technologies and environments.
But there is something common between all those projects, dead code. Dead code can be classified in some few categories:
  • Legacy code.
  • Refactoring-result code.
  • Patches.
It's really frustrating for someone during development to see some code like this:


  • What does the '0' mean?
  • Why is the first line still present there as commented code?
  • Is it really important to have it there?
  • Should I remove it?
  • What about the other parameters?
  • Why it was commented in first place?
  This can lead you to several problems if you don't know how to answer these questions. But then again, why would you? Wouldn't be better to have something like this?:



If it's dead code, I mean, it's already dead, it should be removed for the sake of other developers. If you are working with Revision Control Systems (and I don't know why you shouldn't), the commented code is not longer required, you can revert or reapply a patch whenever you want.

In summary, get rid of your dead code, kill it, burn it, bury it. 


January 31, 2012

Exercise: Sieve of Eratosthenes

After reading an interesting blog post from Robert Martin I started writing this nice algorithm in Ruby (I'm still learning it).

As I'm a refactoring freak, here's the first version:

Nasty right? Then the cleaned up release:

January 28, 2012

El fin de una epoca

Un poco nostálgico para estos dias, pero me parece correcto definir este día como importante con respecto a mi vida. A pesar de que no soy una persona religiosa ni teológica, me he visto afectado por esta noticia:

Ciertamente era una persona apreciada por mucha gente (no por mi persona) y sus palabras influenciaron a miles de personas alrededor del mundo. No es mi intención hacer apología de su trabajo, solamente quiero recalcar que su vida afectó la mía. Que su trabajo de alguna forma me hizo ser lo que hoy soy.

A pesar de que su programa me aborrecía y de que sus mensajes me parecían inútiles, marcaron una etapa imborrable de mi crecimiento.

Junto con el se van muchas otras personas que afectaron mi vida de alguna forma y de seguro la de muchos mas.

January 24, 2012

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.

January 19, 2012

Fossil SCM

A few months ago I listened to FLOSS Weekly's episode about SQLite, and I wondered how this wonderful project was being managed.

After checking for a while, I found that D. Richard Hipp has developed his own distributed SCM based on the very reliable SQLite.


In a comparison with Git and Hg (which I have used), it is more than a SCM, it is a whole project-development space. Some of its features include:
  • Bug Tracking And Wiki, really cool.
  • Web Interface, incredibly simple.
  • Autosync, still wondering what its benefits are.
  • Self-Contained, yep, everything in one binary file.
  • Simple Networking.

As a developer of some internal projects, it's really hard to keep track of my bugs an issues, and the environment required for it costs too much. But this amazing project does it for me!

Its use is very similar to any distributed SCM and the installation/configuration is barely present. I totally encourage you to try it.

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: