Xaprb

Ergohuman Executive Chair With Headrest

I’ve upgraded my office chair to the Ergohuman Executive Chair With Headrest. I had a chair that was less adjustable and was leather, so in the warmer summer months it was not very pleasant to sit on.

So far I’m delighted. I’m 6-foot-4 (195cm) and this is one of the only chairs I’ve ever seen that seats my height comfortably, both in terms of seat height and in terms of being tall enough to relax back into (the headrest extends up high enough to support my head and neck nicely). The mesh keeps me nice and cool. The arm rests adjust out of my way if I want. There is plenty of adjustment, but not too much; it is a well-built chair, not a gadget.

I read a lot of online reviews and considered a dozen or so chair models before settling on this one. Other reviewers commented highly about the durability. Those who had troubles were very happy with the service they received.

A chair is a long-term investment that’s hard to overvalue. If you’re a programmer, you’ll use it day in and day out; you may spend more time in it than out of it. A good quality chair should last ten years, easily; amortize the cost of the chair over that time and it suddenly appears cheap. A typical person will buy enough shoes during that time to pay for many high-quality chairs. I’m a stickler for my equipment; I view it as tools to get my work done; I would never put myself in a bad quality chair, just as my father would buy nothing but Snap-On tools for his mechanical work.

I have nothing bad to say about it. Oh, and it’s certainly a vastly better chair than the Aeron chairs, which are uncomfortable, too short to relax back in, highly overrated, and much more expensive.

Do you test your application systematically when you upgrade or reconfigure your database server? You should! Here’s a real (anonymized) story of what happens if you don’t.

When we upgraded to 5.0.62 (from 5.0.27 and 5.0.45), our code broke for queries like this:

SELECT SUM(amt) FROM daily_amt WHERE day = FROM_UNIXTIME(1222889772);

The problem here was a wrong DATE/DATETIME comparison and other bug fixes in MySQL 5.0.62; it was stricter in enforcing the comparison.

This resulted in an outage and revenue loss to the company.

Daniel and I (mostly Daniel) continue to improve mk-upgrade to make it easy and inexpensive to find these kinds of scenarios before they bite you. Don’t get caught with your pants down — next time you make any major change to your database server (upgrade, configuration change, switching to InnoDB…) follow at least this bare-minimum process:

• collect all queries run against the server for a sufficient time
• get a snapshot of your data
• use mk-upgrade to validate correctness and performance
• submit bug reports — this is a non-trivial tool, and we need your feedback

If you need help with any of the above, I know someone who can help.

A while ago I wrote about a tool to help make upgrades safer. Since then, we have gotten several people to help sponsor development on this tool, and a few of our customers are using it to help find problems before they upgrade their systems.

I can’t think of a single one of the Maatkit tools that didn’t grow out of the need for deeper insight into some part of the system. This tool is no exception. And as always, these tools are like flashlights. When you crouch down near the floor, and shine your flashlight under the refrigerator, you should expect to find a few things that make you cringe.

The other day, one of our customers was using this tool and we started getting an error. The error was caused by the part of the tool that verifies that result sets are the same. Our thought on how to do this was to checksum the results of a query. You can read the specification of exactly how we plan to do this if you want, but I’ll just give you the short version here: use a subquery. But some queries cannot be put into a subquery without causing errors.

Here’s an example:

mysql> select a, a from t;
+------+------+
| a    | a    |
+------+------+
|    1 |    1 | 
+------+------+

If you wrap this query into a subquery, you will get an error:

mysql> select * from (select a, a from t) as a;
ERROR 1060 (42S21): Duplicate column name 'a'

Of course the problem is that the innermost query is actually invalid in a relational sense. Once again, it comes back to the fact that SQL doesn’t keep you from doing things that make no sense.

The exact query that we were seeing on our client was a little bit more subtle, but it’s still a fairly common pattern that I have seen in the real world:

select a.*, [other stuff], a.column1 from ...

This type of query should be catchable by mk-query-audit, when we write it. Oooh — another flashlight to find hairy things with wobbly eyes under your fridge!