You can tell weather or not someone really “gets” unit testing by asking them one simple question, “Do you use mock objects?” Almost invariably, they will say “no”. Even people who have totally gotten the testing religion. It’s like watching someone pray to a statue of Jesus; totally oblivious to the fact that Jesus himself is standing four feet away reading a book.

This is partially due to the fact that most geeks don’t actually know what a unit test is. They think that testing the methods of a specific class constitutes a unit test, but that’s only part of the story. A unit test test is when you test the methods of a specific class in isolation, and the difference is critical. You know how some people call us “computer scientists”. Yeah, well this is the science part.

Imagine you were creating a new medicine, and wanted to test it out on some cells in a petri dish. The weather was so nice you decided to take your dish outside and enjoy the sunlight while you ran your test. It’s a resounding success! Or… is it? How do you know it’s wasn’t just the UV rays from the sunlight? Or maybe there was something floating in from the nearby blossoms? You don’t, and you can’t. You can’t even say, with any confidence, that the medicine worked. Something worked. Maybe the medicine had a part in it, maybe it didn’t. You can’t tell.

The same thing applies to unit testing. If you’re not testing in isolation there is no way to know that the thing your are testing was actually effective or if it just happened to work in the current environment, and when the test fails there’s no way to know (without digging) if your code was responsible, or if something it relies on has broken and passed on its problems. Mock objects are the best tool we have for addressing this problem.

A Mock What?

You probably already know, but just in case, mock objects…

“…are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.” - Wikipedia

In practice it is a functional guarantee that a foreign object/method/API, will behave in a specific way regardless of its implementation. You figure out exactly what a call should return and then you encode that in your mock.

Why?

Let’s look at an example. In a banking application a User would have one or more Accounts, and it’s not uncommon for the User and Account objects to each have methods that reference the other. Maybe, the User object has an available_funds() method that adds up all the available funds in each of the Accounts. User is depending on each Account object to correctly calculate the current balance, minus any outstanding charges. Problems arise when there’s a bug in how Account is doing its calculation. Now, the test of your User’s available_funds() method is failing, but you can’t tell if it’s because it was performing a bad calculation or Account was. Even worse, it could be that there’s bad data in the database, or that someone changed your test data but didn’t update the tests. All you know is that the number expected isn’t the one received.

The problem with this setup is that you’re no longer testing your User object when you do this. You’re testing that the code in your User class works if the code in the Account class also works. The typical solution of carefully chosen test data in a database does not solve this problem in any way. The only thing it does is add in another source of potential failures and misdirections, and provides yet another thing to maintain.

Using mock objects allows you to test that the User class works regardless of how broken the Account class may or may not be, with no database installed anywhere, and no separate fake data to maintain. You create a real User object and mock up the calls to Account to return mocked account objects, mocked data, whatever else is appropriate.

If you’re not doing this, you are not unit testing. That’s not meant to deride what you’re doing. I mean that as a literal statement of fact. Anyone, for example, who is using the built in Rails “unit” testing framework with fixtures (or FactoryGirl fixtures) is guilty of this. No test that relies on a separate class, or API, or interfaces with a database in any way is a unit test. It is an integration test (some people call them functional test), and when something goes wrong it is just a matter of time before it misleads you.

Now, integration tests are great. They serve the very useful function of guaranteeing that your code works within the context of the expected ecosystem, but they’re not very good about telling you exactly what has broken.

People will disagree with me on this. They’ll argue that testing with the db and other classes isn’t bad, that they can generally tell what’s broken very quickly. And it’s true that a developer with a good knowledge of the system should be able to figure out what’s causing a test to fail pretty quickly, but until they start digging there’s no way to be 100% confident that the bug is where the unit test claims it is because of all the other things that could affect it.

But that’s not all

The process of creating mocks to support your tests will very frequently reveal unexpectedly tight coupling’s between classes and systems. Because you need to mock up every interaction with a foreign anything, you end up creating a bunch of additional lines in your test. Each one is an expenditure of effort and each one represents a coupling. If the object you were testing wasn’t coupled to anything else you wouldn’t need to mock anything. Adding a few lines of mocking to your test is no big deal, but when you have 20+ lines of mocking in a single test it’s a strong indication that something is wrong in your system. If you find you can’t figure out how to mock something up it either means that you don’t really understand what the thing you need to mock does, or that it suffers from a notably poor design.

Mocking should always be easy, and quick. The only times it isn’t are when you’ve got a poor design, or an insufficient grasp of what you’re attempting to test. These are both very good things to have revealed.

Sometimes, the mocks will reveal bad designs, or excessive coupling’s in an library you didn’t even write. Part of the reason I started writing this article was because of just that type of situation. I was trying to unit test a Rails controller. Typically people just don’t unit test rails controllers. They do functional tests that tie in the controller methods, the database, and the view generation, which again, is useful, but doesn’t do a great job of telling you exactly what is broken when the test fails until you start digging. Anyway, the methods I was testing required an the user viewing them to be logged in, but try as I might I could not find a way to successfully mock it so that it never touched the database.

I assumed that I simply didn’t understand the library, and began looking and source code and googling around. After hours of trying, and failing, to make it work I eventually started Googling from a different angle and discovered that the problem was that it simply wasn’t possible (by any reasonably definition of the word) to test this library with mock objects, even leveraging its test helper classes. The thing was so tightly coupled to the underlying database that it demanded the presence of a test database with appropriately structured fake data to even create a test login.

I had to make the choice of either giving up on any hope of decoupling my tests from the database or throwing out a working authentication system. I care about my users, and I care about being able to guarantee that my sites work for them, so I spent two evenings throwing out that system, learning and implementing a new one, figuring out how to test it without touching the database, and then making all my controller tests work again.

It was worth every minute.

Reasons not to use mocks

The downside to mocking everything is the inverse of not mocking anything. If you don’t do pure unit testing, and don’t mock anything you can never be 100% confident that your objects work in isolation. If you don’t do integration testing and do mock everything you can’t be 100% confident that your objects work in concert with each other.

A combination of unit tests and integration tests is always best. There’s no reason not to build both. It just makes your system more robust and catches more bugs before they are released. But, if I had to choose one only one method, I would choose pure unit tests with mock objects for two reasons:

1. The objects you test in unit tests constitute the foundation, the building blocks, of your system. If they have problems then everything has problems. I want the maximum possible confidence that each of those building blocks is reliable and well crafted.
2. The process of mocking up the interactions with other objects gives me a far better understanding of how my system works and frequently reveals design flaws in my code, and the libraries I’ve chosen to use. Exposing and correcting those flaws helps improve the maintainability of my code.

I realize this is not the popular choice, and many developers, would argue that if you’re going to write only one test it should be an integration test. There are good arguments for that, but there are no good arguments for doing either without the other.

A moment for FactoryGirl

This one is specifically for the Ruby geeks, but I’m sure there are similar tools for other languages. FactoryGirl is a system that allows you to easily create named fixtures with the data you need.

“When you invoke a factory, factory_girl uses your definitions to compile a list of attributes that should be assigned to that instance, as well as any associated factories… To create an instance, it calls new without any arguments, assigns each attribute (including associations), and then calls save!”

In other words, it’s a nice wrapper around what is an inherently bad idea for unit tests. In fact, using it guarantees that you are not writing unit tests.

From what I’ve seen FactoryGirl is almost always used as a bad stand-in for mock objects. It is a good solution for your integration tests, where you actually want to test that items can be sent to and retrieved from your database from the other parts of your system, but it should never be called from a unit test because that is precisely what you don’t want happening in that situation.

Chris Parsons has a good writeup with plenty of code examples about FactoryGirl vs mocking that you should check out.

The Takeaway

There is immense value to testing in isolation and the process of creating mock objects to support that testing. If you’re not testing in isolation, you’re not writing unit tests.

If you haven’t been using mocks, take the tiny amount of time it takes to learn how one of the popular mock object frameworks for your language, and start updating your unit tests to be true unit tests. Make sure that every new one is a true unit test, and every time you have to touch an old one take a moment to replace the fixtures with mocks. It will be worth it in the long run.

Resources for Ruby Geeks

In the Ruby world we have a good number of mock object frameworks.

• Mocha is probably the best known, and from what I’ve seen most widely used.
• Flexmock is another option, but I have essentially zero knowledge about it.
• RSpec has a built in mocking library called RSpec-Mocks. I have spoken with a number of RSpec users who prefer to use other mock libraries like Mocha instead of RSpec-Mocks. I’ve never gotten the RSpec religion so I can’t comment one way or the other.
• RR (Double Ruby) is a lesser-known option. The syntax is very nice (not nearly as verbose) and it offers some nice features like Proxies and Spies that other frameworks don’t.

Personally I’m a fan of Mocha and RR.

I interview a fair number of geeks every year and usually spend my alotted time going over one programming challenge. Lately I’ve been looking for a new one that was simple, but still big enough to give me a glimpse into their thinking. I think I’ve found it.

Why I Like This

I really like this question because:

• A good solution involves recursion but you could approach it in multiple ways.
• The seemingly simple Array throws a monkey-wrench into the whole thing.
• It tests their ability to follow written instructions.
• It should give an idea of how willing they are to ask questions.
• It’s small, but with 3 separate, but connected, things to handle should be enough to give insight into how they work through things.
• Some people will be able to plow through it in 5 minutes. Some will take 20.

The Question

You’re presented with the following YAML structure which you need to convert to a useful data structure, but for whatever reason you don’t have a YAML library. You do however, have something that’ll convert it into a tree of nodes.

Each node has some useful methods you can call:

• node.name returns the name of the current node or null/nil if you’re looking at a node in an array.
• node.value returns a node
• node.type will be Array, Hash, or String
• node.next will return you the next node in the tree at the current level
• node.children will return all the child nodes.

The goal

Take the following YAML and create a data structure that looks something like this (Ruby notation)

1
2

en-us['date']['formats']['default'] #=> contains "%Y-%m-%d"
en-us['date']['day_names'][1]       #=> contains "Monday"

Notes

Keep in mind that Arrays items can themselves be Hashes, Strings, or other arrays.

The Yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

"en-US":
  date:
    formats:
      default: "%Y-%m-%d"
      short: "%b %d"
      long: "%B %d, %Y"

    day_names:
      - Sunday
      - Monday
      - Tuesday
      - Wednesday
      - Thursday
      - Friday
      - Saturday
  time:
    formats:
      default: "%a, %d %b %Y %H:%M:%S %z"
      short: "%d %b %H:%M"
      long: "%B %d, %Y %H:%M"
    am: "am"
    pm: "pm"

There are two good reasons to serve Octopress from a self-hosted git repo.

1. It provides you with an off-site backup in case your local copies go up in flames.
2. It gives you an environment where you can integrate secondary scripts and libraries that allow you to do things like e-mail posts to Octopress.
3. git provides a very efficient, and atomic, means of uploading your files.

Complicating factors:

1. Not all ISPs have ssh access or the latest version of ruby, and may not have git or Bundlr installed.
2. Because of the above you may not be able to regenerate html files from markdown on the server.
3. You need to have a basic familiarity with navigating directories and editing files over ssh.

These instructions are not for people uncomfortable with using the command line in a *nix environment. Of course, if you were uncomfortable with that you probably wouldn’t be using Octopress in the first place.

In order to do this you must have ssh access to your server, and have git installed on it. In order to generate new files on the server you must also have Ruby 1.9.2 (or higher) and Bundlr installed You must also have a basic understanding of how to get around on a Linux command line. This is not uncommon these days, but in order to check just ssh in and type:

1
2

which git
which bundle

If they both return a path to the executable you’re all set. If git is installed we can proceed without problem. If git and bundler are installed and ruby is at 1.9.2 we can generate the html on the server. For those not already familiar, which xxxx will print out the path of the executable if it is installed and on your path. If it returns immediately with no output it is either not installed or not on your path.

Next check the ruby version:

1

ruby --version

Octopress requires a recent version of Ruby to run, so if it says anything lower than 1.9.2 you will not be able to generate files on the server. Talk to your ISP about installing a more recent version of Ruby. You will, however, still be able to use git to transfer files to and from your server, serve from its generated directory, and act as a backup.

There are a couple ways to make this work. You could just host a non-bare repo on the server and set receive.denycurrentbranch to ignore so that you can push to it, but for security reasons, and safer removal of deleted posts it’s better to use a detached work tree.

SSH to your server, and create a new bare git repo somewhere that will not be served to the public.

1
2
3
4
5
6
7
8
9

#on the server
mkdir octopress_blog.git
cd octopress_blog.git
git init --bare
# core.worktree should point to a directory where 
# everything will be checked out into, but not 
# visible to the public. You must create this 
# directory. Git will not create it for you.
git config core.worktree /path/to/staging/directory

Once you’ve done that we need to set up the post-receive hooks. Create a hooks/post-receive file (in your bare repo) and make it look like this.

1
2
3

#!/bin/sh
# checkout the files after they've been pushed here
GIT_WORK_TREE=/path/to/staging/directory git checkout -f

Next, make it executable

1

chmod 755 hooks/post-receive

Later we’ll tweak hooks/post-receive to auto-generate the site (if you’ve got the pre-requesites on your server) but for now we just want to make sure we can push to it successfully.

Back on your local computer:

1
2

cd my_octopress_blog
git remote add live me@example.com:/path/to/octopress_blog.git

Now try pushing to it:

1

git push live master

It doesn’t have to be the master branch but that’s what most people use so we’re working from that assumption. It should push without problem, but pay careful attention to lines starting with “remote:”. If it does have problems, you should be able to figure out what’s wrong from the error message. At the end of the push you should see a message from remote saying “remote: Checking out files:…”

Back on your server take a look in the directory you pointed core.worktree at and see if your blog has been checked out there. From here on out we have to divide the instructions for people who can generate files on the server, and people who can’t.

To generate server-side or not….

Generating HTML server-side

Generating the html files server-side is good because you can set up things like JekyllMail to allow you to post to your Octopress without having to have a local checkout (great for blogging from work). Another benefit is that your “public” directory doesn’t have to be a subdirectory of your Octopress checkout. You can tweak your _config.yml to generate it anywhere on the server which can make server configuration easier for some. If you do change the destination attribute in your _config.yml on the server to a path that differs from your local version you’ll have to be careful to not commit any local changes to it.

Caveat Emptor: On shared servers there is one gotcha that you’ll have to be aware of. Long-running scripts are frequently auto-killed by the server so that one user doesn’t consume an unfair amount of resources. Until such a time as Octopress is capable of regenerating only the new posts there is the possibility that large blogs with hundreds of posts may exceed this limit and the generate script may be killed before completion.

Generating HTML locally

The only notable advantage to generating locally and pushing to a server-side repo is it works on servers where you have git but can’t run Octopress’ generate script for whatever reason.

Serving from a self-hosted git repo without generating HTML files server-side.

This is the simplest way to go, but it requires one change to the standard Octopress workflow, and the ability to point your server at a specific directory to serve your site from. In your workflow you’ll need to commit everything in your public directory each time your run rake generate, then push to the server. You need to be sure to add & commit any files deleted from your public directory after generation too, or else a deleted post will not get deleted on the server. Typically you can just say git add public each time and it’ll take care of managing the deleted files too.

Since the HTML files are going to be generated in a subdirectory of your Octopress repo (typically called “public”). You’ll need to point your server to the public directory under the directory that your core.worktree option is pointed at. Feel free to rerun the command above that set it if you want to change it to a different place now that you know everything works.

Once you’ve pointed your server to the appropriate directory all you will need to do to update your site and create an offsite backup of the original markdown files (and everything else) is to locally run

1

git push live master

Serving from a self-hosted git repo and generating HTML files server-side.

You’re going to follow the same steps as serving without generating files except you won’t be committing the “public” directory’s contents.

You’ll also need to add the following to the end of your hooks/post-receive

1
2
3

cd /path/to/staging/directory
bundle install
bundle exec rake generate

Note, if you’re using RVM or a custom gem path you may need to add those to the start of the hooks/post-receive script so that git will have it in its environment when it runs. For example, on Dreamhost you would have to add something like this to the top (assuming you’d already installed RVM and the current version of Ruby):

1
2
3

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
GEM_PATH=$GEM_PATH:/home/my_username/.gems
PATH=$PATH:/home/my_username/.gems/bin

Make a commit locally, push it to the new repo, and confirm that your changes have been pushed to the staging directory and that rake generate has done its job and placed the new html files in your “public” directory (or wherever your _config.yml has destination pointing to).

Once you’ve confirmed that that works you can (optionally) change the /path/to/staging/directory to point to somewhere that isn’t just for testing in the hooks/post-receive file and in the core.worktree setting. All that’s left is pointing your server at whatever directory your _config.yaml’s destination is pointed at.

From then on you just run

1

git push live master

on your local machine to update your blog.

This is a simple idea for every web development company (small or large) that owes its existence to open source software. I’m going to use Ruby on Rails as an example, but this is just as applicable to all of the other frameworks and tools we use daily.

On the first Wednesday of every month all of your developers work on bugs or needed features in one of the frameworks or tools that your company can’t live without.

The thinking is simple, and entirely self-serving:

A typical Software As A Service shop, or web development house is constantly depending on the quality of frameworks like Rails, but these frameworks are riddled with bugs and lack features that would really help.

No-one worth their paycheck would allow their own products to remain in a state like that, and yet we typically do nothing about those things in the frameworks and tools we are utterly dependent upon. Spending one day per month working on tools like these is not an altruistic move. It is a form of self defense. It makes your product stronger, and helps to guarantee that the tools you’ve built your company around will not fall by the wayside.

Improving the quality of the tools we all use helps to keep them popular, and popular tools get maintained and enhanced by more developers.

Contributing to the tools you work with regularly also helps build up your company’s reputation with the developers you most want to hire.

Open Source Wednesday helps your business, your customers, and your ability to attract the best talent.

How exactly is this done

Implementing Open Source Wednesday is simple, and there are a couple ways to approach it. One way is to simply point your developers at the issue tracker for the tool you want to contribute to and have them each choose a bug or feature request they think they can knock out in a day. Get together in the morning, make sure everyone’s working on something different, or intentionally joining forces, and set them loose.

If there’s a particular bug, or missing feature, that’s been impacting your daily work you might want to have some of your developers specifically attack that.

The thing to keep in mind here is to not take bugs that can’t be addressed in a day if you’re only going to work on them once a month.

Open Source Wednesday also serves as a useful change of pace. Letting your developers work on things that interest them outside of the tasks they’re faced with every other day helps to refresh the mind. And working in the different codebase is likely to teach them new techniques that can be applied to your business’ code.

What else?

That’s it. Go. Write something cool.

Why Wednesday?

I was looking for a day of the week that was somehow connected to the idea of “open source” and realized that “open” sounds like Odin who used to be known as Wōden and Wednesday is Odin’s day / Wōden’s day / Oden Dag/. Open -> Odwin -> Odwinsday -> Wednesday.

His name is related to ōðr, meaning “fury, excitation,” “mind,” or “poetry.” And what is code if not mind poetry? Wednesday seemed just about perfect.

Where you spend your time developing is an important decision for an open source developer. Partly we do it for personal satisfaction, partly we do it to give us a tool we want, but there’s always a part of us that wants others to use and enjoy our work. I want to talk about that, and I want to talk about the frustrations that people who use those open source projects have, but first I need to set the stage. Paul Ruoget (@paulrouget) has been working on a cool live CSS editor for Firefox which should be out in FF 11.

When he proudly mentioned this on Twitter I responded in a less than helpful manner:

That’s great, and something i’d find useful… but right now all i really care about is seeing FF be as fast as Chrome.

I’m happy to say that Christian Heilmann (@codepo8) called me on it.

can you imagine how frustrating such a tweet is when you spent a few month building this great tool?

and later…

The point is that sweeping statements like that don’t help anyone. Your tweet might make people move, building good dev tools not

I think he was trying to say that stupid statements like mine, borne out of frustration from something only tangentially related can lead developers to simply stop contributing at all. He’s totally right, and I’m sorry I said that Paul.

At the same time, I am frustrated, and while it’s not even remotely Paul’s fault this frustration is shared by many many webdevs and it does affect Paul, and everyone else who wants to develop cool things for Firefox.

Firefox is slow. Once upon a time it was the king of the hill. We switched to it because it was soo much faster than anything else, and then tools like Firebug came along and FF became a joy to use for developers.

Somewhere along the line that changed. For reasons I can’t explain FF has become notably slower than the alternatives… and that is the only comparison that matters. A slow browser is fine if there aren’t any speedy ones you could use instead, but Google has put Chrome out there and, by comparison, it feels blazingly fast. I can feel the delay every time I open a new window in Firefox.

I just tested it. It just took nearly five seconds for FF to open a new blank window. I regularly see delays of one to five seconds. It always takes a fraction of a second for Chrome to do it and I’ve always got way more open in Chrome. Honestly, I don’t like Chrome… not when compared to FF. But every single action we perform in our browsers is affected by the underlying speed of that browser. For a web developer with 20+ tabs open with research, test, and reference pages open all day long this is a huge deal.

And that’s how we end up with people like me saying stupid shit to people like Paul who are trying to make our lives better.

But… I am a developer too. I’ve got a FF extension, a useful Greasemonkey script, and a few cool Ubiquity tools that are all sitting abandoned for the simple fact that I am unwilling to add that kind of delay that Firefox demands to thousands of actions I perform every day. No, I’m not saying that everything in FF takes 5 seconds longer, but I am saying that everything in FF feels like it takes longer than the alternative.

I look at what Paul is doing and think that
A) there’s already live css editing in the Web Developer extension.
It’s probably not as good, but it’s there) and Firebug has it to some degree too.
B) Here’s a guy building something cool that developers like me are never going to use because the environment he’s chosen to do it in is slow, and loosing people like me to the competition at an astonishing rate.

So why is he writing it at all?

Firefox developers have been making progress in speeding up FF, but it’s a hard problem, it’s taken them a long time, and it still feels like they’ve got a long way to go before they catch up. Now, I say “feels” here because that’s what’s important. Numbers don’t matter to end users. It’s all about perception.

Consider this little story from the guys at Panic regarding a metting they had with Apple.

Jeff Robbin then asked us a funny question that had obviously been percolating for a while: “Does Audion do any kind of special filtering?” You see, since the beginning of time, press reviews in magazines, websites, etc., had consistently said that Audion simply sounds “better” than SoundJam, without question. It wasn’t until that declaration showed up in a very respectable, high-end British Hi-Fi magazine that people started to take it even more seriously. Audion was always noted for being “richer” or “sweeter”, and we were tremendously proud of our incredible results in this regard.

The only problem was: we didn’t do anything. We have no idea why people heard Audion as sounding better.

I try and put myself in Paul’s shoes and have to wonder if I’d think it was worth it. Sure, he loves FF, and maybe that’s good enough reason to stick with it. But, I just like Firefox, and wish that it was keeping up because I love the tools I used to use with it. If I wanted to build a kick-ass live CSS editor I can’t say that I would be willing to build it for FF right now.

And that’s a question we all have to ask when we’re developing something that’s completely dependent on some larger project beyond our control. Is loving the platform enough? Even when thousands of the people who would benefit from your work are leaving it?

Saying “be faster” is like saying “be better” Of course we are working on performance. But we can’t work only on perf - Paul

He’s right, and yet, at the same time I think he isn’t. Firefox has better tools, better extensions, better extensibility, better everything, but every action you take on it either is slower or feels as if it is. Would Firefox really be hurt in any notable way if it actually did apply every resource at their disposal to speed improvements? I realize this isn’t realistically possible, because not every developer has the skills needed to address the problem, and no-one wants to see the other aspects stagnate, but I think it’s still a valid question.

Christian is right that those of us sitting on the sidelines shouldn’t disparage those who are doing good work, even if we think they’re doing it on a sinking ship. I really hope that FF can come back from setback that Chrome has presented it, but in the meantime where does a developer put their energy and what is the best way to keep them from not contributing at all.

I should have said something like this:

That live CSS editor looks great.

… but how do I tell Paul, and people like him that as much as I appreciate what they’re doing, and as much as I really want to use it, I’m saddened to and frustrated to think that thousands of people like me may never touch it, because of something it’s tied to that he has no control over? Is there any way to do that without discouraging them? Is it better to just shut up and leave them to their dreams?

Maybe…

I’m sorry that this post, and my earlier tweets are probably disparaging to Paul. That’s a shit thing, but even if I had the polite social interaction thing down, it seems like in the end the only way to avoid future occurrences is for people like me to not ask “why?”, or at least not publicly discuss what comes out of those thoughts.

The uncomfortable state of things doesn’t have to be the end of it though. People like Paul love Firefox enough to devote serious amounts of time to making it better. I think it sucks that we are in a situation where asking “Why is he bothering?” has some legitimate value. But maybe if more of us stopped taking the easy route of jumping ship to whatever competing tool is “better” at the moment we would actually take a moment to help bring the tools we “loved” back into fighting shape.

I may not have the skills needed to make FF faster, but I’ve got some decent JavaScript skills that could probably be used to help improve the test JavaScript test suite. If you’re a geek like me who’s gone to the land of Chrome, but lament all the great tools you’ve left behind, consider swinging over to the Firefox Bug Tracker and see if there’s a small task or two you can help out with. If nothing else there’s probably a bunch of bugs in there needing confirmation.

Maybe, if we get off our asses, we can help get Firefox back to being the most awesome browser around. I know I’d love to have my default browser be the same one with all the cool tools.

At our house, you go to the bathroom armed, or you don’t go at all. At least, once the sun goes down. There’s a pistol wedged between couch cushions with handle raised for easy access as we watch TV. You think I’m joking, that maybe the gun is metaphorical, or that this is the start of some fictional story. It’s not. Every word is true.

It all started a month or two ago. We’d hear them moving around. Little sounds. Things you could write off and not really worry about: “Probably just a mouse…” But each night the sounds got louder. The little scratches escalated until they were thumpings on the wall. And then the hole opened up, like the gaping maw of hell itself. It would almost be better if it really was an entrance to hell. At least with hell there’d be flames, or something. But this is just blackness, silent and dark. Maybe the Christians have it wrong.

We take turns staring at the hole now. We stand watch… once the sun goes down, the dogs safely ensconced upstairs. They’d just be collateral damage if we let them out. Part of me wonders if there’s a point. We don’t know if our weapons will even effect them. We’ve shot at them before with no effect. They’d hear the sound, or maybe see us moving the gun into position. Maybe they simply hear the explosion as our projectiles exit their chamber and step out of the way.

They haven’t touched us… yet. But they’ve come close. For the past couple days, ever since it happened, I’ve been having flashbacks. Adrenaline coursing through my system as I hurled myself backwards watching it pass inches from my face and set my heart pounding at a thousand miles an hour. I don’t think it was even trying.

We tried laying out a field of glue. Some super adhesive stuff. I think they may actually use a variant of it as an organic equivalent to waxing legs. Heat it up, slather it on, add cloth, and rip… Depilation was not our goal though, nor were we so naive to think that it would actually capture them. No, we were hoping that maybe, just maybe, it would slow them down enough to get a shot off, that maybe, it would buy us a moment of distraction, just long enough to aim, and fire.

All it did was annoy them, and I assure you, you do not want to annoy them.

We’ve put in a call for bigger guns. Gods help us.

The idea is that it can be very useful to base64 encode an image directly into your css file instead of referencing a separate file, but doing so usually involves dropping to the command line, calling openssl, copy-pasting the output, specifying the mime-type, etc… Bret’s Terpstra distilled all of that into one drag-and-drop command for Textmate.The following is simply a generalization and instructions for using the drag and drop in MacVim / GVim

First, take the following and make it into an executable somewhere in your path. That way you can use it from any app that can interact with the command line. I called the fill css_image

1
2
3

 \#!/bin/bash openssl base64 -in
"$1" | awk -v ext="${1\#\*.}" '{ str1=str1 $0 }END{ print
"background:url(data:image/"ext";base64,"str1");" }'

It’ll generate something like this (only much longer):

1

background:url(data:image/png;base64,iVBORw0KGgoA...AAAAASUVORK5CYII=);

Now, to call it from MacVim and have the output inserted into your file simply switch to command mode and type

1

 :r ! css_image

leave a trailing space and drag the file into MacVim and hit enter. Dragging it on when in this state will cause the path to the image to be inserted. Enter causes the command to be executed, and the output to be inserted into your file.

There are a few problems with Jekyll / Octopress though that would, realistically, make me less inclined to use it. First, you need to have your entire blog checked out on whatever box you’re posting from, and that is simply not something I’m willing to do on a work computer, and not something I necessarily can do when on a borrowed computer. Secondly, the user interface sucks. Well, there really isn’t one.

Being able to send e-mail to your blog and have it posted solves both of these problems. I can e-mail from anywhere, and there are tons of e-mail clients with good user interfaces, and there are good Markdown apps on the iOS that will e-mail off your Markdown formatted writings. I wouldn’t be surprised if they handled Textile too, but I wouldn’t know.

So, I did a little hunting around and found a script by Ted Kulp that works with procmail to post a Markdown, Textile, or HTML formatted post to a Jekyll blog. Procmail’s not an option for many of us, but POP3 is. So, I did a little hacking, added POP3 support, made some configuration and anti-spam tweaks and JekyllMail was born.

In addation to importing your post it will also save your image attachments. I heartily encourage folks to fork the repo on Github and send in pull requests.

Listen, you are an intelligent person, but someone has led you astray, and it is driving me nuts.

When you blog some information for the world to see, what you have created is a “post” more specifically, it is a “blog post”. Sometimes they’re “entries” but that’s more commonly associated with diary style blogs. In some cases a post could be considered an “article”, but those posts are never, ever, a “blog”.

Blog, as a noun, is short for web log, as in, “there were many entries in his log”. It is a collection of entries, and never a single entry itself.

Blog can, of course, also be used as a verb, in which case it is the act of creating one or more posts for a blog.

When you tell people that you have “a new blog” you are telling them that you have a new log of entries separate from any existing one. This is almost always an indication that you’ve decided to start creating a series of posts that are topically separate from the posts on your current blog. You are not telling people that you have added a new post to your existing log.

Unfortunately the latter is almost always what you intended to convey. So please, please, for all the people who follow you on Twitter, Facebook, Google+, and anywhere else you give notice of new posts, stop calling your posts blogs.

P.S. Some people have countered by suggesting that language is mutable and constantly evolving. While this is true, the word blog has not mutated to the point that it is interchangeable with the word “post”. Using it as a replacement currently only serves to demonstrate an ignorance of the actual meaning, and confuse your readers who know better. You’re an intelligent person. Don’t make yourself look ignorant.

• [Some perspective][]
• [What’s good][]
• [What could be better][]
• [Bugs][]
• [Would I recommend it?][]

Some perspective

I purchased Byword because I think Markdown is a spectacular way to write and was looking for an app that would allow me to create new documents, easily preview them and grab either the formatted preview text or the generated HTML.

Until now, I’d been using Marked for previews while I typed in Vim. Now, Vim’s great. I love coding in it, but it’s really not the greatest when it comes to writing text, and I’m not really a fan of any of the other apps that handle plain text well. So, I went off in search of an app specifically designed for creating documents with Markdown.

What’s good

It does what it claims. Easy markdown editing. It also supports Rich Text and Plain Text.

It’s nice to be able to bold or italicize with Markdown using traditional key-combos instead of having to manually type the asterisks.

Full Multimarkdown support.

You can use it in conjunction with Marked. No need to stop writing to preview the formatted version. Below we have Byword on the left in edit mode and Marked on the right reloading a preview of the changes whenever you save.

It’s only $9.99. Totally worth it. It’s nearest competitor iAWriter is almost twice the price at $17.99

What could be better

The default file format is Rich Text. You can change it to Plain Text or Markdown in the preferences, but I get the feeling that the creators were making a minimalist text editor and then decided to add on Markdown support rather than making a Markdown editor that also supports the other formats.

Preview can be a little slow sometimes.

If you look at the screenshots on the site you’ll see a little popover menu for text styling. That’s there, but only on Rich Text documents. In their defense most of the options there aren’t supported by Markdown, but it doesn’t mean it wouldn’t be nice to have a version of it for Markdown.

Its main competitor iAWriter has “reading time” as one of the running counts along the bottom in addition to the standard word count. I really wish Byword had this.

Like most apps that partially format your markdown while you’re typing it (making *foo* italic in between the asterisks, etc.) it bolds the headings, but there is no difference between a #, ##, or ### heading. They’re all just bolded. I really wish that apps like Byword would make the # headings larger than the ## headings, and so on.

Bugs

At the time of writing (Aug, 14 2011) there are a few bugs that I’ve encountered in my first few thousand words of writing with it:

If you like to balance out your heading tags with octothorpes at the end (e.g. # foo #) you can’t have any trailing spaces afterwards or the final octathorpes will be treated as text not formatting.

Clicking on footnotes in the preview has an odd quirk. The first time you click the footnote number (in preview mode) it opens in the default application associated with the document’s extension. Ditto for the first time you click the return link at the end of the footnote itself. The problem arises when the default application is not Byword. For me clicking the footnote opened it in Vim, but only the first time. Very strange.

Sometimes the traditional keycombos for making text bold and italic simply stop working. For some reason they no longer work in this document but do in others.

The documentation claims that “If you drag images into the text, they will automatically be replaced by a Markdown reference to the file.” Like the key-combo problem this seems to not work all the time. And when it does work it’s missing the initial exclamation point. When you drag an image from the browser you get a link in the markdown, and I don’t mean foo. I mean a blue underlined http://www.foo.com/img.jpg thing that you can click on in Markdown editing mode, which should never happen. When you drag an image from the Finder it gives you file name which ends up being a link instead of an image (because it lacks the inital exclamation point) and it’s a link that won’t work on any computer other than your own.

Saving a file with the .mkdn extension instead of the expected .md makes it cease to display correctly in editing mode (markup is no longer greyed). It still previews correctly though.

Searching for a word or phrase will highlight it, but hitting the delete key will not delete it.

Would I recommend it?

Yeah. Byword is a decent app. It doesn’t wow me, and the bugs are frustrating, but infrequent. The drag-and drop image linking that it promotes simply doesn’t work in any useful way, and I’m annoyed by that because it’s one of the reasons I bought it over iAWriter. With that said though I don’t feel particularly disappointed by it either. Full Multimarkdown support is nice, especially when you consider that iAWriter doesn’t even support full Markdown, and really, at $9.99 you’re still getting a lot of value for your money.