Why I Like

Why I like Heroku

That was me, like ten days ago. I recently started trying to broaden my Twitter horizons to include more python-related stuff, since the vast majority of my feed was either PHP/Symfony2-related, or retweets of funny cat pics. So, I added the first Python user that came to mind, @kennethreitz. As it turns out, he’s the Python Overlord over at Heroku, and tweets about it occasionally, so I decided to check it out.

Color me impressed. As I mentioned in my tweet, I did the quickstart and by the time I was finished with it, I had already decided to make the switch. There are a few features that I really enjoy:

  1. Foreman, which is a command-line tool for testing your apps in the same environment that Heroku will use
  2. Ease of deployment. git push heroku master and you’re done. Seriously. They take care of the rest
  3. Seamless scaling. With Amazon EC2, I had to create a disk image, spin up a new EC2 instance, set up a load balancer… what a pain. With Heroku, you can have as many (or as few) processes running as you want with one console command, and load-balancing will happen automatically
  4. Worker dynos. It’s really easy to spin up non-web-facing processes to manage queues and what have you
  5. Free tier per app. Each app you create gets 750 free dyno-hours per month: more than enough for development and testing and low-scale production work
  6. Suggestions for deployment. You can find tons of tutorials and guides for setting up development environments, but I’ve found very few that talk about creating a production-ready application. As part of the quickstart guide, Heroku actually goes into how to set up and use something more than the built-in development servers (gunicorn for Python, for instance)

Top all that off with easy-to-use add-ons (easy as in “click a button and it’s ready” easy), and I see no reason to ever go back to managing an Amazon EC2 instance again. There’s no “official PHP support” right now, but Heroku and foreman make it easy enough to develop deploy a Ruby or Python app that I no longer stress about setting up environments for them. A big win all around.

Why I Like

Why I like Redis

Or, Redis: my favorite little key-value store

I really like Redis. I mean, really like Redis. From the site:

> Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.

They don’t mention that it is also fast, in-memory (with to-disk journaling if needed) and awesome. I first had occasion to use it as a caching mechanism for user searches, and fell in love with it right away. It’s flexible (like the marketing blurb says, a key can be almost anything), and the command set is pretty straightforward. Plus, if you’re confused about something or just want to take Redis for a test-drive, you can try out most of the commands live on the website.

Some of the features I like the most (note that this is not a comparison between key-value stores; I’ve honestly not done a comprehensive study. Just some things I like about Redis that may or may not be available elsewhere):

  • You can set a TTL on any key. This was the feature that made me look to Redis for caching; you can tell any value that you set to expire in n seconds, and it will expire in n seconds without any more input from you. You can even add TTL to an existing key, if you’d like.
  • Atomic value incrementing. I have nightmares of high-load applications using non-atomic incrementing for object identity. With Redis, INCR not only increments the value, but returns the new value as part of the operation.
  • In-memory store. This feature means that Redis is not the right choice for 100% of use cases (if your intended dataset is larger than your available RAM, you have a problem), but that’s fine. The entire dataset is stored in memory, which means that both read and write operations are really fast (plus or minus network latency, of course).

I know it’s a short list, but Redis has entrenched itself firmly in the set of go-to tools I use for my development stack. I’ve used it for caching, and I’m quite interested to see what other uses it will be a good fit for. I’m thinking job queue.

Why I Like

Why I like CoffeeScript

If you haven’t heard of it, CoffeeScript is “a little language that compiles into JavaScript.” It’s written by Jeremy Ashkenas, and reminds me a lot of Ruby. Also, try getting out of that cave once in a while. Anyway, in the past couple weeks, I’ve had conversations with at least three different people about it, and they all said something to the effect of, “why would you use that? I don’t understand its purpose: it’s just one more thing to compile.” So, I’m going to explain to you why I like CoffeeScript, and then I’m going to have to spend the rest of the post explaining my explanation. Ready?

I like CoffeeScript because it’s not JavaScript.

That’s it, really. I don’t like JavaScript. I think it’s ugly, I think it’s too verbose (typeof foo !== "undefined" && foo !== null makes me die a little inside), prototype-based programming seems alien to me, and I’ll be honest, front-end work kind of freaks me out. I’d rather deal with datatypes on the server than DOM in the browser any day. It’s probably that last one, more than any of the others, that’s kept me away from JavaScript all these years.

Two things convinced me to change my mind and give front-end development a try (and at the risk of sounding like a total fanboy, they were both written by the same dude. Totally a coincidence, I swear). They are CoffeeScript and Backbone.js, but once again, Backbone is a subject for another day. So that leaves CoffeeScript.

First, I appreciate how expressive CoffeeScript is. Scratch that, I appreciate how expressive Ruby is, and I appreciate that CoffeeScript does its best to take the best parts of Ruby and apply them to the problem of writing JavaScript. The fact that I can do something like this (example from the CoffeeScript wiki entry on writing DSLs)…

… and have it come out the other side as valid JavaScript just blows me away. Implicit parentheses and the “everything is an expression” mentality are awesome.

Second, I appreciate the effort that CoffeeScript makes to be concise, and to abstract away the ugly parts of its target language. My if(typeof foo !== "undefined" && foo !== null) example from earlier, for instance, becomes simply if foo?.

Third. Yes, it’s one more thing to compile. And? Don’t you have build and/or deploy scripts or something? Also, if you’re using Ruby or node, you can watch your .coffee files for changes and magically compile them without your having to lift a finger (except, you know, the fingers you lifted to tell the compiler to watch the files in the first place. Shut up). I guess it really comes down to a cost/benefit analysis: if you think the features of CoffeeScript that I’ve mentioned are worth it, you won’t mind compiling. If you don’t, then compiling will just be one more reason not to use it.

Update: here are a few more that sprang from conversations this morning with the same friends mentioned above. You’re welcome.

CoffeeScript takes care of declaring your variables for you, in their proper scope, so you never have to worry about hoisting and undefined variables.

Implicit returns. CoffeeScript will turn the last line of your functions into return statements. That’s right, whatever line is last in your method body will be evaluated and sent back to the calling code (though you can use return as your last line to keep the default “return void” behavior).

This might seem like a negative if most of your JavaScript methods return void and you’re not used to thinking that way, but trust me: it’s a good thing. There’s a comment by jashkenas on an issue in CoffeeScript’s GitHub repository that explains the reasoning behind it. To sum up:

… CoffeeScript forces you to adopt the habit that you have to think about having a good return value for every function you write — and I think it’s a great habit to have. There’s a lot of JS out there that would benefit from better return values, even for side-effect-ful code. …

What? A language that wants to encourage us to become better developers? Preposterous!

End update.

To sum up (and answer my friends’ questions): you would use CoffeeScript when you want to be able to write JavaScript more expressively. You would use CoffeeScript when you’d rather solve problems and let somebody else write (the ugly parts of) the code. You would use CoffeeScript when you want to be awesome. Okay, that last argument might not hold up in court. So anyway, yeah. I like CoffeeScript because it’s not JavaScript, and now you know why.

Why I Like

Why I like Python

(I changed the title from “PHP vs. Python” to “Why I like Python” after the fact. Just seemed more fitting)

Okay, I have a confession to make: this is less “PHP vs. Python” and more “coming from a PHP background, this is why I like Python.” Only, that title was too long. Note well, though… this is not meant to be an unbiased and/or impartial comparison by any means. This is my personal opinion, and should be taken as such. Anyway.

I’ve been firmly entrenched in the PHP world since, oh I don’t know, 2004… it was the language I was using when I really learned about software development, and I’ve been pretty faithful to it for a long time. The large base of information and support available, and the fact that I do primarily web development may have had something to do with it as well, but who’s counting? Recently, though, I’ve been getting kind of bored with PHP as a language. Sure, it’s sort of carved itself a niche as the de facto language of the web, but even as a web developer, there are projects that I would love to tackle that are just… beyond the scope of the language. So, I’ve been looking elsewhere. Python was one of my first stops (the very first was Ruby, but that’s a different post).

The thing that first attracted me to Python was that its syntax reads very much like pseudocode. A Python script reads like I think when I’m writing code. That, combined with significant whitespace in place of braces and semicolons and what have you (it’s really not that big of a deal to get used to, trust me), really makes it easy for me to grasp the fundamentals of what’s going on with a piece of code.

Also, you can call this petty if you want, but I really do much prefer the dot operator to the arrow. Doesn’t foo_object.bar_method() just read so much more clearly than $fooObject->barMethod()? Yeah, you know that’s right.

Another thing that I approve of wholeheartedly are class property attributes. If you don’t know about these, they’re awesome. Coming from a language influenced by C++ and Java, you know up front that if you ever want to have any kind of control over the getting or setting of a property, you’d better make your class properties protected from the very start and use getter and setter methods. With Python? Not necessary. You can start out with plain old properties, modified directly. If, at some point in the future, you decide that you need to wrap property access with additional logic, you can just add getters and setters to the property. Check it out (this is a modified example from the docs I just linked):

In both examples, you’d use the class the exact same way: some_c.x = 'whatever'. But in the second example, you can wrap the call with whatever additional logic you’d like. And, if you decide to switch from the first example to the second, your API doesn’t have to change at all. That’s powerful.

Oh yeah, and Monty Python references. Awesome, right?

I mentioned a few paragraphs ago that PHP has carved itself a niche in the web market. And of course it has: that’s what it was built to do. I often hear the argument made that while Python or Ruby or Node are “better” or “more powerful” languages (imagine air quotes around those, because I think that subscribing to hype is stupid), it’s much easier to get a website online with PHP than with those other languages.

Let me address that for a second: PHP is built to put content on the web, yes. Using just the core language libraries, then yes, it’s probably easier to get that website about your cat Captain Biggles online using PHP. Erm, the website is online using PHP, that is. Not the cat. But I digress.

But here’s the thing: you don’t have to use just the core language libraries. People much smarter than you or I have already come up with a solution to that problem. It’s called Django, or Pylons or web.py or whatever. Web frameworks. Written in Python. Check ’em out. Then you can stop worrying about how hard it is to get content online with a given language and start worrying about creating content that people actually give a rat’s end about.

I reiterate: everything that I’ve mentioned is simply a matter of personal taste. Maybe you hate Monty Python references (heathen). Or maybe you absolutely can’t get past the significant whitespace of the language (this Stack Overflow question on the subject makes my blood boil). That’s fine. Write your own blog post extolling the virtues of your own chosen language. But I think that way too often, we listen to the opinion that the tech in-crowd kids are feeding us and follow like good little sheeple without bothering to check our own facts.

Don’t do that.