Het Bijstere Spoor

So my good friend siep bought Sony headphones a year or two ago. After a while, they broke right at the left earpiece. Kinda sucked.. He didn't have any receipts, so there wasn't a lot that could be done.

They are pretty high quality headphones. Well, at least in terms of audio quality. So he tried to repair them with some screws and some metal:

But they broke again, this time on the other side.

He actually had given the set to me, because I just gave him a new pair for christmas, the MDR-V500. They also broke:

And then, I got another pair of Sony headphones for my birthday in April. This time the MDR-7505. Hoping they fixed some of the issues with a new model, I had full confidence. On top of that I was extra careful this time and made sure they were around my neck when I transported them. It was no use:

We went to the store when the second pair broke, and also now with the third pair. They won't do anything however without the receipts while this is such an obvious faulty product. On top of that I have two other friends with the same stories about the headphones. $400 worth of headphones down the drain.

I called Sony today and they tell me I should go back to the store to try to get a copy of the receipt. I'm going to try to get that, but not really happy with that solution either. It might give me 1 set back at most, while I really want my money back for all 3 of them.

A list apart was probably one of the first feeds I added to my RSS reader, and up until this day I enjoy reading the high quality articles.

Just last Tuesday they published an article around progressive enhancement with css, which covered a rather funny example from Andy Clarke's site, which is completely black and white in IE6, along with modified low-fi images.

I couldn't resist doing this myself as well, so if you hit this site using IE6 now this is how it will look like:

.

The code:

This has been covered on other sites even when FP10 was still beta, but sadly I've just ran into this one right now.

Flash Player 10 no longer allows uploads to be invoked from within javascript, and requires an actual mouseclick or buttonpress event from within flash. For the people using tools like swfupload or the (old version of-) YUI uploader, this is bad news, as these tools will simply break.

The fix was made as a security measure against phishing-type attacks, and this has been the behaviour in browsers for as long as I can remember, so if its any consolidation.. it's a good thing really.

The Flash Blog mentions:

Similarly, another possibility is to overlay a transparent SWF button over the HTML content so that again, the user clicking happens in Flash and not in HTML.

Which is actually kind of funny, in a time where 'Clickjacking' is big news, and I would also strongly discourage such attempts to make sure you have a solution that still works in 2009. I'd like to see an example of this, just to test if noscript's clickjacking protection works.

The only real options out there are to simply switch back to good old html uploaders, or do your uploader interface entirely in flash. We'll probably be implementing the former in the short term to work on the latter down the road. The updated version of the YUI uploader also takes the flash approach.

SolarPHP's framework now comes with SQL adapter for MySQL replicated setups since the 1.0.0alpha2 release. The adapter automatically picks master or slave databases depending on the type of query. If its a SELECT, it will go to a slave, if its a UPDATE, DELETE, etc. it will automatically go to the master.

Let me just put it out there, I think that's a really bad idea. While this will work for certain situations, it is advertised as "The Solar_Sql_Adapter_MysqlReplicated adapter handles all the connections and switching-around for you, and you don't need change a single line of application code.".

Quite frankly, I started out with a similar approach. It worked fine for our staging environment, which didn't experience a lot of load, when it went to the live machine things went bad.

Suddenly I realized there were more than couple places in the application that had to do SELECT based on information that was just INSERT'ed. After the INSERT was done, the SELECT was performed on the slave, while the data hadn't arrived yet from the master. This caused some pretty freaky errors. Hoping to fix the problem, I decided to always execute any query on the master after an data-altering statement was done. Turned out that the master got quite a bit more load than the slaves after that change.

Things got worse when there was a replication lag of say, a second. Users would modify some data by submitting a form, and when they ended up on a resulting page the data was gone!

Some of the things we looked at was using a whitelist or blacklist for queries that are always ok/not ok to go to the slave, but considering we then ended up with decoupling a logical block of code, we went for the pragmatic approach. Always pick the master or slave depending on what is required for a specific piece of functionality. Yes, it might require a bit more thinking as you're working on your database code, but the behaviour is predictable and reliable.