This teetering arrangement of browser tabs would then fall apart when I clicked a link to a ticket in an email notification (opening yet another tab in the wrong browser window). Once I accidentally destroyed a live database table because I got my windows mixed up. Whoops.

With iron resolve and kung-fu like discipline you might be able to keep only one window or tab open at a time, closing out all others as soon as you’re focus shifts. Unfortunately I’m fresh out of iron resolve and my kung-fu is weak.

Fluid

Fluid is a app that lets you turn websites into an app for your mac. Fluid creates a web browser that loads only one page. For example, if you use Google Docs you could launch Fluid, give it the URL for docs, give it a name (like ‘Docs’), and optionally give it an icon.

Fluid will create “Docs.app” and save it in your Applications folder. You can double click the app icon and go right to Google Docs. The app works just like any Mac app. It shows up in Launchpad, Spotlight search, in your dock, and when you Command-tab to switch applications.

At work I have a fluid app set up for all of our work apps. This way I always know what window is what (they have icons!) and it’s fast and easy to launch or shut down one of these apps without messing with my browser. If I crash my web browser while dinking around with JavaScript, my web apps stay open.

The basic version of Fluid is free, but for $4.99 you can upgrade to get features like full screen mode (in Lion) and other neato features. It’s cheap. Support your indie software developer.

Browser Fairy

Having all my web apps in their own application is great, but if I got an email notification to a bug or wiki update, the links would still open in my default browser. Now I’ve got the bug tracker open in two places. Boo.

Browser Fairy is an app available in the Mac App store which sort of sits between links and any browser you have installed.

You set up Browser Fairy by making it your default browser. Then you tell Browser Fairy about all the browsers on your system. When you click on any URL anywhere, Browser Fairy intercepts it, and then re-routes it to a browser your choose.

For example, if your company’s timesheet tool only works in Firefox, you give Browser Fairy the base url (maybe http://timesheet.jobbity.job) and anytime you you click a link to the timesheet app, it will automatically open in Firefox, while all of your other links open in Safari.

Since Fluid apps are just single-serving web browsers, Browser Fairy treats them like Firefox, Chrome, or Safari. So I can configure wiki links to go to my wiki app, bug links to the bug tracker, code reviews to the code review app, etc. All other links go to Safari.

It takes a little bit of work to configure, but you only have to do it once – and once it’s done it’s like magic. Any time I get a bug notification email, the link opens my bug tracking app, not my main web browser. If the bug tracking app isn’t open…Browser Fairy will open it so I don’t have to keep 10 things open all the time.

Browser Fairy is $4.99 in the App Store – with Fluid apps they’re a super-duper productivity enhancing duo.

Why was Wall Street surprised by Apple’s performance?.

I ran into trouble when I pushed my work up to my Dreamhost account. The application was failing silently. Running silex.phar on the command line resulted in meaningless errors.

After a fair bit of Duck-Duck-Go-ing (Duck-Duck-Goosing? Quacking?) I found squat. After dumping out a PHP info page I realized that Dreamhost is using Suhosin (which is a good thing). This was the culprit.

The Silex documentation provides configuration examples showing how to configure PHP and Suhosin to work with the Silex framework. Fortunately, Dreamhost lets you override the system default PHP.ini with your own.

In order to this work you should have PHP 5.3.x FastCGI enabled for your domain. Leave “Extra web security” on so you feel snuggly and safe in your bed at night.

Make sure your login account (your FTP user) has shell access enabled – this configuration cannot be done without shell access.

Follow the instructions on the Dreamhost support wiki for replacing the system php.ini. If you don’t know what any of those instructions mean, this is not for you. Contact support and ask nicely for them to do it for you.

Once you have a shiny new ini file (the file will be named “phpini”) look for the following line:

;;; VALUES BELOW WILL OVERRIDE ANY SET ABOVE! 

Above this line are system defaults. Leave them be. Below this line you will add your customizations.

Add the following recommended configurations from the Silex documentation:

detect_unicode = Off
phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar 

And then add the following to ensure that the PHAR extension is loaded:

extension=phar.so 

Then follow the Dreamhost instructions for forcing PHP to reload the configuration – or go make some coffee and come back in 15 minutes or so. Dreamhost will eventually reload the configs automatically.

Silex should now run fine, both in the browser and on the command line. Of course your mileage may vary.

I understand his pain, but his recipe is too dry. 3 parts gin to 1 part vermouth, people. At a 5 to 1 ratio, you may as well just drink gin on the rocks.

Also, don’t keep your vermouth at room temperature – unless you consume it quickly. Vermouth is wine. It spoils.

He is right that it’s hard to get a well made martini in many places. That’s because most bartenders are taught how to make Vodka martinis, which is basically just chilled and shaken vodka (fine if you like that sort of thing bro). They simply substitute gin when asked. This results in a cocktail that tastes cold, antiseptic, and like a waste of money.

Here in Portland, though, you can find many bartenders who know what they’re doing.

Good morning.

I found this on my balcony this morning. This is probably a good day to write poems.

Oh, there’s also a rather neat reference to a poem by Milton, so do remember to laugh.

To produce the needed base64 encoded images, I’ve been relying on a tiny little command line script to encode the image and spit out the results. While this works, it’s not particularly convenient and it’s not something I can easily share with other developers and the graphic designers on my team.

So over the weekend I built bGrounder.

bGrounder lets you upload images and convert them into CSS rules and HTML image tags with images embedded directly with data URIs. If you’re using a modern browser that isn’t Internet Explorer, you can click and drag images from your desktop right into the uploader. In all browsers you can add many images via the ‘Add images’ button (HTML5 browsers allow you to select multiple images at once).

Process each image individually or do them all at once. The resulting code appears in the text boxes below the uploader. The CSS rules specify the encoded image as a background image, using a class name derived from the file name of the image. The HTML output is a simple IMG tag with width and height set. The IMG tag is probably less useful over all – generally inline images are part of actual content of the page and you probably don’t want to completely ignore older browsers. But maybe you do. Maybe that’s just how you roll. Additionally if you reuse the same IMG tag with embedded image data, you get no benefit from caching…the browser has no way to know that two embedded images are the same (whereas a single CSS sheet is loaded once).

Share and enjoy.

Technical stuffs

bGrounder gave me a chance to play with the Silex PHP “micro-framework”. I found it very easy to get up and running with Silex, surprisingly so. I rather liked the simplicity and minimalism of defining function closures which respond to URL patterns and HTTP methods. Very tidy. My main application file was only 50 lines long, including comments and generous whitespace. (this doesn’t include the Silex library itself, or the image processing classes I wrote, but still. Short.)

This also gave me the chance to work with this jQuery File Upload widget. This set of jQuery plugins enhances an existing file input to allow for multiple uploads in old browser, creates a rich UI with progress bars, and can even support cross domain uploading. It also ships with a number of server-side implementations to help you get started. Perhaps somewhat ironically, this was more complex than the PHP framework. Once I got my head around how it worked though, it was fairly easy to customize the UI and use my own server-side upload handler.

The gist is that Adobe’s magazine app publishing platform (as well as other’s) creates a magazine by wrapping up a big stack of PNG image files in a thin interactivity layer. On the new iPad, these images will be too small to be legible. I hinted at this problem when I reviewed Vanity Fair’s iPad edition. Today each “magazine” is an enormous file (200MB to 400MB) with text that can’t be enlarged, selected, copied, exported, or read aloud by accessibility software. In order for this publishing format to work on high resolution displays, the images will have to be much higher resolution – and therefore much larger in file size. Otherwise the text will be blurry and hard to read. If you increase the size of the images making up each page, you increase the overall file size of each magazine. These things are already too big to store. I never keep more than an issue or two on my iPad. And of course, download times will increase as well.

I already find these magazines hard to read. Even my 37 year old web nerd eyes find the text in these magazines (on the original iPad) to be too blurry. Compared to iBooks, the Kindle App, or just any old web page in Safari, they look terrible (at least for reading). I came to the same conclusion that David did; they should have been using web technologies all along.

Vanity Fair has a decent web site already and they obviously have a CMS supporting it. Why not create a tablet optimized version of the site with the same content as the magazine then make that site an add-on to an existing subscription or create a partial pay-wall? That web content could be wrapped in an app and cached for offline use. Most graphics (borders, boxes, shapes, etc) could be delivered as tiny SVGs, photos could be delivered as hi-res JPGs. The end result would be much smaller than what they deliver now, but far more readable. It’s possible that they might have to sacrifice some fine layout control…but the result would be reasonably future proof content.

Vanity Fair and Conde Naste have already produced and killed one version of a magazine app. The current one is about to be obsoleted, as is all the content they’ve already produced for it. Why keep hitching their wagon to Adobe’s lame last century mentality mule?

• A Retina Display Reckoning for Magazine Publishers
• Via Shawn Blanc

Consumers, in general, have never really liked PCs. They like what they can do with PCs. An iPad does most of the things that people do with a PC and it also looks nice, it’s small, it’s easy to set up, requires almost no maintenance, it’s quiet, doesn’t get hot, it doesn’t weigh much, and it’s priced well under a thousand dollars. Except for cheap, tiny laptops (which also sell poorly) a PC is the opposite of all of those things.

Advertising and marketing with QR codes is absolutely idiotic. QR codes slapped on websites are the worst offenders. I’m already reading a website, on a computer, and you want me to get out my smart phone, fire up a QR Code app, decode your dumb code, and get what? A link to a website? Really? Why not just link to the web site so I can visit the site on the computer I’m already using? Dumb.

I’ve seen advertising with no information other than a QR code. Congratulations! Where you could have had an easy to remember web address or a Facebook page, you now have Robot Barf that no one can read and only the most dedicated neck-beard will take the time to decode. Nice work.

The solution to the problem of “get this text into my smart phone without me typing” is either speech recognition software or OCR (Optical Character Recognition) software. For example there are iPhone Apps which will read signage and translate the text into another language on the fly. QR Codes were created so machines could quickly scan boxes as they wiz by on a conveyer belt. They weren’t meant for people…because people can read.

Some evil genius convinced thousands of marketing weasels that QR Codes were going to be the next big thing, so now they show up where ever there’s a fool who needs to be parted from some money.