lfborjas: tech blog

The last couple of days I've been doing some Sinatra hacking, and in a serendipitous google search, stumbled upon these two little guys: itty and juno. They look like interesting python microframeworks, take 'em for a spin!

Lo and behold, something not very fancy, but perhaps useful

I'm a vim dude, though I still cling to eclipse for django development just because I haven't had the time to read the manual and make the switch. But my ruby and javascript (with node.js ) based projects are proudly developed in vim: from the haml templates to the sass stylesheets to the models and controllers.

And I'm also a paranoid: every day I dread that everything I have in my computer will disappear and I will be lost and forlorn. That's why I have redundant git repos for my really important projects and why I love using Dropbox for my mundane file-related needs.

Ok, world, big fat disclaimer here: I'm not an experienced developer in all of the web frameworks that have existed in the history of ever (I've only done kinda serious stuff in three of 'em) and this thing I'm saying here is more of a hypothesis that I'm currently putting to experience's scrutiny than a rational, exhaustively thought, conclusion. Now, read on.

Nowadays, there are lots of web frameworks, and people have done wonderful stuff with them (twitter was written initially with ruby on rails, p.e.). And, truly, they have allowed the now commonplace fast, yet robust and standards compliant, development of big projects. But what about the little projects? Those little apps with at most a couple of tables in a database and a simple service to offer? Well, the really cool and experienced developers just do that in the big frameworks too...

Ay, there's the rub that makes big frameworks of so big a hype.

My main projects are in Django, and I've become accustomed to developing in english. But my main audience speaks spanish. So crazy stuff happens when other people test my apps and we see, astonished and enraged, a UnicodeDecodeError. In fact, I took a picture of myself when such an error occurred:

Let's go and rant a little somewhere.

So, I released to the wild today an experimental little site: catharted info . The rules there are simple: rant a little, read other rants, watch them disappear forever. The source is open and you're free to browse it in the github repository.

Yesterday, while being super-productive in my main project, I stumbled upon (pun intented) thingler and realie, both of which made me say "holy mackerel, this node.js hype looks extra rad!" So a fellow dev and I decided to start a little project to learn this awesome stuff. Maybe sometime in a future in a possible universe I'll post more about that.

Node.js has two major niceties: it brings javascript to the server side thus allowing developers to stop being bilingual -and thus never quite good in one language or the other- and focus on being extra proficient in one language for both server and client sides. And two, is totally asynchronous! non-blocking and truly multiple threaded.

CouchDB, is a schema-less, no-sql, waddayacallit database server: instead of being relational and having tables and structures and whatnot, it stores JSON strings representing objects. Thus, your javascript prowess can even be applied to the database! RAD.

And remain sane and alive ------------------------------------+++

Here's the deal, the Google docs API is really neat, if you can dance oauth. But, by allowing to do all that crazy stuff with documents is bound to be really complicated -just read that xml, is like something only robots should ever gaze at!. But the nice guys over at google have developed some client libraries, and one of those is the gdata python client library. Which combines all that power with the python inherent simplicity.

But there's a caveat: there's so much stuff that the documentation is sometimes outdated or just plain wrong, as is the case with pdf uploads via the version 1.0 of the API. They would swear that you can upload pdf files. But no, you can't, not with old versions of the client nor with the latest release (at least as of the writing of this post, the version 2.0.11).

So, let's just show our users a message that says "oops, bummer, no can do".

Or not.

So, git, I assume you're familiar with it -if not, take a look at this and this - . Those of you familiar with it may also be familiar with Github, the awesome git hosting service. And those of you who may have used github long enough, are thankful for being able to rest assured that your code will be on a reliable server and never, ever, get lost, even if you computer catches fire and then is stole by ghosts.

But, what happens when the unicorn strikes? Those very rare moments when something happens and github is down. With your code. Presumably when you most need to push or pull changes. That stuff happens, it's the law of nature, and not even a super rad site like github is exempt from some downtime, you know that. But what about your code?

I came up with some kind of solution for my projects, and no, it's not to store it in a usb every five seconds or having a magical RAID, it's just probability: for my really important projects, you can simply create backup repositories in other git hosting websites!

I usually have two options beside github: Codaset and Gitorious. And both have their advantages and disadvantages:

Serendipitron is my new weekend project; find it here http://serendipitron.appspot.com.

Last week, I added markdown support to a little blog engine I wrote for a django tutorial. And well, I accomplished it in minutes! I like markdown because is really easy to write and generates amazing html. It is presented here and the syntax is explained neatly in Stack Overflow, and they use it, too.

My approach was really simple: I wanted to write the posts in markdown with a preview (like in the question edition in Stack Overflow), store the posts in markdown and display them in html.

Last week I realized something: this is a good time to be a web developer.

Why? Well, here are the reasons I have: