Marking Gmail read with Apps Script

Recent versions of Android give you the ability to Archive an email right from the notification bar. I use this like 30 times a day, for emails that I can tell from the subject that I don’t need to read. It’s awesome.

The only issue is that these message stay unread, and seeing a bunch of unread messages in my archive or labels annoys me, so every morning I search “label:unread” and mark all as read. It’s a total first world problem, but annoying nonetheless.

I’ve been looking for some sort of app or something to auto-mark-as-read any messages not in the inbox for months now. Then someone recently pointed me to Google Apps Script and 10 minutes later I had a script running which automatically marks all archived messages as read every minute. I was blown away at how easy this was.

Here’s how it’s done:

  • Head to to start a script.
  • Choose to create a script for Gmail in the little popup.
  • Delete all the sample code it gives you.
  • Replace it with this (written using the API reference):
function markArchivedAsRead() {
  var threads ='label:unread -label:inbox');
  • Save the project with File > Save.
  • Add a new version using File > Manage Versions and enter “initial version” then submit that.
  • Do a test run using Run > markArchivedAsRead and be sure and authorize the app when it asks you to.
  • Add a new trigger using Resource > Current Project’s Triggers and choose to run the above function every minute (or hour or day or whatever if you want to be nice to Google’s servers).
  • Save the script again and exit. Don’t worry, it will keep running.

And you’re done. It will continue to run every minute until you stop it. How awesome is that?

Update: Some people are reporting an error which says “This operation can only be applied to at most 100 threads. (line 3, file “Code”)”. To fix this, you have to manually do a search for “is:unread” and mark all of them as read before running the script, so that it starts with a clean slate. The script can only process 100 threads per run, so if you give it more than 100 on the first run, that’ll obviously bust it.

Hey, maybe you should follow me on Twitter!


Drupal’s Golden Handcuffs

Drupal’s main draw is that it gives you the power to do an insane amount of work with zero coding. This is both its blessing and its curse.

The blessing

Drupal is great for developers for exactly one reason: it’s really, really productive.

Here’s a short list of example things that can be accomplished in Drupal with no custom code:

  • A listing of arbitrary content written by user X and published within the last Y months (where X and Y are arguments in the URL in the form blog/user/X/recent/Y), grouped by month and formatted as an ordered list with custom wrapper elements and classes per-field and per-row.
  • A full featured RESTful API which exposes your sites entities (whether it be products, users, categories, blog posts, videos, whatever) as resources with niceties like YouTube video links formatted as embed code and referenced images converted to grayscale.
  • Completely custom types of content with arbitrary fields such as link inputs with custom validation, photo uploaders with unlimited values and drag/drop ordering, custom tabs acting as field containers, multiple WYSIWYGs per textarea depending on which input format you choose (markdown, raw HTML/PHP, filtered HTML with custom allowed tags, blah blah).
  • Routinely parse and import content from external data sources (XML, CSV, and JSON to name a few) as Drupal content with source fields mapped to Drupal’s custom content fields in the GUI
  • Robust and fast site search powered by a Solr backend and index with support for facets/filters, sorting, weighted results, multiple search sections/pages each with their own set up default filters (by content type, category, arbitrary field value), etc.
  • A global store locator with geocoding and proximity searching, locations displayed as custom icons on a map, and the ability to customize the output of the results list (show a thumbnail of the store if you want to, output results as a table with sortable columns if you want to, I could go on).

Seriously, it’s freaking ridiculous. The benefits of having all this available in a ready-made GUI without custom code should be obvious, but I’m going to list them out here so that I can waste your precious time.

  • No debugging your custom code
  • No digging through the docs trying to find the API function you need for an odd task
  • A discoverable UI–click around until you find what you’re looking for, rather than digging through code
  • A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs
  • A much much smaller risk of security breaches due to that team
  • Holy crap, so much faster

That last one sums it up. Creating advanced functionality by clicking around is so much faster than writing it by hand, even if you’re using an opinionated framework that cuts down significantly on the custom code you’d have to write. The minimal debugging and bug fixing and security auditing and API reading are all just more time saved.

In essence, Drupal is extremely productive once you know your way around core and the popular contrib modules, so much so that it’s very hard to leave it for something else for general purpose site building.

The curse

So Drupal lets you get crap done really quickly and sends you laughing all the way to the bank…what’s the problem? Here’s the problem. Here’s the typical day for a Drupal developer:

  • I’m bored
  • I’m bored
  • WTF?????
  • I’m bored
  • Lunch!
  • I’m bored
  • I’m bored
  • I’m bored
  • I’m bored

The particularly astute readers will have noticed that a Drupal developer is usually either 1) being bored clicking around or 2) screaming at Drupal for failing them in extremely hard to debug ways.

When stuff breaks, it shatters

Let’s start with #2. The issue with building complex functionality on top of code that you didn’t write is that when something breaks, you cry. Debugging through layers and layers of code on top of code written by other people is much more likely to cause you to light socks on fire than debugging your own code.

Say that you’re using the Media: YouTube module to display YouTube links attached to content as embedded videos, and the options to adjust the video size aren’t actually doing anything (note that this bug is entirely hypothetical–Media: YouTube is great as far as I know). Where do you go? You probably first search the issue queue for that module, and maybe you’ll see an issue about it and a fix which might involve upgrading to a dev release and possibly breaking compatibility with the version of the Media module you’re using. Or, more likely, you can’t find anything in the issue queue so you dig through the Media: YouTube code which contains lots of calls to custom formatter hooks (in Drupal core) and to hooks in the Media module, all of which have their own nasty call stack to worry about. So basically, you’re going to have a bad time. However, at least you’re doing something that requires brain power.

The click monkey

That brings us to #1. Most of the time everything works alright more or less so you’re just clicking around plugging away with building the site. This is almost worse, because you are now a click monkey (the type of monkey that code monkeys make fun of).

Everything that you were excited about as a programmer–working through interesting solutions to complex issues, writing sweet algorithms, refactoring crappy functions into beautiful snowflake functions–all that stuff is just a pipe dream, and you’re nothing more than a well paid mouse button operator.

Can custom code cure cancer cornflake?

Still, you’ll likely need to write some custom code, whether it’s for a unique feature that there isn’t a module for or you’re just doing some theming overrides. It seems like this should be the escape from the monotony of clicking but really it generally just ends up being frustrating. Drupal just isn’t a great system to code for.

  • It’s complex. Try wrapping your head around the render array in 7 or figuring out WTF to do with stream wrappers.
  • Content and display are not well separated. Modules build markup directly, hopefully with theme_whatever functions that you can override in your theme, but often not. Doing this in custom code just feels sad, even after years of doing it.
  • The Drupal 7 database abstraction layer is nothing more than a PITA. I don’t know anyone who prefers that to raw SQL, and IMO the added benefit of having a tiny bit more database agnosticism isn’t worth the decreased DX.
  • Drupal 8 will “hopefully” bring with it Views in core, a GUI layout builder in core, edit-in-place in core, all of which are things which will have their own complexities to learn and understand and override and debug.
  • Many changes require flushing the Drupal cache to appear. If I had a jellybean for everytime I flushed Drupal’s cache in the last few years, I would be too busy eating jellybeans to write this.
  • Documentation is still a mess, despite a huge community-wide effort to improve.
    • Individual contrib modules may or may not have docs, and if you’re lucky they may be a page on or a README.txt in the module. However, the chances that there are docs specifically for developers rather than site builders are slim to none, so you’re often stuck digging through contrib module code looking for hooks and functions to do what you need.
    • Drupal core documentation is scattered across various book pages throughout the site and many things just don’t have documentation at all (at least that that I’ve found).
    • Many docs pages are outdated but don’t tell you that, so you find yourself hoping that someone in the comments has said what Drupal version that page applies to, and maybe even linked to an updated page for the newest release.
    • It’s always a battle to find the API function you’re looking for if you don’t know what it’s named. What’s the function to select all nodes assigned to a taxonomy term? Here, let’s search the API for taxonomy. Hmm, 10 pages of results. How about for “taxonomy nodes”? Zero results. Resort to Google, hope that someone has asked this on Stack Overflow, finally find it, and repeat the process 10 minutes later with another function.

So no, custom code cannot cure cancer cornflake. Custom code is either also boring if you’ve done that thing times before or frustrating if you haven’t.

Note that I understand that there are many reasons why most of the above list of grievances can’t be changed (for example, if modules didn’t build markup directly then you’d be stuck doing it all yourself in the theme ala Expression Engine which would greatly increase your development time), but it doesn’t mean that I have to enjoy it.

The future

Will Drupal become more fun in the future? Possibly, but likely not. Possibly because things like API cleanup and docs and miscellaneous DX niceties can add up to a difference, but likely not because Drupal has always been and always will be about being productive over being fun to code on. Drupal 8 is adding more functionality (see Spark) rather than subtracting it.

It’s a vicious cycle–Drupal attracts people who want to get crap done and don’t care as much about getting it done in the most enjoyable or most elegant way possible, because that’s what Drupal’s good at. These people in turn become contributors and push Drupal further along that road.

The Golden Handcuffs

So your work isn’t quite as interesting or challenging as it might be if you’re working with Django or Rails or whatever, but you’re able to do stuff a lot faster than you’d be able to do it using anything else so you can’t leave without dealing with the frustration of knowing that. Try spending 150 hours building proximity search with mapping in Django and knowing that it would take a day in Drupal. It’s the Drupal Tradeoff ™ and unfortunately it’s not something that any version of Drupal can really improve upon.

So what to do? Well I know what I’ll do, I’ll keep using Drupal and getting crap done, and I’ll just use other technologies on side projects to stay sane and feel challenged and interested. Tis the power of the golden handcuffs.

Discuss on Hacker News or reply to me on Twitter.


Nerf guns don’t matter

I’m seeing it more and more–job descriptions with perks about nerf guns and happy hour, or new grads who joined a startup and are bragging about ping pong tablesand free coke. This is apparently something that people see as a fun culture, a sign that this is a place you’d enjoy working at and has people you’d enjoy working with.

This stuff doesn’t matter.

A fun distraction is still a distraction

This stuff is all stuff you do when you’re not working. When you have a few minutes to spare here and there and are bored and want to have fun. It’s recreation. It’s a distraction from work. It’s not going to make you more productive, or make you happier with the work you have to do, or the people you have to work with.

In fact, it might make you less happy with those things. Suddenly the work you have to do, which could and should be fun and challenging if you’re in the right field, is just a necessary evil to spend a few hours on before the next game of ping pong. You’re not at work to play around, you’re at work to get crap done, but if you spend long enough in an environment like this, then the work becomes the distraction and the nerf guns and happy hour become the thing you look forward to and are excited about.

This will not help your productivity and certainly won’t make doing actual work any more enjoyable.

Keeping work and play separate

Lots of people seem to love bragging about working hard and playing hard, and it’s a pretty common attitude that working with people you can go play laser tag with and be friends with is a big win. I’m going to disagree.

I’d like for people at work to judge me based on my work, not on how good I am at pool or how well I can handle my alcohol. I’d rather they didn’t know any of those things, because it just distracts from what you’re there to do. I don’t want to have to deal with the drunken argument last Friday night at the bar when I’m working Monday morning. I don’t want someone I work with to be bummed out with me because I didn’t want to hang out on Saturday since I have a family.

Trying to enforce a culture where people are all friends with each other and go out drinking together and watch movies together does not make anyone any happier when they’re working, it just creates more opportunities for drama and biases.

What really matters

It’s easy to throw some toys into the office and call it your culture. Actually creating a good, positive, productive culture is much, much harder than that.

Do your employees feel heard when they have suggestions or questions? Do your managers do a good job of keeping track of budgets and focus without micromanaging and getting on everyone’s nerves? Do people have a solid method of critiquing each others work and providing helpful feedback without hurting any feelings? Does everyone feel challenged and interested in the work they’re doing?

These are the things that produce a good culture, and these are the things to strive for, and these are things that you can’t buy at Target or brag about on job descriptions, but they’re the things that keep people around and working hard and happy.

Discuss on Hacker News.


Coding skill vs. employee skill

At the extremely basic level, there are basically two good qualities that each programmer should strive for: programming skill and employee skill.

Programming skill is basically the ability to write good, solid, performant, maintainable, and all-the-other-desireable-code-adjectives code. This is what coders tend to spend their time harping on and debating about and reading about.

Employee skill is the ability to be a good employee and coworker. This means being responsive, being able to communicate well, hitting deadlines, being open to feedback, being able to explain complex things clearly, stuff like that.

An extreme example

Picture two people:

Rodrigo is an MIT graduate who writes compilers in his spare time. He is a core contributor to Haskell and wrote a few very well known Python packages. He can generally write very solid code that’s readable and handles edge cases beautifully. However, he takes days to answer emails, he rarely picks up his phone, he doesn’t seem to have much of an understanding of the importance of deadlines, he does things his own way, and you can’t get a clear thought out of him without rambling incoherence surrounding it.

Gabriella isn’t a very good coder. Her code is obviously written by an amateur. She takes 30 lines to write what should be written in 15 or 20, she introduces bugs that QA has to spend their time on, and she doesn’t really grasp the concept of writing code that performs well–“if it works, it works!”. However, she’s incredibly responsive–she answers emails within minutes and never misses a call, she is a great communicator and is able to explain complex technical issues quite clearly to clients, she has never missed a deadline, she is constantly looking for feedback to improve her work, and she’s an easy person to talk to.

So really think about it. Which would you really rather work with on a day to day basis?

What really matters?

In my experience, a programmer would rather work with Rodrigo, and a manager would rather work with Gabriella.

This makes some sense–after all, programmers are the ones who would have to deal with crappy code, and managers are the ones who would have to deal with missed deadlines and crappy team communication, so we all want the person who causes us the least amount of pain.

However, the point is that managers are the people you need to impress to get jobs and promotions and raises and pats on the back, so in this scenario, Gabriella comes out way ahead. And I’ve seen it happen many times–programmers who are great employees but not great coders move to the top while the great coders but poor communicators stay on the bottom.

Despite what we as programmers like to think, coding skill is not what really matters if you want to find success in a job, or at least in many jobs. Being a good employee is at least as important, sometimes more.

Discuss on Hacker News.


Taco Bell Programming

If you haven’t read Ted Dziuba‘s post on Taco Bell programming, go do that now. It’s really a great post.

The gist is basically that we can and should be writing programs using the stuff that’s been available for tens of years, stuff like bash and xargs and find, and that using the latest and greatest tool or language simply adds complexity and bugs. He compares it to Taco Bell, which uses “roughly eight ingredients” in random combinations to make the entire menu.

This was like a smack in the face to me, a person who always gets excited about trying the new hotness. One thing about it concerned me though – a lot of that stuff just isn’t fun. Nobody wants to write stuff in bash, and there’s a reason people use modern tools: they’re often more fun and less annoying.

So I emailed him to ask him how he balances that. Here’s my email:

Hey Ted,

Feel free to ignore this question if you’d like. I’m sure you get a lot of emails from random devs, especially lately.

Straight to the point, just read your taco bell programming post and was intrigued by it, but it didn’t mention anything about dev preferences or the dev experience. For example, writing something in bash (like Hubot for example) might take less code to do it in Python or CoffeeScript or whatever and it might be the more solid solution but most devs will go way out of their way to avoid having to write something non-trivial in bash.

So the question is, how do you find a balance between simplicity/tried-and-tested-tools (taco bell ingredients) and ease or enjoyment of development (using a more modern language/tool just because it’s less annoying)?

Thanks. Big fan of your posts.

Here’s his response. I wasn’t planning on posting his response (if he even ended up responding) but it’s such a great answer, I’d feel like a chump if I didn’t share it.

Hey Mike.

I know a lot of devs will go out of their way to avoid shell scripting, and generally using the tools already available to them by their operating system. I know, I used to be one of them.

I got into letting Unix do as much as it can for me by the advice of a systems administrator I hired, who really swayed me toward that culture, and after the first project I wrote on Unix principles, I immediately saw the value of it (this one piece of functionality was the most rock solid thing I have ever written, it’s been running for 2 years now with zero maintenance).

On to your question. I guess it depends on what’s easy for you to do as a developer. Learning a new language like Bash isn’t something to take lightly. I still don’t know enough of it to be dangerous, but I hack things together. Once you understand the Unix Way, the process becomes much easier. I’d recommend reading “The Art of Unix Programming” for some great insights.

Generally, you’re never writing nontrivial code in Bash. You use a bash script to string together smaller utilities into something useful. All the real meat of execution happens in the programs your shell script calls. Nothing precludes you from writing bits of functionality in any language you want. One of the Unix Way principles is that “a program should do one thing, and do it well”.

When I try to find the balance between Unix tools and custom tools, I ask 3 questions:

What parts of this problem does the operating system solve for me?

Of the parts that the OS can’t solve, am I simply not aware of something my OS does that can solve the problem? (This happens a lot.)

What’s likely to be the most brittle part of the system?

I find that a lot of developers have gross misconceptions about how operating systems work, and will try to excuse themselves behind a veil of “scalability” or somesuch. For example, I had a good argument with a developer last week who was convinced that “starting processes was slow”, so he was cooking up some threaded catastrophe.

Fact was, it’s simply not true. Modern Linuxes can spawn processes very quickly, and actually use the same syscall to spawn a process that they do to spawn a thread (clone()).

At the end of the day, it’s really something that comes with experience. With any system you write, V2 is always way better, because you’re more aware of the things you don’t know 🙂


Why would anyone use vim?

(Note: this is a post for vim newbies. If you’re an experienced user, you won’t find anything new here)

I recently switched to vim full time after years of asking myself that question. It seemed like a huge percentage of the better hackers I came across used vim, but all I could see was “no mouse, no IDE goodies, no deal.” Why would anyone subject themselves to that? Well, turns out, here’s why:

Vim is ubiquitous

For web developers who do a decent amount of SSH’ing and editing on a server somewhere, this is huge. Pretty much any Linux box you can find yourself in will have vim installed, and it’s a huge plus when that editor just happens to be the editor you use day in and day out and are comfortable with.

To take it a step further, you can even use vim key binding in Firefox, Chrome, bash, Thunderbird, etc. Here’s a nice list. It has a decades-long history and tons of fans, so you start to find that almost anything you do on a computer can be done in a vim-like fashion.

Vim is lightweight

Vim starts up immediately and leaves a teeny tiny footprint. Maybe this isn’t important to some, but it really makes me happy.

Contrast this with the beastly modern IDEs or even the “lighter weight” text editors (Atom and VS Code especially, which are Electron-based) that take seconds to launch and gobble RAM. It’s very refreshing.

Vim has everything I wanted in an IDE

One of the main things that stopped me from giving vim a serious look for so long is the false belief that it was just a simple editor with some crazy key bindings. Turns out, I couldn’t be further from the truth. After just a couple days of using vim, I had set up an environment with:

  • Tab autocomplete (for both project functions and language functions) complete with a function definition popup
  • The ability to jump from function call to function declaration and back easily
  • A sidebar function outline, automatic syntax checking (even including JS using JSLint and HTML using Tidy)
  • Spell check (for typing up blog posts like this one)
  • Tabs for switching files (although it seems basic, I was worried about using multiple files in vim, but it’s really great)
  • Project search (including replace and regex support)
  • Smart indenting and auto-indent support
  • Just about any other IDE goodie that I wanted.

I really can’t think of anything I’m missing now that I would have with a different setup.

Vim has some really great plugins

I’ve found the plugin selection for vim to be a cut above that of most other editors. Some of my favorites are:

  • Fugitive – A vim-based Git wrapper that lets you do most git things without leaving vim.
  • Syntastic – Automatic syntax checking for many languages. Opens errors up in a split window, highlights problematic lines, lets you jump from error to error, etc.
  • Ctrl-P – Quickly open project files by typing any part of the filename/path. Much faster than using tree-based sidebar project file lists for me.
  • Gist – Create a GitHub Gist out of the document or selection. This is really, really awesome for me as I tend to send code a lot in IRC.
  • Tagbar – Displays a toggle-able sidebar of project or current file functions/variables for easy jumping.
  • NERDCommenter – Comment out lines/chunks/selections of code in many languages, with your choice of comment types.
  • Emmet – Vim support for the amazing HTML/CSS shorthand expander.

Vim’s modal editing really opens doors for amazing things

This is the main thing that keeps vim users happy. Vim has a “keep your hands on the home row” philosophy, and the only way that’s really possible is by making the main keyboard keys do more than just type letters. So, because of that, you have your regular old insert mode (same as other editors), but you also have a “command mode” that lets typing things execute commands rather than inserting text. Here are a few examples:

  • Type d$ to delete everything from the cursor position to the end of the line (d = delete and $ = end of line)
  • Type o to create a new line below the current line and enter insert mode on that line.
  • Type ci" to delete everything inside double quotes and enter insert mode (c = change, i = inside, and “ = what you want to change inside of)
  • Type gg=G to autoindent the entire file (gg = top of file, ”=“ = autoindent, and G = end of file).

This is crazy for awhile, but then it starts to not seem so crazy, then it starts to actually seem pretty sane, then it becomes amazing. For a quick intro to vim’s commands, type the vimtutor command at a terminal and go through that – it only takes about 10-15 minutes.

Vim is fun to use

All of this adds up to a really enjoyable experience. You have a lightweight, free, feature-rich, customizable editor that’s everywhere and lets you get crap done more quickly. I’m glad I gave it a shot.


On Google Wave

Google finally threw in the towel with Wave, saying that adoption rates just weren’t as they hoped. Many have said that Wave’s fail was that it launched as an invitation based service, which meant that you couldn’t really use it because Wave can only be used with other Wave users, and none of your friends had been invited yet. However, that’s not the reason; Wave still could have succeeded once everyone had access to it.

Here’s my take on it. The trouble with Wave is inherent in what it is: it’s an all-in-one communication tool. It’s part email, part chat, part word processor, part task manager, part twitter, part whatever the crap you want it to be. So where is the problem? Well, that’s not really a graspable and definable goal, so people had trouble understanding what it was really useful for in the real world.

Wave tried to do too much, which in turn made it seem like it didn’t do enough. It wanted to replace email, but it couldn’t contact people who weren’t already using it. It wanted to replace IM, but you had to use a browser for it to work, not an IM client. It wanted to replace collaboration apps, but lacked many of the task-specific features of such apps. Any app that attempts to be an end-all solution like Wave will constantly be plagued by people wanting it to do more to replace the individual tools they’re already using. It’s the age-old problem of doing many things, but doing none of them well

When it comes to successful apps, there are only two varieties: simple apps and onion apps.

Simple apps like Twitter (post your status, read others’ statuses), eBay (buy stuff auction style), Wikipedia (encyclopedia edited by everyone) are all deliberately simple. They are all easily understood at first glance because there’s nothing to not understand. They solve a problem that is easily defined and, as such, are instantly graspable.

“Onion apps” are just as easily understood, but their feature sets go a little deeper. Look at Google search, for example. At first glance, it’s an uber-simple search engine; the UI reinforces that. Then you see that you can also search for products and even buy products. And then you find out that you can search local businesses. You can even get maps and directions of those businesses. There are tons of really cool features that you slowly come across. This is what makes it an onion app – it seems simple until you peel (get it?) away at it a bit.

Facebook is the same way. At first, it seems like Twitter without the word restriction (i.e., a way to say what you’re doing and find out what others are doing), and people get that. Once that makes sense, then they notice that they can post photos and photo albums, and they can follow famous people and businesses, and they can even play games. All of this comes after the initial “oh, so that’s what this is used for”, or, once they are ready to peel away at it a bit.

And this peeling is why onion apps don’t suffer from the “it does too much” syndrome. Facebook, for example, could easily be ridiculed by saying that it’s for communication but it can’t replace email since you can only communicate with friends. However, nobody says this because we all understand that communicating with friends is the whole point of Facebook. It’s not a general purpose communication tool. This understanding may be false, since it’s used for much, much more now, but because of that initial impression and how Facebook presents itself, that’s all we really expect of it, so we don’t complain when we don’t get more.

This is Wave’s failure. Instead of being simple and graspable or even giving the initial impression of that, Wave gave you everything up front. It was an onslaught of “WTF is all this and what do I use it for” upon first loading wave, and that is a question that can’t really easily be answered, because it is “useful” for so many things. For Wave to have succeeded, it would have needed an actual problem to solve first and foremost, and focused on that problem, adding the rest of the features as layers.

So the point here is that for any app to be successful, it has to be understandable and it must solve a real, definable problem. You would think this is old news, but Wave obviously couldn’t do this, and sadly it had to die. RIP.


What to NOT say to soon-to-be parents

As a dad to be, I’m more or less a trained expert on this now.

Aren’t you SO EXCITED?!?!

Sure, we’re excited. We’re also nervous and stressed and paranoid and freaking tired of people asking if we’re excited.

(To the mom) Oh, you’re feeling [insert some horrible pregnancy related condition here]? Well just try [insert stupid home remedy or food here]! It works wonders!

No it doesn’t. Go away.

Oh, you’re going to name it [insert name here]? Well, what about [insert completely different name here]? I like that a lot better.

Hey, great! Let’s drop the name we love and decided on in favor of a random name from a stranger!

[Person starts rubbing the mom’s belly]

Good idea! Here, let me pick your nose.

[Upon seeing a random kid misbehaving] You better get used to that now! You’ve got one on the way!

WTF! I do?! And you’re telling me kids are bad sometimes? I want out!

Were you trying or was it an accident?

Don’t know what to say about this one. It’s just really really awkward to be asked that.

Are you going to have another one?

We were kind of hoping to have this one first, and then decide. Is that ok?


Progress ruins it (or, Drupal is boring)

I love Drupal, don’t get me wrong. I have a really soft spot in my heart for ExpressionEngine too. And WordPress always has its place. But I’m growing more and more frustrated at the various CMS’s out there for one reason and one reason only: they’re too easy. Here’s a typical day spent building a site in Drupal:

  • Fire up the browser and go to the admin section.
  • Click around and change a few options
  • Go to and download a few modules
  • Copy them to the /sites/all/modules folder
  • Enable them in the admin section
  • Click around and configure those modules for awhile
  • Log out, test the site as an anonymous user
  • Log in, fix whatever didn’t work (usually permissions issues in my case)
  • Repeat until the site is finished.

Of course, this isn’t always the case. Often you’ll run into cases where custom modules need to be built or contrib modules need to be extended, etc., but more often than not, you can build a whole site without any code. The exception to this is the templating which is really more annoying than fun. To illustrate, here’s the process for templating in Drupal:

  • Start with a PSD
  • Slice it up
  • Code up a static template with flat HTML/CSS (this is usually the fun part)
  • Create a new Drupal theme (usually by adapting Zen or Basic or BlueTrip or Starkish whatever)
  • Delete all preloaded CSS and upload your CSS
  • Open up page.tpl.php and throw in your container divs
  • Spend a while changing your CSS selectors to match what Drupal gives you

Boo. Coding is all about finding clever solutions to unique problems, and so far, the only part of the Drupal process that lets us do that is the slicing and dicing, which isn’t even really part of the “Drupal process” if you think about it. The beginner to novice at any of these CMS’s will love this, because it’s amazing the amount you can accomplish in a short period of time without even really doing anything yourself. That’s great right? Well yeah, sort of. It’s great for budgets and time constraints. It’s great for happy clients.

But it’s just not any fun. We didn’t learn how to build compilers and optimize enterprise web applications in school so we could click around all day. After the first couple sites built on Drupal, you find yourself hungry for coding. You need to code! You need syntax errors and for loops and SQL queries, all that meat and potatoes stuff that comes along with web development. And don’t say “well just code your own modules, then!” because that ruins the point of using a CMS. Why use something on the basis of it being so powerful if you’re just going to ignore all that and make it powerful yourself? That’s stupid.

It seems to me that we’ve taken so many steps forward by now that we need to take a couple steps back. I can now set up a full-featured ecommerce site with no coding whatsoever. I can set up a social network with nothing but a tiny bit of knowledge about FTP and Databases, and access to Google. Drupal is the “Self-Checkout” of web development: it’s progress because it saves time and money, but it’s depressing because it invalidates the education and jobs of the cashiers who used to do the checkouts (ok, maybe a bad example). I find it hard to believe that I’m called a “web developer” when all I do is enable and configure somebody else’s code.

I feel like I need to mention the happy medium: frameworks. Anybody else tried Django? Or CodeIgniter? Or Cake? Or anything out there? If you have, I’d be willing to bet you enjoyed it. Why? Because it let you code! And we’re not talking about the grunt code of opening and closing DB connections or validating email addresses. We’re talking about the awesome stuff…intense image manipulation algorithms for example. Or unique user input processing. Or anything cool and not boring.

I will never say that frameworks are gaining ground because they’re the end-all-be-all of web development. They’re not. If anything, Drupal is, because it makes everything so doable. But frameworks are gaining ground because they’re the perfect balance. You can do just enough coding but also have just enough handled for you. But the CMS is still king, and looks to stay there for awhile.

I don’t know if there’s really anything intelligent to take out of this. Drupal will be around for awhile because of the amazing timesaver that comes along with the extreme power and modularity. Developers will still push it because faster site turnaround in general means more sites which means more cash, and the average worker will take more cash (i.e., Drupal) over more interesting projects (i.e., Django) any day. And I can’t say that I wouldn’t. We all have to eat. It’s just a little disturbing to have your jobs reduced to pointers and clickers. It’s boring. It’s scary.

At the rate turnkey solutions are progressing, I’d be willing to bet that it’s only a short matter of time before the bulk of Drupal’s downloads go from developers to end users looking to cut out the middle man. I’m not going to say that we need to be worried about job security. There will always be the anti-DIY types, or the non-technical types, or the types who need really complicated sites (i.e., custom Drupal modules), etc. So don’t call it paranoia. Just call it food for thought. Call it stupid. Call it Ralph. I just think it deserves your point-and-click brainpower for minute. Thoughts?


Just water in our bodies

I haven’t talked about my dad in a while. I just woke up from a dream about him.

In the dream, somehow we found out that he only had a couple more days to live, because he got sick. After a bunch of really random things (you know how dreams are), we went out to eat for the last night. No restaurants were open, and he said it was because if they opened and he went there there would be a riot of people trying to get in to say bye to him. We finally found a place, and me and my sister had to sit on the floor for some reason. My parents kept trying to sneakily get me drunk, and I just pretended to drink. I thought that they probably assumed it would be easier for me if I didn’t remember the last night, but I couldn’t stand the thought of forgetting.

The next day, I went to his work to try and talk to some people he worked with while he was still alive. I remember hoping that when I got there, I’d find out that he hadn’t told anybody about it, because that would mean that he was playing a trick on us and he was really ok. I found some guy that I recognized, and stopped him on some stairs. He realized who I was and broke into awkward chatter about pointless things and wouldn’t make eye contact. Then my dad walked up behind him.

I said, “Hey dad.” He didn’t say hey back. He just said “Superheroes don’t give themselves their nicknames. Somebody else does that.” He paused and looked at me. He starting scrunching his face up to fight back tears, but I could see his eyes getting red. I knew then that it was real. “It’s all just water in our bodies,” he said.

That’s when I woke up. For a second, it was relief; the dream wasn’t real. And then it was.

On the upside, I went to Tsunami (the sushi place downtown) for the first time since I went with him the night before he died. I even saw the table we sat at. And I didn’t cry. That’s good right?

Or maybe crying doesn’t matter anyway. Maybe it’s all just water in our bodies.