2006 September
Sunday, September 24th, 2006
at 2:41pm
As John Herren pointed out in the comments to yesterday's post, my suggestion for PHP syntax coloring wasn't working for several versions of Trac.
After a little digging, it turned out that my CSS rules were based on the non-standard SilverCity highlighting output, rather than the newer and more common native PHP highlighting.
While reviewing the output from the native PHP highlighter, I noticed that Trac's manipulation of the output from highlight_string() isn't quite right. The way things are now, as of Trac 0.10rc1, an intended multi-line docblock only has the first "/**" highlighted as a comment ... the rest of the docblock is highlighted as default PHP (the code-lang class).
I've been clamoring for good PHP syntax coloring output in Trac for a long time. Rather than pass the buck and put this on the Trac team, I've released a little PHP-based shell script called php_mimeview.
With php_mimeview installed, simply update the [mimeviewer] config section of trac.ini in your Trac project to point php_path to the full path location of php_mimeview. With that script, plus these rules in your site_css.cs template file:
[source language=":css"]
.code-keyword { color: #007700; }
.code-lang { color: #0000BB; }
.code-comment { color: #FF8000; }
.code-string { color: #DD0000; }
[/source]
... you'll get what you're probably used to seeing in syntax-highlighted PHP code.
Thanks to John Herren for the nudge to investigate this further.
Saturday, September 23rd, 2006
at 4:26pm
Two quick notes for Trac users out there:
- I banged out all 33 lines of my first Trac plugin last night. The FlexJsPlugin allows Trac users to add JavaScript to the <head> block of their Trac-powered sites without needing to hack ClearSilver templates.
- For PHP source files to display in the Trac Browser with default PHP syntax highlighting colors, use this:
/* trac php syntax highlighting */
.code-block {
line-height: 1em;
font-family: Courier, monotype;
font-size: 12px;
}
.h_question { color: #0000BB; } /* highlight.default */
.hphp_commentline { color: #FF8000; } /* highlight.comment */
.hphp_operator { color: #007700; } /* highlight.keyword */
.hphp_word { color: #007700; } /* highlight.keyword */
.hphp_default {}
.hphp_variable { color: #0000BB; } /* highlight.default */
.hphp_hstring { color: #DD0000; } /* highlight.string */
.hphp_simplestring { color: #DD0000; } /* highlight.string */
.h_tagunknown {}
.h_default {}
Drop the CSS in your project's site_css.cs file and you'll feel a little less like a stranger in a strange land. And while I haven't started playing too much with what some easily customizable JavaScript can bring to a Trac project, I'm looking forward to experimenting. Trac is great, but for all its coolness, it's lacking a bit in the area of today's JavaScript coolness.
Monday, September 18th, 2006
at 10:49am
So I passed the Zend PHP 5 Certification Exam this morning. 
While not necessarily blog-worthy in and of itself, I wanted to write about the experience for the benefit of those developers who are on the fence about taking the exam, and for employers who may or may not know about the exam or consider it valuable.
First off, as Davey blogged last week, the PHP 5 exam is much, much better than the PHP 4 exam. I felt that the questions were more challenging, and that they were more representative of real knowledge and understanding of PHP 5.
If you're not sure if the exam is worth taking, I believe that it is (for whatever that's worth). While I've gotten a bit of a rep as a Zend basher over the past year, I firmly support the certification program (especially the PHP 5 version).
As a developer, in the year or so since I've taken it, I've gotten a number of opportunities thrown my way that I don't think I'd have seen if I hadn't taken the exam.
As an employer (I'm the guy with the final say-so on the developers we hire or don't hire at Mashery), I can say without hesitation that I am more likely to call in a Zend Certified Engineer for an interview than Average Joe PHP Guy without certification. Granted, I haven't been fortunate enough to GET a resume from someone I didn't already know who was a ZCE ... but it's the first thing I look for when I get resumes in.
We often get candidates who have a mixture of programming experience, without a real PHP focus. When asked about that, most of them say "Oh, I could learn PHP in a day." I believe that most of those hotshots would fail the PHP 5 Certification Exam.
Of course they would. After all, when someone says something like that, they mean "I can figure out enough to get by" in a day, not "I can become an expert in a day." The thing is, I don't want people who can "get by." We're building some complex OOP PHP 5 stuff here, and "getting by" doesn't cut it here.
In fact, I'm considering making passing the ZCE the final step of our hiring process for PHP people. It's much cheaper for us to pay for someone's testing fee and use the result as a determining factor in hiring than it is for us to hire someone based on a hunch on someone's skill/knowledge gleaned from interviews. I recommend that others who are serious about finding competent PHP developers do the same.
Wednesday, September 6th, 2006
at 5:49pm
If you're like me, either you or someone you work with forgets the details of octal notation for *nix file systems from time to time. I know I space out on it occasionally.
While playing around with "protaculous" a little bit on my BART commutes, I whipped up a little octal notation interactive cheatsheet. It seemed like it might be useful to others, so I put it up at http://per.ms.
Got a code that you can't remember the meaning of? Just click the numbers below the checkbox grid on http://per.ms, and the correct corresponding checkboxes will be checked for you as a reminder.
Hope you find it useful on those days when your memory is a little hazy.
