Hopefully this can be of use to others. YMMV:

The mixin definition:

=dead-center(!height,!width)
  :height= !height
  :margin-top= -(!height / 2)
  :top 50%
  :width= !width
  :margin-left= -(!width / 2)
  :left 50%
  :position absolute
  :text-align center

To use it on an element:

#centered
  +dead-center(200px,500px)

Now I’ll never forget how. Thanks Sass!

No related posts.

Awesome!! Well, kinda.

The problem is that most plugin developers don’t include release notes with each version, rendering the awesomeness of no effect. For instance, I have no idea what I’m getting by upgrading the Google XML Sitemaps plugin. This is what you see after clicking the “View Version 3.1.4 Details” button:

The closest thing offered there is a link to the Changelog, which opens in a new tab/window. Totally lame. Check out the Changelog. It is filled with totally useful information. Make it accessible!

Slap your users in the face with reasons to upgrade!

Contrast that with what is displayed to potential upgraders (not sure if that’s even a word) of my WordPress Console plugin:

Two things to notice:

1. WordPress provides a special tab called Changelog that will be loaded right inside this window by adding a Changelog section to your plugin’s readme.txt. USE IT!! (more readme info)
2. For some people, even clicking the Changelog tab is asking too much of them. Including what’s new since the last release of your plugin right in the description is a big win for everybody involved.

There are many plugins that handle this just fine, but many more that do not. My hope is that other WordPress plugin developers will adopt this practice, to the benefit of their users and the community as a whole.

Related posts:

1. Introducing the WordPress Console
2. Clean WP Dashboard
3. Debian 5.0 (Lenny) Released

I decided to ditch jQuery UI on a recent project when I couldn’t get tabs & accordions to play nice together (also, their site was down when I needed it so I took that as a sign). This was a great opportunity to try jQuery Tools and I have been very impressed thus far.

To use the minimal tabs interface you can simply follow the instructions on their site, but if you want to nest tabs inside one another you’ll need to change things slightly. I’ll demonstrate below:

the Mark Up

<ul class="tabs main">
  <li><a class="main" href="#1">Main Tab 1</a></li>
  <li><a class="main" href="#1">Main Tab 2</a></li>
</ul>
 
<div class="panes main">
  <div>this is main tab 1 content. it includes another set of tabs
 
    <ul class="tabs nested">
      <li><a class="nested" href="#2">Nested Tab 1</a></li>
      <li><a class="nested" href="#2">Nested Tab 2</a></li>
    </ul>
 
    <div class="panes nested">
      <div>this is my nested tab 1 content</div>
      <div>this is my nested tab 2 content</div>
    </div>
 
  </div>
  <div>this is my main tab 2 content</div>
</div>

The key in this sequence is that the seemingly arbitrary href attribute on the tab anchors has different content for the main tabs (#1) than the nested tabs (#2). This is required or your nested tabs will keep returning to the main tabs when you click on a tab link.

the JavaScript

To configure the nested tabs, you can define the JavaScript as simply as this:

$(document).ready(function() {
  $("ul.main.tabs").tabs("div.main.panes > div", {tabs: 'a.main'});
 
  $("ul.nested.tabs").tabs("div.nested.panes > div", {tabs: 'a.nested'});
});

the tabs() function is called on a jQuery selector that matches the unordered list and it takes as its first argument a selector for where to find the tab’s content panes. It’s second argument is a single option that tells tabs() which elements to use as links for the tabs. The default is ‘a’, but to differentiate the main tabs from the nested tabs, it needs to be passed explicitly with the correct class for the anchor.

the Style

Of course, to make these look cool you’ll need some nice CSS applied to the elements at play. I’ll leave that to you, but you can get a decent start from the demo page for the library.

Enjoy!

Related posts:

1. Great jQuery Reference
2. Rails: Nested Layouts
3. jQuery – Open External Links In New Window/Tab

I love Ruby and Rails, but being a contract developer means I go where the money is and recently that has been in WordPress plugin development. I enjoy developing for WordPress, but I’ve been spoiled by Rails and I often long for an interactive console for WordPress.

As a result, I’ve been developing (and using) a Wordpress plugin built for Wordpress developers. It provides an in-browser console where you can “play” with the code you’re working on.

If a picture is worth 1,000 words, this screencast will be worth at least a bazillion of ‘em:

So there you have it. It is currently version 0.1.0 (very young) and I would love some help to make it even more awesome. The source code is hosted on GitHub, so please fork away and I’d be happy to merge in your changes.

Or, simply go download the plugin and try it.

*NOTE*
In developing this plugin, I leaned on a few other open-source projects for inspiration (and in some cases, code). They are:

• PHP_Shell
• htsh

I thank the authors for opening their source.

Related posts:

1. On WordPress Plugin Release Notes
2. Clean WP Dashboard
3. Rails + Screen = Awesome

1) Download and Install Paros

Grab the download from the Paros site. Your install process will differ depending on your O/S, but they’ve provided some install instructions here. Everybody will need the Java Runtime Environment 1.4 or above.

2) Configure Paros

Once installed, launch Paros and find the configuration options (on OS X they are under Tools -> Options). Paros is configured by default to listen on localhost only, but we are going to route our iPhone’s traffic through Paros, so we need to set it to listen on the IP address of the interface connected to the same LAN as the iPhone.

My LAN’s network is 1.1.1.0/16, so I’ll configure the Local Proxy address accordingly:

That should be the only setting that we need to fuss with. Paros is all set and listening on port 8080, let’s configure the iPhone to route its traffic through our proxy!

3) Configure iPhone

On the iPhone, open the “Settings” app and navigate to the Wi-Fi page. Once there, edit the settings for the wireless network you are currently connected to (this needs to be the same network where your proxy is running). To do this, click the little blue arrow on the right side of the screen.

Now, scroll all the way to the bottom of the settings page and change the “HTTP Proxy” setting to manual. Enter the IP address and port number of your Paros Proxy.

All set! Now all web traffic to and from the iPhone is routed through Paros. Let’s go see what we can see.

4) Using Paros

The main section of Paros is the “Request/Response/Trap.” As the iPhone talks through Paros to Internet sites, it will display the iPhone’s request and the server’s response. The “trap” functionality allows you to stop either the request or the response and view/modify it before sending it along to the recipient. Trapping is very cool, and why Paros is used for security auditing, but for our purposes we just want to see what is going on, so I won’t explain it any further.

For now, let’s see what happens when we fire up my iPhone’s “App Store” app:

In the bottom section of the screen is the history viewer. There we can see that my iPhone made 4 requests to different servers ( 3 GETs and 1 POST):

Highlighting the first GET in the history list shows its details. The iPhone’s HTTP request header looked like this:

One noteworthy tidbit is that the iPhone is sending a custom header (X-Apple-Connection-Type) which tells the server that it is connected to WiFi. Next, let’s take a look at the server’s response:

Notice that in the response we see both the headers that the server returned AND the response data itself, in this case an xml plist file.

Sniffing traffic like this can help you understand how different iPhone apps work behind the scenes or it can help debug interaction for an app that you’re writing. Hope this helps you get started!

Related posts:

1. Configure Network Time Protocol (NTP) in Debian
2. Dreamy: Now With 100% API Coverage
3. Ruby to the Rescue

Thankfully, MacPorts has a readline variant that can be easily installed:

sudo port install php5 +readline

If you execute the command above, apache2 will come along for the ride because it’s a default variant for the PHP5 port. If you don’t want apache2 (OS X ships with apache2 anyways), modify the command to look like this:

sudo port install php5 -apache2 +readline

Not sure if your PHP install has readline support? Execute this one-liner to find out:

<? echo function_exists('readline') ? "yes\n" : "no\n"; ?>

Related posts:

1. Debian Quickie: MailUtils

With this task, you can quickly upgrade all your Debian machines to Ruby 1.9.1 without having to go through the process each time. Just:

cap ruby:install_19

Related posts:

1. Debian 5.0 (Lenny) Released

Thankfully, a couple of technologies have come along and made my deployment process a whole lot easier.

1. Passenger

This was the big one. The Phusion guys’ “Hello World” app (as they called it) has really had a positive impact on the Rails community, and me personally. Suddenly my Rails (and Rack) web apps are first class citizens to Apache (and Nginx), which means I can just point a virtual host at the public directory and go. I had almost forgotten how good it feels to just drop some files in a directory and have Apache serve them.

2. Git

Ok, so maybe Subversion allows a similar workflow, but for some reason Git is one of those tools that is so much fun to use that it makes me think of different ways I can use it.

My Flow

How I deploy these days (when I’m not deploying to Heroku) is dead simple. I host my private Git repos using Gitosis, but the same would work with GitHub or any Git server.

Initial Setup

1. Clone the repository on production server.
2. Create database.yml and any other production-specific configs
3. Configure an Apache virtual host pointing to “public” folder of the repository

Deploys

1. locally:

   git push origin master

2. remotely:

   git pull origin master && touch tmp/restart.txt

I know what you’re thinking, “Wow, that is dead simple”. It’s even easier by using Capistrano to execute the remote commands. Here is an example Capistrano task from one of my Rails apps:

task :deploy, :roles  => :production do
  system "git push origin master"
  cmd = [ "cd #{root_dir}", "git pull", "touch tmp/restart.txt" ]
  run cmd.join(" && ")
end

This task can be extended to automatically install required gems, update Git submodules, migrate the database, and so on.

Other Benefits

Besides the simplicity and ease of deployment in this process, I have also enjoyed the ability to make edits in production and pull them back in to my development environment. And because my production environment has a complete history of code changes, it is trivial to revert commits that cause major problems.

This work flow is by no means a panacea. How do you handle deployment?

Related posts:

1. git clone & pull without changing directories
2. Rename A Gitosis Repository
3. Date Range Goodies in Rails

I recently needed to rename one of my repositories and couldn’t find any info on how to do it, so here is a walk-thru. I will demonstrate the steps of renaming a repository called “tk” to “show-time“.

1. Rename project in gitosis.conf and push changes

Before:

[group main]
writable = tk

After:

[group main]
writable = show-time

git push origin master

2. Connect to gitosis server and rename correct folder

cd /home/git/repositories
mv tk show-time

3. Change the remote reference in all repository clones

cd /src/show-time
git remote rm origin
git remote add origin git@example-git-server.com:show-time.git

Done and done.

Related posts:

1. Dead Simple Rails Deployment

1) Microwavesque Deployment

When Heroku claims that you can deploy your Ruby app instantly, they’re pretty much not exaggerating. Seriously, you should try it. It’s so fast I had to ignore my spell-checker and describe it as microwavesque. Remember when microwaves first hit the scene and people couldn’t believe how fast they could “deploy” a meal? Yah me either, but the microwave changed the game big time.

If you haven’t tried deploying a Rails app to Heroku, just go do it. Here are the steps from start to finish:

rails myapp
 cd myapp
 git init
 git add .
 git commit -m "my new app"
 heroku create myapp
 git push heroku master

If that looks like too much work for you, have Remi walk you through it in this nice screencast.

2) Drag To Scale

Scaling is a problem we all want to have, but few of us do. The rest of us spend way too much time thinking about it. With Heroku’s architecture, you don’t have to think about scaling. You just do it. If you’re fortunate enough to have your app featured on TechCrunch, Slashdot, Digg, HN, Reddit, etc, etc, you simply log in to the Heroku admin panel and “crank your dynos” (love that term) to handle the load. How do you do that? By dragging a little bar vertically. How’s that for a learning curve?

Note: This isn’t the only way to ensure your app scales. You should still optimize your code for performance, but Heroku takes care of all the server configuration (compression, caching, memory allocation, etc) and you just ask for more power when you need it.

3) Rack Support

Heroku isn’t just a Rails platform, it’s a Ruby platform. They support any Rack-enabled Ruby app. Check out how many Ruby web frameworks have Rack adapters:

• Camping
• Coset
• Halcyon
• Mack
• Maveric
• Merb
• Racktools::SimpleApplication
• Ramaze
• Ruby on Rails
• Rum
• Sinatra
• Sin
• Vintage
• Waves
• Wee

That’s a long frickin’ list! Developers can pick the right tool for their need (or write their own Rack-enabled app) and not have to worry about deployment gotchas.

For example, I wanted a way to quickly resolve the public IP address of any machine I’m using (including servers) so I wrote and deployed this trivial Sinatra app in less than 5 minutes.

# public_ip.rb
require 'rubygems'
require 'sinatra'
 
get '/' do
  raw = @request.env["REMOTE_ADDR"]
  raw.match(/^(\d+\.\d+\.\d+\.\d+),?/)
  @ip = $1
  haml '=@ip'
end

# config.ru
require 'public_ip.rb'
run Sinatra::Application

The rackup file (config.ru) tells Heroku to use Sinatra to run my application. Rails would have been overkill for this, don’t you think? (Heck, Sinatra may be overkill too. You could probably write a raw Rack application in even fewer LOC, post in the comments if you have a better solution).

UPDATE: Blake Mizerany provided a few shorter examples here.

So

What Heroku offers Ruby web developers is instant deployment, fast & easy scaling, and vast tool selection. Now we can concentrate on building our applications and forget the tedious deployment and server administration tasks that used to strangle our productivity. We can deploy fast, scale quickly, and adjust to circumstance as needs arise. The game is changing, and Heroku (and others like them) are changing it.

**disclaimer**
I am only affiliated with Heroku as a customer, and receive no recompense from the ridiculous amount of props I’m throwing their way. They do have a few drawbacks, one that is a show stopper for many apps, which I will detail in a future post.

Related posts:

1. Dead Simple Rails Deployment
2. git clone & pull without changing directories
3. New Gem: Rack-noIE6