Couple things happened today (Friday, of all days):

1. My old blog hosting company sent a "we are shutting down" notice. Out of curiosity I clicked through and quickly found myself reading 5-year old posts. One of them was ranting about code maintenance.
2. A friend tweeted a link to a blog post by Rohan Singh: Isn't All Coding About Being Too Clever? where he's also talking about maintainable code (with a different perspective).

This got me thinking...

In majority of software engineering literature, "maintainability" of code is hailed as sacred. It's easy to relate to the sentiment: no code gets written once and then forgotten. When you ship code, you give it birth, but the actual life of that code is only just starting. You want to make sure your code spends its life well -- goes to college, marries the right person, and makes the "parents" proud when other people have to deal with it (that's the maintenance part).

Except, much like with kids, your plans for your code almost never work out as initially foreseen. If you are smart enough you accept them just the way they turn out to be (at least - code, if not kids) , without trying to be a control freak. And that's where this obsession with "maintenance" can become a problem.

read more

APC 3.1.9 has a nasty bug, causing a frustrating error: "PHP Fatal error: Unknown: apc_fcntl_unlock failed: in Unknown on line 0" to appear when installed with PECL on Mac OS-X (and reportedly other Linux platforms).

There's a very easy fix. When you install APC through PECL it asks for a number of settings, do NOT go with the default value for "spin locks" even though it warns the feature to be experimental. Experimental or not it's a dependency for the rest of APC so: shame on them and go "wild", say 'yes':

Enable spin locks (EXPERIMENTAL) [no] : yes

That's it. At least seemingly. Who knows what else is broken, but, hey, it's PHP! :)

No, seriously...

Elastic Search is a fantastic, clustered search server built on top of Apache Lucene search engine. It's very easy to install and configure.

However, on some servers, if you follow instructions (which is basically: download, unpack, run: bin/elasticsearch) you may get a weird permission error:

$ ./elasticsearch exec: 179: : Permission denied

even though there are no apparent permission problems and even if you run the script with sudo (which you should not have to).

The solution is extremely simple: if this happens, the real issue is that you do not have JDK 6. I know, that's not what the error complains about, but that's typically the root problem. Install JDK6 (e.g. with: "sudo apt-get install openjdk-6-jdk" on Debian) and the problem will go away.

It's not always easy, in PHP, to figure-out which PHP ini files are actually parsed and loaded. CLI may use diff set than web, and if you are using NginX with FPM, there may be yet another set.

Following extremely simple piece of code can greatly help in clearing-up the confusion:

print_r( php_ini_loaded_file() ); print_r("Scanned: "); print_r( php_ini_scanned_files() ); exit();

I like Espresso from MacRabbit for server-side scripting a lot. The latest version (2.0) has merged a wonderful code editor with the best-of-the-class CSS editor, giving one awesome, unified experience. And, of course, you can edit your files directly over an SSH connection (the latter, alas, is not as straightforward as it is in Panic's Coda, but, well, we love both of them for different reasons).

Nothing in this life is perfect, however. One glaring shortcoming of Espresso is: no UI for assigning a syntax highlighter to custom file extensions. Espresso recognizes most common file extensions, but if you do something slightly different, e.g.: use .tpl files in Drupal (which are PHP files) or use Handlebars templates in Javascript (which are basically HTML), you won't get default syntax highlighting because Espresso does not know what type of files these are.

Let's see how we can teach Espresso custom file types. I will do this for .handlebars files, which are template files I use for my Javascript coding.

1. Right-click on Espresso.app in Finder and select: "show package contents".
2. Go to folder: Contents > SharedSupport > Sugars
3. Right-clic on "XML-and-HTML.sugar" and select: "show package contents".
4. Open Languages.xml for editing (with vi, Textmate or whatever your favorite text editor is)
5. Scroll down to detectors section which should read something like:
   <detectors>
     <extension>html</extension>
     <extension>htm</extension>
     ...
   </detectors>
6. Add more extensions to the section, e.g. for handlebars, I added:
   <extension>handlebars</extension>

read more