I am always fascinated about the cleanliness of UNIX . One
tool only should do one thing, but it has to be the best in
that way. The operating system itself will glue all the
modules together and give you a complex feel of a system, you
don’t have to take care of huge, bloated software, don’t […]

When I joined Pinterest, my first three weeks were spent in Base
Camp, where the newest engineering hires work on real production
issues across the entire software stack. In Base Camp, we learn
how Pinterest is built by building it, and it’s not uncommon to
be pushing code and making meaningful contributions within just a
few days. At Pinterest, newly hired engineers have the
flexibility to choose which team they’ll join, and working on
different parts of the code as part of the Base Camp experience
can help with this decision. Base Campers typically work on a
variety of tasks, but my project was a deep dive into a MySQL
performance optimization project.

Pinterest, MySQL and AWS, oh my!

We work with MySQL running entirely inside Amazon Web Services
(AWS). Despite using fairly high-powered instance types with
RAID-0 SSDs and a fairly simple workload (many point selects by
PK or simple ranges) that peaks around 2,000 …

A good portion of the startups I meet and advise want to use the
newest, hottest technology to build something that’s cool, but
not technologically groundbreaking. I have yet to meet a startup
building a time machine, teleporter or quantum social network
that would actually require some amazing new tech. They have
awesome new ideas with down-to-earth technical requirements, so I
kept wondering why they choose this shiny (and risky) new stuff
when all they need is a good ol’ trustworthy database. I think
it’s because many assume that building the latest and greatest
needs the latest and greatest!

It turns out that’s only one of three bad reasons (traps) why
people go for the shiny and new. Reason two is people mistakenly
assume older stuff is slow, not feature rich or won’t scale.
“MySQL is sluggish,” they say. “Java is slow,” I’ve heard.
“Python won’t scale,” they claim. None of it’s true.

A Pattern for a Newly Hired DBA? I don’t think this experience is
unique. It has been shared repeatedly among those starting a job
as a DBA (database administrator) at a new company, especially
when the organization has never had a dedicated DBA. The
conversation usually goes something like this: – “Welcome aboard
<insert name here>! Here [...] …

In early 2006 Paul Hurley (ideeli’s CEO) and I (Mark Uhrmacher,
CTO) were thinking about a new business. We had the idea to
create a community based around great deals for Women’s fashion
products where we saw a great deal of potential for great content
and product sales. Now, over five years later, we’ve realized
much of that vision. Our business success has been chronicled
over the years in several places (see here and here). Though we’re very proud of our achievements
there, that isn’t what this blog is about.

Insatiable Demand is about a mostly untold story. Over the
past five-plus years we’ve built a phenomenal technology platform
and team. From two people and three servers to a 70 person team
and a 100 instance production environment, …

It’s been some time now that we’ve been talking about devops, the
pushing together of application development and application
deployment via IT operations, in the enterprise. To keep up to
speed on the trend, 451 CAOS attended PuppetConf, a
conference for the Puppet Labs community of IT administrators,
developers and industry leaders around the open source Puppet
server configuration and automation software. One thing that
seems clear, given the talk about agile development and
operations, cloud computing, business and culture, our definition of devops continues to be accurate.

Another consistent part of devops that also emerged at PuppetConf
last week was the way it tends to introduce additional
stakeholders beyond software developers and IT …

Whenever we are faced with a choice between two designs, and the
first design is upward compatible with the second (i.e. the first
design is more restrictive, and implementing design two would not
affect functionality provided by design one), and the full
impliciations of the second design are not yet known, the first
design choice is recommended.
Formulated by C.J. Date in "Relational Database: Writings
1989-1991"

Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.