The longest route

I found myself in need today to share my local installation with a co-worker so that he can test a massive memory optimization I made.

Unfortunately me working from office and a ton of infrastructure with firewalls and what not between us I was forced to come up with a kind of non-standard solution to make it work. Here's what I've done:

1. The application runs locally on Tomcat (using Maven's tomcat6 plugin so mvn tomcat6:run)
2. Local Apache installation forwards requests from port 81 to 8080
3. An ssh tunnel is made that forwards my local port 81 to a remote port 8080 on a machine in Amazon
4. That remote machine has haproxy installed with a certificate that forwards local ports 80 and 443 to 8080 effectively allowing the user to login to my local installation

To test this I've used another Linux machine at home to login to with X forwarding enabled to locally view a remote Google Chrome running and accessing my local installation.

How can you not love Linux for that?

Removing executable bit from files

I don't want to bore you with the details but I've been looking for a nice solution for this problem for a very long time. Today I came across this post:

http://superuser.com/questions/234647/how-to-remove-executable-bit-recursively-from-files-not-directories

chmod -R -x+X *

And life's simple again :)

Thanks to Pabouk (whoever you are)! You made my day!

Why documentation doesn't matter?

Well, it's not really true, it does matter - just not post mortem. It does tell the developer what to do - sometimes even how to do it. It tells the tester how to test it. After the release it's no longer valid nor accurate for anyone to use. Wanna know why?

A simple case

Imagine for a second there's a new position you just stepped into. It's this glorious application that everyone keeps talking about on the 'net. You took a position in one of the teams because you were certain that this can't be wrong - people have been doing that for years so good established processes and a proper technical documentation will be accompanied by a proper introduction training - something to take the edge off from new hires.

Introductory shock

I mean, woooow!!! You just came to the office, suddenly you realize nobody knows who you are, nobody seems to care. People seem to be rushing for no apparent reason through the floors - it's nothing like the place you've envisioned. But that's ok, right? You came here to do the job so let's get that notebook and let's get this show on the road!

Still positive, still passionate, still a foreigner - but you feel this is your chance! In this company, in this corporation there are endless possibilities! Here you will shine!

The second disaster

Ok, so you finally know where you sit, you've got your shiny new notebook on your desk trying to figure out what you've been given, trying to get your familiar tools installed so that you can finally kick start that 'being a developer at ' dream come true.

First of all you don't get to install whatever you want on company's property. No no.. There are rules in place preventing you to utilize whatever power Today's software market has to offer (commercial or OpenSource) so you're kinda stuck with what your new employer has carefully selected for you. You keep telling yourself that it's just a matter of time, that chemistry doesn't happen over night and that you'll get used to it. Why wouldn't you?

Anyways,... There comes the big moment: you're getting the sources! Obviously it's all going to be professional, high quality, top-to-bottom properly designed and brilliantly described in a few pages of perfect documentation. Well.. Our heroes rarely live up to our expectations and my friend this ain't no different. Suddenly it looks like some soft-skill course is more important than getting things done (the famous 'complete this course by today midnight or you'll be terminated' email floating around). Product training is something nobody heard within this walls since the company grew from 7 enthusiast to 1300 employees most of which have better things to do than to sit here, with you and explain obvious things - that seems like a giant waste of time, right?

So you're a professional, right?

And so you've got the code, you've got all the tools you shall need, you have access to the password-protected Maven repository and by all means - let's get to hacking! Obviously we need to start that thing first on that shiny new piece of equipment to compensate the lack of documentation with a debugger session. But wait! What's that error during compilation? Does that look like a broken test? NO!!! It's the code in one of the core modules that a colleague from abroad committed a few moments ago - just forgot to add that new class to version control before and it just so happened it landed this way on your machine. No worries! This is a good version control system so people's email addresses are there to chase that person and to give 'em hell! And so you do:

Dear John,

I've tried compiling our solution a moment ago but it seems like the code you committed Today lacks one of the new classes. Can you please check what's missing? Thanks!

Best regards,

Francisco

One should thing that such an error like "code does not compile" would be spotted by some continuous integration environment where it's constantly tested to meed the high quality standards everyone talked about on the interview. It just so happens that the server CI is on went down 3 weeks ago and nobody noticed. Since everyone sat so far in the same room with nice flowers and A/C if John would commit the code with errors Sally would come over for a coffee and tell him to fix it. This time John is some 6000 miles away on another continent and just called it a day.

No worries - I'm a professional!

And so I'm capable of at least learning the inner workings of the system by going through that clear-cut set of unit and integration tests the project is obviously equipped with. So where are they?

The real life

As with any corporation there are rules: you don't moan, you be creative, think outside of the box, be proactive - and all that politely and politically correct. Following this path 2 weeks later you've got the application running, the database it talks to is across several VPN connections so it's ridiculously slow, most of the external systems don't respond since their security just isn't setup for your location (you being the new developer in the team abroad) and quite frankly you start to miss on the boss that told you you can go to hell because he's not going to be giving you anything you didn't earn with blood and sweat and tears.

So why doesn't documentation matter?

Plain and simple: if you think you have any form of documentation other than the application code itself you're mistaken. Anything talking about the code, telling you how things are is bullshit and does not mean a thing. Wanna know why? Because your compiler doesn't read wiki, it doesn't have access to your email account nor does he care at all about Word documents and Excel spreadsheets. All it's interested in is the funky looking wall of text in source files - that's the only specification, the only documentation, the only rule book that will tell you everything.

So for the love of God: KEEP IT CLEAN! You're gonna need it 'cause you're gonna read it over and over and over and over again. If your co-workers (co-located and those miles, miles away) don't understand the need for keeping things clean tell them it's important to you, that you don't want to work in manure.

And if they will not listen - to hell with them! Tell the world how things are so that the next person drown by the lucrative perspective of working in young and highly motivated team will stay away. Let other learn from your experience.

Post scriptum

If any of you felt this matches any of your previous experience I rush to say it's fiction (well at least some of it). The situation as a whole didn't happen at all (would have been a disaster and a case for a shrink afterwards :] ). It's just to underline the importance of clean code and the fact that the code is the ultimate documentation out there. Don't undermine it.

It's been a while...

.. but I have not forgotten :) There was just not much going on in my life. A nice and quiet 6 months.

Recently I've been working on some health issues but nothing really serious. My doctor asked me to collect some statistics for heart parameters (pressure, pulse) for review. Since I hate dead-tree versions of pretty much everything I decided that it's the best time to renew my friendship with Ruby and Sinatra.

The challenge

The challenge for me was to write the app in about an hour, with possible extensions at a later time, but to start collecting evidence as soon as possible. Although I'm a huge Grails fan (like you didn't know that) I think it is just too damn heavy for simple data collection applications like the one I have had in mind - thus the obvious dilemma between PHP and Ruby/Sinatra. I really like the embedded nature of PHP but to write anything in a sane way one needs to employ frameworks like CakePHP and the like. I hate that. I wanted to have as minimalistic as possible, with everything just working in a matter of minutes.

My sweet Ruby, Dear Sinatra,

You all know what Sinatra in the Ruby space is, right? If you don't - just go to http://www.sinatrarb.com and find out. Here's what I did with it:

1. All in one construct with everything in one place (configuration, controller, views, css, javascript)

2. All of it takes 210 lines of code (63 Ruby, 143 Erubis and a few while lines for convinience)

3. Deployed to Heroku in a matter of minutes

4. Using MySQL backend because it was just convenient.

Heroku provided the infrastructure for free (the one web worker that's always for free), a free database and Git repository. With all that in place I was ready with the first usable version in about 30 minutes (that's how quick Ruby and Sinatra and Heroku are).

Iterate iterate iterate

As with everything in software development there are going to be bugs, there are going to be new requirements and there are going to be "things that could be done better". One of them was for me to be able to input new measurements using my phone's web browser (the simplest thing that could possibly work). And it worked right out of the box but the default font size is just so small on my S3 that I've had to go through a number of zoom-ins to make out what's in there. Every navigation to another page returned me to that ugly small fonts. Changing the font size to like 40 did the trick :)

Then there was the matter of inputting numbers into the edit boxes. See, the default keyboard is an alpha-numeric-on-request type of keyboard which means that to enter numbers you have to either long-tap on the screen every number you'd like to enter or to switch to the numeric-special-characters-page on every input box which was just plain ugly. Changing the input types to "number" did the trick. Fortunately I'm not using Firefox on my Mobile where this type of inputs are just plain text inputs (as per some sophisticated page that knows all about browser compatibility).

And there was light! I have had enough measurements to actually display them on a chart. I wanted it to be an interactive graph, obviously, so my first choice was Google Charts. Even though beautiful and easy to use almost out of the box I felt kind of cheated because it used Flash underneath the skin. That obviously didn't work on S3 so I needed some alternative. Dygraph to the rescure (with GViz interface) and in a matter of 10 minutes (including research) I've had my charts up for display.

A small snag

As it turns out MySQL by default doesn't understand time the way it's supposed to. It just knows that 13:21:43 is almost half past one but with no particular interest for time zone. An obvious way to overcome this issue was to set all times to UTC and convert them when interacting with the user. Piece of cake. I'd like to point out that the author of mysql2 gem could finally extend the thing to allow something else than 'utc' or 'local' for the automated conversion and life whould be a lot simpler.

Closure

I always believe that software should be written according to high standards, with proper code coverage, proper planning, agile mindset and clean code in the end. Even though I tend to not do TDD in the case of such simple project such as this I still think it makes sense in other cases. I know I shouldn't talk like this since I'm the "Mr TDD" among friends but guys let's face it: throw-away software happens all the time and there's no reason to follow the routine blindly even in the case of spikes. Production code you write for someone else - TDD all the way; spikes no.

I'll probably use the app for another week or two, maybe even for a couple of months, who knows. I just hope it'll give my doctor enough information to get me back on track.