I've stumbled upon (what appears to be) a bug in MySQL .Net Connector (version 5.1.3).
I opened the bug in the MySQL bugs database, you can read the details here - bug #31617.

Basically, when calling MySqlCommand.ExecuteReader with an sql statement that times out - you get back a closed MySqlDataReader and the underlying MySqlConnection becomes corrupted, meaning you cannot use it for new operations and you cannot close it either.

The workaround you can implement in the meanwhile is:

1. Always check that the reader you got is open before iterating on it:

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

There is a strange, underground, free-mason, rappers-delight, a-tribe-called-quest, thank-you-chuck-norris, scrum-lover-association-kind-of-thing taking shape as we speak.
For some reason, Moti and Oren simultaneously posted some seriously weird posts with some scrum mambo jambo in them. Moti even added some scary Egyptian-writing-stlye codewords in the end.

And then, of all things, they tagged me to be a "scrum clan member".
Well well. And I thought this blog doesn't take itself seriously.
If this is some sort of scheme to make me write something I don't stand behind, well, you got another thing coming, boys. My opinions on the Agile Methodologies are well defined and will be expressed in written form sooner rather than later.
And I'm supposed to tag someone.

Goodie goodie, it's a game.

For my serious pick, I tag Shani, who is doing really cool agile stuff as a team lead.
For my less serious, I-can-post-weirder-than-you-can pick, I tag Tomer as "scrum lover undercover".

p.s.
Does "tagging" mean I'm supposed to actually post something on scrum? Is that it?

p.p.s.
Google experiment #29:
1. Teenage mutant ninja turtles.
2. Scuba diving makes you hairy.
3. "Less code, more features" said the joker to the thief.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

All web applications can be seperated by the way they charge users into three groups:
1. Free forever - using the application is free, for all the parts of the application, forever. Example: Google search engine.
2. Free to try - using the application for some time is free (usually first couple of weeks/months), then you have to pay to continue using the application. Example: Clarizen Project Management (my previous employer).
3. "Freemium" - there is a free version of the application that you can use forever, and there is one or more payed versions. The versions are distinguished by the features they provide.

The third model is maybe the most common and definitely the easiest to do wrong. That's because the devil is in the details.
The details are how the free version is different from the paying version. Your goal as a developer is to give something valuable to the user for free and make it so valuable that they want even more.
The goal is not to annoy your free users so much that they will pay just to make you stop annoying them. It won't happen.

And most importantly: don't design your differentiation in a way that in the free version it's possible to do everything that the payed version does but in a more annoying way.

The problem is that differentiation in the freemium model is very hard to do right in a service that is narrow and well defined, which is often the case. When your application does just one thing - how can you have different types of users?

Case in point:
Cafe Press, an otherwise great idea, has the freemium thing all screwed up:
They provide a service for people to design their own stuff (t-shirts, mugs...) and sell it in a web store hosted on Cafe Press. They take care of actually manufacturing the products and handling the ordering and shipping against the customer. You just design your stuff and take a percentage of the sales.
It's free to setup a "basic" store and it costs money to setup a "premium" store. The difference is that the "basic" store can only have one design for each product type. So you can sell just one white t-shirt, one colored t-shirt, one hand bag and so on.
But
Any free user can setup as many basic stores.
So, you can sell as many items as you want, just like a paying user, you just have to work harder (basically more clicks) and get more annoyed. The premium store can also have custom designs and better display of items, but that's not as important in terms of features to the user.

The people at cafe press have a great business. They make money from selling t-shirts and they don't have to pay for the designs. In my opinion, they should abandon the paying version alltogether. That will just drive more people to upload designs and increase sales.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

On this happy day, I am most pleased to announce the launch of my own clothing line - "bitzwear".
It's about time I joined the ranks of many sports celebrities and hip hop artists and designed my own, signature wear.
So, if you're young, cool, hip, smart and beautiful - get yours now! And get something for your friends too.
Available only from the official bitzwear store on the web.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

This post is a continuation of two previous posts: Solving the Measuring Paradox and If You Measure This Then Your Children Will Be Next.

When setting quantity-based goals or metrics, it is usually better to measure over a period of time that is long as possible.
Consider the following example: suppose you want to motivate developers on your team to resolve as many bugs as possible. So you start measuring the number of bugs closed by developer and set the following goal: each developer must resolve at least two bugs a day.
Here’s what will happen: Alice, a developer on your team resolves her second bug of the day at 2PM. By 4PM she already has a fully tested solution to her third bug. Alice, being the perfectly logical creature she is and aware of the goal you set, will not check in her fix but rather wait until the next day. This way she will make it easier for herself to reach her goal tomorrow as well. In fact, your developers will start accumulating these “spare” bugs “just in case”.
I’ m against the measurement tactics altogether, but if you have to id it, it is much better to define the metric for a longer term.
Suppose that instead you define the goal to be “40 resolved bugs per month” (I’m assuming 20 work days per month here). This way, your developers still have more of an incentive to work on bugs throughout the period, because “good days” (with lots of resolved bugs) will balance with the “slow days”.

“What’s the difference?” you say. “This way or the other, 40 bugs have to be resolved over the month”.
Not exactly: first – the fact that bug fixes are being “held up” for later, stalls other things (such as other people waiting for the fix). Second – under the first version of the metric, a developer who already has a few bugs “reserved” has less incentive to work hard on new bugs, whereas under the second version of the metric, assuming the metric is not much less than the developer “usual” throughput, the “slow days” balance out the “good” ones and the developer has motivation to work on bugs to meet the long-term goal.

Here are two interesting analogies from the world of sports:
The football championships in Argentina have a unique (and genius IMO) system for relegation from and promotion to the top league: instead of relegation based on the performance in the last season (number of points) like everywhere else, teams are relegated based on their performance over the last three seasons. This avoids the common scenario where teams placed in the middle of the table have “nothing to play for” at the end of the season and games involving these teams tend to be rather boring.

Another example: players’ contracts often consist of a base salary and some performance based bonuses. These bonuses are always set based on a long period (e.g. average points scored over the whole season) and not a single game (bonus for scoring over X points in a single game).

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

I finally caved and got the Flickr "Pro" account.
So now everything, old and new, is available here.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

That was fast.
Oren wins a beer correctly answering the quiz.
Not exactly what I had in mind, but the rules didn't say anything about googling it.

Solution:
MySQL thinks that in my time zone (Jerusalem) daylight savings time starts on March 30th every year (which is not exactly true) and on that day the clock goes from 01:59:59AM straight to 03:00:00AM. So all the datetime values between 30/3 02:00:00 and 30/3 02:59:59 are considered invalid.

Also funny how another person who ran into this thought it was quiz material.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

First correct answer to win 1 free beer!(List of beers available upon request)
Post your answer in the comments.

The question:
I am trying to enter the value "30/03/2007 02:15:00" into a datetime column in MySQL and get the error "incorrect datetime".
What's wrong?

*update* Hint #1: format is okay, MySQL knows that 30 is day, 3 is month, 2 is hour and so on.
*update*: Solved! Answer here.

Fine print:
1. The free beer prize is available only within 25 miles of Ramat Gan. No beer-by-mail.
2. Shlomo may not participate.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

Zoominfo is a website that exposes a database of companies and people. Zoominfo builds this database automatically by software that crawls the web and extracts structured data from unstructured web pages (for example, "about" pages in company websites and press releases) using natural language processing algorithms.
A while ago, I posted a little satirical "press release" about me, the CTO of pashabitz.com, purchasing a burekas from "sammy burekas".
A couple of weeks ago zoominfo's crawler reached that "press release" and now I am listed as the "chief technology officer of pashabitz.com".

Just a reminder of how hard it is to code anything related to AI.
Computers just can't get a joke.

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co

As I've mentioned, I left Clarizen a couple of months ago.
Now about the new thing:
I joined a new startup company - Semingo.
During the past year I got certain that what I want to do right now is develop ideas "from scratch" in a startup environment. So when Sagie, who is one of the founders of Semingo and my friend from the army days invited me to join - it was a perfect fit.
The idea we're working on is very exciting and the people on the team are very bright.
Oren and Tomer are also blogging from a few feet away (and more bloggers coming soon!!).
We've only just started but it's been a lot of fun already.
About the product: all I can say right now is that it's related to social networks (just because that's what the press release says) and it's as cool as ice (before global warming). Don't worry, we're planning to release soon, so you'll be able to use it in no time (touch wood) - stay tuned!

Want to join me as partner in a cool new startup?
Get in touch: pasha at cohai dot co