Switch gears. The reasons for Apple’s rebirth are often recounted as:

• Steve Jobs’s genius
• The iPod
• The iPad
• Jony Ive’s brilliant design
• Apple’s insistence on simplicity

These reasons have all played a part, no doubt, in Apple’s ridiculous ascent, but absent from this list are Ruby on Rails and TextMate, which either run best (Ruby on Rails) or only (TextMate) on Mac OS X. Apple owes more to Rails and TextMate than anyone lets on. Why? Back up a few years, to around 2005. Just as enterprise developers everywhere began to tire of XML and WSDLs and EJBs and SOAP incompatibilities and JSP syntax and all the other stuff that Java Enterprise Edition uses to yank data from a database and show it on a web page, Rails poked its head out of 37signals and started a cult. People called it magic and mind-reading and crowed about its convention over configuration. Oh, it was so easy to create web apps with, and then oh, it was so easy to write them in TextMate! This fledging cult pushed its dogma until developers everywhere dumped Windows and Dell and even Linux and started tucking MacBook Pros into their backpacks. Speakers at developer conferences soon delivered their talks to a sea of shining silver rectangles sporting glowing Apple logos. Developers had moved to Mac OS X.

All these Rails developers on MacBook Pros needed tools, and discovered they could build them. Xcode was a download away, and you could write shiny apps, so why not? Then the iPhone came and the iPhone SDK that changed its name to the iOS SDK when it married the iPad, and the Xcode acolytes stuffed the iOS App Store full of apps. Some people prospered, most got by, but consumers bought iPhones and iPads faster than Apple could produce them because they could always find “an app for that.” After all, people don’t run OSes; they run apps, and Apple has a bunch of ‘em.

Switch gears again. TUAW reports today that hotkey programs have until month’s end to enter the Mac App Store. After that, it seems that Apple will graciously allow grandfathered apps to have their bugs fixed, but can’t accrete any new features (hotkey-related or otherwise). The reports are a little fuzzy, and may pan out to be inaccurate, but they’re alarming. Why? Because developers love keyboards. They love automation. They drift to the mouse as little as they can get away with, express undying love for their keyboards, and never perform manual tasks that they can write a script for. And Apple is telling them they care more about protecting people that don’t know how to protect themselves from random downloads and phishing scams and trojan links. And someday soon they may rip Alfred from us and make us gesture our way to Launchpad and click on apps to launch them and then we’ll really have some gestures for Apple.

Note to Apple: don’t do this. Where developers go, consumers eventually follow. Right now you have the developers. Don’t push us away. And don’t think we wouldn’t dream of going elsewhere. As long as we have bash, vim, and a compiler, we’re pretty mobile. And we hate the mouse–and your mice suck anyway.

Good post by John Gruber that explores the rumor that Apple will break from Google’s map data in iOS 6. He then goes on to say:

What else remains hanging low on the iOS new-features tree, though? I can think of a few:

Clever inter-application communication. Seems crazy that iOS, the direct descendant of NeXT, doesn’t have anything like Services, which were one of NeXT’s most touted features (and rightfully so). It’s also worth noting that Android has a pretty good Services-esque system in place, called “Intents”, and Windows 8 has an even richer concept called “Contracts”.

Third-party Notification Center widgets. Like the Stocks and Weather ones from Apple — information at a glance, without launching an app.

Third-party Siri APIs. Let other apps provide features you can interact with through Siri.

But that’s about it. And even the Siri API idea seems more like a “nice to have” feature idea than a low-hanging “Apple really has to do this sooner or later” idea. Again, I’m not saying Apple’s iOS to-do list is empty; I’m just saying the list of obvious they-gotta-do-it stuff is getting short.

I can think of one more developer API, though, that (unless I’ve missed it) remains glaringly missing: integration into the iOS search screen, aka Spotlight for iOS. Third-party apps should be able to plug into that search screen, offering up their data when users conduct searches. iPhones would be that much more useful if the search screen could be extended to cover third-party apps.

I’m sure Apple is concerned about malfeasance and abuse, but that’s what the app review program is for. The third-party apps that supported search would display in the Spotlight Search settings screen as well, so apps that matched terms too generously or otherwise misbehaved could be switched off from the privilege of responding to searches.

I’d love to see this in iOS 6.

I recently bought a 2010 Camaro SS with leather seats, premium sound system, and a V8 engine that mainlines gasoline. While I normally listen to podcasts and music from my iPhone (plugged in to the car’s USB port), I occasionally listen to the radio. The first time I used the radio’s tuning knob to change the station, I expected the radio display to remain static save for the frequency, which would increase or decrease as I spun the knob. Instead, the display changed to a skeuomorph, mimicking an old car radio band view, with the frequency spectrum displayed along a horizontal axis and a pointer indicating the current frequency, like this:

My first reaction was, “Aw, cool!” but the excitement quickly waned. This skeuomorph tells you two things:

• The breadth of the spectrum
• The relative position of the current frequency to that spectrum

Neither datum is particularly useful — who cares how close I am to the end of the spectrum? — and I can no longer see the time while I’m tuning. The “tuning” view is gratuitous skeuomorphism that quickly becomes annoying. Good thing I’m a Jungle Insider and can just listen to Rome rants from my iPhone.

Switch gears. I’ve been tracking my weight on my iPhone with the Lose It! app, which is great for tracking calories consumed and expended, but not so much for weight (no graph, for example, that I could find). I tired of tracking my caloric consumption, and I log my runs in Daily Mile, so I really wanted an app optimized for tracking weight. Enter Weightbot, by the makers of Tweetbot. I bought it, weighed in, and went to enter my weight. I assumed I would type my weight using the onscreen number keyboard layout, but instead I saw another skeuomorph: a horizontally-rotating dial that mimicked an analog scale, like this:

This time, I didn’t think, “Aw, cool!” Instead, I thought, “This sucks!” Tapping out a number on the keyboard is quick and requires little precision, as the numbers on the keyboard are plenty big. Spinning the dial at the bottom of the screen takes longer and requires more precision. I felt disappointed.

After a couple days of use, though, I changed my tune. At my daily weigh-in, I have to scroll that dial up or down (well, left or right, but left is down and right is up. Stay with me). Scrolling it down reflects weight loss, which is exhilarating. The more weight I lose, the farther I get to scroll down and the more reward I feel. Scrolling it up, however, represents weight gain, and it hurts. Scrolling up motivates me to work harder not to have to scroll up the next day. Brilliant interface.

The message? Use skeuomorphs with care. Misapplied, they annoy. Correctly applied, though, they enhance the user experience. Make sure you spend some time using your interface yourself and don’t overlook the annoyances.

And I must confess: I’m not under 200 pounds. Yet.

Insufficient access privileges to apply this update.

I assumed that the IT group here at work hadn’t given my user permissions on the /Applications/eclipse directory, and I’d never been motivated to investigate. Today, that motivation came. I quickly determined the fallacy of my assumption and, with nowhere else really to turn, I ran to Google. I found this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=344977

It had this explanation:

In case anyone wants to workaround it manually, go to:

eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\SDKProfile.profile

• Edit the most recent profile file
• Find the section in comment #1
• Remove the line:

  <property name='org.eclipse.equinox.p2.type.lock' value='1'/>

• Now start Eclipse and update it

I didn’t have that file, but I rooted around that directory and found a 0-byte file called .lock in this directory:

/Applications/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/epp.package.jee.profile

I don’t know where that file came from, but since it looked suspicious (and I was reasonably confident I could recreate the file with its original contents if it weren’t the culprit), I deleted that file, restarted Eclipse, and now my update works.

No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you’re likely to find. This will be true forever, so the sooner you come to terms with this, the better off you’ll be as a software developer.

(Via Coding Horror)

Jeff Atwood’s take on a post by Brandon Bloom. This is my beef with comments as well–some folks push “well-commented” code, but comments rot disproportionally faster than the code they describe. No one opens bugs on comments. No one writes unit tests for comments.

Help files often lie as well.

I know bupkis about Apache Solr except that it embraces the Flickr spelling approach and it lets you search for things, but an online tutorial and a few Ruby scripts later and I had a working Solr instance on my local machine, complete with the entire NPI database. Spinning up Solr with the NPI database on the target Linux server proved just as easy. When I discussed Solr startup scripts with the architect on the project, however, eerie background music started playing and I knew I was in for trouble. He told me to install the Solr webapp and run it on the app server instead of as a standalone server.

Actually, I had no such foreboding. The request was reasonable and the approach superior, so I found and installed solr.war on the app server. I also configured the two app server variables that I’d read were necessary (solr.solr.home and solr.data.dir). I fired up the app server and tried to access the Solr data and got an error: “missing core name in path.” Hmm. Time to debug. And you know what I did first, don’t you? I Googled “missing core name in path” and got a page of magic answers.

I read through a ton of results, trying all the solutions I found (even those that made no sense), and nothing worked. I became more and more desperate, especially because it was Friday afternoon and I was scheduled to go on vacation all the next week. I eventually became convinced that my app server didn’t see the solr.solr.home variable I’d configured, so I began spraying variable declarations into my app server, anywhere I could find a place to define a variable, like a dog marking trees. I stopped and started the server as if I were driving in Chicago’s rush hour. Each restart brought hopeful anticipation and glum dejection. I was ready to juke out the architect, write an init script for a standalone Solr instance (which worked fine!), and blame the sysadmins if it were ever detected.

Before acquiescing, however, I decided to look at the log files, which showed me that the app server knew all about my solr.solr.home variable. I was chasing the wrong squirrels. I continued reading the log file, though, and found this:

[#|2012-03-16T21:09:18.721+0000|SEVERE|glassfish3.0.1|org.apache.solr.core.CoreContainer|_ThreadID=27;_ThreadName=Thread-1;|java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or '/opt/solr/./conf/', cwd=/opt/liferay-portal-6.0.6/glassfish-3.0.1/domains/domain1/config

Aha! A real error message! I checked, and solrconfig.xml was indeed not in /opt/solr/./conf — it was in /opt/solr/npi/solr/./conf. I changed my solr.solr.home to /opt/solr/npi/solr, restarted, and my search was on!

At this point, I should be claiming victory. After all, I weaned myself from debug-by-Google-search and returned to old fashioned debugging by looking through log files and figuring out exactly what’s going on. Alas, however, I wasn’t the one who thought to look at the log files. One of the Google results I read suggested I do that.

I’m not in the market for another calendar app for my iPhone–I have the built-in Calendar synced to my Google Calendar, but that goes largely unused because my most used calendar is in Outlook/Exchange/Good. I also have the Cozi app to coordinate calendars among my wife and five children. I wish it were all integrated. Why would I need another calendar?

The quality of the writeup merited that I at least go to the Faraday site, though, so I pulled it up . . . and I saw something pretty cool. It looks like this:

He’s anticipated that someone might check the site, have desires to follow up on the app, but not have time at the moment to do so. It’s like Instapaper for this one site! Pretty clever.

Following instructions from Linux geeks feels like trying to read Charles Dickens while having a stroke

(Via Hacker News)

Perhaps a bit hyperbolic, but great line!

When Bill Joycreated the vi text editor he used the ADM-3A terminal, which had the arrows on hjkl keys, so naturally he reused the same keys. And that’s the whole story!

(Via Hacker News)

Even cooler is where the ESC key was positioned. I wish my MacBook Pro had a bigger ESC key (and no, Ctrl+[ is NOT easier, at least for me)