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.

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.

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

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

• Home page http://www.jedsoft.org/jed/
• Quick guide http://www.cs.cmu.edu/~jeliza/work/jed-intro.html
• Reference guide http://espec.ppgia.pucpr.br/doc/editores/jed/quickref.html

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.

Presentación: Desarrollo de Software, Lecciones Aprendidas

About the joy of reading, and getting older

During the last few years I've started reading many books in all areas I'm interested on. Not only technology related, but also drama, history, and even comics.

Reading was not pleasant for me for a while. I tried and tried during my teenage to be interested in books, because my brothers were avid readers, but I couldn't. I couldn't share their taste or interest for books, not even the intensity they have for them.

But after a while I began to try something different, reading at my own pace, try to not compete with them. This is not a race, it doesn't matter how many books you read and how fast you do it, reading is reading, the more value you get out of them the better for you it is.

I don't appreciate people having a huge cabinet full of books in his main room, we know, you are a reader, don't be so arrogant. I believe that an author's goal is to be read and understood, many times the message will be misinterpreted and even changed, but that depends on the reader.

Reading is now a pleasure for me, I read slowly, very slowly. Sometimes I had to go back and read again because of my messed up memory, but is worth it. The message gets stuck in my head forever, wrong or right, doesn't matter, the message is there, and because I took so much time to read it I do care about understanding what I read.

Now that I aged a little bit, it's hard to know what to read, there are some many things, so many ideas and stories, so many, so little time. A stupid problem when living in a society that needs more work than ever, but a problem after all.

I'm trying to read and read, to understand and do it with things that I think are interesting, not reading because a boss requires it, not reading because everybody's reading it. Read because you care about, if not, go watch a movie, there are multiple forms of storytelling right now, you don't have to be limited to a media. Go listen to some podcasts, watch some movies, listen to the radio, talk with people, listen to them, learn... that's the real joy :)