Slowdog

Learn to Properly Coil Your MacBook’s Power Cord

robl — Fri, 13 Aug 2010 21:36:15 +0000

Nice little tip. Bonus is that by keeping the cord through the loop, it doesn’t come completely unraveled while on top of my desk (which it really likes to do otherwise).

RegExr

robl — Fri, 06 Aug 2010 17:45:43 +0000

Awesome little tool for checking regular expressions (despite that it’s in flash ).

Terminal Tips and Tricks For Mac OS X – Super User

robl — Wed, 28 Jul 2010 23:29:10 +0000

Something worth keeping an eye on as I’m sure there’s going to be some useful stuff from time to time.

Roasted Apricot Ice Cream with Almond Praline Ripple

robl — Sun, 25 Jul 2010 03:09:23 +0000

Despite my denials, I’ve been getting increasingly more lactose intolerant. But I still like me some ice cream. Enter coconut milk. I’ve been enjoying it with my coffee for a while now, and, as it turns out, the ice cream (or “frozen non-dairy dessert”) is delicious. None of that weird soy taste (my son says he tastes the coconut, I can’t; maybe I’ve become immune). Anyway, I’ve been wondering about making it at home and did some looking. This recipe, by far, looked the best. Will update after I’ve had the chance to make it.

5 reasons why your company should be distributed « toni.org

robl — Wed, 17 Mar 2010 22:46:37 +0000

Great post about the plusses of having a distributed company. I’ve worked remotely now for 5 years, so this hits home for me (so to speak).

I’d dispute #3 somewhat as this certainly doesn’t force your team to use “better communication tools” (I have a founder who lives on the phone), but it’s certainly made me better at recording things (either by wiki or email – none of use chat much).

Really like idea #4, but currently all our developers are here in Portland, so there’s not much need (still think it’s a good idea, though).

For #5, we all meet once a week in a coffee shop. I like the idea of having something more permanent, though, and especially using the space for meetups and such.

Portland Architecture: Ecoroofs: for the birds?

robl — Wed, 17 Mar 2010 21:19:51 +0000

Our roof has so much lichen that I call it an living roof. Despite the joke, I’d really like to have a living roof, or ecoroof. Looks like the pitch of the roof must be under 25 degrees, so I don’t know if we’d qualify. But I need to follow up on this.

Gay marriage: the database engineering perspective @ Things Of Interest

robl — Wed, 17 Mar 2010 21:16:02 +0000

Whoda thought that combining gay marriage and schema design would lead to an great post?

Two MySQL Posts Which Make Me Secure In That I’ll Have Work For a While

Administrator — Wed, 17 Feb 2010 19:44:59 +0000

This is going to make me sound like an old man (OK, right, I am old. So, suck it.), but these two posts alternately scare me and let me know that I’ll have work going into the future as a DB developer.

In the first post, Chris Moos describes a problem he’s having with queries performing badly, doing full table scans over a 12M row table. His answer: partition the table. So, Chris, first off, let’s talk about this 12M row table. Does it really have to be so long? Can something be done (other than partitioning) to make it smaller. Second, um, have you heard of indexes? They work pretty well. (Not that our tables are all that big, but) We have tables well over twice that long (and they sound like they are much wider as well), and get good response on queries using the indexes. Why, why, would you go with something as complicated as partitioning, when there’s other approaches that should be tried first.

The second post describes how, with the coming of more NoSQL solutions, MySQL doesn’t need to be used to store data objects as blobs anymore. A solution that earlier “made perfect sense.” There’s many arguments to the design of data objects, and I’ve been a part of many of them. I have big problems with the storing of objects as blobs which I won’t go into here. If that’s something you want to do, fine. But to do that using MySQL (or any relational DB is just plain stupid). And, it never made any sense, let alone perfect. When picking tools, familiarity with the tool is only one aspect. A much larger aspect is whether it’s the right tool for the job. MySQL has a lot of strengths, but the way it stores blobs is not one of them. And, the NoSQL solutions aren’t really new. Object-Relational, Object, and Document-based DB’s have been around for a long time. Not to mention, just using ye ole file system.

My design steps?

Choose the right tools and be able to defend why you’re choosing them.
Keep things simple. Only get more complicated as the product/users dictate.
Think ahead, but not too much ahead. Are you designing for today, or the future? Don’t want to go crazy as who knows what the future holds, but try to at least think 3-6 months ahead.
Be ready to redesign something. Don’t hold onto a design for reasons of pride. It doesn’t work, then it doesn’t work. It’s only data, it’s movable.

How to load large files safely into InnoDB tables

Administrator — Wed, 17 Feb 2010 02:41:33 +0000

This is awesome! We’ve been having multiple issues with data loads recently. Especially one file we get monthly, which is not very wide (few columns, with small data types), but has over 27 millions rows. Even though our server is now huge, and I split the file into 7M row files, one of the “chunks” still almost brought down our database this month. About an hour into the load (the first two chunks, which loaded with no issues, took about 2.5 hours), all inserts started timing out. Looking at the monitoring graphs on RightScale, the cpu’s were pegged all waiting for disk response. Selects were still being returned, but all inserts had stopped. Weirdly, while new inserts were timing out, two inserts and one update were just hanging. Unfortunately, killing the load didn’t have any immediate affect as it needed to rollback the hour of changes it had made (don’t ask me why MySQL does a “load data infile” within a transaction; seems much smarter if it weren’t, but anyway …). Luckily, killing the three “hanging” processes did allow other inserts to start up again. And, after about 30 minutes, the data load process finally went away.

So, I went a-googling and found this article. We tried it on one file made up of the two remaining “chunks”, so around 13M rows (1.3GB). We set the fifo to 500K, and a delay of 30 seconds between each. Not only was the load on the db amazingly lower, but (most likely since memory wasn’t filling forcing the system to start swapping) the load was amazingly fast, loading everything in just over an hour. Yes, that’s right, from 2.5 hours for 7M rows to (I’ll round up and say) 1.5 hours for 13M rows.

Needless to say, I’m geeked-out about this.

Now, we just need to figure how to turn this into a repeatable monthly process.

Portland Transport: What Kind of Traveler are You?

robl — Wed, 17 Feb 2010 02:12:31 +0000

From a survey originally done in Germany, five type of travelers are identified.

Public transport rejecters. These believe public transport provides little sense of control or excitement. They are not open to change and see access to mobility as very important.
Car individualists. Similar to public transport rejecters, but are open to change and consider privacy more important.
Weather-resistant cyclists. Positive towards bicycles and will cycle even in bad weather.
Eco-sensitised public transport users. Positive towards public transport and are highly influenced by their environmental conscience.
Self-determined mobile people. Perform the highest percentage of trips by foot; they do not consider mobility important and are not open to change.

Among these, I guess I’d be closest to #5. Would much prefer to do my trips by foot. But, in no way do I “not consider mobility important”: in fact, it’s mainly for reasons of mobility that I prefer walking. Though, by mobility, I’m thinking versatility, and they may be thinking distance. Nor do I think I’m “not open to change”: though I used the bus a fair amount in Phila, I use it much more often here in Portland since distance if much more of an issue.