The latest version of the Evil Overlord Name Generator is free, and available on GitHub. Enjoy !

I wrote this engine entirely for myself, without the intention of opening it up to other people. But since realizing that it has improved the way I think and write, I’ve decided to open it up to a small number of vetted bloggers. At least at first. The goal is simple: when you see the Svbtle design, you should know that the content is guaranteed to be great. Network bloggers are encouraged to keep quality high at the expense of everything else.

Then, Nate Wienert created obtvse, intended to be an open-source alternative to Dustin’s svbtle software.

So, I decided to do something about it. Svbtle was nearly exactly what I had been looking to do with my own blog. I wanted it, and I wanted to share it with friends. I whipped open terminal, typed in rails new obtvse, and a few hours later I’m here.

Then, Nate posted the link on Hacker News, and the top comment came from Dustin:

This is almost unbelievable. No matter what you think about me or my product decisions, it is flatly wrong to ripoff work. It’s shameful, even.

Please take this site down and delete the Github repository. The work isn’t yours.

Just wait until Svbtle is finished and open to the public. The reason it’s closed is really simple: it’s not ready yet.

Let’s get a few facts straight before we go on.

1. Nate Wienert did not copy any source code from Svbtle when creating Obtvse. The implementation of Obtvse is an entirely original work, including the HTML and CSS.
2. The function and underlying idea of the Obtvse software are exactly the same as those of Svtble software.
3. The design and features of Obtvuse, though not identical, are strikingly similar to Svbtle, and this is intentional.

What happened ?

Nate owns the implementation work for Obtvse. He wrote it himself, and it bears no significant resemblance to the implementation of Svbtle. Dustin has no business telling anyone else what to do with the code they write.

No one owns the general idea behind the software: less clutter ? Emphasis on content instead of presentation ? Markdown ? None of these are original, and if they were, then 2007 called : the people at Tumblr want their ideas back.

The design and features are more of a gray area. Creating an aesthetically pleasing design is more difficult than turning that design into HTML and CSS. The original Obtvse was indeed dangerously close to plagiarism, but has moved away from the original Svbtle design and is looking for its own visual identity.

So, is Dustin entitled to complain about the situation ? I believe so.

Obtvse is blatantly hijacking the Svtble brand. But first, let me mention an article written last year by Zach Holman :

Last Monday, I sat down to hack.

After a few hours, I open sourced the code. By the end of the week, it had 1,000 watchers and 70 forks on GitHub, and 500 upvotes on Hacker News.

It’s my favorite example of open source recently. Here’s why it worked.

He then explains that his project took off because it was easily portable, simple and fun. No. These certainly helped a little bit, but the main reason the project had a massive audience is because Zach Holman has a massive audience : he has a popular blog that is regularly seen on Hacker News, he is followed by ten thousand people on Twitter and he works at GitHub. In fact, I would be quite interested in the following experiment : create a new blog, new twitter account and new GitHub profile, publish an awesome project and see how long it takes to get 1,000 watchers !

I’m not saying that Zach Holman was lucky. Quite the contrary : building an audience takes time and effort, and I’m quite certain that Zach earned  every single one of his feed subscribers and twitter followers.

Which brings me back to Svbtle and Obtvse. I may disagree with the «Invite-Only Network» mostly out of jealousy for not being able to join, but I will be the first to agree that Dustin Curtis worked hard to build the personal audience that he could pitch Svbtle to. The main reason why Nate Wienert rose to the top of Hacker News is that it’s a different take on a well-known and trending topic — in all honesty, if you had never heard of Svbtle in the first place, would you have paid any attention to Obtvse ?

And this is unfair. It’s unfair to Dustin, who worked hard on getting people to know Svbtle and is being painted as a bad guy because of what is ultimately an emotional reaction that should not have been posted. And it’s unfair to all of us who would rather be acknowledged because of who we are instead of what bandwagon we rode on.

If i want something i will go look for it, if i don’t find your product- tuff! If you go out of business, tuff because you had a rubbish business plan, specialised product with limited appeal or whatever- your product is not good enough!

[...]

Pull your head out your arse will you! Cold callers are the scum of the earth and so are their advocates! Retailers are scum too but at least i get the choice or opening the conversation or not!

I wish to thank Stu for his kind words and interesting comments about my anatomy. But, more seriously, I sincerely wish my customers were like him. Wait, let me rephrase that. I wish all humans were like Stu Millett.

This is what we all expect humans to do when solving problems : research the issue, examine the solutions and pick the best one. If you’re not being picked, it must be because your product sucks.

Such an analysis is correct for wedding planners. Every year, there’s a crowd of young couples who never needed to plan a wedding before. The only course of action for them is to research possible options, which provides wedding planners with a constant flow of potential customers that they have to convince based on the merits of their product.

It does not apply, however, to hairdressers. When you set up shop, all the people in your area have already finished their search for a hairdresser. This is not a product issue : even if your skills and your pricing are a clear improvement over the competition, your potential customers are not looking for a hairdresser anymore, and so you will never have a chance to compete in the first place.

If a new hairdresser appeared in your town and offered better haircuts at a lower price, how long would it take you to notice ?

Your strategy is going to be entirely different based on whether you’re selling a wedding planner or hairdresser product. Wedding planners have to spend most of their resources on being easy to find and easy to compare. Hairdressers have to spend most of their resources telling their potential customers that there’s a new player on the field.

The worst possible mistake you could do here is this :

«Our product is unique, there’s no entrenched competition, we are obviously wedding planners.»

Let me make this clear : being a wedding planner or a hairdresser is not about what your product is, it’s about the pain it solves. If you’re solving a pain that a lot of people experience for the first time, then you’re a wedding planner. Otherwise, you’re a hairdresser.

And guess what ? I made that mistake. Our product makes group managers so awesome at managing groups, I thought, that most of our target market will agree we’re the best. So we designed a wedding planner release, and watched quietly as… nobody ever came.

Group managers are not idiots. They know they have group management problems, and they have already looked for solutions years ago. Most of the time, these solutions are contraptions made of mailing-lists, online forums, Microsoft Excel spreadsheets and random pieces of string ; they are frustrating to use and cause many problems of their own, from lost data to people not receiving important messages to privacy issues, but that’s not enough to cause group managers to start looking for other solutions.

In the words of Stu, is our product «not good enough» ? No. Every time we have shown our product to a potential customer, they have loved it, and they even told their friends about it. This is not a product problem. Then did we have a «rubbish business plan» ? We most certainly did!

Our real challenge is not to convince people we’re the best, but to tell as many people as possible that there’s a new hairdresser in town.

As I mentioned previously, there are three ways of doing that : word-of-mouth, advertising and direct contact. Depending on your target population, one of these solutions is going to be better than the others. Direct contact may be the scum of the earth, it may be extremely annoying to many people, but that doesn’t make it a bad marketing strategy.

My first reaction was «Nice, I wonder what my usual passwords look like.» My second reaction was «I should fork this and AJAX all the passwords to my server»

Does that make me innately evil ?

Now I’m a fourth year university student (which is the undergrad year in the US but the first of the two grad years before PhD in France) and I don’t know which one to chose: launch my startup or academic career?

Of course the easy and realistic answer to my question is: finish your studies, do a PhD, start an academic career and when your research brings you an awesome and marketable idea, launch your startup.

But that means maybe launching a startup almost ten years from now, at least. And I must admit that some times I want to live the startup adventure right now, without waiting. When I want that, I’m never stopped by missing startup ideas, I already had plenty of that. What’s missing is the courage to jump and go for it without knowing what happens if it fails, because I haven’t finished my studies yet. That’s an horrible feeling. We people of my generation, at least in France (Europe?), have a lot of pressure about that. We feel like any wrong move will lead us to life-long unemployment and misery. I’m of course exaggerating a little, but you get the idea.

His blog does not allow comments, so I am going to answer his questions on my own blog [1].

Alone, humans have a lot of trouble merely surviving, let alone leading a modern life with its plentiful food, high-speed internet, health benefits, cell phones and MP3 music. Your main priority as a human being is to get help from other human beings. The most common way of doing this is by helping them in return for money, and use that money to buy help from others. Being an employee, a freelancer or an investor are three kinds of help you can offer, each with its own risks and rewards, but ultimately it does not matter.

The single most important skill in modern society is convincing people to accept your help for a good fee. From my experience, young people in general and those with a technical expertise in particular, do not have this skill. They naturally seek out careers where this skill is not necessary: obtaining several degrees (which involves mostly their technical expertise, and makes it easier to convince people to accept their help) and settling on a job that is as stable as possible so they get a maximum bang for the proverbial buck they spent during the recruitment process.

The pressure you describe as «any wrong move [...] life-long unemployment» is a consequence of your lack of skill in getting money from people : you need to spend most of your time building up powerful arguments (good degrees, a brilliant yet consensual early career) to compensate for it. It is hardly surprising that any such argument you fail to build up feels like a setback for your future career.

The secret is that this getting-money-from-people skill can be trained: try spending one day each week with a different recruitment officer, and after a while, you will start to get the hang of it. Once you’ve went through enough interviews that you feel you could get a soulless but high-paying job on a whim, you will feel a lot safer.

Another thing: this skill can be supplemented by things that are neither degrees nor traditional career moves. The very act of founding and sticking with a startup, even if it ultimately failed, is a strong selling point because it says a lot about your ability to function autonomously. Reputation, such as being a known speaker to trade conferences or writing an expert blog on a given topic, is also a great way to convince people. Networking means you can be on the receiving end of an «I know a guy who knows a guy» recommendation, and the act of stepping outside of your social comfort zone is in itself a refreshing activity.

Obviously, having an original early career will make it hard for you to work as a corporate drone. Corporate drones are chosen for their blandness, predictability and lack of surprises, and startup founders are the opposite of all three. So you won’t get a job as a corporate drone. Boo hoo. But many companies, including mine, actually enjoy original profiles [2].

But, and here’s the funny part: you can never build a successful startup if you don’t have mad getting-money-from-people skills. Building a working product is the easy part, especially for technical founders like us, but you won’t sell it, you won’t get investors to fund you, and you won’t convince the mythical «sales co-founder» to join your team. So, if you’re not ready to brush up on those skills, don’t even think of creating a startup. You may certainly join one that already has a competent evangelist on board, but there’s a high risk that it will feel like you’re working on someone else’s project.

Before I go, one final thing about startups. Your «what if I fail ?» makes absolutely no sense. Your startup will fail. Probably several times, in fact. The beauty of startups is that failure is not permanent: you’ve discovered one way that doesn’t work, so pivot the hell out of your business model and try another approach. As long as you keep working on it, there’s no definite point in time where your startup will be objectively and irrevocably dead. And that’s the hardest part about a startup: the only way it can die is if you kill it. [3] If you stop the «okay, one more try and then I give up» game and accept to live forever with the crushing suspicion that one more try would have made it work.

This, in itself, is a lot more painful than the fear you won’t ever find a paying job again.

[1] and if you’re interested in meeting me to discuss this in person, there’s a nice Sushi place near Place d’Italie.
[2] I still wouldn’t hire you, you blasphemous dynamic typing Racket freak
[3] So, when are Republicans going to outlaw startup abortion ?

One of our heaviest database hitters is our « Notifications » dashboard : it contains several notifications such as « James Bond has written a message on the event Tommorow Never Dies by the MI5 organization. » The data presented for each notification comes from several CouchDB documents : a notification document, a message document, an user-profile document, an user-profile-picture document, an event document and an organization document. On a typical dashboard, this represents around 120 documents. A naïve database access layer (one that performs one query per document) would take nearly half a second to extract all that information from the database, not counting the information needed to render the rest of the page.

The recommended CouchDB strategy for this situation is, I believe, a mess. First, all documents involved in rendering the notifications should be present in the same database, or at least a denormalized copy of their data should be. Then, the view that returns the notifications to be rendered should be designed to also contain the documents related to those notifications : the notification document contains the identifier of its dependencies, so it can emit([doc.usr_id,doc.time],{_id,doc.author_id}) to include the user document in the view output. This has the side-effect of completely messing up paging, as it is no longer possible to just grab the first 20 notifications if every notification has a variable number of dependencies.

The traditional SQL strategy for this situation is arguably simpler : INNER JOIN all the required data, then LEFT OUTER JOIN the optional data, and let the ORM map all of that to actual notifications-and-dependencies. Still, it means that notifications cannot be encapsulated, because a single query should be able to get the necessary data for all notifications, so it should know how those notifications are represented.

Our project uses one CouchDB database for each document type. There’s a database that contains only notifications, a database that contains only user profiles, and so on. The application is responsible for bringing together the necessary data by performing GET queries against all the databases. For instance, the code that extracts the notification data from the database looks like this :

let render_event_message msg_id =
  let message = Message.get msg_id in
  let author  = Profile.get (message # author) in
  let picture = Picture.get (author # picture) in
  let event   = Event.get (message # event) in
  let org     = Organization.get (event # org) in
  Html.render_notification ~message ~author ~picture ~event ~org

let render_item = function
  | `EventMessage msg_id -> render_event_message msg_id
  |  ... -> ... 

let render usr_id =
  let items = Notification.for_user usr_id in
  Html.concat (List.map render_item items)

This architecture has two main benefits. First, the segregation of different document types into separate databases makes it easier to split the load onto multiple servers should the need arise, and querying the documents by their identifier makes it easy to insert a simple key-value cache between the database and the application. Secondly, and I believe this is the most important benefit, the code structure is very straightforward, as it is written exactly like one would expect it to be written instead of bending all over for performance reasons, and adding a new kind of notification does not involve changing any existing code, merely adding entirely new code that can be safely encapsulated away in another module.

Obviously, if the above code performs one HTTP GET for every call to a get function, the performance will be disastrous. The solution is to use batching, which involves grouping several queries into a single HTTP request:

GET http://localhost:5984/db/_all_docs?include_docs=true&keys=[1,2,3]

This is three times as fast, but obtains the same data as:

GET http://localhost:5984/db/1
GET http://localhost:5984/db/2
GET http://localhost:5984/db/3

All that remains to be done is to make sure the OCaml-CouchDB interface batches requests together. This is where we originally hit another snag : the application runs each get call in isolation, and it must return a value for execution to continue before it even knows what the next call will be. In order for batching to be possible, the application must be able to call several get functions in parallel, but without the design overhead of making the parallelization explicit.

The solution was to use a monad-based pre-emptive threading model, such as Lwt — the one we use is called Ohm and has several key differences to Lwt, but the underlying thread principles are the same.

When using Ohm, one manipulates queries instead of values. For instance, Profile.get id is not the profile with identifier id, but rather the query that fetches the profile with identifier id. What this means is that, instead of returning the HTML of the page to be displayed in response to a request, every RunOrg request handler returns a database query that returns that HTML. The evaluation engine then evaluates that query, optimizing it on the fly.

The most frequent operation performed on queries is deciding what will happen to the value returned by the query. For instance, to return the picture of an author, one binds a secondary query (get the picture) to a primary query (get the author):

Run.bind
  (fun author -> Picture.get (author # picture))
  (Author.get author_id)

In order to keep things readable, the above is equivalent to :

let! author = ohm $ Author.get author_id in
Picture.get (author # picture)

The second most frequent operation is implicit parallelization, by performing a query for every element of a list, using Run.list_map instead of List.map. The query optimizer will notice this, and will attempt to run all those queries in parallel.

The syntax extension makes the query-based code look very similar to the natural code :

let render_event_message msg_id =
  let! message = ohm $ Message.get msg_id in
  let! author  = ohm $ Profile.get (message # author) in
  let! picture = ohm $ Picture.get (author # picture) in
  let! event   = ohm $ Event.get (message # event) in
  let! org     = ohm $ Organization.get (event # org) in
  return $ Html.render_notification ~message ~author ~picture ~event ~org

let render_item = function
  | `EventMessage msg_id -> render_event_message msg_id
  |  ... -> ... 

let render () =
  let! usr_id    = ohmctx (#user) in
  let! items     = ohm $ Notification.for_user usr_id in
  let! html_list = ohm $ Run.list_map render_item items in
  return $ Html.concat html_list

The benefits of the query optimizer include :

1. The above 120 queries are reduced to around 12 queries, most of them batches. It’s not perfect — manual optimization could have brought this down to 8 queries — but it’s quite good for an approach that does not change the structure of the code.
2. Batch requests to different databases can be performed in parallel.
3. The optimizer also caches values that are read from the database, which is quite useful for frequently-accessed values : a typical user receives most notifications from only a handful of organizations.

This should go without saying, but don’t cold call or spam me. If your product is good and meets my needs, I promise that I’ll find out about it.

I call bullshit on this one. Not the « no cold calls or spam » part, of course (those are an absolute pain) but rather the « I will find it » promise.

You will not find my product …

Because, maybe my product is solving a need that you don’t know you have. Perhaps it’s a pain that you have come to accept as a natural part of life, and you wouldn’t expect a solution to exist. If you already have a working thermostat in your house, how likely are you to search for a better one — and discover that Nest solves your user interface pains ?

Or maybe your needs may look vaguely similar to a problem you have solved in the past, so you will use the same solution as before instead of doing a brand new search for new solutions. You need to split expenses for a party, and you know a Google Docs form would solve the problem, so you don’t bother looking for anything else and never discover more adapted solutions, such as Splitwise.

… so I need to reach you.

There are many ways of doing that — ads, social marketing, press releases, viral features, cold calling — and depending on the product and the target audience, some of them may work better than others. Yes, it’s possible for cold calling or mass e-mailing to achieve better results than all other techniques combined.

As surprising as it may seem, my startup has achieved the best results by calling or e-mailing people directly: we reached more people, we had a better conversion rate, and we had higher profits.

Am I suggesting cold calls or spam?

Kind of. The situation is far from black-and-white.

At the white end of the continuum, I know with perfect accuracy whether my product meets your needs. Maybe you posted about it on your blog, or mentioned it at a conference, or one of your friends tweeted about it. I can call you and say « Sir, I’ve noticed that you are looking for a Frobnicator, and we happen to be the only Frobnicator providers in your area. » and to you, this will not feel like a cold call, it will feel like someone paying attention to you.

At the black end of the continuum, I have no idea who you are or what you want. I can call you and say « Insert name here, would you like to purchase life insurance for your pet goldfish? » and your pet goldfish died last week and you burst into tears on the phone and curse me and my kin for seven generations.

The question is, where do we draw the line? How qualified do your leads need to be before you contact them directly? And if the leads are qualified enough, why are we not calling them?

She called a store employee for help, explained the problem and apologized for not being able to use the machine correctly.

My first thought was « Why apologize ? This is clearly a technical problem, the machines should be able to handle broccoli correctly ! Blame the machines or the engineers who invented them ! »

Then, one of the other voices in my head whispered to me « Oh look, you’re thinking like a product designer ! » and that voice was indeed quite right : I had spent the day working on some product design issues for my startup, and I was deep in the « Never blame users. Always blame the machine. » mindset that comes with it.

Had I spent the day writing code, I would have reacted exactly like that woman had — well, perhaps instead of calling for help I would have tried to debug the issue myself, but I would have still felt deserving of some kind of karmic blame for not being able to scan a piece of broccoli. How much of an idiot do you have to be to fail to scan a piece of broccoli ?

The first rule of programming is that The Machine Is Always Right. If something wrong happens, you messed up. You made a typo, left in a logic bug, failed to take an edge case into account, or had any other kind of brain fart. The chances of cosmic rays corrupting your RAM or compiler bugs mangling your algorithms are exceedingly slim. The reflexive reaction to any unexpected program behavior is to ask yourself « Where did I go wrong this time ? »

When improving a software product, the opposite mindset is necessary : if the program surprises the user, then the program is wrong. The chances of a complete idiot expecing your accounting package to play music are exceedingly slim.

So, to design software you need to be in blame-the-machine mode, and to develop software you need to be in blame-the-human mode. If you’re both the designer and the developer, you had better be good at context-switching those two modes.

I patted myself on the back for my awesome context-switching abilities. I swear, I have a brain lobe entirely devoted to patting myself on the back.

Then I looked back on all the team meetings I had at RunOrg and examined the evidence in light of this blame-assignment mode, with alarming conclusions : it turns out that the context switching speed is not that good, and the speed depends on the direction. All you need to do to get me from blame-the-machine to blame-the-human is mention an interesting technical problem and hint that a solution might be needed, maybe, someday. Then I will put on my developer hat, reach for the caffeine and start thinking of possible solutions.

However, my non-technical co-founders are permanently in blame-the-program mode. If I am in blame-the-human mode and they suggest a program change, my thought process is as follows :

• FOOLISH MORTALS, ARE YOU SAYING MY WORK IS CRAP ?
• Wait. Stay calm. I’m not my work. I should take criticism like an adult.
• Ok, I understand what you expect, but that’s not how it works.
• Wait. They know that’s not how it works. What do they mean, then ?
• Oh, you mean users expect that to happen ? They’re wrong.
• Wait. Customers are always right.

… and then I snap back to blame-the-program mode and all is well. Depending on how diplomatic I am feeling at the moment, one or more of the above steps may be played out silently in my head instead of being spoken out loud to my co-founders.

Does anyone else get these context-switches wrong, too ?

For the sake of discussion, let us assume that truth may only be found within your version of the Holy Bible — however unfair it may be to members of other religions — including, of course, that God does indeed exist as described therein.

As you might know, the Genesis describes how the Lord created everything. The most well-known quote from the Holy Bible is probably this :

And God said, Let there be light: and there was light.

This answers the question « Why is there light ? » that, quite shockingly, secular science never considered interesting enough to ponder. Indeed, secular science instead concentrates on more empirical questions such as « How does light behave ? » — answered in part by the laws of Maxwell — or « Is light a special case of a more general phenomenon ? » — which is indeed the case, as visible light is made of the same stuff as X-rays or radio waves.

In a sense, secular scientists do have a point : questions such as « How does it behave ? » give us the ability to predict the behavior of things, which is essential in order to build tools or technology. Understanding the wave-like behaviour of light, for instance, is essential to building lasers, which in turn enable us to have DVD players and eye surgery. Questions such as « Why does it exist ? » have no such practical application, unless the answer covers both Why and How.

As such, « Light exists because God created it » is of no practical or scientific use — it is, by definition, a small bit of trivia : true, but useless for anything but the sake of knowledge. Then again, knowledge begets knowledge : if the information contained within the Holy Bible is true, why are we not using it as a starting point for increasing our knowledge of the universe ?

For instance, we know from the Bible that God said, Let there be light.

What language did He speak ? Was it one of the early semitic languages, such as those that transmitted the early versions of the Bible through oral tradition ? If that were the case, linguists worldwide would be thrilled to learn that a language from the afro-asiatic family existed before humans were around to speak it. Or was it something else entirely ?

In that case, what were the exact words He used ? Could we use them to infer the vocabulary and grammar of that language ? How would it relate to modern or ancient languages ?

We know that the words carried the power to create light, but was the power within the words or did it come from God ? If it was within the words, could we harness words of power ourselves, perhaps by emulating the anatomical characteristics God used to speak them ? If not, why were words necessary and what does this tell us about the interaction between words and power ?

These are just elementary questions related to a single sentence in the Holy Bible, and they are not directly answered therein. Finding the answers would greatly further our understanding of our word, and have great practical applications. Why are we not working on these questions ?

Because we can’t.

All the supernatural aspects of the Bible, including God, are out of reach of our tools and experiments. Any attempt to test, observe or replicate supernatural events mentioned in the bible : either the event was observed and could be explained with purely natural reasons, or it could not be observed.

I fear that God may be beyond the reach of our scientific methodology because He does not wish to be a subject of research. In that case, it would be wise to keep God out of the science classroom, because He does not wish to be there.

I suspect, however, that science has actually always observed God and His actions on our world, because all happens in the world through His will. This would mean that any scientific observations, laws and theories are merely boring and secular descriptions of the Lord’s actions. But then, what happens when the Words of God and the Actions of God appear to be contradictory ?

It is because our human interpretation of His Words and our human observations of His Actions do not match. Either the man reading the Bible made a mistake, or the man studying the world made a mistake. And both have happened in the past. We should act in this matter as we act in all other cases of contradiction : ask both men to explain their work, so that we may check it for them.

It is sinful to presume that your interpretation of God’s Words is true, for you are but a man. And to say « It is written in the Bible ! » is a lie, you should instead quote the Bible and meditate differing interpretations from your peers.

Then again, maybe science has never observed God simply because God does not exist.

The current iteration of the competition has the subject «Love» which, as you might imagine, led to many heart-rendering, pink-tinted applications being submitted.

My own submission is «Why am I single ?» :

It performs a simulation of a 50%-male, 50%-female population (entirely heterosexual — I couldn’t fit anything else in those 1k bytes) of things that bounce around a room and enter variable-duration relationships whenever opposite gender couples collide. A pie chart in the top left corner displays the current proportions of single males and females.