Wouldn’t you like to find the root cause of that downtime incident? Many people would. But experience has taught me that there is no such thing as a single root cause. Instead, there’s a chain of interrelated causes, each of which is necessary but none of which is sufficient to cause the overall problem.
I use Mac OSX’s built-in Time Machine for backups, and a couple of times I’ve noticed my backups failed and couldn’t be completed successfully. I was unable to fix the problem until I reformatted the backup drive. Today I think I stumbled on the solution.
Focus is perhaps the most important attribute in an organization. In fact, my dictionary defines an organization as “an organized body of people with a particular purpose…” A focused organization recognizes and cleaves to its purpose.
Likewise, the ability to create and sustain focus is perhaps the most valuable skill of the organization’s members, including both individual contributors and leaders.
My dictionary says focus is “an act of concentrating.” Consider the root words: concentrate literally means to bring to a common center, to be centered together.
Join me and other Velocity attendees during the Wednesday afternoon 2:40pm break for a 10-15 minute guided meditation session appropriate for people of any faith or of none.
Meditation has a host of scientifically proven immediate and long-term benefits. If you get an extra 10% of clarity and effectiveness for the rest of the afternoon, you’ll end up learning more and making your conference experience more worthwhile.
Over the years I’ve come to believe something that I’m not sure others will agree with. I would like to hear your point of view on it.
I posit that some code can become literally unfixable. Programmers can paint themselves into a corner with the code and it becomes impossible to get out again.
The scenario arises when a specific set of conditions exists:
Two of my favorite conferences are coming up. One’s just next week, and another’s in the fall.
Velocity is such a great event. I wanted to go for years, and when I finally did it was honestly one of the highlights of my professional career. I still don’t know what I did get get invited to speak that first year. It was a golden horseshoe falling out of the sky and landing right in front of me.
I’ve had conversations about time-series databases with many people over the last couple of years. I wrote previously about some of the open-source technologies that people commonly use for time-series storage.
Because I have my own ideas about what constitutes a good time-series database, and because a few people have asked me to describe my requirements, I have decided to publish my thoughts here. All opinions that follow are my own, and as you read you should mentally add “in my opinion” to every sentence.
Once upon a time I managed several teams of consultants. At a certain stage of the organization’s growth, we wanted to achieve a higher billable-time utilization more easily, and we wanted more structure and process.
Cary Millsap, about whom I have written quite a bit elsewhere on this blog, suggested that I might profit from reading The Goal by Eliyahu Goldratt. I will let history be the judge of the outcome, but from my perspective, this was revolutionary for me. It is a clear watershed moment in my memory: I lived life one way and saw things through one lens before, and afterwards everything was different.
A while ago I wrote about some of the things that can make MySQL unreliable or hard to operate. Some time after that, in a completely unrelated topic, someone made me aware of a set of principles called 12-factor that I believe originated from experiences building Heroku.
That’s been over a year, and I’ve come to increasingly agree with the 12-factor principles. I guess I’m extremely late to the party, but making applications behave in 12-factor-compliant ways has solved a lot of problems for me.
This experience has repeatedly reminded me of one of the applications that continues to cause a lot of the kinds of pain that the 12-factor principles have solved for me: MySQL.
I spoke at Gophercon last week in Denver, and it was one of the best conferences I’ve attended. I can’t remember learning so much and meeting so many great people in years. I have page after page of notes in my notebook, many of which I’ve yet to follow up on. The conference prompted a burst of learning and a flurry of creativity for me, as well as a huge list of things to study further.
In no particular order, here are some of the many highlights for me:
I was listening to a conversation recently and heard an experienced engineer express an interesting point of view on joins and key-value databases. I don’t entirely agree with it. Here’s why.
First, the opinion. If I may paraphrase, the discussion was something like this:
I’m simplifying, because the speaker actually suggested that MySQL makes a really good database for primary-key lookups as well.
The place I would differ slightly is on the last bullet point.
Have you heard of sharding a database? Of course you have. Do you know where the term comes from? Someone asked me this at a cocktail party recently. I gave it my best shot.
“The earliest I remember was Google engineers using it to describe the architecture of some things,” I said. “That would have been about 2006.”
“Nope. Much earlier than that,” said my new friend.
I pondered. “Well, I guess there was the famous LiveJournal architecture article about MySQL. That was, I dunno, 2003?”
The person then told me the following history. I can neither confirm nor deny it; what do you know about it?
I’ve used Vim for as long as I can remember, but when I started to work with Go at VividCortex, for some reason I started to use Sublime Text instead. It does make a very nice GUI-based editor, but I never felt that it was as powerful as Vim.
Ever notice how the Vim logo looks a little like Superman’s logo? No? Squint a little harder, then.