@nleach

The Magic

Properly prepared cold brewed iced coffee just begs to be enjoyed black and the experience is unique and worthwhile. Cold brewing greatly reduces the acidity of the coffee produced, making it significantly less bitter and easier on your stomach. It also causes the flavors to be expressed differently than with a hot brewing method, so even your old, tired roasts can taste fresh and new.

The Method

This is a matter of preference, but as far as I’m concerned, cold brewed iced coffee is the only way to go. My device of choice (mostly out of convenience) is a french press, and it certainly gets the job done.

1. Coarsely grind about 20% more beans than you normally would for your press
2. Add cold water and stir aggressively, making sure that all the grounds get fully mixed
3. Optional After a few hours, stir again to allow for more even and fuller extraction
4. After 12-16 hours, plunge and pour over ice*

The Alternative

The cold brewing process requires more coffee and more time, which makes it more expensive to produce. This means that most coffee “establishments” simply chill a stronger brew and call it good. This kind of iced coffee starts off pretty wretched but turns okay once some of the ice has melted. It’s by far the most common, so it’s pretty much unavoidable.

Where To Go

Some of my favorites in NYC:

• Think Coffee
• 9th St Espresso
• Irving Farm Coffee

I’m a huge fan of Google Chrome for Mac OS X. It’s painfully fast and lightweight (especially when compared to Firefox); however, it’s still very much in beta. One place this has become glaringly obvious is the lack of a bookmark manager.

One way around this limitation is to edit the Bookmarks file located in:

$HOME/Library/Application Support/Google/Chrome/Default

Editing configuration files is generally less than ideal, but luckily this one is laid out in a pretty straightforward manner.

I love Gmail, I really do, but it can be frustrating to always be tied to a web application. I tried using Fluid to give my email experience more of a desktop-y feel, and I even wrote a nifty userscript to display a Growl notification when you receive a new email. It worked for the most part, but high memory usage rendered the fluid app painful unpleasant to use, and I eventually abandoned the setup all together. Recently, I’ve been using my iPhone as a email notification system, and Gmail lives happily inside Chrome.

That is, until I found Notify. I only installed it a few minutes ago, but my first impressions are extremely positive. It’s a sleek, no-nonsense app, it supports multiple accounts, and Google Apps. The $10 pricetag seems perfectly reasonable, but even better, the free version does just enough to make me happy.

Notify is a perfect example of why I’ve fallen head-over-heals in love with OS X software. The attention to detail is just phenomenal and is present in every part of the application. I mean, just look at the website! It’s this insane quality that make me sometimes wish I could give up this whole web thing and just write kickass Cocoa.

DISCLAIMER: I do sysadmin work out of necessity, not by choice. Your mileage with these suggestions may vary. As always, exercise caution when making changes to your application’s architecture.

Background

When scaling your MySQL-based web application, setting up multiple databases in a master-slave configuration can be a great way to distribute load. The procedure is well documented, and fairly straightforward.

• Any queries that change data (INSERT, UPDATE, ALTER, etc) are performed on the master
• These changes are replicated the slave server(s)
• Read queries can be performed on both the master and slave servers

The real advantage here is when a write query on the master locks a table, data from that table can still be read from a slave. WIN!

So once you have your master-slave setup running, you may notice that the slave servers periodically fall behind the master server. Usually, the lag is just a few seconds, but under certain circumstances, slave servers can lag dangerously behind (my personal best is just under one hour). Why? On the master server, multiple queries can be executed in parallel, but when the slave server reads queries from the binary log, they must be executed one at a time. While this may seem like a huge waste, it’s really the key to the replication sceme as it ensures that data on the slaves will exactly match that on the server once all of the queries have been executed.

Preventing Minimizing Lag & Being Smart About Laggy Data

1. Optimize your queries - Because the slaves can’t replicate queries in parallel, this is your primary target. Break up large INSERT and UPDATE queries into several queries that deal with smaller data sets. And as an added bonus, optimized queries will make your entire application faster! </obvious>
2. Beef up your slave servers - Conventional logic may suggest that your master server should be your most powerful and that your slave servers can rely on less stellar hardware. However, your master will always be able to process queries more efficiently than the slaves. Once again, it’s because slaves execute each query sequentially. (Notice a pattern?) Chances are, disk IO is going to be your bottleneck. Consider investing in faster hard disks in a RAID configuration.
3. Give lagging slaves a break - Throwing queries at a lagging slave is only going to make matters worse. Not only will it be less efficient when churning through the binary log, but you’re also much more likely to be working with outdated data set. Incorporate logic into your application to distribute load to your slaves intelligently based on their individual lag (don’t forget, you can always run SELECT queries on the master).
4. Memcache your writes - When your slaves are lagging, you run the risk of accessing old data. A great way to minimize this risk is to cache all of your most recently written data in some kind of caching layer, I like Memcached. This can be tricky to do depending on how your application interfaces with your database, but if table rows are discretely representated inside your application (IE - rows translate to objects), and you can isolate changes to these individual rows, caching that data can be a great way to prevent inconsistency and improve performance.

Additional Resources

Here are some outstanding resources with even more suggestions and detailed instructions on how to combat a stressfully high Seconds_Behind_Master.

• MySQL Slave Lag (Delay) Explained And 7 Ways To Battle It
• Managing Slave Lag with MySQL Replication
• MySQL Slave Database Can’t Catch Up
• Database replication lag