Google Wave is not for everyone, but it’s definitely a decent tool for collaborating on documents and for planning vacations or other events. One important thing missing from the standard set of features is the ability to print.

There’s no way to print a Google Wave by default!

Looking for existing solutions

That’s when I started looking for a solution and here are the options I found:

• Use the PDF Wave Exporter extension for Google Wave
• Use the Ferry bot to export the wave to a Google document and print it from there
• Make Google Wave think you’re an iPhone (using a User Agent Switcher extension for Firefox for example)
  • This one didn’t work for me
• Use the Readability bookmarklet

None of these solutions were particularly satisfying: most of them lose quite a bit of formatting and some require too many steps to be considered practical.

After waiting for about a month for a decent solution, I decided to do it myself.

Do it yourself

My original idea was to do it via a bookmarklet. If you are not familiar with bookmarklets, they are bookmarks that execute client-side code when clicked on. So I started looking for tutorials on making bookmarklets. I know JavaScript (and if you don’t, don’t even try building a bookmarklet) so this path looked promising. I found the excellent Bookmarklet Builder tool that lets you make a bookmarklet from the ground-up and iterate very quickly. I then needed to know what to extract from the HTML. Using Firebug I explored the document’s structure and found out that all the important text was located inside divs with the class “document“. So I gathered the content of each of those document containers and appended each of them to a new window created in a pop-up. I end the script by telling the pop-up to print its content.

The ultimate Google wave printing solution (until Google builds the feature itself)

The result is this bookmarklet which makes printing a Google wave as easy as opening the wave and clicking on the bookmarklet.

Drag and drop in your bookmarks

The big idea

My idea was to build an open distributed social network that anyone could host. Each hosted version of the app would be referred to as a node and would be able to communicate with all the other nodes. You would have been able to install it like WordPress, but you would be hosting a social network instead. The nodes would only need to share a common API, other than that each node could be programmed in any language.

Reality check

In the following days, I was refining my idea, thinking about the kind of work it would need, which features had to be built first, what to name the project (I actually had a great name), etc. I was getting pretty excited about the project and wanted to start talking about it publicly when I heard about Diaspora via Kickstarter. That was pretty much the exact same project, they had already started and were being backed by other people like me who were tired of being Facebook’s toys.

Then I saw Wired’s article that I mentioned at the beginning of this post, the author also wanted an open alternative to Facebook. In shock, I kept searching the Web for “open social network” and “distributed social network” and found out about OpenSocial (a common API for social networks proposed by Google) and OneSocialWeb (a direct competitor to Diaspora).

How much is an idea worth

There I was with my big idea and already dozens of people had been at work on similar projects. That got me thinking about a quote from Derek Sivers I had read in the excellent book Getting Real by 37signals (which you can read for free online).

It’s so funny when I hear people being so protective of ideas.  (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

[...]

The most brilliant idea, with no execution, is worth $20.

The most brilliant idea takes great execution to be worth $20,000,000.

That’s why I don’t want to hear people’s ideas.

I’m not interested until I see their execution.

source

The birth of an idea

I like to think of myself as a perpetual thinking machine, constantly juggling ideas about new projects. Each time, someone else had the same idea. The more I have ideas, the more I find out that no matter how good the idea is, someone else had the same idea too and for every person trying to bring an idea to life, I’d bet there are dozens of other people that just didn’t put the effort or didn’t have the capabilities to do so.

Ideas are worthless unless you execute them well enough.

More on this topic:

• Ideas are easy… execution is difficult
• The difference between innovation and invention

One account, multiple profiles

What I suggest is that upon registering on a website, one account is created. The only information associated with the account would be what is needed to contact that person and to login, so a name and an email adress (or the OpenID account used to open the account for example) would sufice.

Then the user needs to create at least one profile (or persona/personality/…) to start using the service. Of course, the first profile creation could (and probably should) be created at the same time of the account so that the user can start using the service as soon as possible.

The user should then be able to create as many profile as wanted and switch between them easily (see mockup further down). Ideally, the account would be invisible to other users, only the information in the profile would be visible.

Which services?

Of course, not all services would benefit from having such a feature, but I feel like most would. I know of one company that manages the accounts in a way that is similar to what I’m suggesting and it’s 37signals. At the end of 2009, they noticed (and probably experienced first-hand too) that users needed multiple accounts for their services and had to log out then sign back in to switch between them. So they did what I’m suggesting now and introduced a single sign-in across all their products.

Other websites that would be great with this feature include Gmail/Google, reddit, Twitter and your favorite social networking site. Imagine being able to switch between your real profile and a number of other novelty/fun/secret profiles on which you wish to remain anonymous.

A mockup of how it could be implemented (mockup made using Balsamiq Mockups)

Merging

This is probably the single most problematic issue with Subversion. Merging often causes headaches, errors and wastes a lot of precious time that could’ve been spent on development. Merging is so bad that many teams avoid branching so that they don’t have to deal with the merge later on. Mercurial (hg) and Git have both improved this aspect tremendously and I’m pretty sure its the reason why most people are moving away from Subversion.

The reason why Subversion has trouble with merging has to do with the way it stores the version history.

Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time.

In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.

Source: HgInit: Subversion Re-education (an excellent tutorial and guide to Mercurial or other distributed version control systems)

So Subversion compares whole files when merging while Mercurial (or Git) compares each change set individually. Conflicts occur far less frequently when dealing with changesets.

Improving SVN

Use changesets

As I said earlier, the biggest difference between Subversion and Mercurial/Git is the way they each deal with modifications to files. If Subversion started using changesets instead of revisions, a lot of the headaches and problems would disappear.

Local commits

Another advantage of Mercurial and Git over Subversion is their distributed nature. With Mercurial and Git, you can commit changes locally on your drive whenever you want (while you’re offline too) and commit all those local changes to a central repository at the time of your choosing. This improves commit logs since the developers don’t have to worry about breaking anything until they actually commit to the central repository (or push their changes if we use the distributed version control system terminology). You can even have multiple intermediate repositories between the developers and the central repository. For example, all developers could commit to a team lead repository which would review every changes and then commit the reviewed modifications to the central repository.

So, to improve Subversion, I don’t think the multi-stage distributed system is necessary. The real value is in local commits, the rest can be easily emulated by using a simple branching process.

Subversion’s future

Unless Subversion works on these two issues, I don’t think Subversion stands a chance against the newcomers. Slowly but surely, teams will migrate to alternative version control systems because they make branching fun again.

Bonus: Move all the repository information at the root

This one is not as bad as the others, it’s just a regular annoyance that could be improved. Instead of having Subversion meta-data in every single versioned folder, Subversion should keep all the info in a single meta-data folder at the root of the checked out repository.

From a programmer’s point of view, it behaves like a folder under version control that automatically syncs any time something new is added or modified. It takes care of merging and conflicts without ever bothering you (in case of conflicts, it just shows both files and renames one of them appropriately).

Dropbox doesn’t currently offer a self-hosted solution and I think there’s an opportunity here for someone to fill a small part of the market. Companies could offer accounts to their employees and/or share folders among all the employees. An open-source solution would certainly be doable, there’s no need for a fancy web interface (although it’s pretty useful), the core of the application isn’t too big. Someone even managed to get something running that offers the basic functionnalities of Dropbox.

Once the problem is fixed, it’s time to review the problem and find out what went wrong so that it doesn’t happen again. Every mistake is an opportunity to learn. Maybe a single person was responsible for the error, but no one else caught it either. Is there some way to make it impossible to repeat the error? Do you do enough testing (automatic or manual)? Do you do any kind of reviewing? Or do you simply tell your people to be extra careful?

Don’t let people the opportunity of making mistakes and they won’t, otherwise you’re just as guilty.

The World Wide Web, on the other hand, is intrinsically stateless because each request for a new Web page is processed without any knowledge of previous pages requested. This is one of the chief drawbacks to the HTTP protocol. Because maintaining state is extremely useful, programmers have developed a number of techniques to add state to the World Wide Web. These include server APIs, such as NSAPI and ISAPI, and the use of cookies.

Source: Webopedia

As “maintaining state is extremely useful”, there are plenty of ways to maintain the state across requests.

An introduction to states in a web environment

However, you have to be careful how you do it because there are many ways that a request can be done. The most common are:

• A direct GET request through a bookmark or an URL entered directly in the address bar
• A GET request coming from an external web site (this is essentially the same as a direct request in terms of state: there’s no previous state)
• A GET request coming from an internal page of your web site
• A POST request. These usually come from an internal page of your web site, but you can’t count on it

In the case of a GET request coming from an internal page, there’s also the possibility that a new tab was requested, making the originating tab a valid state. If you’ve ever seen a revision graph (I sure hope you have), a state graph would be quite similar.

Taken from the Branching and Merging Primer at MSDN

The same graph adapted for a state graph

The merging is not exactly present as in the revision graph, but it’s there. In fact, an opened tab/window could have an effect on any other tab, not only its parent. Let’s say the user opened a tab from a listing of items to edit a particular item. It modifies the item and saves it. The next state in the listing would reflect (ideally) the modifications to the item.

Maintaining the state

Now that you are more familiar with the state in a web environment, let’s get to the point: how to persist information across requests. From the discussion above, we can extract two key points:

• Never assume the request comes from an existing state, always check if a state existed before
• Never modify a state directly, always make a copy (in case of tabs)

Most web frameworks (if not all) offer one or more ways of maintaining the state. Most of them rely on the good old cookies, but you have to be careful with those because you don’t want to change an existing valid state.

You could also use a session identifier, but you can’t always rely on them because different browsers treat sessions differently. Firefox and IE both consider that each tab is in the same session as the originating tab while Chrome considers them differently, it treats each tab as a new window (which is a different session for every browser).

Another (very ugly) way, is to simply pass an identifier (usually a Guid) in the URL all the time. However, you can’t assume that the user just won’t delete the ?SessionID=… part from your URL before performing a request.

Finally, the Asp.Net WebForms framework simulates a stateful application by wrapping everything in a single form field and doing everything by using post backs (POST requests). A post back does not allow new tabs so it’s safe to just change the originating state.  It also makes something clear, every GET request is considered a new entry point and does not rely on the previous state to perform the actions.

Cleaning unused states

Persisting all those states can make a dent on your memory usage, that’s why you’d want to remove unused (closed tabs/windows) states from the graph. To do so, I suggest that you implement some sort of keep-alive object that sends Ajax request to keep the state of the page alive every x seconds. Once the requests stop coming, you can safely delete a state*.

* I haven’t explored the possibility of resurrecting a tab (via undo close tab), this might be an issue and a reason to never delete a state until the user session is dead.

Conclusion

Stateless programming is not a problem easily solved and thoughtful thinking is required before using any of the solutions presented above.

My needs

The first thing to do when looking for a web host is identifying your own needs. Some hosts are better for low traffic web sites while others are better for high traffic/bandwidth requirements. I only need to host a couple of blogs with very little traffic.

Among the plethora of options available, a few seemed a bit better (and more trustworthy):

• A Small Orange
• DreamHost
• FatCow
• GoDaddy
• NearlyFreeSpeech
• WebFaction

My experience with the hosts

GoDaddy

I used to be with GoDaddy because I didn’t know any better. The price is definitely on the lower end and offered everything I need. The administration panel is also one of the best I’ve seen. The only complain I had was the performance; Loading any of my blogs was too slow for my taste.

FatCow

The first contender I seriously considered was FatCow, it was recommended to me and they claim that they are 100% wind powered (they actually buy Renewable Energy Certificates (RECs) to offset their energy use. The reviews online were more positive than for the average hosting company so I went with it.

I’ll just start with saying that I didn’t even last a day. In fact, I couldn’t even purchase a hosting account on my own, I had to go through a support agent via a live chat (nice!) to set-up my account (first red flag). The whole administration admin is a mess, the options are not always shown for no reason, the navigation menu won’t load most of the time, etc. (second red flag). I decided to still go through and try to set-up one of my blogs to see how FatCow performs. Well, I couldn’t even import my data, their phpMyAdmin installation wouldn’t even run my SQL import scripts and wouldn’t tell me why. That’s when I pulled the plug and cancelled my account.

They have excellent support (even though I suspect they use bots for most support tasks), but they lack a decent hosting service.

A Small Orange, DreamHost and WebFaction

I didn’t try those three because they didn’t match my needs, but they all were highly recommended to me. A Small Orange has a unique 25$/year plan for very small hosting needs (perfect if you have just one or two small websites). DreamHost offers something quite similar to GoDaddy without being GoDaddy. Finally, WebFaction costs a little more than others but seems to offer much better quality hosting. The only reason I didn’t go with them is because they offer more than what I need and I didn’t want to pay for something I don’t need. If my needs ever grow, I’ll definitely consider them.

NearlyFreeSpeech

I just said that I didn’t want to pay for something I don’t need, well NearlyFreeSpeech was the perfect choice for me and was very highly recommended by many. Unlike most web hosting company, there is no contract, you simply pay for what you use (there’s even a pricing estimator). If your needs are small, it’s going to cost you a lot less than at GoDaddy for a much better host. They don’t offer free support, but their FAQs are well written and I haven’t needed more than what was in there. I wouldn’t recommend this to someone not familiar with hosting, but for anyone who has a little knowledge of hosting, this is a great host. You can even play around their administration panels for free because you don’t have to purchase anything to create an account.

The way they charge you for your usage is that they take money from a bucket of money that you set up. For example, you could add 10$ to your account and NearlyFreeSpeech will substract the money from that amount. You can set-up alerts at certain amounts to be notified when you need to add more money.

They are missing one feature that I would’ve liked: support for Ruby applications. I don’t actually know Ruby, but it’s something I’m interested in learning. If I ever decide to do so, then it’ll be time to look for a new host which is going to be easy since I’m not on contract with anyone.

Wrap up

I’m a little saddened that the search for a reliable web host is so difficult. I would’ve thought that by now a few web hosts would have made their mark, but this is still a field where there are mostly small players and none of them is standing way above the crowd.

Identify your needs and do your research.

Read more:

• The reddit discussion that helped me choose my host

synergy is when different entities cooperate advantageously for a final outcome. Simply defined, it means that the effect of the whole is greater than the sum of the effects of the individual parts.

In software, that means that multiple programs or tools work together to accomplish something that wouldn’t have been possible if each program had been used individually.

My experience with synergy

For the past few days, I’ve been working on tools to simplify our release process and help us trouble shoot eventual issues. First, I implemented a system diagnostics page: a page giving us information about the current state of the application. One important thing it gives us is the version of every assembly used by our application. This brings me to the second tool: a version updater. This tool automatically updates the version number after a commit in subversion. So whenever we release some code, it has its own unique version number.

The two used together give us an always up-to-date diagnostics page that we can really use. Without the automatic version updater, the diagnostics page would always tell us the same versions are loaded even though the assemblies would be different. And without the diagnostics page, the version number wouldn’t have been as useful. Now that we have both, they’re immensely useful.

On top of those two, we also have an automatic build system. We really believe in the second point of The Joel Test:

2. Can you make a build in one step?

We can in zero steps (simply committing in the right branch which is part of our normal process anyway) and we even have a release package built automatically ready to be sent to the client.

Synergy is everywhere

You may not be aware, but software synergy is omnipresent. Every day you use a multitude of applications that you use for one goal: creating software. You use an OS, one or more browsers, an IDE, a versioning system, a database manager, a text editor, etc. Without one or the other, making software would be much more difficult and a lot more boring.

If you’ve been reading Coding Horror for a little while, you might remember that the blog had been labeled “the world’s most dangerous programming blog” by some reddit commenter (I couldn’t find the link). Jeff responded by saying that you should always read critically. That’s easy to say, but Jeff has the bad habit of taking one side and rejecting the alternatives, he’s always black or white, he has no middle ground. This is one way of blogging and it has worked wonderfully for him, it provokes reactions all the times and he likes that.

So, is Jeff Atwood really incompetent?

I don’t think so, I just think his blogging style is not understood by many. Jeff Atwood (and Joel Spolsky) are both highly experienced professionals in the programming world (though Spolsky hardly has anything to do with programming anymore) and they have something to show for it: Stack Overflow (while suffering from the programmer interface syndrome) is a wonderful web site that has helped millions of programmers already (including myself, Jeff himself and most likely you too).

So why did he experience the data loss and how can he write things that mislead fellow programmers? First of all, he’s human, so he’s prone to make mistakes. Secondly, as I said earlier, Jeff has no middle ground because he understands that if everyone agrees with you, you’re boring and not worth reading.

Blog post after blog post, he manages to pass through the filter in his brain that stops most of us from posting, he dares post an unfinished/under-researched post. Then, his hundreds of thousands of readers analyze his post and correct him, making him learn a lot more than if he had refrained himself from posting. Both him and Joel Spolsky are really good at sharing their experiences and we all got better at our profession by reading those articles.

So don’t follow blindly, always keep a critical eye open for flaws in any blogger’s judgment. Take what’s useful for you and forget the rest, never assume someone’s right without actually thinking about what’s written and why it was written.