programming

Meetings and Introverts

Erik Dietrich's blog, Daedtech, contains a lot of great posts concerning programming and workplace dynamics. In today's post, Meetings and Introverts: Strangers in Strange Lands Erik writes about the vexing relationship between introverted people and typical meetings. In a prior post, he wrote about the general problem of social situations and introverts:

Social situations are exhausting for me because of their inherent unpredictability as compared to something like the feedback loop of a program that I’m writing (or even the easily curated, asynchronous interaction of a social media vehicle like Twitter).

From the Server Check.in Blog: Keeping a Lid on Technical Debt

I recently wrote a post on the Server Check.in blog titled Improving architecture and adding features by containing technical debt. The post shows how the server checking architecture on Server Check.in was improved so it will expand horizontally and scale with new clients over time, and the main theme of that post was how managing technical debt (keeping it low for a small development team) has helped make sure new features and architecture improvements work reliably and simply.

The two main takeaways in the article are:

  • Simplicity and stability trumps features.
  • Get the architecture right, or die slowly.

I hope you can take the time to read the whole post, and also this excellent explanation of technical debt by Martin Fowler.

The Drupal Way™

The Drupal Way

I've worked with a wide variety of developers, designers, content managers, and the other Drupal users in the past few years, and I'm pretty sure I have a handle on most of the reasons people think Drupal is a horrible platform. But before I get to that, I have to set up the rest of this post with the following quote:

There are not a hundred people in America who hate the Catholic Church. There are millions of people who hate what they wrongly believe to be the Catholic Church — which is, of course, quite a different thing.

Forgive me for diverging slightly into my faith, but this quote is from the late Fulton J. Sheen, and is in reference to the fact that so many people pour hatred on the Catholic Church not because of what the Church actually teaches, but because of what they think the Catholic Church teaches. Once someone comes to understand the actual teaching, they are free to agree or disagree with it—but there are comparatively few people who disagree with teachings they actually understand.

Similarly, the problems most people have with Drupal—and with systems like it—are problems not with Drupal, but with their perception of Drupal.

Java Jane: One-off vs. Flexible Design

A Java developer (let's call her Jane) is used to creating a bunch of base object classes and a schema for a database by hand, then deploying an application and managing the database through her own wrapper code. Jane is assigned to a Drupal project, takes one look at the database, and decides that no sane person would ever design a schema with hundreds of tables named field_data_* and field_revision_* for every single data point in the application!

Why does Drupal have So Many Database Tables?

In reality, Drupal is doing this because The Drupal Way dictates that things like field data should be: flexible (able to be used by different kinds of entities (content)), able to be translated, able to be revised with a trackable history, and able to be stored in different storage backends (e.g. MySQL, MariaDB, MongoDB, SQLite, etc.). If the fields were all stored in a per-entity table as separate columns, these different traits would be much more difficult to implement.

Thus, The Drupal Way is actually quite beneficial—if you want a flexible content management system.

I think a lot of developers hate Drupal because they know they could build a more efficient web application that only has the minimal required features they need by simply writing everything from scratch (or using a barebones framework). But what about the next 72 times you have to build the exact same thing, except slightly different each time, with a feature that's different here, translation abilities there, integration with Active Directory for user login here, integration with a dozen APIs there, etc.?

There's a maxim that goes something like: Every seasoned web developer started with plain HTML and CSS, or some hosted platform, then discovered a dynamic scripting language and built his own CMS-like system. Then, after building the CMS into a small system like many others but hopelessly insecure and unmaintainable, the developer realized that thousands of other people went through the same progression and ultimately worked together on systems like Drupal. Then said developer starts using Drupal, and the rest is history.

I know you could build a small system that beats the pants off Drupal performance-wise, and handles the three features you need done now. But why spend hours on a login form (that probably has security holes), session handling (ditto), password storage (ditto) forms in general (ditto), content CRUD interfaces, a translation system, a theme layer, etc., when you can have that out of the box, and just spend a little time making it look and behave like you want it? The shoulders of giants and all that...

.Net Neil: Letting Contrib/Bespoke Code Let You Down

A .Net developer (lets call him Neil) joins a Drupal project team after having worked on a small custom .Net application for a few years. Not only does he not know PHP (so he's learning by seeing the code already in use), he is also used to a tightly-controlled application code structure, which he knows and owns end-to-end.

Time Refines Code

Smooth stone

Legacy code—warts and all—isn't such a bad thing.

If it's built well, and maintained well, it probably takes care of the hundreds/thousands of edge cases with which your beautifully-rewritten new codebase doesn't yet cope.

Unless it's not well-documented (or self-documented), or incompatible with modern systems, it's often a better idea to refactor and clean up old code than to scrap a system entirely and rewrite from scratch.

Image from Thinking Through.

The Story of the PING Program

I love finding little gems like this: The Story of the PING Program.

The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:

ping goodhost | sed -e 's/.*/ping/' | vocoder

He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.

Don't Wait, Delegate! Proper use of threading and queueing

There are hundreds of ways you can improve your app or website's performance, but few have the potential to improve your app or website's responsiveness as much as queueing or using background processes. There are so many complex operations that can be improved by looking at them in a new way. For example:

Not-so-Instant Oil Change

I like changing the oil in my car, but it often takes a bit of time (definitely not an 'instant!'), and involves the following:

  • Drive to auto parts store, pick up oil and oil wrench, and drive back (30 minutes).
  • Jack up front of car on stands (5 minutes).
  • Drain oil into oil pan, remove old filter, prep new filter (5 minutes).
  • Install new filter, refill oil reservoir (2 minutes).
  • Remove jack stands, clean up mess (5 minutes).
  • Drive to oil disposal center with old oil in pan, and drive back (20 minutes).

Total elapsed time: Over 1 hour! Maybe it's worth spending a few extra bucks on an 'instant' oil change to get back 45 minutes of my life.

Dreaming in Drupal

How do you know you've been thinking about work too much? When your wife relates a conversation she had with you in the morning, and you don't remember a word, but can definitely see how what you said relates to what you're working on:

Saith my wife: "Jeff, how do you set your alarm?"

My (groggy) reply: "Hit field, the arrow, then default."

Now, this could possibly have something to do with alarm clocks. There are often arrows on them, and you hit buttons... but I know better. I was referring to:

$this->addFieldMapping('field', 'source')->defaultValue(0);

...which I have probably typed about 100 times in the past week, and maybe 20 or so last night during a late-night debugging session with the Migration process of flockNote v2 to v3 (from a proprietary WAMP-based system to a new Drupal 7 LAMP-based system).

On Writing Documentation

I've been slowly reading through "Coders at Work," an excellent book in which Peter Siebel interviews many different programmers on their work and craft, and I hit a great little snippet of advice from Peter Norvig:

"The overall design of what's going to do what, that's really important to lay out first. It's got to be something that everybody understands and it's also got to be the right choice."

Basically, before you start doing some huge project, have a bit of a meta discussion about what you're trying to do. Document the process / steps, make sure it makes sense, and code to that process. You don't need to necessarily comment on every little tidbit of code you write—code should be somewhat self-explanatory if written well—but you should at least document what your functions do, and what kind of idea you're trying to implement.

Plus, if you document beforehand, you'll be able to conform code to documentation, and at the end you'll have a framework of your docs already complete!

Catholic Programmer's T-Shirt and Mousepad

Reposted from Open Source Catholic:

A few weeks back, after finishing a full day of swimming in PHP, HTML and CSS, I was pondering the great mystery of human existence, but probably had a little too much to drink. The result?

Catholic Programming - Design

You can buy the design on the following products (via Zazzle):

Would you like the design on anything else? I could do a mug, or socks, or anything else in Zazzle's catalog...

Alternatively, can you think of a way to code this better? ;-)

Subscribe to RSS - programming