Laravel Tutorials

I’ve wanted to start learning MVC for quite some time now and have decided to learn Laravel at the same time. I already have experience with MVC on a few projects, but I’m still at the point where any practice helps.

This is a forum post on the Laravel site that lists some awesome tutorials on using Laravel. I’ve never used a PHP framework, but Laravel is awesome. I’ve read through the first few posts listed there and am really liking it so far.

As a somewhat obscure side note, this is what I wanted to build when I realized I wouldn’t finish Dsgn365 last summer. For an intro project I’m building to teach myself how to use Laravel, I added the Laravel Github repo as a remote and did a fetch to get the latest copy. Then I pushed to my own repo. Now I can build on top of the latest build of Laravel and when he releases a new version, I can rebase and keep everything up-to-date.

What Powers Instagram

This is an excellent article on Instagram’s engineering blog. You’ll appreciate this if you’re a server nerd like me. I found a summary of the technologies they write about here, as well. This is rather impressive. With three engineers they they run 100+ servers including a dozen PostgreSQL servers and 25 Django application servers.

A couple things I found particularly interesting:

  • SSL terminates at the Elastic Load Balancer, which lessens the load on nginx.
  • Ubuntu 11.04 (Natty Narwhal) was the most stable thing they could find. It’s what I run as well, but I always thought I would feel safer with 10.04 (Lucid Lynx) as it is the current LTS. I suppose you still only need to do a full distro-upgrade every three years or so even when you’re not on an LTS.
  • Guincorn instead of Apache. This doesn’t necessarily surprise me, just interesting. Apache is a memory hog, though you can probably fine-tune it if you’re interested in that much configuration.

Email

MG Siegler recently wrote about his choice to archive 50,000+ emails one night. And how he used that to decide to archive everyone once a week from now on.

A week ago, I came home after a long night of drinking and wanted to vomit. It wasn’t the whiskey. It was the email.

The way I deal with email is only slightly different from MG’s. The ammount of email I get is extremely tame, but I still think the workflow could help a lot of people. It’s something I’ve worked into after hours of listening to Merlin Mann, in various formats, speak about email and time management.

I use my email in very tight conjunction with Things. It could be any “to do” list style app. OmniFocus is another good one. I like Things for its simplicity.

There’s one rule that I have with email, only read it once. That’s not the perfect way to say it. Of course I read emails multiple times, but when I read and email there are three things that can happen.

  1. Junk. Delete.
  2. I can do this in a minute or two. Do it. Archive or Delete.
  3. I don’t have time to do this right now. Put it in Things. Archive.

When it’s something I don’t have time for, I’ll drop a link to the email in the notes field of Things if I’m going to need to reference it again. This obviously requires you have an active to do list that you keep up with. It might seem like you’re just pushing the problem out of email and into another list, but ideally your to do list is more organized that your email. If you read the same email six times before you do something about it, you were wasting your time the first five times. With a GTD type approach, you can quickly look at your list and know what needs to get done and what things you can currently do based on contexts.

This works for me with a small volume of email. I imagine it gets even better the more email you get. The more email you get, the more time you waste re-reading everything.1

MG writes about how relieving it can be to have the weight of 50,000 emails moved out of your inbox, to a place that you only ever see them when/if you need to. It’s funny because I’m the same way, though I don’t clear my RSS reader every night, it’s something I do regularly. And those red Push Notifications. I don’t think this is uncommon though.

It’s essentially out-of-sight, out-of-mind. I should have known this would be the case since I’m also obsessed with clearing my RSS reader every night (even though I barely use it anymore) and am a slave to clearing red Push Notification dots on the iPhone/iPad.

I only slightly disagree with the final point:

Read most of it. Respond to some of it. Keep all of it. But hide it. Then forget about it. And repeat. And repeat. And repeat.

I don’t keep all my email. There’s a lot of email that I know I’ll never need again. I delete them. Maybe you never get email like that.


  1. Now if Sparrow would only have an option to check my mail every hour instead of pushing it to me as it comes in. I know I can set it to manual, but that’s too hard. 

Roots Hide WP

Theme author, Ben Word, has been working for some time on Roots: “a starting WordPress theme based on HTML5 Boilerplate & Bootstrap from Twitter.” Back in November, Word wrote an article about how they’re hiding the fact that the theme is powered by WordPress.

In the Roots theme we’re taking several steps to ensure that a visitor to your website won’t know that you’re using WordPress

They do some interesting things, including rewriting URLs to theme assets & plugins to hide the wp-content directory and rewriting URLs to root-relative addresses. Additionally there’s a “walker” class for custom navigation menus, so you could do something like:

wp_nav_menu(array('theme_location' => 'primary_navigation', 'walker' => new roots_nav_walker()));

I’m offering it here as a plugin with some minor changes. Word’s original post is code directly from the Roots theme which is meant to “hide” the fact that a site is running on WordPress. That’s fine for them. I didn’t want to make any decisions about where the assets folder should be for an unsuspecting person who may have been using WordPress for some time. Cleaning wp_head sounds good in practice and I’m sure there’s some stuff in there that most people don’t need, but there’s a reason it got so messy in the first place. I’m still doing a bit of cleaning there, the scripts to make tagging word in Windows Live Writer will be removed along with the wp_generator script that writes out the WordPress version to a meta tag — it’s considered to be a security risk to let people know your WordPress version.

View in Plugin Directory Download on Github

The Beer Game or Why Apple Can’t Build iPads in the US

The Beer Game explains why Apple can’t build iPads in the US. It’s not labor costs, it’s the supply chain. Apple could build a factory to assemble devices in the U.S., but all the components come from China anyway.

In the end, we had lost hundreds of dollars in backorders and excess inventory and were cursing out our upstream or downstream vendors for being idiots.

The lessons of the Beer Game are pretty evident. Delay in the supply chain causes amplified downstream problems. The problem wasn’t that we were kids running beer supply, the problem was the structure of the chain itself. Small changes at the front end lead to massive mistakes down the line.

From the transcript of This American Life’s “Retraction” episode:

But labor is such an enormously small part of any electronic device, right? Compared to the cost of buying chips or making sure that you have a plant that can turn out thousands of these things a day or being able to get strengthened glass cut exactly right within, you know, two days of this thing being due, that’s what’s important. Labor is almost insignificant. What is really important are supply chains and flexibility of factories.