Juggling

Introduction

Been busy! I just now realized I missed last week’s check-in. That’s not to say there hasn’t been progress. I’ve been busy juggling different projects: a foray into Django (Python’s Rails equivalent), dabblings in Laravel (PHP’s answer to Rails), writing a gem for generating Sass scaffolding for new WordPress themes, and a breakable toy that tests recurring billing using Stripe. I’ll briefly touch on each in a bit, but I want to explain a bit why I’m working with so many different frameworks. In an ever-changing technical landscape, if you aren’t constantly sampling bits of all technologies, you’ll quickly become out-of-date. My main personal focus for the forseeable future is Rails (strengthened by these forays into other frameworks), but there’s no denying that Rails won’t be around forever—to think otherwise is naive. Languages and frameworks come and go, and it’s our job as web professionals to evaluate and adapt accordingly. Now, on to some quick thoughts on some of the things I’ve been busy with. First up, Django.

Django

Django is pretty nice! I’d initially evaluated Django when deciding which framework to dedicate myself to. Hearing good things on both the Rails and Django camps, I jumped in on both. Django was nice, but I favored "convention over configuration“ instead of ”explicit is better than implicit". I also enjoyed the expressiveness of Ruby; though Python is easy to read, it reminds me too much of a stuffier language like Java or the like (I know, not fair, but I can’t help my feelings!). This time, I worked through the sample app on the Django Project homepage. Here’s what I liked about Django:

  • How modular everything felt. With Django, you can create a blogging app, then port that app to another project with ease. Rails projects don’t feel that portable.
  • Knowing what a model looks like by looking at the model file. In Rails, if you want to know what the database structure looks like, you need to look in schema.rb. In Django, just look in the models.py file.
  • I18n. I usually don’t worry about this feature too much, but I know it’s important downstream. And Django does it nicely, with ugettext and a command-line call to python django-admin.py makemessages -a to generate a file for each language you want to translate to.
  • Out of the box user auth and admin modules. Rails has these as gems, but Django has them as part of core. I can’t remember an app that didn’t need some sort of user authentication or backend management at some point, and the developers of Django must have felt the same way.

And, what I didn’t like:

  • Migrations feel more permanent. This is probably not the case, but I like being able to visually see which migration I should roll back to like in Rails.
  • Regex’d routing. Just feels risky to me. I don’t trust myself around regex, to be honest. I can imagine accidentally allowing for a large security hole somehow. I’d rather let Rails intelligently determine routes for me.
  • Clunky views. How scientific! I honestly don’t know why I don’t like Django’s controller and view implementation, but Rails feels much more user-friendly. Sure, Rails views allow for newer developers to put a LOT more application logic code than should be in a view (which is bad), but they feel more powerful, and feel like a “truer” View than Django views, if that makes sense.

Laravel

I haven’t gotten too far into a Laravel application, but I have to say I’m impressed. The developer obviously borrowed a lot of key concepts from Rails, and it actually makes PHP not such a pain to work with. Along with the Eloquent ORM for easily managing database objects (I really hated writing SQL queries when dealing with PHP in the past), Laravel is definitely a contender on the framework front. After considering that most servers serve PHP with little-to-no configuration, and the majority of the web uses PHP (around 70% last I checked), I think a developer should at least have Laravel on their radar.

Tonic-WP

My Ruby gem is in its infancy, but I’ve got some big plans for it. I’d like to create a Sass scaffolding command line tool similar to Bourbon or Neat, whereby a command will generate all necessary files to get started with the chosen framework. That’s step one in my quest for world domination creating a full-featured Yeoman generator that will create a fully namespaced starter WordPress theme using underscores and my preferences for folder structure.

Job board

My breakable toy is a job board app, though that’s not the main focus. The main focus is creating a recurring billing system that accepts payments through Stripe. I just got started with the app, so not much technical information. I will say, however, that Stripe is truly a payment processor service for developers, by developers. Their documentation is robust, featuring examples for every major programming language. Over the next week, I’m looking to test building an API and incorporate some sort of front-end framework into it (Angular, Ember and Backbone are my self-imposed choices). Until then!