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:

• Sublime Text 2 ($59 after an unlimited free trial)
• Package Control (free)
• SideBarEnhancements (free)
• Divvy ($14) — other alternatives are: Moom ($5), Optimal Layout ($14), Window Tidy ($8)
• LiveReload ($10)
• Sublime SFTP ($16)

Transcript

Contents:

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

Part 1. Installing Plugins

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

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!

(Be sure to subscribe to this blog if you don’t want to miss future screencasts. Or subscribe via email.)

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’.)

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.

Repeat.

(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.)

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: FollowUp.cc.

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.

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?