Problem: I get an "access denied" error message when trying to save some change done to a web application in the IIS manager on Vista.

Possible solution:
Windows Vista comes with a new version of IIS. One of the new things in IIS 7 is that it saves it's configuration in the .net web.config files (previous versions used the "IIS metabase", which is a bunch of files internal to the IIS configuration tool). This is an improvement because it simplifies deployment and versioning - all you need to do is edit an xml file, whereas the IIS metabase is configurable only using a special API.

Correction(following Eyal's comment): actually the IIS metabase is an xml file that can be directly edited.

So, why the "access denied"? If you're making an application-level (as opposed to machine-level) configuration, many times it's because your application's web.config file is not checked-out for edit in VS, and so it is read-only on disk. IIS manager cannot write to it and shows you the error.

More on IIS 7 at pashabitz.com:
How to setup a custom HttpHandler in IIS 7
Developing ASP.NET apps under II7 on Vista.

This is so cool. I just bought the new Radiohead album, "In Rainbows".
What's so special? The album is available only by direct download from a website set up by the band (http://www.inrainbows.com/).
Everybody wins:
1. The buyer - finally, I can legally download music from the internet (iTunes and the like do not allow downloads with a credit card that is issued in Israel).
2. The seller - Radiohead bypass the record label, and probably profit more for each album sold.

But that's not all. Coolness factor number 2 - you get to set the price you pay for the album. That's right. This is a brilliant idea already emplyed in the past (read here). When you trust your customers, they return the favor. Turns out, people end up paying more on average when given the chance to set the price themselves.
This is a very interesting pricing model that I think can work out very well for various products (perhaps web applications too). This method probably suits best products where the "normal" price is lower than a certain limit (say 100$). Above that I'm not sure it will work.

As to bypassing record labels and selling music direct over the web - I think in 2 years 90% of the artists will go this way.

p.s.
I payed 6 GBP, which is about 12 USD or 50 NIS.

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:

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.

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.

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.

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

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.

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.