1. Hanukkah: 53,200,000 hits.
2. Chanukah: 8,860,000 hits.
3. Hannukah: 1,890,000 hits.
4. Hanuka: 1,440,000 hits.
5. Hanukah: 1,170,000 hits.
6. Chanuka: 989,000 hits.
7. Chanukkah: 670,000 hits.
8. Hanukka: 522,000 hits.
9. Channukah: 332,000 hits.
10. Chanukka: 323,000 hits.
11. Xanuka: 198,000 hits.
12. Hannuka: 134,000 hits.
13. Hannukkah: 120,000 hits.
14. Channuka: 46,600 hits.
15. Hannukka: 23,500 hits.
16. Channukkah: 18,200 hits.
17. Channukka: 13,400 hits.
18. Janukah: 12,800 hits.
19. Janukkah: 9,330 hits.
20. Chanuqa: 3,730 hits.

Hanukkah (חֲנֻכָּה) started at sundown on Saturday, December 8th, 2012. This year’s data was collected on the last day, December 16th, since early years have skewed data in the past (and it was a busy week).

My original 2005 post: 16 Ways to Spell Hanukkah.
Updated annually: 2011, 2010, 2009, 2008, 2007, 2006

Google Trends: Top five spellings since 2005

Notes on data:

I had no luck with either Google’s or Bing’s APIs this year and eventually I just decided to paste the numbers from searches. Data was collected using a Chrome Incognito session to avoid search engine personalization. I thought I might average Bing & Google’s numbers (see 2012 data sheet), but ended up using only Google’s data since their numbers were more consistent.

Updated datasource: How to Spell Hanukkah Spreadsheet

One of my goals with PHP is to simplify and streamline my workflow as much as possible. Ideally this helps prevent wasting enormous amounts of my time on stupid crap like autoloaders, library dependencies and re-inventing the wheel.

I’m using a few libraries on IOP’s site, but as much work as these have saved, I ended up with an ugly mishmash of autoloading and require code.

Enter the Composer project.

Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you.

Together with Packagist, which is sort of a nascent RubyGems or PyPI equivalent, using libraries in PHP just got a whole lot cleaner. Composer even generates a complete autoloader, meaning a bunch of annoying code can be replaced with a simple composer.json file and this:

require 'vendor/autoload.php';

Except when they don’t. Because, sometimes, they won’t.

There’s always a catch, isn’t there?

The problem I ran into was the dated default PHP configuration on our shared cPanel host. Trying to run curl -s http://getcomposer.org/installer | php threw this back at me:

#!/usr/bin/env php
Some settings on your machine make Composer unable to work properly.
Make sure that you fix the issues listed below and run this script again:

The phar extension is missing.
Install it or recompile php without --disable-phar

The allow_url_fopen setting is incorrect.
Add the following to the end of your `php.ini`:
    allow_url_fopen = On

The ionCube Loader extension is incompatible with Phar files.
Remove this line (path may be different) from your `php.ini`:
    zend_extension = /usr/lib/php5/20090626+lfs/ioncube_loader_lin_5.3.so

* sigh * These are not settings most shared hosts grant users access to–and if you ask they’ll probably just try to upsell you a VPS. Thankfully though, many cPanel installations now allow users to select different versions of PHP (A2 does). And thankfully again, these alternate versions are often compiled with different flags.

That’s great for web pages, but Composer’s installer uses the command line. To use an alternate version of PHP in a shell, we need to know where the alternate PHP binaries are. An easy way is simply to switch the PHP Version via cPanel, then load a page containing phpinfo();. The actual PHP binary path isn’t listed, but it’s easy enough to figure out from what’s there. Mine was /opt/php/php-5.4.0/bin/php.

Once you’ve got that, you can fiddle with your $PATH (it’s searched from left to right) or just alias the alternate PHP binary:

alias php='/opt/php/php-5.4.0/bin/php'

I aliased php in my .bashrc file (reasons previously discussed) and composer installed flawlessly.

So a few months ago I mentioned wanting to get away from WordPress and PHP. It’s not going very well.

WordPress keeps sucking me back in. A favor here, a quick job there. Next thing I know, I swear I can’t remember how to iterate an array in Ruby or Python.

While sitting down to work on a WordPress project still fills me with dread, I did recently discover a few things which slightly alleviate my misery.

My favorite, as described here by David Winter, is the ability to move the wp-content directory out of the standard WordPress hierarchy. Aside from the database, wp-content holds basically everything which makes a site unique; themes, plugins, uploads, etc. With those out of the way, all of the core WordPress application code can be removed from the site’s git repo and stored as a submodule (pulling from the WordPress GitHub mirror), making version control a lot cleaner and easier and giving me one less thing to think about.

This directory layout should really be the default. The WordPress folder ought be a sacrosanct library, only changing when the application is upgraded. The ability to move wp-content was added back in version 2.6 released in July of 2008. I wish I’d learned about this sooner.

I’m also doing something inspired by Mark Jaquith’s WordPress local dev tips which also allows me to also keep my wp-config.php file versioned and outside of the wordpress directory.

Because it’s a really bad idea to keep password files in version control, I created a wp-config-db-sample.php file containing placeholders for the database login information:

That file gets copied to wp-config-db.php, populated with the appropriate settings (and added to .gitignore), then included by changing the top of wp-config.php like this:

Adobe recently announced their new Creative Cloud software subscription service. While regular paid updates have essentially already made Creative Suite subscription software, I wanted to know if there was any cost benefit in switching our conventional CS Master Collection licenses over to Adobe’s new Cloud.

After projecting some numbers, I was disappointed by what I found.

(source spreadsheet)

Should you switch?

Starting from scratch? Yes.

Creative Cloud is clearly a smart financial move for those who don’t own any Adobe software. Buying Creative Cloud vs. a full price Creative Suite Master Collection license will save money for the foreseeable future.

Upgrading existing licenses? Erm, maybe?

For existing users, the value of Creative Cloud gets murky. It looks like Adobe set their price based on a straight transition of existing Creative Suite users to Creative Cloud. When compared to the standard Master Collection upgrade path for existing licenses on a 12-month product cycle, Adobe’s revenues are precisely maintained–with a slight tip to their favor. I believe this is shortsighted and fails to recognize the potential of growing revenues by increasing licenses.

Adobe’s Introductory offer for current CS customers ($29.99/month, for one year) ends on August 31, and taking advantage of this offer makes Creative Cloud much more compelling. With standard pricing ($49.99/month), Creative Cloud subscription costs would equal Creative Suite upgrade costs after 11 months, though the advantage sawtooths back the following month. Taking advantage of promotional pricing pushes cost-parity back to almost 4 years.

Teams and temporary workers? Probably not.

Team-ready pricing ($69.99/month) seems the most broken. Maybe there’s a cost/complexity crossover with bigger groups, but for a small office I can’t imagine any collaboration or turnover features would justify the significant additional costs.

The month-to-month price of $74.99 is unfortunate too. Paying for eight months of Creative Cloud is the same price as a year at standard prices (four months costs the same as a year at the promo rate). A small army of fine artists support themselves by freelancing as typesetters, retouchers and production artists for only part of the year. They need software, but for many studios with a distinct busy season, those licenses sit idle for half the year–effectively doubling the cost of necessary software.

Conclusion

One would think the truck-loads of money Apple is making on volume might make a compelling argument for Adobe to dramatically undercut the price of Creative Suite and push their customers towards Creative Cloud. In 2007, Steve Jobs was asked if he feared cannibalization of Mac OS by iOS. He replied that if there was to be cannibalization of Apple products, it should be by Apple. This is exactly how Adobe needs to start thinking.

Reducing the price of Creative Cloud by a third or even half would not diminish the perceived value of Adobe’s apps, but it would help dissipate the perception that Adobe’s products are impossibly expensive. This poisonous idea carries on long, long after people leave school and is partly why Adobe always tops lists of most-pirated software.

Going back to Apple as an example of doing things right, Creative Cloud should not have five price tiers (promotional, standard, team, student & teacher and monthly). The CS6 product grid is bad enough. Educational users should not be rewarded for forswearing commercial work, nor should they be financially punished when their skills are practically applied in the marketplace. The Student & Teacher price should be the only price. If Creative Cloud was simply $30/month–with no caveats–I’d recommend it without hesitation.

For Adobe’s existing customers, Creative Cloud is a slightly better deal, but disappointingly, not by much. When compared to the cost of upgrading existing software, Creative Cloud is more of an installment plan than a subscription. It costs the same, but the payments are spaced out over time.

We’ll be switching over, but with full knowledge that the monthly fees are not really saving us anything in the long run.

Other thoughts

• Creative Cloud appears to be platform agnostic. Being able to install on Macs and PCs would be a big plus.

• Immediate updates sounds good, but it could also present a huge headache if a critical bug or backwards incompatibility slips through. If an update breaks an application, which has happened in the past, will Adobe offer rollbacks to previous versions?

• Promised “community collaboration” is a potential security disaster. Having worked on projects with sensitive information, the potential for a slip-up is terrifying. Agencies should be very concerned about pre-release materials being “shared” before they’re public.

• A lot of studios purchase every-other Creative Suite upgrade. The chart clearly shows this is cost-neutral. While there may be some benefit because known systems increase productivity and reduce training costs, Adobe’s upgrade pricing model has eliminated any cost saving from skipping versions.

  Adobe’s Creative Suite release history:

  • CS1: September, 2003 (19 months)
  • CS2: April, 2005 (25 months)
  • CS3: March, 2007 (18 months)
  • CS4: September, 2008 (19 months)
  • CS5: April, 2010 (12 months)
  • CS5.5: April, 2011 (13 months)
  • CS6: May, 2012

  In 2011, Adobe announced they had switched to an annual release cycle.

“‘O Butterflies, lend me your grace and swiftness!’ I repeated, rubbing the broken wings over my pounding heart. If this would give me grace and speed I should catch many butterflies, I knew. But instead of keeping the secret I told my friends, as my grandfather knew I would. And how many, many we boys caught after that to rub over our hearts. We chased butterflies to give us endurance in running, always rubbing our breasts with their wings, asking the butterflies to give us a portion of their power. We worked very hard at this. because running is necessary both in hunting and in war. I was never the swiftest among my friends, but not many could run farther than I.”

“Is running a greater accomplishment than swimming?”

“Yes, but swimming is more fun. In all seasons of the year most men were in the rivers before sunrise. Boys had plenty of teachers here. Sometimes they were hard on us, too. They would often send us into the water to swim among cakes of floating ice, and the ice taught us to take care of our bodies. Cold toughens a man.”
— Plenty-coups (1848–1932), last hereditary chief of the Crow Indians

From the book, Plenty-coups: Chief of the Crows (also Google Books, via Tuck)

I’m not going to WWDC this year. I made the decision a few months ago, but since tickets went on sale this morning, I thought I’d post my reasoning. Maybe even before it sells out. (update: WWDC sold out in two hours)

I’ve been trying to get an iOS app together for a couple years. While not having finished one feels like a personal failing, I accept that some circumstances are simply beyond my control. So I should restate that; I haven’t finished an app, yet.

My past few WWDCs have gone something like this:

Tickets go on sale and I realize I haven’t worked on iOS stuff for months. I buy a ticket, knowing they’ll sell out, then frantically try to clear my schedule and restart work on my apps. I’ve forgotten nearly everything, so I’m sort of starting from scratch. I order updated versions of several iOS books, read articles and watch sessions from previous WWDCs. If it’s a good year, I have a few weeks to cram and actually start developing something. This makes me happy.

Then the conference starts. It’s embarrassing to be there again with nothing to show or really talk about, so I tend to avoid conversations and keep to myself. This makes me miserable.

The years I did get ahead and had an app partly working, I would come home to find existing responsibilities gradually crowded out iOS work. After a month or two, I’d once again forgotten not only what I was working on, but entire chunks of the language and workflow.

WWDC has also been a week I tend to get horrible news. As in, people-are-dying, horrible. But if not that, some work emergency or obligation always seemed to come up, and instead of returning to my hotel room to review questions from the labs or to try out concepts from presentations, I end up fussing with WordPress or PHP and being miserable.

This year my available time has been a disaster and I don’t see that trend easing anytime soon. There’s no way I could realistically clear my schedule to prepare, so I’m skipping it.

I attended every WWDC since 2003, and I’m especially glad I got to see Steve Jobs speak, both in his prime and one last time in 2011.

I will watch the keynote, renew my developer account and learn from the sessions once they’re posted. But I’m not going to pay all that money, feel guilty taking a seat someone else or put myself through all the same old misery. Hopefully next year…

On Saturday I’ll be participating in a one-day Movnat workshop. I’ve been attending the NYC Movnat meetups for about a year, but this is my first official session. I’m ridiculously excited.

Despite exploring the ideas and emulating the practice of Movnat for the past year, I still find it difficult to talk about. But there will apparently be news media covering the session, so I thought I should figure out something to say, quick.

I first learned about Movnat through Erwan Le Corre’s original videos a few years ago. They seemed slightly preposterous at first, but something about them got stuck in the back of my mind and I couldn’t stop thinking about them. When I was a child pretending to be an adult, this was everything I imagined an adult should be able do.

Several of my interests converged here. I’ve been running barefoot and following a paleo-ancestral diet for a couple of years. There’s a philosophical thread that runs through these: People are exceptionally capable, adaptable, amazing creatures. When we choose to be. The idea of recognizing our inherent human capacity and reclaiming those abilities as our common birthright fascinates me. I’ve heard this described as both rehabilitation and prehabilitation.

The fitness aspect seems almost secondary. One of Erwan’s original inspirations for Movnat, Georges Hébert, said “Être fort pour être utile” (“Being strong to be useful”). This works both ways, strength comes from use as much as use requires strength.

It’s also just plain fun. I sometimes joke that the weekend Meetups are my “grown-up playgroup”. My daughters think I’m crazy but they love that I’m always up for climbing trees and rocks with them.

Watching Movnat’s influence spread over the past few years has been great. I’m looking forward to seeing how the formal principles of Movnat fit together with my own evolving philosophy.

I’ll be sure to post a followup after the workshop.