Andrey Tarantsov

on cutting-edge tech and beautiful tools


Today we black out Photoshop to protest the time people waste doing Save for Web.

Here’s how you can help:

  1. Support the anti-SAVEFORWEB tools:



  2. Educate others! Click to tweet with #StopSAVEFORWEB.

  3. Subscribe to be prepared when Save for Web returns.

Which of the following topics do you want covered in Ep 05? Let me know in the comments!

  • Sharing code between projects (a spotlight on git-submodule, git-subdir and Git client apps)
  • Static site generators
  • Getting started with SASS and Compass



  • Imagine a world without free kitten images
  • The shenanigans of old hardware
  • Today we fight back
  • Steamy, yes?
  • Bonus: Hazel

1. Imagine a world without free kitten images

If you’re like me, you spend a lot of time working on your images in Photoshop.

Let’s say a new questionable law has appeared and you want to send a message to your visitors:

So you make the change, and then go:

…Save for Web…




…and then maybe you have to refresh your browser on top of that.

And the way it should work is: make a change, push a button, boom, make another change, push a button, boom.

(You really need to see the video if you want to appreciate how nice that can be.)

This is possible with a piece of old German equipment called Enigma. (It’s also an app that adds one-click image exporting options to Photoshop.)

Here it is:

Let me walk you through my settings:

  1. “Prompt File Name” is off, because otherwise Enigma would be asking me for a file name every time.

  2. PNG and JPEG settings can be adjusted to your liking.

  3. On the main screen, I choose the image format (JPEG in this case) and the output folder.

  4. There’s also an option to trim the transparent pixels around your image and to optimize it. I don’t care about the optimization one because I see this as a development process. Before a release, you would run your images through something like ImageOptim anyway.

When you click the “Visible Canvas” button, the visible layers are saved into a file in the output folder with the same name as the PSD file.

Alternatively, if you have separate layers for separate images, you can click the “Selected Layers” button to export a file with the same name as the layer.

Now, this is WorkflowThu, so we cannot simply leave it at that, can we?

2. The shenanigans of old hardware

There are actually several problems with this workflow that require additional tools to solve.

The first problem is that Enigma does not support hotkeys. When I’m working on something, I really don’t want to move my mouse to click the button, because I might be adjusting a setting somewhere and I want to continue doing that while previewing the results.

The second one is that Enigma never overwrites files. So if you configure it to output into your actual images folder, it won’t overwrite them, it will simply create additional files with numeric suffixes.

And the third issue is pushing the changes into your browser window, but we all know how this is going to be solved (hint hint).

3. Today we fight back

Let’s handle the hot keys first. We’ll use a tool called Keyboard Maestro.

(This part is going to be Mac-only. On Windows, there’s Sikuli that can do all these tricks, but it’s not nearly as user-friendly, and there are some crazily expensive tools for automated testing, but I haven’t been able to find a good solution for a regular user. Let me know in the comments if you know any.)

Create a new macro called e.g. “Enigma Export”, assign a hot key like F6, and add a new “Move or Click Mouse” action from the “Interface Control” section:

Here’s the magic part: set “relative to the found image’s center”, then make a screenshot of the “Visible Canvas” button of Enigma, and drag the screenshot into the macro action’s image well:

(Btw I have the Desktop folder as a stack on my Dock, really helps to get to the screenshots faster.)

Enable “Restore Mouse Location”, and we’re almost done — the action now works!

There is a problem, though: after you click the Enigma button (or run our macro), the keyboard focus moves into the Enigma window, and many Photoshop shortcuts (the ones without modifier keys: 1..9, Shift-1..Shift-9, tool selection keys) stop working until you click one of the native Photoshop windows.

We can extend the macro to perform that second click for us too. A safe place to click on is, say, somewhere on the toolbar of the layers view.

Done! Pressing F6 now runs the export, and the Photoshop hotkeys still work after that. Nice.

You can enable Display checkboxes in the macro editor to see the winning match (green) and other potential matches (orange):

You may want to drag the fuzziness sliders all the way to the left so that there is no risk of unwanted matches:

Are you already thinking about all sorts of ways you can automate stuff using this app?

4. Steamy, yes?

So how about the file names issue?

Well, Enigma is set up to put the files into a separate ‘exported’ folder, and we’ll use another tool to move them into the images folder, overwriting the existing files. In the example, we need to move images from ‘exported’ into ‘img/examples’:

I’m going to show two different ways to move the files: the first one uses LiveReload, and the second one involves an app called Hazel.

We’ll now set up LiveReload to push image changes to the browser, and also to move the files:

First, drag the entire folder into LiveReload. (This is actually all the configuration we need to do to push the changes into the browser.)

Second, let’s add a post-processing command to move all files from the “exported” folder into the images folder: mv exported/* img/examples/:

Third, open our site in the web browser and enable the extension:

Note that because I’m working with local files, I need to have “Allow access to file URLs” enabled on the Chrome Extensions page; Safari does not provide a similar option at all.

And everything should work now!

Switch to the Photoshop, change something, hit F6, boom.

Isn’t it just awesome? I think it is.

Bonus: Hazel

If you do not want to use LiveReload, or find that figuring out a right post-processing command is too complicated for your needs, there’s an app called Hazel.

Hazel is actually my first choice for any automated file manipulations. It’s a Mac app that monitors a given set of folders and does stuff based on a set of rules. There’s also a similar free Windows app called Belvedere. Hazel has a huge following, and is literally the difference between a clutterred and a clean Mac. I use it to clean up my Downloads, Desktop and Trash folders and to highlight the apps I haven’t used for a while.

Let’s add the “exported” folder to Hazel and create a new rule to “move all images to destinations”. Set it to match all files, and move them into the images folder with overwriting enabled:

That’s it. As soon as a file appears in the “exported” folder, Hazel will notice it and move into “img/examples”.

There is a couple of seconds of delay, though, because Hazel does not process the changes immediately. This is the downside of the approach; on the other hand, you can easily set up very complicated rules in Hazel which could get tricky to do in LiveReload.


The next time we’ll dig into what makes Sublime Text great.

All episodes of WorkflowThu:

Click here to subscribe!

Which of the following topics do you want covered in Ep 05? Let me know in the comments!

  • Sharing code between projects (a spotlight on git-submodule, git-subdir and Git client apps)
  • Static site generators
  • Getting started with SASS and Compass


  • “Steamy, yes?” is a reference to The Oatmeal (mildly NSFW).

  • Kitten image by BigTallGuy, courtesy of {placekitten} — a leading source of free kitten images that power the web.

7-minute Guide to Source Maps With CoffeeScript and Uglify.js

Hello, and welcome back to the rebooted #WorkflowThu series.

Today we’re going to see how ridiculously easy it is to debug CoffeeScript files with source maps. Watch the video (07:14) or read the article below.

Tools mentioned in this video:

Subscribe to #WorkflowThu if you don’t want to miss future screencasts.



  • Intro
  • Producing Source Maps with CoffeeScript
  • Important Notes
  • Producing Source Maps with Uglify.js
  • Workflow Discussion
  • Preview of WorkflowThu 03


Let’s start with a copy of chardin.js, a neat library for adding simple overlay instructions to your apps:

Screenshot of chardin.js overlay in action

It’s written in CoffeeScript. If we open the developer tools, we will only see the compiled JavaScript, of course. While it’s readable, it’s still a mess: the line numbers don’t match, some constructs are less than obvious, and so on.

Thankfully, now we have a tool to deal with that, at least in Google Chrome. Let me show you how.

Producing Source Maps with CoffeeScript

We need to change CoffeeScript compiler options to generate a source map. I’ll be using LiveReload here because, you know, I’ve made it, and also because it’s a very simple app. But pretty much every similar tool will support source maps soon.

Let’s go to Compiler Options in LiveReload and enable “Generate source map”. (If you were using CoffeeScript on the command line, you would simply pass --map.)

The next time we save a .coffee file, there is an additional .map file generated:

Let’s open Chrome Developer Tools again. We can now see the source CoffeeScript file, set breakpoints and step through the original code:

That’s it.

If you’re running a web app server like Rails, Django or Node.js, there is an additional step for you because you need to make sure that the map files and CoffeeScript source files are exposed to the web browser. Rails apps can use coffee-rails-source-maps gem, otherwise Google for your framework name plus “source maps”.

For most PHP apps and static designs files, however, the steps described above should be enough.

Important Notes

First: Source maps must be enabled in Chrome Dev Tools options. Click the gears button in the bottom-right corner and then enable the checkbox:

Second: You need a recent version of LiveReload; I have v2.3.26 here, which is available both on the Mac App Store and on the support web site.

Producing Source Maps with Uglify.js

Let’s now minify the library, but still keep the mapping to the original source lines.

We’ll be using Uglify version 2 for that, which I already have installed (it’s as simple as sudo npm install -g uglify-js as long as you have Node.js).

I’m going to set up LiveReload to run minification on every change. I don’t normally recommend that, but it’s appropriate for the demo. The syntax is uglifyjs source.js -o minified.js:

If we re-save the coffee file, we now get chardinjs.min.js. Let’s also fix index.html to include the minified file, and then reload Chrome:

Not very promising for debugging, is it? We can fix it, though, in two easy steps.

Let’s ask Uglify.js to generate a source map for us by adding --source-map

Re-save the coffee file, reload Chrome and things are looking better now:

We see the unminified version, can set breakpoints and single-step. But we wanted to see CoffeeScript here, not JavaScript, right?

That’s the next step. Instead of giving Uglify.js an input JavaScript file, let’s give it an input source map (produced by LiveReload) instead: --in-source-map

And here we get the holy grail of web development — a minified JavaScript file that can be debugged as if it was the original CoffeeScript:

Workflow Discussion

So that’s source maps in CoffeeScript. Yes, you should be using them; it’s ridiculously easy, and you basically have no excuse.

If you’ve been waiting to try CoffeeScript, this is probably a good time to see if it clicks with you and your team. There are no semantic differences between JavaScript and CoffeeScript, so the choice is purely a matter of personal taste and aesthetic.

Now, the minification workflow we saw is a nice way to debug an occasional production issue. I still don’t think it’s a good idea to use minified files during development, at least not until all your target browsers support source maps. Right now only Google Chrome and WebKit Nightlies have the support; hopefully Firefox will join the bunch soon.

Preview of WorkflowThu 03

As I’ve mentioned, this series is resumed and will continue for a while. In the next installment, I’m going to show a ming-bogging images workflow involving Photoshop, Enigma64 and LiveReload.

Note: I promise there will be episodes that don’t feature LiveReload. :-) I will obviously mention my products often, but the series is focused on using hot / new / frequently-asked-about technologies in everyday work, and not on any specific products.

All episodes of WorkflowThu:

Click here to subscribe!

Underscore.js Cheatsheet

Underscore.js is an awesome utility library for pretty much every project. I’ve made this cheatsheet to have a quick refresher handy.

Download underscorejs.pdf.

Unlike other cheatsheets, it is produced automatically by applying print styles to the original reference web site, so it can be kept up-to-date easily. Fork the user styles on GitHub.

Print it yourself:

  1. Install Stylish for Safari, Stylish for Chrome or Stylish for Firefox.
  2. Apply this stylesheet from
  3. Visit
  4. Print 2 pages per sheet with no headers/footers.

Sublime Text Workflow That Beats Coda and Espresso

Welcome to the new #WorkflowThu series which helps web developers try new great things.

In this episode, we’re talking about jumping into Sublime Text 2 and setting up a workflow that beats traditional tools like Coda and Espresso. Watch the video (10:30) or read the article below.

App and plugins mentioned in this video:



  • Installing Plugins
  • Managing Windows
  • Live Preview
  • Switching Projects
  • Preferences and Key Bindings

Part 1. Installing Plugins

We’re starting with a freshly installed copy of Sublime Text 2:

A pointless screenshot

Unfortunately, it does not ship packages for languages like LESS and CoffeeScript out of the box, so one of the first things you need to learn is how to install packages.

For that, you need a package manager called Package Control. Copy the strange-looking piece of code from the installation instructions, switch to Sublime Text, open the Python console (View » Show Console), paste the code into the input field and press Enter:

After you restart Sublime Text, you are ready to use this package manager to install the plugins that you want. For that, you need to learn a central concept of Sublime called a “Command Palette” (Tools » Command Palette, or Command-Shift-P). It lists all the commands that Sublime can do:

In particular, you can see that Package Control has added a bunch of commands of its own. What you’re interested in is the Install command, so you just type Install to search for that command and press Enter. You get a list of packages; there are lots of them available for Sublime, which is one of the reasons it is awesome:

Choose the LESS package, and in a few moments it is installed and ready to use. Syntax highlighting works for .less files now:

Do the same with CoffeeScript (you really want to learn that Command-Shift-P shortcut). Another plugin I absolutely recommend to install is SideBarEnhancements; it adds many useful commands to the context menu of the sidebar and changes how New File command works.

Part 2. Managing Windows

This will be a key part of our workflow because we really want to run the editor and the browser side by side. There are many apps that can help us with that, see the beginning of the post. My favorite one is Divvy; the way I normally use it is by setting up a set of keyboard shortcuts to quickly make the current window full screen or position it on the left or right half of the screen:

So let’s put Sublime and the browser side by side. Additionaly, to save some space, open the files you want to edit in tabs (by double-clicking them in the sidebar) and then hide the sidebar (View » Sidebar » Hide Sidebar or Command-K Command-B).

The second trick you need to learn is to split the window into groups, which allows you to see several files at the same time. There are multiple split layouts to choose from (View » Layout submenu). In our case, we want to see the PHP file at the top and the LESS file at the bottom:

You can drag’n’drop tabs between groups, although I recommend you to learn the shortcuts under View » Focus Group and View » Move File To Group submenus.

Part 3. Live Preview

To really take advantage of this layout, you want the browser to be refreshed automatically when you change a file. For that, we’ll be using an app called LiveReload (made by yours truly). Run it and drag your project folder onto LiveReload’s menu bar icon. Additionally, enable compilation of LESS and CoffeeScript:

Follow that link you see in the window and install browser extensions. Switch to your browser and enable LiveReload by clicking on the toolbar button:

Now, when you make a change on the page, the browser is refreshed automatically. When you change a LESS file, it is automatically compiled and applied to the page without reloading it.

Part 4. FTP/SFTP

Chances are you are using SFTP to publish your site or even to edit it directly on the server. You may be using Coda or Espresso or Transmit for that, but Sublime has a good solution too: the SFTP plugin. Install it via Package Control; it is not free, but, like Sublime Text, it has an unlimited free trial.

After installing the plugin, right-click your web site’s root folder in the sidebar and choose SFTP/FTP » Map to Remote. A JSON file appears, which you can enter all the connection settings in. Don’t forget to set remote_path, and be sure to enable upload_on_save if you need it:

Save the config, make a change to your php file and watch it being uploaded:

There are sync/upload/download commands available in the sidebar context menu and in the Command Palette for those who only publish their changes occasionally.

If you work with a remote site using the upload_on_save option, you need to configure LiveReload to handle that — otherwise, it will try to reload stuff while the upload is still running. Click the monitoring Options button, set up a small delay for full page reloads and enable CSS overriding:

Now when you change a PHP file, it is uploaded to your server and then the browser is refreshed. When you change a LESS file, those changes are applied immediately.

You still need to upload the compiled CSS file later; for that, SFTP plugin has a monitoring option: open the CSS file (be sure to double-click it — single click does not create a tab), invoke Start Monitoring command from the Command Palette, and don’t close the tab. Or you can simply use the Sync command when you are satisfied with your stylesheet changes, relying on LiveReload’s override behavior to preview them.

Part 5. Switching Projects

This is a small tip: you really want to save your projects using Project » Save Project As, because you can later switch between recently saved projects using Project » Switch Project In Window command (use the Command-Ctrl-P shortcut).

It’s a real killer when working on several projects: hit Command-Ctrl-P, type a few letters of the project name, Enter, and you have that project open, with all of the open files preserved from the last time:

Part 6. Preferences and Key Bindings

Customizing Sublime Text may seem a bit nerdy, so you need to get used to it. Let’s say you want to make the font size a little bit larger. When you choose Preferences, you get this empty JSON file:

Turns out, there is another file with exactly the same format which contains the default values of all available settings. Open it using Preferences » Settings - Default. The settings are pretty well commented. Find the one you want, then copy it into your personal settings file.

Your new preferences are applied the moment you save that file:

One setting that I recommend you to enable is auto_complete_commit_on_tab, explained in the comments:

Sublime Text’s completion feature is really awesome: for example, you can type “accot” and hit TAB to complete auto_complete_commit_on_tab — and before you finish typing half of that, Sublime usually has a proposal right there on your screen:

You can customize the key bindings in a similar way. For example, I show and hide the sidebar very often so I prefer Control-S to the default Command-K Command-B shortcut. To set that up, you need to search for side bar in the default key bindings file (Preferences » Key Bindings - Default):

then paste that line into your personal key bindings file (Preferences » Key Bindings - User) and change the shortcut to Ctrl-S:

As soon as you save the file, Ctrl-S starts working. (The default shortcut works too, so this is adding a shortcut rather than changing it.)

The End

You can Google many more plugins and tricks for Sublime Text. Thanks for watching (err, reading), and see you next week!

All episodes of WorkflowThu:

Click here to subscribe!

The third definition of open, or How I nearly picked GPL for my product, but ended up simply publishing the source with no license (for now)

There is an urge that every hacker has: to share whatever he creates.

When I got my first day job, the owner of the company explained that he always wanted to run a “fully open-source company” with open accounting and everything. This may seem nuts to a business person, but to me it sounded like the only natural thing to do. I still can’t imagine wanting to run a business any differently.

Fast-forward about 6 years. Apple and Google battling over who’s better at bending the concept of openness, John Gruber making good laughs of that, and me finishing up my first launchable product.

To give you some perspective, for the last 4 years I’ve been trying to get into the product business. My first idea has been to make a killer IDE for Ruby on Rails, with the beauty of TextMate and powerful code analysis and refactoring. I’ve gathered a great team, and it could have been an easy job, but I’ve been way too immature to run a product. While playing with fun stuff, we’ve ran our consulting business right into the ground, found ourselves arguing a lot and separated.

Then a similar thing happens with another idea. I don’t have enough steam to do a big project on my own, so I get a really good partner, and we work for a little while, and then he gets drowned in other work (and me too, trying not to repeat the previous experience), splits up with his wife and leaves for another city. I continue for some time, but a proper launch seems years ahead and I’m hopelessly undermotivated.

Meanwhile, the livereload gem, which we’ve hacked together to make coding up our single-page web app more tolerable, gets pretty popular. I always meant to make a GUI wrapper for it, but since I already had my “startup” as a fun out-of-normal-work project, it was impossible to justify spending time on another fun project which was never going to bring any money.

What all of that boils down to, is: there are ideas I really want to implement, but doing that while also doing contract work leads both into wrecks. I also have a wife, a 7-year-old daughter and expecting a second child soon, so I need money to live on — and not just pizza-and-ramen kind of money; I feel oblidged to provide a decent lifestyle to my family.

So I decide that LiveReload GUI app could be the middleground I am looking for. A small app I have time to develop and launch, bringing in the additional income which might allow me to partly ramp down on consulting and get more awesome things into the world.

Well that, and I’m really pissed with having to baby-sit the livereload gem every time I want to fix a bunch of styles on a web page.

So LiveReload 2 is really about the money. I don’t want to risk that goal, but I still believe sharing is right, so I email Richard Stallman asking to talk me into going open-source.

His response has been great and led me to carefully think through my values, but on the other hand it completely missed the point for me. See, GPL is very clear-cut when dealing with large companies (which will surface in just a few moments) and their questionable intents. They want to screw us over, we defend and screw them in return.

Where this system breaks down is a community where an absolute majority of people have good intentions, something that indie/early-stage-startup community qualifies for in my opinion. I’d certainly prefer to work on great things for free, and whatever resources and occasional luxuries we need to magically materialize themselves. The fact that people work best when they don’t need to think about money is pretty well-studied.

Some people are fine with working on a day job and hacking on free software in the free time. I can only envy those guys; forcing myself to do consuting sucks up so much energy I have pretty much nothing left. And it’s not like I don’t like what I do; I have really awesome clients and I love the projects. But other people’s projects just don’t excite me for long, no matter what.

So guys like me go into indie or startup business. And we don’t have the option of stuff materializing itself. The options we do have is to either sell stuff for money, or get funding, or tell our families to fuck themselves.

The reason the idea of GPL breaks down for us is that we’re very motivated guys when working on our own stuff, and the world needs us to do our best work. We are also happy to share and contribute whenever we can; the better we are doing, the more awesome stuff we can make free and open-source. But we need to be making money to be banging on our stuff; it’s already hard enough, and adding obstacles to that is not helping either us, or users, or other developers, or free software community, or the world in general.

I think deep down Richard Stallman believes that the kind of life we want to live is very wasteful, and our desires are unresonable. I disagree. It’s ok (and desirable!) for everyone to be doing equally well, but it’s not ok for everyone to be doing equally poorly. So far, our technological progress really sucks; we can’t even produce enough resources to feed everyone in the world, less so to cure everyone and to enable everyone to pursue their dreams. And yet I want my children to be well-fed, healthy and enabled.

So back to LiveReload, here’s chapter two in which large companies go visiting and try to get us into a tight place (also known as asshole).

While I was going rounds about releasing or not releasing the code, a certain company has contacted me with a bunch of questions on how my browser extensions operate, having done surprisingly little homework. It went like, is open-square-bracket the only requirement of your protocol? — WAAT? didn’t you actually read the protocol spec? — Yes, but we don’t trust specs, so we reverse-engineered your Firefox extension. — WAAT? you didn’t notice the extensions are all open-source on GitHub? — etc etc.

And then it went like: Will LiveReload be mentioned in your UI? — No, sorry, this feature will really be invisible. — Will you provide a link back somewhere? — No, sorry, I’m not authorized to make such promises, but maybe the documentation guy will put it somewhere. — Can you put me through with that guy? — No, sorry, he’s not involved yet and he cannot make promises either. — Can I talk to someone who can negotiate the terms of usage? — No, sorry, I’m the only one responsible for this feature. — Will the extensions themselves provide any user-visible indication of being part of LiveReload? — Sorry, I cannot to make any promises.

Initially I told them extensions and livereload.js are MIT-licensed, which btw they are (otherwise guard-livereload and others wouldn’t be able to bundle them). But I happened to not publish a license on GitHub by mistake, which gave me an opportunity to think it through.

Could GPL be an answer to this shit? It could well be. You’d release your extensions under GPL, and the guys would have to fork your project, release their changes, and then maybe have their app download and install those extensions at runtime to avoid bundling them with the app. Not like this scenario really helps you, but there is some chance that doing bullshit like that is harder than to give a proper attribution to the original project.

As irony goes, however, the IDE that company makes is under GPL.

Is it a big win of the free software movement to have a bunch of douchbags create a crappy IDE which anyone can use, change and redistribute? It most certainly is. We should stop and reflect on this; 20 years ago douchebags did not share their source code.

That’s only one kind of freedom the world needs, however. It is most unfortunate that the free software advocacy is largely missing out on startup boomers (can I suggest the term?) The forefront of free software, GPL, is about fighting douchebags with proprietary codebases. It does not help indie developers get the most into the hands of people (including the most free stuff!), doesn’t help them share the most they could share, and it does not help against the new GPL-equipped douchebags.

So back to LiveReload once again. Ihe initial plan has been to call it licensed under “GPL with moral strings attached”. Legally it would be GPL, so you can’t get into trouble for using it, but morally it would require a payment unless you have a good reason not to pay (for which being a student with little money certainly qualifies).

The approach is very fragile, though, because it heavily relies on your exact message getting through to everyone, intact.

One problem may be that the legal side does not accurately reflect the intentions. GPL says “fork, redistribute, rename, sell”, while in reality I’m not comfortable with people forking LiveReload and selling it under a different name unless I abandon the project.

However, I would say undermining the legal side can only be a good thing, given the abysmal state of copyright and software patents in US. Not having the rights at all and not having money to defend your rights in court is pretty much the same, so you might as well give them up and save the trouble.

A bigger problem is that people associate GPL with “free”. No matter how much RMS talks about freedom, the primary meaning of “free” is not the one RMS wants it to be (like no matter how much we complain, the primary meaning of “hacker” won’t ever be “ingenious computer enthusiast”). Now, if I can stare into your face and explain the stuff about GPL being the legal side, and me being in it for money, and the moral strings, you will get it all right. My staring capability is limited, though, and people who simply hear GPL will get a very different idea.

So, I decided to completely avoid the legal side for now and release LiveReload on pure moral terms, described on the home page. I’m happy with people exploring it, modifying it and sharing their modifications, but by default I want to get paid. Fork the source code, but don’t fork the project; I’m not happy with someone taking my app and starting to sell it under a different name. I don’t want you to publicly distribute the binaries either, because people coming to my web page are as much of an asset as the money are, and both page visits and money will help me achieve my bigger goals and ultimately produce more fun stuff that everyone will benefit from.

(If you do contribute extensive modifications, I’m sure we can work out a way to make you happy about that.)

Of course, you are free to choose your own moral grounds. I don’t want to extort the money from you. If you cannot pay, or you’re tight on money (I know I sometimes am), or you believe payment is not morally right in your case, go ahead and use it for free. (So far, it may be a bit tricky. You can ask me for a free license, or you can get a copy from someone — there is no copy protection. I will try to work this out in a better way in the future, but I need to balance that with not sending a message of payment being a highly optional thing.)

And to top that, if I abandon the project, or die without assigning a maintainer, or just turn into Oracle, you are free to take over and run it or fork it.

So there you have it. You can define being open as “repo sync; make; make install”, which is bullshit if you then screw those who did it, or as not doing vendor lock-in and using open technologies, which is just as much a stretch with Apple, despite me being a fanboy. Or you can define “open” as sharing as much as you can share, while being honest about your intentions and NOT being a dickhead. (Oh yeah, and not stealing the address books of your users. Just sayin’.)

Papers Every Programmer Should Read

None. Academic papers are shitloads of crap. Want to read something? Read some beautiful source code instead.

Then go hack on something that you love.


(Also read this essay. If you don’t identify with it, nothing written on this blog probably applies to you. I guess I should put this into the sidebar.)

Two Indispensable Email Add-ons ( & OhLife)

Of all the personal planning tools I have tried, the only one sticked and is measurably improving my daily life of a freelance software developer:

Of all the personal diary tools I have tried, the only one sticked and is used — well not daily, but fairly often: OhLife.

OhLife is fun because it emails me every day, so I can skip any days I like knowing that eventually I will write again. The default outcome for other diaries is exactly the opposite (you stop writing), so a guilt builds up as you skip days.

The power of FollowUp is that it does not try to be your todo list, and the reminders only fire once. You can move them with one click (which is very important), but you don’t have do anything if you no longer care.

A recipe for a successful productivity tool is to take away the problem, but avoid adding any pressure or maintenance:

  1. Expect and encourage the user to start small. One entry, one task, no pressure to do a braindump.

  2. Don’t put pressure to use it regularly. Should not be a mess when I come back after ignoring it for a month. But can’t also irreversibly forget things unless I act on them timely.

I’m yet to see someone solve this for news, RSS and twitter, which either accumulate unread items or loose old results forever. I think FollowUp’s found a sweet spot by focusing on future events, but keeping the old ones accessible on the calendar (and in email archives).

Consider e-mail as the primary UI for your next little project.

The Story of LiveReload: The First Anniversary

In the summer of 2010 we were hard at work implementing a startup idea. That did not go very far (yet?), but it did give birth to an unrelated worthy tool used and praised by many people.

That summer I’ve started using LESS and CoffeeScript for the first time. LESS was fantastic, but it also presented a problem: as a long-time loving user of CSSEdit, I would never agree to a less-than-instant editing experience.

Mockko (our “startup”) was WebKit-only, so using the Firefox-based XRefresh was not an option. After stuggling for a few days, I set off to write a similar tool for Safari.

It was a Sunday night when I finished putting the final touches on LiveReload 1.0, published the command-line tool and went to sleep, fully expecting maybe 10 downloads over the next week.

I woke up to find some unusual Twitter activity. After a quick check, it seemed like the whole Internet started talking about LiveReload. Envylabs made a great screencast, misattributing the authorship to my cofounder-at-the-time who happened to fix a few lines in README while I’ve been sleeping. We even got into the list of trending repositories on GitHub.

1.1–1.4. The active development continued over the course of another month: more configurability, Chrome extension, our own file system monitoring gem with powerful filtering facilities and all 3 platforms supported.

Soon, however, that progress came to an end. The market was recovering from the crisis and I got a lot more load in my consulting business. I’ve also parted with my co-founder, and poured the little time I had left into the development of Mockko itself and not the side projects.

1.5–1.6. Luckily, LiveReload has attracted an active contributor who continued to improve the existing browser extensions and added one for Firefox. With his help we released versions 1.5 and 1.6.

Other people have made alternative command-line tools for our extensions or even included LiveReload into their apps.

By the spring of 2011, it was clear that I would never continue the development of LiveReload. Mockko has been stagnating for months and I had many ideas for new projects, so spending time improving an already-working open-source tool did not seem reasonable.

On the other hand, I’ve been using LiveReload a lot in my consulting work, and really hated to run 4 or 5 monitoring tools on the command line. I badly wanted a UI version that would also take care of running the compilers and minifiers.

2.0. A LiveReload GUI could help many users and potentially bring in a nice cash bonus. That, however, did not get me excited enough. The ultimate motivator (competition!) arose when I learned that someone else started working on a similar tool. Two weekends later, I had the initial prototype ready, crafted a pure-HTML (meaning no-CSS) web site and offered a private alpha version to several trusted people, calling it LiveReload 2.0.

The feedback has been positive. In fact, I’ve never heard anything negative about any version of LiveReload. Even those who couldn’t install or run it considered the idea somewhere between very useful and incredible. This was encouraging but also troubling, and I’ve always felt like I was overlooking some catch.

After living through several failed-to-deliver-anything “startups”, I was intending to launch LiveReload 2 very quickly, with 2.0 being on par with 1.6 feature-wise. Based on the feedback, however, I’ve changed my mind and included compilation support into the roadmap. The design side of things lagged behind the development, so launching quickly was not an option anyway.

It is now the end of July, which means LiveReload has been out for a year. It has gathered 199 Twitter followers, 792 watchers on GitHub, 10788 gem downloads, 5 alpha builds released and 460 users trying them at least once. We have a strong team which has been working together for many months, with @NV going from a major LR1.x contributor to a LR2.x partner, focusing on the browser side of LiveReload. We’ve just got an icon designed and preparing to submit to the App Store soon.

What’s really exciting is that several competitors are rumored to launch soon too, and even FogCreek has released a kinda-similarly-targeted tool. Stepping into an unknown territory of marketing is equally thrilling: after reading dozens of articles on launching products and getting coverage, would be nice to finally proceed.

So tell me: are you still hitting Refresh?