I’ve been telling more people about the benefits I’ve received from meditation. Meditation has greatly influenced the way I think, behave, and relate to others.
I noticed recently that Google Play Music has a set of features I wasn’t aware of before, and decided to give it a try. Through various kinds of yak shaving, I ended up tackling a project I’d wanted to look into for a while: which formats and settings are really the best for lossy music compression?
What I learned was both fun and surprising, and ultimately highly practical. If you’re in a hurry, the summary is that high-quality variable-bitrate MP3 produced with the LAME encoder is probably the best all-around choice if you want broad compatibility; if you want the best sound quality, though, AAC (Apple’s native format) or Ogg Vorbis are much better than MP3.
But before I get to that, let’s sharpen some yak razors, shall we?
About 18 months ago I began an experiment on social media.
It’s a new year and I drew a diagram.
I switched to an iPhone about 6 months ago and have found it superior to the Android phones I’ve used, except for one baffling thing. The GMail app on iOS is awful compared to the Android version. Unusably awful, actually. Fortunately, Outlook is very good. Better than the alternatives. Here’s why.
When someone shares your blog article on a social network, odds are it will appear with some descriptive text, images, and so on. If your blog lacks explicit instructions, in many cases these properties are just guessed-at and won’t be great.
I’ve seen a lot of blog authors and template creators go too far the other direction and add tons of redundant meta tags, which will make the page larger, heavier, and slower.
What’s the minimal necessary set of tags?
I often see benchmark reports that show charts but don’t provide tables of numeric results. Some people will make the actual measurements available if asked, but I’ve been interested in analyzing many systems for which I can’t get numbers. Fortunately, it’s usually possible to get approximate results without too much trouble. In this blog post I’ll show several ways to extract estimates of values from a chart image.
Hi! I probably don’t know you, but I’d like to make this blog better for you. If you’re disabled—for example, perhaps you use a screen reader, a special device, or have other needs that I might not anticipate, I’d really love your feedback on what I can do to make my content easier for you to read and enjoy.
In the last couple of weeks, there have been a few blog posts about benchmarks comparing the performance of various versions of MySQL and variants such as MariaDB. There’s also been some analysis of the results using formal models such as Neil Gunther’s Universal Scalability Law.
What can the Universal Scalability Law (USL) teach us about the performance characteristics of these systems, as revealed by the benchmarks? To find out, I’ll examine one particular benchmark, MariaDB 10.1 and MySQL 5.7 performance on commodity hardware.
At Velocity/OSCON 2015 in Amsterdam a couple of weeks ago, the conference committee approached me to ask if I’d be up for doing an Ignite talk. It was rather last-minute and I had only hours to prepare. I said yes and then tried to think of a topic. I turned to Twitter and asked, if you could have me talk for 5 minutes on any topic, what would it be? A couple of people responded that they wanted to know what founding a company was like, so I sat down in the speaker lounge at the RAI and started trying to figure out what it’s like to be a founder/CEO.
You’d think I’d know after three years, but truthfully, it’s still hard to really know what I feel.
I was talking with someone the other day about a visualization I remembered seeing some years ago, that could help set a reasonable value for a threshold on a metric. As I’ve written, thresholds are basically a broken way to monitor systems, but if you’re going to use them, I think there are simple things you can do to avoid making threshold values completely arbitrary.
I couldn’t find the place I’d seen the visualization (if you know prior art for the below, please comment!) so I decided to just blog about it. Suppose you start off with a time series:
If you haven’t heard about PGConfSV yet, it’s a conference for the Silicon Valley PostgreSQL community and beyond, featuring leading PostgreSQL performance and scalability experts. It’s happening November 17-18 at the South San Francisco Conference Center. I encourage everyone in the area to attend, since this is likely to be the best Postgres conference held thus far in the Silicon Valley.
I also urge you to buy your tickets before they sell out! Of course, the earlier you buy, the more you save, too. (Use SeeMeSpeak for a 20% discount).
I’ll be at the conference along with some of my colleagues. I’m pretty excited about this for a few reasons. Allow me to ‘splain why?
A while ago I wrote a blog post about time series database requirements that has been amazingly popular. Somewhere close to a dozen companies have told me they’ve built custom in-house time series databases, and that blog post was the first draft of a design document for it.
One of the things I said in the post was that I had no use for the “tagging” functionality I’ve seen in time series databases such as OpenTSDB. I’ve since reconsidered, although I think the functionality I now want is a bit different.
Over the last couple of years I have increasingly studied and used personality tests for personal and professional uses, both for myself and for others. I’ve seen a variety of benefits, but these assessments are not without drawbacks, and not all assessments are created equal.
Running a conference is hard work, and lots of things need to come together in just the right way to make it a great experience for everyone. This blog post is a collection of the most important things I’ve seen conference organizers get wrong (with the best intentions). It’s not comprehensive, but I hope it will help point out “low-hanging fruit” for interested people. Hopefully you’ll be able to avoid some of the mistakes as a result.
A number of people have commented to me over the last few years that when they search for me on Google, it suggests that they might want to search for “Baron Schwartz left Percona.” This is a top suggestion when I search for myself, too.
Since people are searching for it, maybe I should explain it.
Years ago I pursued my interest in InnoDB’s architecture and design, and became impressed with its sophistication. Another way to say it is that InnoDB is complicated, as are all MVCC databases. However, InnoDB manages to hide the bulk of its complexity entirely from most users.
I decided to at least outline a book on InnoDB. After researching it for a while, it became clear that it would need to be a series of books in multiple volumes, with somewhere between 1000 and 2000 pages total.
At one time I actually understood a lot of this material, but I have forgotten most of it now.
I did not begin writing. Although it is incomplete, outdated, and in some cases wrong, I share the outline here in case anyone is interested. It might be of particular interest to someone who thinks it’s an easy task to write a new database.
UPDATE: the book is now available from https://ruxit.com/anomaly-detection/.
Together with Preetam Jinka, I’m writing a book for O’Reilly called Anomaly Detection for Monitoring (working title).
I’d like your help with this. Would you please comment, tweet, or email me examples of anomaly detection used for monitoring; and monitoring problems that frustrate you, which you think anomaly detection might help solve?
Thanks in advance.