You know what? Let’s make that the long version as well. I think I’ve articulated my thoughts on the matter about as well as they’re going to be articulated. Anything else would be superfluous.
With that in mind, I link to this review of a Jurassic-sized “mobile” phone because it includes one of the best lines I’ve heard in a very, very long time:
The Galaxy Note’s tagline asks if the device is a tablet or a smartphone, but like a girl in Spanx, it’s so much more.
Ah, yes.
(Source: thetechblock.com)

Wherein you:
You might be wishing you could use Alfred to control Pulsar so you didn’t have to activate the app every time you wanted to pause a great song by Starland Vocal Band. I was too. Eventually, I decided to do something about it.
Pulsar’s script API isn’t very extensive, but it does cover pause/play as well as a few other useful bits. The Pulsar extension supports:
xm playxm pausexm show (display the channel, artist, track and album now being played)xm next (changes the channel to the next Favorite channel)xm prev (changes the channel to the previous Favorite channel)I chose the xm keyword because it’s short and reasonably descriptive since I’m playing a Sirius_XM_ channel, but that’s easy to change once the extension is installed. If you have Growl installed, the xm show command will display a Growl notification. If not, it will degrade to an ugly, but functional alert dialog.

Hint: Any command other than play, pause, next and prev will behave as show. Give it a try.
Download the Alfred Pulsar Extension
Terrell Owens' workout attracts zero NFL teams -
All dressed up and nobody showed.
If you’re a good guy, you just have to be better than a few of the other guys and someone can take a chance. If you’re not, you have to be better than a few other guys and better than your own personality.
Maybe teams have finally decided that TO can no longer outrun his own baggage.
Anonymous asked: This Auditable Behavior sounds great! But the links are dead.. is the code still available? /post/867819035/an-auditable-behavior-for-cakephp
Sorry about the dead links. You can find the code on Github.
Solve Gmail's Disappearing Cursor in Safari -
This has been annoying me for the longest time.
Gmail uses Flash to provide “advanced attachment features,” the capability to attach multiple files at once and to display progress bars while attachments upload. As far as I know, that’s the only place Gmail relies on Flash, and if you switch to Basic Attachment Features in Gmail’s Settings, that eliminates Gmail’s use of Flash and works around the bug.
I’ve looked for a solution before, but it was never given a high priority. I guess I just assumed that Google and/or Apple would care enough about getting it fixed to, you know, fix it. Apparently not.
The fix is somewhat “hacky”, but it works and I haven’t felt any sense of lost functionality in the short time since turning off the whiz-bang attachment functionality.
Photoblog - Bridge to somewhere:
Remarkable feats of engineering like the Hoover Dam and now the bridge over the dam are endlessly fascinating to me. I was there just under a year ago and it’s hard to believe that the bridge is now complete.
Licensing State of the Union -
Nick Paulson (in a guest post to Mike Rundle’s blog, Flyosity):
Most pirates had no intention of purchasing your application in the first place. Donʼt hurt your real customers. If your application is good enough, people will buy it. The best way to prevent piracy?
Make great apps.
Nick gets it. It’s only natural to want to protect your work, but nothing—not our cars, our homes or our software—is impregnable. Someone who wants it badly enough will find a way. So how much time and effort do we, as developers, spend in an attempt to lock it down? How much should we impact our customers’ user experience in that pursuit? Ever the pragmatist, I’d argue not much to both questions.
Most of the article is centered around a description of the licensing options available and their vulnerabilities. If you don’t care about those, skip to the last paragraph. That’s where it all coalesces into something in which I think we all share an interest.
Nick’s philosophy—one that I share, obviously—is simple, concise and it places the focus squarely on the people who cared enough to become customers. That’s exactly where it should be.
I’ve learned to loathe CSS. As a developer with a lot of OOP experience, I love the intent, but I can’t endorse the implementation. Then, about a year ago, I found Compass and my grey skies became blue again or, at the very least, they became a whole lot less grey.
The point of this post isn’t to dive deep into either my hostility towards CSS, my newlywed love affair with Compass and SASS or even to spend a lot of time discussing the latter two. Rather, the point is to document how I configure a Ruby tool to play nice in a PHP code base, specifically a CakePHP code base. Since we’re making introductions, though, it’s worth touching on the highlights of the ecosystem. If CSS frustrates you on a regular basis, I’ll leave it to you to read on.
Sass makes CSS fun again. Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin.
As the acronym hints, SASS is essentially just an (awesome) alternate syntax that takes advantage of a “compilation” process to translate the alternate syntax into standard CSS. Baked into that compilation process, though, is a lot of power. Variables and mixins (think functions) right a lot of CSS wrongs.
Compass is a stylesheet authoring framework that makes your stylesheets and markup easier to build and maintain.
I can’t improve on something as clear and concise as that so I won’t try. Compass includes an executable that provides some handy command line tools and offers a lot of plugins that port many of the popular CSS frameworks (e.g. Blueprint, 960gs, Susy, etc.) to SASS syntax.
As a quick example, rather than littering markup with non-semantic span-[number] classes in a site built on the Blueprint CSS framework, you can drop those classes and reference a mixin that creates the same effect. For a sidebar div that might get a class of span-4, drop the class and update your main definition instead:
#sidebar
+column( 4 )
Cleaner markup, improved semantics. Win-win.
Since Compass and SASS have deep roots in the Ruby community, they may be easily overlooked by other developers. They shouldn’t be. While it’s true that Compass is written in Ruby and old-school SASS looks a bit like Ruby (the old syntax is still supported—I even prefer it—but the most recent syntax is more CSS-like), it compiles down to plain, old, ordinary CSS without all of the headaches of writing (or maintaining) it as CSS.
Because it compiles down to CSS, it can be used in any project written in any language that I can think of. I’ve used it in small, standalone PHP projects as well as framework-based projects using Symfony and CakePHP.
Since I prefer CakePHP, I’ll use that as the model, but the instructions should be easily extrapolated for any other language, structure or framework.
Before getting into Compass itself, here’s how the relevant directories of my CakePHP project directory are laid out:
<project root>
+ app
+ webroot
+ css
+ img
+ js
So let’s get started with Compass. If Compass isn’t already installed, just install it via its gem: gem install compass. That’s it. We’re going to deviate slightly from the instructions on the Compass homepage, so for the project creation & configuration, I’m going to ask you not to RTFM until we’re through here.
First, in your Terminal:
$ cd <project_root>
$ mkdir sass
$ cd sass
$ touch config.rb
This creates the top level directory for this project’s Compass framework files and an empty config file that will soon tell Compass how to do what it does. Here’s what my config.rb file contains for a CakePHP project:
http_path = "/"
sass_dir = 'src'
css_dir = '../app/webroot/css'
images_dir = '../app/webroot/img'
javascripts_dir = '../app/webroot/js'
http_stylesheets_path = 'css'
http_javascripts_path = 'js'
http_images_path = 'images'
environment = :development
output_style = :compressed
The config file tells Compass where everything belongs once the project is initialized. In short, I’m telling Compass to install the supporting SASS files in a child directory named src and also how to access CakePHP’s asset directories from the SASS root (e.g. <project_root>/sass).
The *_path variables tell Compass how to reference these assets via HTTP. An image, for example, would be referenced as /img/my_image.png.
The last two variables tell Compass something about the operating environment and how the compiled stylesheet should look. A “compressed” stylesheet contains the entire declaration for each selector on a single line. I’d never create CSS that way because I find it miserable to maintain, but since I won’t be maintaining any CSS, this is a nice space saver. Complete documentation of the config file is available on the Compass site.
All that’s left is to initialize the Compass project. You should already be in your sass/ directory, so:
$ compass install blueprint/semantic
Now you’re ready to go. You can compile your stylesheets manually whenever you’re ready to test in a browser, but it’s much less hassle to let Compass do all of that work for you. It will “watch” your project and compile each time you save a .sass (or .scss) file in that directory.
$ cd ..
$ compass watch sass
Start editing—and saving—your SASS files and you’ll see the terminal come alive with activity. Your plain old CSS files are being compiled and stored right where CakePHP expects them to be. Your days of writing and maintaining CSS are over.
Exchange "remote wipe" is a terrible, terrible bug -
Those sons of bitches.
The day after I left AOL, I woke up to find my Blackberry restored to factory defaults. No warning, no exit interview heads up, no courtesy notification, no dinner, soft music, candlelight or lubrication. Lesson learned.
I’m a pretty accessible guy. I don’t stop answering the phone or email at 5pm. I don’t mind being so available because my lackadaisical approach to work-life balance has never been abused. After that experience, though, I decided that if I ever work for a company that deploys this Draconian policy to mobile devices accessing corporate email then the company has two choices:
What’s that they say about having your cake and eating it too?
In case this is your gateway into this series, the context is this: I often explain my (relatively recent) preference for Macs with the statement that they occupy something of a sweet spot for me. Because the operating system is Unix-based, development environments are a snap and stability is baked right in. I also get a powerful command line environment. Because it’s Apple, I get some swell eye candy (hardware and software) and all of the “lifestyle” components (e.g. iTunes, video, upgrades, etc.) are also easy. Speaking very generally and with the understanding that nothing is perfect, Windows misses on the former, Linux on the latter.
This is the fourth post in a miniseries that defines my own personal OS X starter kit. In the first post, I covered configuration—those things (read: settings) I change before I add anything at all. Next was applications, the third party additions to the /Applications folder that have to be installed and configured before my system begins to feel like home. In the last post, I covered third party preference panes which I’ll describe as mini applications that reside in the System Preferences dashboard rather than as standalone bundles in the /Applications folder.
Closing out the series is the plugins. These aren’t quite like anything else. Once I install them, I’m forever forgetting where they went—the don’t live in the /Applications directory or in any other location that you’re likely to spend any time, but they’re there when I need them, where I need them.
Visor is a plugin for OS X’s Terminal (/Applications/Utilities/Terminal.app) application that makes a Terminal window available via hotkey. It’s a little difficult to describe since it doesn’t launch or quit Terminal, but it essentially toggles the visibility of an open Terminal window. I spend a lot of time in the Terminal, but I’m not always in it. I like being able to put it away when I’m done, but call it back out when I need it the next time. Visor is perfect for that and throws in a bit of configurable eye candy to boot (i.e. I configure mine so that the window will slide down from beneath the menubar). The plugin does break one Terminal feature—window groups, but it’s not one that I’ve ever used.
If you spend any amount of time in the command line interface, I highly recommend this plugin.
It’s hard to believe that this isn’t included with the native OS X color picker, but that oversight is filled by this plugin. Hex Color Picker puts an extra tab in the system-wide color panel that displays the hexidecimal color code for any color. As a developer who spends a considerable amount of time on web-centric work, this is an invaluable plugin.
Thus endeth my starter kit. Four categories, four episodes. What’s in your kit?