There's no excuse these days for crappy web performance. The low hanging fruit is just too low. It is trivial to make a web site that loads fast for users. Do it. If you don't know how, you should come to my Web Performance Boot Camp tutorial at ApacheCon. Make you site fast — no excuses.
JSON sucks. Don't get me wrong, I love the simplicity of it. It's simple, it's easy, it's portable, it's ubiquitous at this point. None of that means it doesn't suck. Outside of Javascript (hence the portability), JSON itself is limited to native types in the grammar:
null object (like a hash) array string integer (signed 32bit) number (double) boolean Really? It's 2010 and we're all flocking to a grammar where we can only accurately represent integers up to 231-1.
Hey you! PostgreSQL process running a query over there... Yeah you. What's your search path?
Hello? Why aren't you listening to me? Oh, just because you are busy running queries for someone else for hours means you don't have to take some time to answer my question? Apparently, that's a good enough excuse. You, yes you process ID 18883, need to respect my authority.
# echo '*postgres`namespace_search_path /s' | mdb -p 18883 0x9d5420: noit_a29_n625680_noit, stratcon, public I done told you.
This past Thursday and Friday (and much of Wednesday honestly), OmniTI went where it never went before: we ran a conference. Surge 2010 was, in fact, a unique conference despite its close relevance to others in the industry. This conference was assembled to answer one question: "How do I build systems that perform well and scale to meet demand?" That may seem like a simple question that someone has asked before, but I am an engineer and, as such, use an engineering definition of "
A while ago I started a project to add DTrace probes into common open source applications we use at OmniTI. I added them into Apache/APR-utils (which were put back) and PostgreSQL (which were also put back). I’ve also added metrics exposure to the many applications we write internally (either in JSON or the Resmon XML DTD) over HTTP. It’s so easy these days to include an HTTP server into whatever daemon process you are writing/working on that there are almost no excuses to not wire one up and expose your application’s internal metrics.
It’s been ages since I wrote about a book I’ve read. I didn’t stop reading, just sharing.
I recently read Jared Diamond’s “Gun, Germs & Steel.” I’m not going to spoil the book, but not for the reason you think. You can’t spoil this book without regurgitating it in its entirety: it is pure content. Every page is interesting and I refreshingly exercised my mind on the challenges of our world from an old-world perspective.
Many people have asked me how Oracle's recent actions will affect OmniTI and our clients. As you may or may not know, a considerable amount of OmniTI's internal infrastructure is built around the OpenSolaris platform. Given Oracle's recent announcement about their path forward toward Solaris 11, what does that mean for OmniTI and OmniTI's customers?
In short: what's old is new and what's new is old and business as usual.
