I probably could’ve titled this post, “Man, I love my 50mm lens”. Just snapping random photos while testing out my new vertical grip. Just posting the two best ones in the batch.

This photo proves how insane the noise reduction is in Lightroom 3. Taken at 1600 ISO in a fairly dark room. Only thing on my side was the bright 50mm prime lens, which pulled amazing depth of field even from the dimly lit evening room.

Love this photo. Though, she almost looks like she might be getting sick. I hope not.

Got my new Canon T3i today. Still trying to figure out all the tricks to it, but I’m still happy with some of the results of day #1 of shooting with it. After spending some time reading the manual and clicking around the house, I took it with us to Jeannine and Joel’s to meet baby Megan.

I did a bit of cleanup to this shot. Not because of a bad picture, but because the carpet was way too messy and it was distracting. Lightroom’s heal tool came in handy to “clean” the carpet.

I love this shot. Best one of the night.

Jeannine and Joel have an awesome barn off beyond the edge of their backyard. None of the shots I got were that fantastic, but this one looked much better once a bit of Sepia was added.

Don’t let my expression fool you. I’m a sucker for babies. My wife took this shot with the “Green Square” full auto mode. It came out pretty nice. The handling of auto white balance is way better than on my old 300D.

All in all, I’m thrilled so far. Just the startup time alone is worth it. The fact that the images are gorgeous doesn’t hurt either. Still feel a little weird not shooting RAW, but the files are almost 25 megs a piece – it’s just not worth it for stuff that’s not super-critical. I just don’t have that kind of HD space on my laptop.

Of course, shooting JPEG means I’m bound to the white balance gods. But, so far the results have been decent, and for anything that’s been off, Lightroom could more than handle fixing it up enought to look natural. I’m sure once I get used to the camera, I’ll be able to compensate while balance without thinking.

Taken w/ Instagram

Inspiring photography. Do yourself a favor. Watch it in Full Screen HD and turn up the sound. :)

Stumbled across the awesome Grape framework for writing a simple REST server for a small project I’m messing with. Since I was trying to write tests right out of the gate instead of using curl to do everything, I immediately started trying to get Rest::Test to work, which was failing miserably.

After googling and playing around for awhile, I did eventually get it. It was mainly with how to setup the app function, which didn’t make a lot of sense when config.ru uses the run function to get itself going.

I figured I’d just post this code below so if anyone else runs into this issue, they’ll have the answer. This is using MiniTest and Ruby 1.9.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

require 'helper'
require "rack/test"

class TestApi < MiniTest::Unit::TestCase
  include Rack::Test::Methods

  def app
    Rack::Builder.new {
      map "/" do
        run Rest::API # The class that extends Grape::API
      end
    }.to_app
  end

  def test_it_gives_back_some_content
    get '/rest/v1/content'
    assert last_response.ok?
    assert_equal '[]', last_response.body
  end
end

Taken w/ Instagram

When I setup Jekyll, I wanted to make it so it was possible to deploy new posts automatically. I wanted to be able to drop a file in my _posts directory in any of my Dropbox enabled devices and have the site rebuild itself. Plus, I wanted my _drafts folder to go to my dev site that show my Draft posts.

The most obvious solution would be to setup a cron job that runs every 5 or 10 minutes. Of course, not only does this make the site build unnecessarily, but it also kills any immediate satisfaction of seeing my posts immediately. I needed to find another way.

Incron to the Rescue!

After some clever Google-fu, I stumbled across incron. The website doesn’t quite do it justice, or even do a good job of explaining what it does. The basic concept is that it’s a cron-like daemon, but it fires if there are file system changes. A file is added, removed, edited, etc. – see where this is going?

To get started, I installed incron from apt. Everyone that can use incron has to have their username added to /etc/incron.allow by the root user like so:

1

tedkulp

Then as your user, fire up incrontab -e. After messing around with it for a long time, I found the proper entry is something like:

1

/home/tedkulp/Dropbox/tedkulp.com/_posts IN_DELETE,IN_CLOSE_WRITE,IN_MOVE,IN_NO_LOOP /home/tedkulp/runbuild.sh

The first section is the directory to watch, which in my case is my _posts directory. The next section are the various flags. In this case, I want it to fire whenever a file is saved, moved or deleted. The IN_NO_LOOP is especially important, because it will allow my script to only run once at a time, even if mutliple events fire. The last bit is obviously the script that fires.

Because I use RVM system-wide, the script is a little complicated. This is because incron only sends a very minimal amount of environment variables to the script when it’s invoked. RVM relies heavily on environment variables, and since they’re not being set, we have to write them by hand. I haven’t found a better way – and I tried a lot of them. Here is my script… it’s using rvm installed ruby 1.9.2.

1
2
3
4
5
6
7
8
9

#!/bin/bash
cd /var/www/tedkulp.com/jekyll/_source

export LANG=en_US.UTF-8
export GEM_HOME=/usr/local/rvm/gems/ruby-1.9.2-p180
export GEM_PATH=/usr/local/rvm/gems/ruby-1.9.2-p180:/usr/local/rvm/gems/ruby-1.9.2-p180@global
export PATH=/usr/local/rvm/gems/ruby-1.9.2-p180/bin:/usr/local/rvm/gems/ruby-1.9.2-p180@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p180/bin:/usr/local/rvm/bin:$PATH

/usr/local/rvm/rubies/ruby-1.9.2-p180/bin/ruby /var/www/tedkulp.com/www/bin/jekyll /var/www/tedkulp.com/www/_source /var/www/tedkulp.com/www/_source/_site > /tmp/blah.txt 2> /tmp/blah2.txt

I got the majority of this information from rvm info while logged in as the same user that would run the script. I also pump the output to tmp files for debugging purposes, because incron doesn’t really handle any script output at all – it’s terribly difficult to debug.

That being said, except for a few hiccups, it’s a nice stable system. I now have my site automatically updating whenever I change a file, which is stupidly convenient.

Bonus Dropbox Trick

I won’t take credit for this one, as it was suggested by Dan Benjamin of 5by5. He’s a smart dude.

Chances are that you really don’t want to have your whole personal Dropbox sitting on a server somewhere that you might not have a full amount of control over. Of course, you do want to be able to edit your posts from various machines, and get them onto the server, though.

What to do? What to do?

It’s pretty simple, actually. Create a second Dropbox account for your site. Create a directory for your site, and put your posts and drafts directories in there. Then, share that directory with your main Dropbox account.

On the server, sync to the 2nd account instead so that you’re only syncing over just the files needed for that site. Don’t feel bad about this, though. You’re not really “getting one over” on Dropbox. Files in shared directories are subtracted from the quotas of ALL the users that share that directory, so in essence, except for some overhead for Dropbox having to keep track of a 2nd accounts details, you’re not really taking very much advantage of their kindness.

For more information on my interaction with Jekyll, check out the Jekyll tag on my blog here. I’d also love any Dropbox referrals you might be able to give, click here.

Taken w/ Instagram

As I posted earlier in my introduction to the new blog, I said that one of the main things I liked about Posterous was being able to create a blog post from an email. It serves two pretty cool purposes for me.

First, it allows me to write a blog post anywhere and send it at will. While I’m not the biggest blogger ever, it was definitely a convenience factor for me. However, with the Dropbox integration, this becomes less of an issue, because I can write a post pretty much anywhere now, including my iPad.

But, more importantly, it gave me a way to send content from other services and import directly into my blog. A blog for me is kind of a collection of rag tag stuff… photos from Flickr and Instagram, articles that I star in Google Reader, etc. Now that I don’t have a common API like I did with Posterous, it becomes a challenge to get content into my blog automatically. I’ll go more into how I got around that later on.

Getting Email In

Since I have a dedicated Ubuntu server for several sites of mine on Linode, I have the power of being able to hack up Postfix to bend to my wills. This probalby isn’t the case with everyone, but if it does apply, please read along.

The idea was to create a hidden email address on my main domain, take emails from that and get them to a ruby script.

The first thing I did was create a quick and dirty script that takes an incoming email over stdin and processes it into the correct directory (either _posts or _drafts, depending on tags – more a in sec). The way I tested this was just to take a full email that I sent to Posterous earlier, grab the source of it (Show Original in Gmail), and put that into a text file. Then just pipe that into my script (cat email.txt | receive-email.rb) and I was good to go. Sure I could’ve created a test suite, but like I said, it was quick and dirty.

Some things of note, here. I’ve taken the Posterous system of being able to put metadata tags right into the subject line. So, it uses the majority of the subject as the post’s title, and filters out any tags that look like: ((key: value)). Right now, it handles tags ((tags: tag1, tag2)), the ability to use drafts ((draft: true)), type of markup: ((markup: html)), slug ((slug: this-is-the-slug)) and layout ((layout: post)).

Files are written out to the appropriate dropbox folder, and picked up automatically to rebuild the site. I’ll describe that in detail in another post.

Postfix config

It took a bit of playing to get this working in Postfix, but I did eventually get it. Without going into crazy detail on stuff that’s already been rehashed several times on other posts, let’s just say that putting a script into your alias file is a bad idea because the script will be run as root. It’s better to use the transport method to pipe emails to a particular script – sort of how something like Spamassassin would be setup.

In your master.cf, you would add another handler to the bottom similar to this:

1

jekyll    unix  -       n       n       -       -       pipe user=tedkulp argv=/path/to/jekyll/email-script/receive-email.sh

It very simply takes any emails with the “jekyll” transport and pushes them to the script that I setup. Notice it’s an .sh and not the .rb. This was because I have rvm setup globally, and it’s a bit difficult to get the environment params correct. Basically, it’s just setting the environment and pushing all of stdin to my script – no big deal.

Because I’m hosting my tedkulp.com domain on this server as well, I can’t just push all of my email to jekyll. So, for my hidden email address, I use a trick in my virtual file to rewrite it to an unusued subdomain, which in my case is hidden.tedkulp.com. My line in the virtual file looks something like:

1

hidden-email@tedkulp.com     hidden-email@hidden.tedkulp.com

This is only rewritten for the purposes of Postfix, and doesn’t translate to anything else. It’s only purpose is to allow me to write a custom transport rule for hidden.tedkulp.com.

The last trick now is to setup my transport file to take all emails to hidden.tedkulp.com and push them to jekyll. Since it’s not a real subdomain, it’s only going to see emails from my rewritten hidden email address. It looks something like:

1

hidden.tedkulp.com jekyll

A quick postfix reload, and you’re good to go.

If then what now?

Now for the issue of the automated posting. Since we have our email address to send content to, we just need something to do it for us.

There’s a new service that’s still in early beta that is making that process a WHOLE lot easier. IfThisThenThat (lovingly called ifttt) is a service that allows you to take triggers from one thing and apply them to another thing. So, basically, you can make a task that will, say, email your hidden email blog address everytime you create a new photo in Instagram. It’s stupidly powerful, totally nerdy, and downright awesome. They’re really responsive on twitter and very receptive to new ideas, which is great. I’ve been using it for a few months now, but it really didn’t becomes THAT useful until the blog switch.

Here is an example of the template for the email that’s sent from my Instagram task. Simple as can be…

Now, I have all of my automated posts emailed to me to my secret email address. Awesome!

In my next post, I’ll discuss how to get my posts from Dropbox to automatically show up in Jekyll without touching the sever.

A little while ago, while listening to Build & Analyze, Marco and Dan we’re talking about the idea of having a static page blogging system. It was a fairly simple concept… Store all your posts in Dropbox, and have a system that could automatically generate a full website based on those posts.

In a way, it makes a lot of sense. Blogs started out as static sites, and only moved to dynamic code when people wanted things like comments or trackbacks on their site. But in the days of Disqus, it doesn’t really make a ton of sense to have a whole site regenerate a site from static content. Add the fact that I get very few comments, and no trackbacks, it’s really just a waste of processing power.

My site has been hosted on Posterous for awhile now. And I’ll be honest, I really have nothing against them. If someone was going to go into blogging for the first time, they’d be near the top of my list – it has a lot of great features. But, it also has a few small nagging items – which wouldn’t bother normal people. But, I’m an nerd, and nerds aren’t normal.

Marco was starting from scratch, which is fine for him. Since I knew that I was going to probably add a lot of stuff to this system (and since Marco still hasn’t released his code for his yet), I decided to do the smart thing and look for some other system to build on top of.

Since I’m living the Ruby lifestyle these days, I decided to start messing with Jekyll. Jekyll is great. It does the bare minimum of what I needed to get started. It takes a directory of posts and creates a static site around them. It handles Markdown, it has a basic plugin system and it uses a decent template language. So after exporting all of my posts from Posterous, I proceeded to start hacking the thing up for my benefit.

There were a few things that I really appreciated about Posterous that I wanted to get into my own system. The first was the ability to create blog posts via email. While I didn’t always use this, I really liked the idea and did post about half of my articles that way. It also is a very easy way to automate posting from other systems (I’ll get more into that later). The other thing was the Autopost system. I loved being able to create a post, and have it show up in Twitter, Facebook, etc. Of course, they have a ton of infrastructure dedicated to this system, but I at least wanted to hack together a very basic system.

After roughly two weeks of hacking here and there, I’ve changed my site to point to my Jekyll blog instead of Posterous. While the site isn’t completely done (will it ever be?), it’s at least far enough along that I felt it was ready to go live.

Over the next couple of weeks, I’ll do some posts that give specifics on how it all goes together. It’s a fairly complex system, and while totally unnecessary, it helped me learn a lot… and that’s what it’s all about.

If you’re interested in the code that’s gone into this, you can check out my Jekyll Fork, my templates and plugins, and my email-to-jekyll script.