This is Customer Service: Aptana

Earlier today I wrote a post describing my difficulties with Aptana, which is an IDE for PHP, Ruby on Rails, and other things.  A few hours after I published my post I was contacted by means of a comment and an email by several people from the Aptana engineering team.  They wanted to know more about my troubles and offered personal assistance.  Are you kidding me?  This is perhaps the most exquisite customer service I’ve ever been witness to.  Not only is the Aptana team willing to help me for free, but they’re also actively searching for bloggers having trouble.  I’m speechless.

Customer service like this makes me want to run down the streets of Seattle skipping and screaming, “Aptana! Aptana!”  Seriously.  Once I get a response I’m going to give Aptana another chance as an environment for running Rails apps – currently I just use it for text editing.

Hats off to you guys, Aptana engineering team.

A Second Look at Software Engineering a Startup

I wrote a post a while back about software engineering a startup, and Clint‘s comment made me realize that my post was poorly thought out and just plain bad.  I argued that the quality of code you write should be related to the type of financial situation you’re in.  For example, if you’re a funded startup, then you should be writing good, maintainable code.  However, if you’re not funded or if you’re doing a personal project, then you should code quickly to get features out the door.  I want to revise my argument.

I’ve now worked on two pretty large personal projects: Cellarspot and Best Seattle Bars.  Cellarspot was developed in JSP, and the code we wrote was totally maintainable and robust.  On the other hand, Best Seattle Bars was developed in PHP, and the code I wrote was all inline.  The following analysis may be obvious, but I’ll make it anyway:

Robust, Maintainable Code
Advantages: Maintainable, easily refactorable, and expandable
Disadvantages: Generally requires more work, thought, and usually a more advanced development environment

Inline Code
Advantages: Requires less work, less thought, and a much less sophisticated development enrivonment
Disadvantages: Not maintainable, not easily refactorable, and not expandable

So when should you write fast, inline code, and when should you write good, robust code?  Inline code is great when you want to prototype something.  It allows you to quickly launch a set of features so you can evaluate your idea.  Robust, maintainable code is basically great for all other cases.  Now let’s examine three cases:

You write inline code and your idea blows up
Your idea takes flight and before you know it you have tons of users, tons of peers programming with you, and your users want more features and better reliability.  Chances are good that you’ll have to recode your entire web app, and that’s going to be a HUGE upfront cost that perhaps is more costly than writing good code to begin with.

You write good, maintainable, robust code, and your idea flops
First, let me just say that I feel your pain. One might think that this case is a total waste of time, but I’ll argue the contrary. I learned an insane amount by going through the process of writing good code, and it would be a good practice for me to do it again. The value one gains by going through this process is huge – it can help you get jobs (it did for me at least), and it keeps you sharp.

You use Ruby on Rails or some similar framework
Frameworks such as Ruby on Rails and Django let you write good, maintainable code very, very quickly.  They let you avoid the above two cases completely, because you won’t waste your time on a flopped idea and you won’t find yourself scrambling for dear life if your idea blows up.

My conslusion is the following: write good, maintainable code, and choose a framework that makes it easy for you to do so.  You’ll avoid the upfront costs of writing good code, and you’ll avoid the posiblity of large refactoring down the road.

Ruby on Rails: First Impression

First impression of Ruby on Rails: awesome.  It does so many things for you, and it makes things so easy.  “Things” is a very vague term, so I plan to write a much more in-depth post when I know more.

I tried to use Aptana as a fully enclosed IDE, but I couldn’t get it to work correctly after trying to reinstall it at least 10 times.  I followed a guide on how to install Ruby on Rails on Mac 10.4; I got everything working from the command line.  Finally!

More Ruby on Rails updates to come.

My Relationship with JavaScript

I used to hate programming in JavaScript. I remember the days of debugging-by-alerts and strait up trying to guess problems that were occurring in situation where alerts weren’t useful. I always used to complain endlessly about JavaScript’s poor debugging mechanisms, its odd bugs in Internet Explorer, and its documentation, or rather lack thereof. I even remember the first time I learned what AJAX was. Jim pointed me to some tutorials and explained a thing or two, and my first AJAX feature showed up in Cellarspot. I pursued Cellarspot in a software engineering class, and I explicitly remember proudly showing the insanely basic feature off to the entire class, smiling all the while.

I suppose what I’m trying to get to is that I’ve taken a liking to JavaScript. I’m by no means an expert at it, but I’ve begun to thoroughly enjoy programming in it. Tools like Firebug have made JavaScript much more manageable, and for whatever reason I’ve been able to find better help docs online lately.

What was once an enemy has become a friend; now all I need to do is start writing object-oriented JavaScript and using libraries such as JQuery and Scriptaculous. I’m going to make a valiant effort to do so in my developing nations project, which we’re implementing with Ruby on Rails.

5 Hours of Debugging for This

Guess what? The following C code compiles with no warnings in gcc with the -Wall option:

sh: /usr/bin/states: No such file or directory

My partner and I just spent 5 hours debugging the rest of our code only to find out that the assignments were supposed to be assigning from k1 and k2, not key1 and key2. Shit. Lesson learned I suppose.

PHP Pretty URLs

I’ve always wondered how to handle pretty URLs in PHP. Read the whole article, but in summary, you setup an Apache Rewrite:

sh: /usr/bin/states: No such file or directory

And setup your index.php file with the following framework:

sh: /usr/bin/states: No such file or directory

Turns out pretty URLs in PHP are super easy, and they’re great for SEO.

Update: You need to be a little more careful will 404 handling. Your 404.php page must have the following line at the top of it:

sh: /usr/bin/states: No such file or directory

If you don’t do this, then search engines who come across your “404″ page will get a status message of 200, indicating that the page loaded just find. This means that they’ll add this page to their index and also not remove any pages already in their index that no longer exist.

Create RSS Feeds with PHP

I found a forums post about how to create RSS feeds in PHP. Turns out it’s pretty easy!

All you need to do is create an instance of a class, fill in some fields, and add entries via a function call.  Once you’ve added all your entries, you call the output function and you’re good to go!  You can either create a PHP file that dynamically serves your feed or create a PHP file that writes a XML file every so often with a cron script.