It's very simple. I work at a publishing company in northern New Jersey. I think we hire pretty smart, but the technical interview tends to be more of a conversation about technology than a series of quizzes on the whiteboard. We've been hiring for a few positions lately, and I've recently hit upon the perfect conversational tech interview question. It's separated a lot of wheat from a lot of chaff for me in the past few months.

“What text editor do you prefer?”

---

I've recently begun using PHPStorm after several years of bouncing between Vim for server side languages and TextMate for Javascript. I've had a license for PHPStorm for almost a year now, but never really got into it. In my younger days I guess I was kind of a hipster in that I thought I too cool for an IDE. Rather, I wanted to be too cool for an IDE. IDEs were something you used if you worked with some bloated language like Java, or some compiled thing like Objective-C. If you used a slim, elegant, interpreted language like Ruby, you only needed a text editor. TextMate was the perfect little text editor for me for a number of years.

When I started here, we were still on Windows machines. Our entire Drupal stack was running on Ubuntu, and all of my background was in Linux and Mac, so it didn't make any sense to me to learn the tooling to work on Windows. So I downloaded VMWare Player and spun up my first Ubuntu 12.04 desktop VM. I taught myself to set up an intermediate LAMP/LEMP stack on this VM, and decided to start using Vim as my editor. I'd read about it plenty and most of the TM community seemed to be scattering to either Vim or Sublime. So Vim it was.

I became pretty proficient with Vim, but when I started playing Angular about this time last year, I was really missing a tree view. One of the killer-est plugins for Vim is vim-rails, and the reason is actually because of the way that Rails is architected. It's very predictable if you go with the flow, and vim-rails let's you jump from controller to it's view to it's model to it's tests, over to any other model with a series of very simple and easy to learn shortcuts (the only kind I ever learn). I found myself really missing something like this with Angular, and just decided to go back to TextMate for Angular projects. TextMate has that fuzzy file search and a file tree explorer by default so it really made getting around an Angular project a little less tiresome. I know, I should have taken the opportunity to get to know Vim better, but I had (as you can imagine) a shitload of work to do.

So I spent several weeks back in TextMate. I'm vastly more productive in an editor with the Twilight theme, by the way. Those weeks go by and it's back to Drupal and Vim. My Vim chops have weakened by this point, and I've gotten pretty used to having the Twilight theme, which apparently didn't exist for Vim. So I spent a day hacking an approximation together. It's also annoying to not have a file tree. I could install NerdTree, and tried to several times, but just never could figure out if I was learning a tool to get a job done, or just as some kind of test.

Enter my first project in Java a month ago.

---

We have some infrastructure here. It runs a lot of Java. This is a critical and most interesting piece of infrastructure, and we only have one Java guy here and he's pretty booked. Building web sites and writing javascript is fun and all, but underneath that is the layer of data in which my company lives and breathes. This is the layer for which this piece of infrastructure does the plumbing, therefore it has become much more interesting to me as of late.

This requires, obviously, learning a little bit about Java – something I'd stringently avoided for several years now. Java was old, Java was derided, Java could simply not be written without an IDE. These are prejudices which I no longer hold. I take this as a point of pride that I've risen to a level where I no longer define myself by my choice of technology. I've chosen enough of them at this point to see the merits of each for what they're for, as well as what they shouldn't be for. This is called experience, I think.

So anyway, my experience with Java and Eclipse is rather interesting. “Jump to declaration”. Wow. A tree view not just of the files within my project, but of the methods within a file! Wow. It's at this point that I have to jump back into Drupal to do some plumbing between this and that. I fire up PHPStorm, thinking hey, this IDE thing is kinda cool.

Lo and behold, many of the shortcuts in Eclipse are the exact same in PHPStorm. The menu and layout are very similar. I'm being productive in a tool which had previously only been sort of useful under come circumstances. I haven't even gotten to the debugger yet, on account of plumbing it into Vagrant and back being a pain in the ass. Just being able to reformat files and jump to function definitions is pretty nifty.

Then I have to jump back into another Angular project. Hey, I think. PHPStorm is basically also WebStorm, and therefore should be aware of Angular. It is! It indexes my entire project and within 30 minutes I'm being way more productive in PHPStorm on an Angular project than I would've been in TextMate. It's effing amazing! So I'm pretty much sold on PHPStorm, and then I notice that it doesn't support the little Sinatra/Sidekiq endpoint that goes along with this Angular project. I start thinking about IntelliJ a little bit, as I'm really starting to see the gains from being able to use one tool across many different technologies.

---

My point here is that I can go on for a ridiculously long time about my text editor and why. There's a story, and it also takes a winding path through what technologies I've used, why I used them, why I moved on or stayed with them.

I don't care what editor you use. Ok, I kinda do actually, but I care much more that you have some opinions on the matter. If you don't, I'm not sure you really write code and that's kind of a problem for the types of technical positions that we are filling. These positions require a curious mind, one that likes to check out new things, and one that's ok with using old things if that's the right tool for the job.

If you're interviewing at ABM and you come across this blog post in doing some research about the team and the company, feel free to mention that. Taking the initiative to do some research on your potential teammates speaks much more to the kind of curious mind that you posses than a long winded discussion about your text editor ;).

#general-development

This is not for programmers. This is for myself, because when I first started poking at Rails 6 months ago, I didn't have any idea why I needed to edit a migration file, much less what a migration was, except that it must have something to do with a database. I only knew that because of the command

$>rake db:migrate

that I was told to perform and the fact that it had the letters “db” in it.

So here's the deal. This morning I talked about version control and it's place in the life cycle of your application. What version control does is keep track of the changes that you make to your applications source code from start to finish (whenever that is). The only problem with this is that a big chunk of the data and functionality of a modern web application doesn't reside in the app's source code, it resides in the database, and nobody has invented an efficient version control system for a database yet. Some friends of mine have tipped me off to different methods that they've used – mostly around writing down DB schema changes into a text file that then gets placed under version control with the rest of the source. That's not entirely efficient, though, is it?

Ruby on Rails has come up with a system called “migrations”. Actually, someone surely came up with this way before Rails was invented, but I'm new here, so feel free to correct me in the comments section down there. Let's say you create a new rails app (This is directly from the awesome book “Agile Web Development with Rails” by a bunch of smart folks, and this example is the beginning of building a shopping cart system) :

$>rails newapp

This generates a load of boilerplate code which makes up the bones of any Rails app. That means that instead of spending the first week of the development cycle sitting there writing low-level code that provides primordial programmatic structure, you can spend it writing code that actually does something that you (or your client) can interact with. Let's keep it as simple as possible and say that you are going to have three fields that will be stored in the database to start. Rails let's you run this scaffold generating command:

$>ruby script/generate scaffold product title:string description:text image_url:string

This command runs a ruby script that builds a LOT of code for you, so much that you're only minutes away from tinkering around and you only started a few minutes before that. This command creates the “products model”, which is how a programmer says that they are going to start by creating some place for the admin to store the products that they want to sell online. The fields that were initially created were for the name of the product, the description, and the URL where you're storing the picture of the product. Don't worry about it too much, but take a look at the command up there, it'll make sense if you know what a string is. Just know that the data entered into these fields is going to get stored in a database. Wait, how are we gonna store this stuff in our database? Have we even created the tables for the database yet? No. Rails does it for us. Here's how.

One of the files that is created when we run that scaffold generator is called a “migration file”. This migration file is what actually creates the tables in the database, the columns in the tables, and can even populate the tables with data (used for testing), depending on what you do to the migration file. There is a command (or method if you're OOP savvy) created when the scaffold is run called the “up method”. That's the one that changes your database. There is also a “down method”, which is what undoes the changes to your database. When you run the good old rake db:migrate command Rails goes applies the appropriate changes to your database for you, and provides a way to undo them later. So, your client comes in and wants to add a Price column to the store. In the old days, you'd execute this SQL statement :

ALTER TABLE products ADD column price DECIMAL (8,2) NOT NULL;

Now, what if you wanted to undo that? That's a command you ran there, not some source code that you can save and delete later if you change a few things. You can't place SQL statements under version control. You'd have to go and type that statement into the text file that was under version control, and then hope that you could effectively backtrack to it later if you wanted. If your application and it's database have come a ways since that command you're going to have a good time figuring out how to undo it. Rails doesn't make you do that. In fact, you almost never are going to talk directly to your database in Rails. Instead, you go to the most recent migration file (which is source code and thus under version control) and alter a line to look like this:

add_column :products, :price, :decimal,
  :precision => 8, :scale => 2, :default => 0

Then you run a script that alters the database for you. Below this add column instruction, or “up method”, you add the remove column instruction, or “down method”:

remove_column :products, :price

This is the undo button for your database and any schema changes along the way. Since this command is under version control, and since you're not directly interacting with your database, and since Rails knows how and which migrations to apply and in what order if you ever want to go back to a previous version, you've just made your life a LOT easier. Now if you only understood what the hell you were talking about!!

For a vastly better explanation, try here. Good luck.

#rails #general-development

So it's been a while, eh? Not too much in the mood to write about what I've learned when most of what I've learned is how much I have to learn, y'know? Anyway, I've been back into Ruby on Rails lately, since Ruby has got to be the dead simplest real programming language out there. Oh yeah, and I have a major project cooking on Rails, but I'll elaborate later. Let's talk about version control...

Let's pretend you're typing that last term paper in college. This is the modern era, so we're using a word processing program. That program has eaten a few of our papers over the course of our college career, so we know to save our paper often. This is a huge paper, so we've also decided that it'd be prudent to save it under different names as it progresses so that we can go back in time to an earlier version with no hassle, y'know just in case we stray too far from the objective in the future. This is basically the same idea behind version control.

When dudes or dudettes are sitting at their text editors coding away at whatever they're coding, in whatever language, they're typing characters into a keyboard, just like I am now. The difference with software is that there are usually numerous files that all relate to each other in some way, and a change in any one of those files will impact the entire application. So say you make one little change here and another little change there, and then you skip over to another file and make a change there, and then you skip over to another file and make a couple of changes there. How the hell are you supposed to keep track of all that? Version control.

Whatever the flavor – CVS, Subversion, Git – all version control systems track changes made to the files in your fledging (or production) application. The manner in which they do this varies from system to system, and they all have their proponents and detractors, but that you have GOT to be familiar with at least one of them is beyond dispute. These will give you the ability to hack around all you want in the comfort of knowing that you can roll these changes back if you're not getting anywhere.

Now, the only problem with all of these version control systems is that they don't track changes to databases. The reason that this is a big deal is that the vast majority of large, modern, dynamic websites store a lot of data in their database. Some content management systems like Drupal actually store templates that determine how the website gets rendered to your browser in their database by default. You can change this if you know what you're doing, and that assumes a lot. Nothing is going to change the fact that many database powered websites have to occasionally make changes to the layout (schema) of their database to incorporate new features and the like. The new Like feature on that site probably has it's value stored in a column somewhere in a database. What if that feature sucks or is buggy? How can you roll back a database to an earlier state without using up your quota of blood pressure meds too soon? Under traditional version control systems, you can't.

Luckily, someone has figured this out for us. It's called a “migration”. I'll be back. I promise...

#general-development

Facebook made this announcement yesterday through the Developers section of their site:

Today we are excited to announce an important step toward greater openness through Facebook Platform. For the first time, we're opening the core Facebook product experience — the stream — with the new Facebook Open Stream API.

What this says to me is that Twitter is having a major impact on the evolution of the internet right now, namely in the heat they're putting on Facebook to innovate.

Now, the close up view of Twitter and Facebook looks pretty similar. Facebook is a place where people can make their own little website and stash pictures there to show their friends, etc., but the real innovation of Facebook has been to tap into the collective ADD of humanity and provide a place where you can tell people what you're doing and read about what they're doing, in small chunks. Twitter is a place where you can tap into the collective ADD of humanity and tell people what you're doing and read about what they're doing in small chunks, but the real innovation of Twitter is their API.

An API (Application Programming Interface) is basically the software equivalent to a door into your application. The 3rd party developer is then able to write his own application that uses that door to do stuff with the application (or it's data) on the other side. It's cool. It's what takes your application from being more or less a mute, single-celled organism to one that all the sudden can speak with others and communicate. That's why there are so many Twitter clients coming out all the time. Twitter on it's own is cool, if a bit mundane, but that they've opened the system to others to make more fun/valuable for them is why they are changing the world right now.

Facebook is paying close attention. They've kept lean and innovative where MySpace went bloated and corporate, but they've always preferred the closed ecosystem approach. All those applications that people continually send you are cool and all, but they force the developer to work within the confines of FB rules if you want to interact with the stuff that's going on within their walls. And there is an unfathomable amount of stuff going on within their walls. Think what you could do if you could break out all those people talking to each other, all those people posting photos, all those people connecting over similar interests or old school ties and start figuring out new ways to play with all that. The possibilities make Twitter look like a drop in the bucket...

#general-development

As in, what does that mean, anyway? I'll try and keep it short.

When I spoke of Ruby on Rails the other day as the 'hotsh!t dev platform of the day', I realized that it would need some clarification. So let me clarify.

Coding pretty much anything is a massive, time consuming job. That's part of the reason that computer languages have evolved from 1s and 0s to Fortran to C to C++ to Java to Ruby: if you were to try and write the Twitter website in assembly language (binary), you'd be there coding for a very long time. If you were to try and write Windows 7, you couldn't do it. Hell, they can barely do it now.

Man has devised a better way. I wrote about some of it in the Database post. He has set to automating as much of the menial, repetitive work as possible so that the developer may set his mind toward accomplishing other tasks, like the fun bits of the application. In the case of iPhone development, Apple has created an environment in which to write the apps, X Code. X Code is itself an application that runs on your Mac just like any other application. The nice thing about X Code is that Apple designed it specifically for the purposes of making applications for Macs and iPhones.

History lesson, culled mostly from the Mac dev bible, Cocoa Programming for Mac OS X:

Apple computers was started years ago in a garage by two guys named Steve. They're both very famous now, Steve W perhaps slightly less so. The two guys named Steve decided that since they were both programmers and engineers, that perhaps they should hire a CEO type to help them with their rapidly growing company. CEO guy came in and moved Steve J to some kind of powerless position in the company, so he split. He started another company called NeXT. They never did anything commercially successful, but they did develop an operating system and a platform for writing applications – one that started with a fairly significant library of code already put together to make the developers job that much quicker. At some point, Apple was not doing well financially or otherwise and Microsoft came in and basically gave them a lifeline. This was in the 90s. Steve J at that point was an intensely innovative failure. Funny, huh?

Around this time Apple decided to buy NeXT computers along with the Operating System that they had developed. Steve J was brought back as an advisor for a little bit before becoming CEO within a year. The NeXT OS eventually became Mac OS X, which eventually became the iPhone OS. The point is that even though the iPhone has only been around for less than 2 years now, the developmental lead-up took decades. During that time, various developers decided that they would put together 'libraries' of code for making Macintosh applications and save themselves the time of having to rewrite all this code that's essentially “boilerplate”, meaning the same in every app, there to provide low level functionality that the end user never encounters and is very rarely altered even by the developer though widely varying apps are coming out the other end. Every language that's in any kind of wide use has it's own set of libraries, there to provide standard functionality for the programmer and standard sets of instructions for the computer to execute when certain functions are called within the app.

Okay, sorry. There's a lot in there that I wouldn't have understood 9 months ago, so let me break it down for you.

When you tell X Code to start a new project, it asks you what kind of project you'd like to start. It gives you the options of a couple of different layouts of iPhone apps. Perhaps you'd care to build a navigation-based application. That's when you use buttons to navigate through different tables of data and settings. The Setting app on your (or your friends') iPhone is an example of a navigation-based app. Maybe today you'd like a tab-bar based app. This is like the iPod app on the iPhone. You have a menu of a few pages at the bottom of the screen that take you to different pages in the app. Maybe you just want a blank window because you're building a game that your crew can play in the bus between gigs. Anyway, after you decide that, it puts together the skeleton of your application with a bunch of different chunks of code that every single app is going to need to run. The developer then fills out the skeleton and a newborn baby application is brought into the world. Apple calls their development framework Cocoa, and for iPhone it's Cocoa Touch. Cocoa is just a collection of pre-compiled libraries of code lashed together to help make the dev process that much easier. Cocoa has a name, so it seems like it should be a physical thing. It's not. This has been one of the hardest parts about this process to get my head around. It's a bunch of code that someone else already wrote so that you don't have to.

Ruby on Rails is also a framework. A big part of writing Rails apps is using a command called 'script'. You call a script command to help you build these chunks of code, and the script automatically does a LOT of the tedious work for you. I love this, because I don't have nearly the experience to write something from the ground up, and that sounds like a lot of wasted time besides. Tweaking the generated code is then how the developer builds his app. Brilliant. This is what a development platform is. This is why most Mac applications have that “Mac-y” look and feel. This is why all these New-Web social networking sites have a that sorta clean, modern look and feel, and why so many of them employ Google maps as well as each other in their functionality.

Once you get your head around which platform you want to develop on (I'm thinking Rails to learn), then you can start learning your way around the API, which is where the real fun begins. I'm not there yet, but will try to remember to link there when I am.

#general-development

This part of the blog is going to be tough to write. Not because I don't have much to say on the topic, but because I have frequent pangs of “dude, you don't really know anything about any of this stuff”. Then the other side of my brain speaks up. “Dude, it's cool. They know you're not a professor. That's the point of this whole thing, right? If someone wants hard facts and a professionally written tutorial on computer science, they'd probably go somewhere else. If they're here, they're either a friend or an understanding onlooker, and either way they're probably well aware that you're just a bass player. Nobody really expects that much from the bass player.” So, I'm on I 70 headed east across Kansas after selling the shit out of the Ogden theater this weekend.

And now, my initial impressions on the theory and practice of the database.

What the hell is a database? Being a visual kind of thinker, I've been trying to come up with some sort of relatable analogy to help myself understand exactly what it is.

“It's a series of tables, populated with data, and the tables relate to each other.”

Okay. What do you do with it?

“Well, once you have the data in your database, you can run queries on it.”

That sounds like a lot of fun! But what the hell does that mean?

“Well, queries are like a request that you make. Say you have a database that's populated with every song that RRE has ever played at every show in every venue. If you wanted to know what you played at a given venue the previous time that you were there, then you could query the database to give you the set list from that show.”

Well, that's cool.

“Yeah, but say you wanted to know how many times you've played Mighty River. You could query the same database and get an answer on that, too. Say you wanted to know the venues where you played it. You could query that, too.”

Okay, I get it. So a database is kind of like a big spreadsheet?

“Sort of, but not really. You see a spreadsheet is basically one big monolithic sheet that stores your data in rows and columns; like a database, but a database is made up of many of those sheets, and the collection of those sheets and the way that they relate to each other, and the queries that you can then make of the data is what makes it a more useful tool than just a big sheet with some numbers on it.”

Okay. So, how about an example?

For this, we shall turn to the web. Actually, never mind because this is a blog which means that you don't need to turn at all. Let's press Ctrl-T and get a fresh tab going in your browser and go on over to Amazon. Mac users have the option of Cmd-clicking the link to open in a new browser tab, so you don't have to navigate away from me.

Okay. You see all that stuff on the page? Just about everything there is stored in a big-ass database – all the text, all the ads, all the pictures. Now, why is this important? For that, we'll turn to my bookshelf and it's copy of The Complete and Unabridged History of The Internet. I see here in chapter two after all this non-sense about universities and the DoD that once upon a time there was no such thing as the World Wide Web. I'll skip to the part where then there was a WWW. The first websites on the newborn baby web were mostly authored in straight HTML, an interpreted language used to help your computer assemble some data on the other end into a web page. A skilled HTML coder can control every single element on the page that's being displayed down to the very pixel (until it's opened in another browser, but that's another chapter). The HTML basically tells your browser what text to display, how to format it, what the background color ought to be, where to place the pictures and to what they should link. This is understandably tedious and time consuming work, but you gotta do it if you want your website to look right.

Somewhere along the way, websites started getting much more complex. Some genius decided to make a big online store where you could get pretty much anything, from books to socks to computers to whatever. Now, imagine if you will, the task of hand coding every page. For every item and every view and every picture and every review there was some army of poor bastards on the other end furiously coding away to keep up with the inflow of new inventory/users/reviews. I recently read about some guy who worked for an online newspaper, and he supposedly spent 14 hours a day coding HTML for the site before he figured out that there was a better way to get your steady flow of content up there.

The answer lies in scripting language and a database.

A scripting language is basically the same thing as an interpreted language in as much as it's not compiled, or even thought of until “runtime”. At runtime, the computer gives instructions to something, probably your browser, which then passes the request along to the code. It's at that time (runtime) that the code is crunched into the binary code that your computer can actually do something with on the processor level. This is hyper-simplified.

What this means in the Amazon example is that instead of hand-coding every page, why not just build a template that gets populated with the data that's requested at the time? Then you don't have to rebuild the wheel every single time a page request is made. Well, how do you build a template? With a scripting language, of course!

I'll just cut to the bird-eye view. When you go to Amazon, and it knows that it's you, and it spits out all that stuff that you should buy based on past purchases, that's because all of that info is stored in a database. When you click on an item and go to that items page, and the page looks just like the last one, that's because all that info is stored in a database. There's a table in there for every one of you, and for every item on the site. The table for you has all of your info in it, including past purchases, addresses, billing info, etc. The table for each item has the description, pictures, reviews, links, etc.

The point is that each of these tables is filled out in a standard way with all of their pertinent data. Why this is cool is that some automated process can then do something with it, like fill out a web page, or display your customer profile. The scripting language is what automates the process. It provides the instructions for the web server on the other end of your computer to “dynamically” make up the HTML needed to display the pictures and profile info and whatever else in a cohesive way across the entire website. Dynamically means that you don't need an army of HTMLers because the computer is writing the HTML at the time of the page request. Every different kind of page on the site (say reviews vs. the home page) has it's own scripted template that's called up when the appropriate request is made. Kinda cool, no?

So, a database is somewhere between MS Excel and that big Tupperware bin where you keep all your summer clothes. We'll dive into the beauty of doing things this way later.

A few database driven websites:

• Archive.org
• Twitter
• This blog
• Any message forum

Extra credit : Start paying attention to URLs, especially whenever the letters .php are used. PHP is a very widely used scripting language for making database driven websites, and if .php is included somewhere on your address bar, you're looking at data that's stored in a database.

#general-development

Step 2. Learn to program

Here's the thing. Computers don't think like you and me. They think in 1s and 0s. Every programming language ever invented has basically been a way to translate what a human wants to have done into a stream of 1s and 0s to be read by the computer. The translation into binary can happen at a couple of different points along the way from programmers head to users computer screen, but there are basically two different methods for how different languages do this. Some languages, especially the older (pre-1990) ones are “compiled”. That's a really byzantine process that basically involves taking the code that you have written, translating it into some 1s and os, linking it with other files in your code, and wrapping it up into an “executable” – a program that you can execute on your computer or whatever. The advantages of this method are thus:

Some larger applications can have bazillions of lines of code to execute (think about a Windows installer disk). If all of these lines of code were translated into binary at the time you run the application, the app would run so slowly that it'd be useless. This was obviously a big deal before CPU speeds got to be what they are now. Back in the day, the act of compiling was in itself a very time consuming procedure, and still can be today, so by doing it beforehand you save that much time and effort on the part of your computer. You also have the advantage of tuning your application on a lower level with regards to interaction with the Operating System (we'll get to that), thus making it possible for your app to perform much more nimbly. So basically, most of the benefits of compiled languages are in the performance arena.

The disadvantages of compiled languages have mostly to do with portability. Since the code has already been bundled into binary, the only machine on which the executable will run is the one for which it was written. That's why you have Mac and PC versions of the same software on the shelves. They had to be written and compiled separately since the two different computers have different methods of operating at the OS level and thus need different sets of instructions to accomplish the same task. C is the mother language from which virtually all other languages are descended, and the perfect example of a compiled language. iPhone apps are written in a language called Objective-C, descended from C with an OO twist. Since iPhone apps are written for one device and one device only, and since application performance on a phone really matters (think battery life), compilation makes perfect sense.

The other side of the coin, and I've been looking for this side for a while and have only recently found it, is an “interpreted” language. HTML is the perfect example of an interpreted language. HTML is only lines of code, just like an iPhone app or the Windows executable. The difference is that you leave the code alone and don't compile it. The code is instead “interpreted” at the time it's run, in the case of HTML by the browser that you're working in. The pros and cons of interpreted languages are exactly the opposite of compiled languages. You only write the code once and it works for every machine out there. It's left alone until that particular section of code is needed at “runtime”, at which point whatever is doing the interpreting, be it the browser or the server on the other end, crunches your code into binary and spits it out into whatever the application needs at the time. As computers have gotten more and more powerful, this method seems to be gaining a lot of traction as the preferred method of writing new applications. Some examples are JavaScript, PHP, and Ruby – languages that get chewed up into something actionable at runtime. In the case of Ruby on Rails, which is the hot-shit dev platform at the time of this writing, the code actually gets interpreted twice – once on the server side where the code is translated into HTML, and again on the browser side when the HTML is translated into something that you can read and work with.

Twitter was originally written with Ruby on Rails. If you think about it, Twitter is just an application that communicates over the internet. It really only does that one thing. They don't even display advertising (yet). Many of the traditional features of a commercial website are not there, so why write it in HTML? Especially when you have this vast database of information that gets displayed uniquely on every different computer screen out there, it's a perfect solution. Parts of Facebook are written with PHP, another interpreted language. PHP is designed to interact with info in a database – users and their profiles, pictures, text, whatever – and to write the HTML to display that info on the fly at the time of the page request.

Pretty cool, huh? Comments? Suggestions?

#general-development