The 11th Hour

Anger and Programming

2007-09-12T06:16:00.000-07:00

I have been thinking about this for a while now. I haven't been performing up to my usual standards lately and I think now I know why. I'm too damn happy!

It seems that I'm able to develop applications and websites better when I'm angry about something. It lets me focus better somehow. If my insides are roiling in anger about an IT-related topic, it spurs me to code faster. Now, I've been hearing all over media how anger is bad for you and I have analyzed that to death.

See, anger has always been my driver. When I needed to do better in school, I just thought of all the injustices that I had to suffer through to get to Canada and to a better life. When I got my first professional job, I had been angry at my college for feeding me propaganda. I was also angry at myself for falling for the propaganda.

After completing this program, you will gain a job in the industry within 6 months.

Our programs are superior to other colleges.....They also have the advantage over university courses, because they offer practical training, rather than theoretical.

I believed that, believe it or not. I had to at the time. My world had been turned upside down, since I always assumed that I'd go to a university. I didn't, and this college looked like the next best thing. Maybe I will elaborate that in another post.

So, after finishing college with top marks and being in the 95th percentile of my class, I languished as a Best Buy salesman for 11 months. That, in itself, is enough to send someone over the edge. Combine it with the college propaganda and, as you can imagine, I was very angry.

That anger carried me through my first job, a contract opportunity with Environment Canada. A VB 6 job, but I didn't care. Something, anything was better than Best Buy. I optimized their existing apps to run much faster. Once I understood their processes, I started seeing opportunities for improvement. For example, the data downloads from remote stations were going through a third party FTP server that was frequently down. This resulted in loss of that day's data, which was barely, if at all, acceptable. So, a bit of process re-engineering, a bit of ingenuity and the use of PHP's RPC functionality and the data download process was much more reliable.

Once the contract was up, I got a job with a consulting firm of sorts. They were interested in me, because of the Environment Canada job. I was interested in them, because of their focus on cutting-edge technology. I squeaked through their very ASP.NET-specific interview test. I wondered why anyone would be interested in whether I knew a specific line of code in ADO.NET. I mean, if I needed it, I could just look it up. That's what reference books are for, right? Looking back, that should have tipped me off that something was wrong with this company.

Anyway, back to the anger piece. Since I was pretty happy about the fact that I got the job, you might wonder where the anger would come from. Well, it turns out that this "company" was run by bunch of morons. That might sound a bit strong without any context, so let me give you some.

The sales guy would promise our customers applications that were not written yet. That's right, not features, APPLICATIONS. If that were not bad enough, my immediate supervisor had no managerial experience. This meant that he would not back up the developers, but rather leave them in front of the firing squad. The project manager and the owner were constantly interrupting development work. As much as I hate the interruption, I hated more the fact that both of them would put higher priority on cosmetic bugs and features, since "It will take you only a few minutes".

Right.

Oh, and remember that very ASP.NET-specific interview test, one that no interviewee has been able to pass? Well, it turned out that NONE of it is actually used in the environment. The ADO.NET piece has been supplanted with an ORM (Object Relational Mapping) system. So, NO knowledge of ADO.NET is required for the job, but it's actually tested and the candidates are evaluated on it. How would you feel if you found that out?

The point of this mini-rant is that the anger, once again, was in an abundant supply. The work hours were determined by the "upper management". So, if they wanted me to work through the night, that was what was expected of me. However, I excelled at my position, simply because I was so damn angry. I could vent my anger through the keyboard or I could go and get arrested for punching someone out.

If you have managed to stay with me this far, you will be rewarded with my point. My current job offers none of the above challenges. I am not angry about my college lying to me anymore, because now I have enough experience to be very marketable and getting a job is not an almost impossible task. Also, the people here are awesome, so I can't be angry about their personalities, nor how they run the development group I'm in.

So, my productivity is currently suffering. I am not able to scrounge up enough anger to work fast. I am also, so far anyway, unable to find another source of motivation. My marriage is great, my wife is to die for, I've got a house that is in an good condition. I also have started a side-business in my off-hours, one that I hope will be successful enough for me to work on it full-time. I do need a partner or two to really make it fly, but that's another subject for another time.

All of this makes me HAPPY. I can't work fast while I'm happy. I need to be angry. I need to feel the anger boiling inside of me. Or do I? I don't know. Hmm, they do use (relatively) old technology at my current job. And, they don't seem to be knowledgable about technology itself. Maybe that will let me get angry.

Maybe.

Thoughts on Lisp and Rails

2007-08-28T06:49:00.000-07:00

There has been a lot of buzz about Lisp and Ruby on Rails lately. Hell, just the other day, I managed to compose a post extolling the virtues of Rails, especially in comparison to .NET. However, I am coming to a realization about these two. I will try to articulate that realization to you.

Rails first

Let's start with Rails, since I'm more familiar with it. David Heinemeier Hansson has evangelized it, many have talked about it, including myself and Steve Yegge has even copied it. It promises faster and cleaner web development. It promises to release you, the poor web developer, from the chains of idiotic frameworks and languages. It includes an ORM to abstract the database, a templating engine to abstract the front-end and many more things. And, as far as I am concerned, it lives up to hype. Sure, there are compromises and things that could have been done differently, it gets knocks for its performance, but all those issues can be solved or, at least, worked around.

However, I will not recommend it to a novice web developer. That may sound counter-intuitive at first, but if you think about it, it makes sense. The abstraction that is so useful to someone who has been in the trenches of .NET and PHP is DEADLY to a novice. Black magic will remain black magic and the novice will not learn how things work.

Only after you have felt the pain of connecting to databases from more than one language, dealt with ASP.NET's idiotic Server/User Controls system, seen a page with a 6 MB ViewState, tried to build your own abstractions in PHP where the requirement was that you need to connect to either MS Access or MySQL and more can you appreciate and understand the Rails. If you start with Rails and get used to its magic of scaffolding, you are in serious trouble as a web developer. Scratch that, you will be fine as long as you don't run into problems. But, at the sight of the first problem, you are screwed.

That's why I usually tell novice web developers to start out with preferably PHP, but in worst case with ASP.NET. There are still free tools available for .NET and PHP is obviously open source. Once the novice has been put to hell on several fairly complex projects, managing database issues, debugging application code (especially PHP, since there's less integration than ASP.NET), as well as any AJAX-related issues, then we can talk about using Rails.

Rails, in my opinion anyway, is for experienced developers. It's for people who are sick and tired of battling the programming language and framework limitations and would like to simply work on getting the site or web application launched. These professionals already know how the process works and they find that current technologies impede them. They spend more time trying to work around limitations of the framework/language in question than solving problems. Rails makes it easier and more fun.

Novices would get the fun part, but would learn nothing more than to rely on Rails' magic. That's not good.

Don't forget about Lisp

Paul Graham loves it. He loves it so much, he evangelizes it. Steve Yegge swears by it, especially Scheme and eLisp (the Emacs implementation of it), although he doesn't peg it as the Next Big Language. I haven't delved too much into Lisp to confirm or deny the gospel.

I do understand, after extensive reading, the potential power in Lisp. I'm actually excited to find the time to learn it. Practical Common Lisp may be the way forward. There are a few nice projects that let you learn the language while creating something. This is in tune with Rails. Hopefully, it will be as fun working with Lisp as it is with Rails.

Secret projects abound.

Rails and I

2007-08-01T20:47:00.000-07:00

This is absolute craziness. I cannot stop thinking about development in Rails. I work with .NET in my daily job, but Rails has occupied every other piece of my spare time. Now that I think about it, this is how web development should be. Now, I know that sounds like a fanboy-ish thing to say. Maybe you're right, maybe not.

My current job requires me to spend time in .NET 1.1. Before that, I had to work with .NET 2.0. While the latter is much better at helping out the web developer, it does not compare to Rails. Of course, all of this is documented elsewhere, so I want to just share my experiences.

Views to the max

The simplest example I can think of off the top of my head is building views (HTML ones, not database views). While Rails has a fairly well laid-out convention on how to build a view of data, such is not the case in .NET, especially 1.1.
I've recently had to learn a new data model, as well as re-introduce myself to 1.1 and I was shocked at how hard it is to set up a simple view in ASP.NET 1.1. While I was mucking around with DataGrids, DataGridItems, manually setting up DataSets, etc., I reflected on how easy it would have been to do this in Rails. Hell, I would have appreciated just the ORM part of it, if not the conventions and the MVC way of doing things.

Of course, a lot of this is the environment. Where I currently am, there is an over-reliance on stored procedures. I am not against the stored procedures per se, but if I see a 3 line SELECT query being bundled into a stored proc, I lose my mind. Not to mention that the 3-line SELECT query gets its data from a database view which consolidates a myriad of database tables. Even a query that simple takes over 5 seconds to run. UGH.
When I think about it, I come to the conclusion that these people NEED Rails. You see, since Rails enforces a default way of doing things, it's harder to f**k things up. Not impossible, mind you, but harder. There may be a bit of flexibility lost, but when I look at where the unconstrained lead developer's mind can take me, the misery it can cause me, I'd actually love to have him constrained to a set of conventions.

I love templating

Templating, is to me one of the most important features of Rails. Again, speaking from experience, whereas .NET 2.0 has a template engine of sorts, it doesn't compare to Rails. As for .NET 1.1, well........put it this way, I've seen what a programmer can do when he needs a feature and thinks he's smarter than the people putting together a framework. Again, lack of standardized features within a web framework has caused someone to go off the deep end (and I mean, the deep end. This guy has managed to bypass how ASP.NET operates and replicate its rendering capability, all for the sake of having a template for web pages. I shudder every time I think about it.).

Can you say, Javascript integration?

JavaScript integration rocks in Rails, as well. Now, where I am currently, there is no such thing. The "template" created by someone here has the path to a JavaScript file hard-coded. Now, I'm not talking about a relative path, no, I'm talking about a nice absolute one.

However, I do have experience trying to integrate a JavaScript library at a previous position. Back then, we used a very early version of the Dojo JavaScript library (0.2, I think). Huge thing, this library. Also, our "clever" lead dev decided to freeze the library at that version, though as it matured, the Dojo library/framework really came into its own. That is beside the point, though. We experimented with different AJAX libraries in order to get the desired functionality. All of the libraries we tried (AjaxPro, Anthem.NET, even Atlas) did one thing good that the others didn't. So we ended up with 3 of them. Dropping Dojo into the mix to have file uploads without having to refresh the entire page, plus using its effects features, caused havoc, as it could have been expected. This is what impresses me about Rails. The core developers of Rails managed to integrate a fairly full-featured JavaScript library, AJAX-enabled and all, into Rails in such a seamless way that one does not need to think about whether or not JavaScript calls are going to work, but rather how to use this wonderful JavaScript library to his/her advantage.

Conclusion

Of course, there are whole lot more features that I have not covered here. As soon as I learn Rails more deeply and have a chance to compare its implementations to other frameworks/technologies, I will write about it.

Until then, I hope that you enjoy using Rails as much as I do. And if not, well, it's your loss.

Really.

Recursion is hard

2007-05-17T08:15:00.000-07:00

Recursion is hard. People keep saying that all over internet, but one really cannot develop an appreciation of how hard it really is until there is a problem in your code that's related to recursion.
I'm currently solving such a problem. The handheld code I wrote for a tree-like data structure is returning the wrong result. Why? Because, although I thought I was explicitly clear on what process should the intermediate result follow, it seems that through unwinding of the recursion call, a piece of my code simply ignores that result and it goes on checking other nodes and leaves. If these latter nodes and leaves return a positive intermediate result, my code seems to just run with it and therefore breaking functionality.

Recursion is hard.

Srki

P.S. This is my first blog post. I love it.