Git PHP lint pre-commit hook

This post describes a small tweak to make to php lint checking via a git pre-commit hook.

Using git hooks to check syntax errors – Tim Akinbo’s Blog


JSON supplanting XML

Lessons: Use Cases matter, and programmers (the users in this case) will choose tools that are both simple, in that they are not complicated/over-engineered, and easy to use, requiring little setup and code to accomplish a task.  For parsing data with PHP, constrast using something like SimpleXML or DOMDocument (which is light-years better than where we were in parsing XML just 5 years ago), to just doing json_encode() or json_decode().

In particular, JSON shines as a programming language-independent representation of typical programming language data structures.  This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this.

James Clark’s Random Thoughts: XML vs the Web


Drupal: Invoke blocks and views from code

While Panels is great for controlling the layout of drupal pages, there are times when you can’t use the module to theme a page.  For uncached content, it does introduce some performance overhead into the drupal request change.  It can also be tedious to migrate changes from one environment to the other if you don’t export pages and variants to version control.

When you’re working in the stock theme layer, the following functions can come in handy.

Render a Block

   * Convenience function to easily call a block from a module
   * @param string module name
   * @param string delta
   * @return array block
  public function invoke_block($module, $delta) {
    if ('block' == $module) {
      global $theme_key;

      // the block_block view is pretty useless
      $block = db_fetch_object(db_query("SELECT b.*, bl.title, bl.*
                   FROM {boxes} b
                   INNER JOIN {blocks} bl ON (bl.module='block'
                       AND AND bl.theme='%s')
                   WHERE = %d", $theme_key, $delta));
     $data['subject'] = $block->title;
     $data['content'] = check_markup($block->body, $block->format, FALSE);

      if ('n/a' !== $data['content']) {
        return ($object) $data;
    } else {
      if (module_exists($module)) {
        $block =  module_invoke($module, 'block', 'view', $delta);
        $block['delta'] = $delta;
        $block['module'] = $module;
        return (object) $block;
      else {
        trigger_error("Module $module is not enabled.", E_USER_ERROR);

To show block with delta 1 defined by module foo:

$block = invoke_block('foo', 1);
$output = theme('block', $block);

Render a View

   * Convenience function to easily get the output of a view
   * A note about the display id, this is NOT the identifier
   * that you can set in the Views UI. To see the display id, look
   * at the theme information for the display.  For blocks it will
   * be something like block_1 or block_X where X is a number.
   * If the display_id doesn't match then Views automatically
   * uses the default display which can make themeing a pain.
   * modeled on view_embed_view().
   * @param string view name
   * @param string display name (see theme info for the display name)
   * @param array additional options
   * @return string
  static public function invoke_view($name, $display_id = 'default') {
    $args = func_get_args();
    array_shift($args); // remove $name

    if (count($args)) {
      array_shift($args); // remove $display_id

    $view = views_get_view($name);
    if (!$view) {
      trigger_error('Unknown view invoked: ' . $name, E_USER_WARNING);

    // validate the $display_id is valid
    // generate an error to prevent wasted time debugging.
    $defined = array_keys($view->display);

    if (!in_array($display_id, $defined)) {
      trigger_error('In view "' . $name . '" unknown display invoked "'
                  . $display_id . '"', E_USER_WARNING);

      // lets not render, chances are we don't want
      // the default display if we invoke a specific view

    // if a view is empty, dont return anything
    $r = $view->preview($display_id, $args);
    if (false !== strpos($r, '
‘)) { return $r; } else { return null; } }

To render display page_1 from view foo. You can even pass arguments to the view.

$output = invoke_view('foo', 'display1');
$output2 = invoke_view('foo', 'display1', 2010, 111); // with args!

Feature module example to bundle WYSIWYG Configuration

This is a concise example showing how you can use the Features module to bundle configurations in Drupal into a module.  It's great to see the Drupal community moving towards using code to capture, reuse, and deploy configuration settings.  It's been the biggest pain point in working with Drupal for me.

One of the things Drupal core does not do well at all is provide an easy way to switch on a WYSIWYG editor. There is no editor out of the box and setting it up requires some custom configuration of several Drupal core settings, installing and configuring several contributed modules, and also installing one or more external libraries, like the TinyMCE library.

WYSIWYG as a Feature 


NetBeans 6.9 is out.

There's a new release of the the one full-blown IDE that I've managed to stick with.  If Eclipse doesn't fit your style, give Netbeans a spin – I like its inline code completion, the source-code beautifier, and the integration with SVN and Mercurial.  I particularly find the source control usability much better than Eclipse.

After bug fixing period NetBeans 6.9 final build is available. You can download it as usual from NetBeans site. What is new, you can read in this document and also you can watch some new features in NetBeans 6.9 Overview video.

NetBeans for PHP : weblog


TekX – Introduction to Testing with Selenium

Arne Blankerts – part of, premium PHP consulting and training.

  • Selenium is a java based portable testing framework.
    • Seleniumm RC runs any browser supported by the framework, firefox, opera, etc
      • Can operate/execute ANY browser available on the host machine
      • On Linux, have to tweak how process is shutdown.
    • Selenium IDE – extension for Firefox to Create and Edit Tests.  Can record clicks instead of writign code.
  • Where to use it?
    • Acceptance/Integration Tests – test behaviors in the browser.
    • Compatibility Tests – test that new functions work across browsers/versions
    • Monitoring – you can record behavior and trigger events.
      • Can test that, for example, your registration form actually works not just makes the page available.
    • Test case recording for Bugreports.
      • Provide more detailed, reproduceable bug reports.
    • Development – automate filling out forms during development.
  • Selenium does not replace unit testing or other forms of testing.
  • Useful RC options
    • -port alternate listening port
    • -log save console output to logfile
    • -debug more trace output
    • -timeout seconds to wait before giving up on a test
    • -html run a single standalone test
  • Selenium Tests
    • Written in browser independent JavaScript based DSL
    • Same test can run on any OS with Java runtime and many browsers
      • Firefox 2+, Internet Explorer 6+, Opera 8+, Webkit from Safari 2+
    • Can write tests using PHP as well.
    • Can test for presence of elements – seems to use XPath to select elements, but you can use other notations.
    • Pretty powerful selectors for finding elements.

Talk derailed a bigt by technical difficulties, but provided a good introduction into selenium.


Day 2 Keynote – 10 Developer Trends

Today's keynote is about trends that developers across platforms and languages will face.  None of these should be big surprise if you keep up to date and "read the internet".  Presented by the VP of Technology at

  • The Rise of Agile and Lean
    • Majority of developers report using Agile, but it means different things to different people – i.e. using Scrum, User Stories, etc.
    • Agile is a hot topic at DZone, so there's an audience looking for help and information on using it.
    • Noticed a rise in consultants and software claiming to help implement Agile.
    • People with small teams/enterpreneurs are the ones practicing agile.  Hasn't broken into "the Enterprise".
    • But, does Agile lead to better software?  Do more frequent releases mean we hit schedules, are more secure,  and solve user problems?
      • More frequent releases DO cut down on having to explain stuff to clients, because you can show them stuff.
  • Switch to Standards based Browsers
    • Chrome has had tremendous growth, particularly with technical audience.
    • Windows developers are switching quickly to IE8.
    • Overall developer population is still largely on Microsoft.  But those developers don't go to conferences?
  • Everyone needs to know Ajax/Javascript
    • Back end developers need to understand the user interface too.
    • Should learn at least on framework such as jQuery or Prototype
    • Understand how ajax works, and its data transports like JSON, XML.
  • Focus on Security
    • Vulnerabilities get more and more media coverage.
    • Are there more security holes or are attackers getting smarter.
      • XSS, SQL Injection, weak passwords, etc…
    • Can't assume your framework takes care of all security.
    • Give equal time to security audits of your code.  Think about security when you're developing.
  • Rich User Interfaces
    • Users expect much more dynamic interfaces, even if they prefer style over substance.
    • Lots of options for RIA – Flash, Silverlight, Flex, Ajax, HTML5
    • Must RIAs run outside the browser?
      • it can run on the desktop – what opportunities does this create?
    • Benefits of RIA vs. normal website?
  • Mobile and other UI Form Factors
    • Can't presume that everyone has a mouse.  Link targets will have to get larger, more touch friendly.
    • Different platforms have touch interfaces that behave differently.
    • Supporting multiple platforms will be a point of pain.
    • But users expect application to just work.
  • Death of Relational Databases
    • Can mean different things to different people.
    • Data store that is focused on horizontal scaling, massive data, and lookups based on primary keys.
    • Large Web 2.0 sites are moving to NoSQL – Digg, Twitter, Reddit
    • But relational databases are not going away any time soon.
      • Most developers are fie on RDMS.  Few need to Scale at this level or deal with massive data storage.
      • Not all queries convert easily.
    • NoSQL data stores very common on the cloud  – App Engine, Amazon SimpleDB
  • Distributed Version Control
    • Many choices emerged – Git, Mercurial, Baazar
    • Git seems to have most momentum
    • Adoption driven by Open Source
    • Does anyone still use CVS?
    • Subversion still big, driven by tool support.  Its entrenched in the enterprise because the IDE's have good support built in.
    • Distributed VCS encourages outside participation.
  • Cloud Computing
    • What does the term really mean?
      • non-root access on someone else's hosting platform (ie my blog is on
      • or virtual servers with root access that can be easily replicated.
    • Lot of "Cloud" platforms – App Engine, Azure, VMForce, hosting companies, etc…
    • Hand-in-hand with NoSQL
    • Most apps don't need that kind of scalability
      • Complex systems require more management and automation.
    • Is it worth rewriting our application to run in the cloud.
  • Rise of Interpreted Languages
    • Ruby, Python, Clojure, Scala, Groovy
    • New languages to solve new problems
      • Better support for the cloud
      • Take advantage of multiple cores and parallel processing.
      • Often early takers of NoSQL
    • Is the JVM empowering language developers?

Code and Release Management notes

I'm attending tekx, and while I'm taking notes in all the sessions with Evernote, I'll try to clean up and summarize my notes here as well.  One of the session's I attended yesterday was Eli White's session on Code and Release management.  It focused more on the techniques, policies, and practices to think about about and implement rather than the nitty-gritty howto details of each version control system.  I found that very helpful because oftentimes its difficult to learn how effectively use version control especially as part of a team's workflow.  Also, its clear now that distributed version control systems have a lot to offer, primarily, and this was my AHA! moment, because they do not impose any workflow on you.  With a central subversion repository, all the developers on a project are forced to work in a certain way.  With multiple repos, you could still setup a central repository for everyone to push changes to.  However, everyone can also have their own repository which I think encourages them to commit and track local changes more frequently.  With SVN, especially as you work on larger teams, its tempting to commit less frequently especially if you don't use branches at all.

  • We're talking about managing daily workflow – editing, testing, and releasing
  • Have to use version control, there's no way to get by without it.
    • It's a core component, with same core concepts across different systems – checkout/commit/merge/concurrency
    • Distributed is great when stuff will eventually be thrown away, ie for individual experimentation
  • Policies – come up with general rules for your team.
    • You need to find rules that fit how you work and how you release code balanced against how you support older code, if at all.
  • Use of Tags/Branches/Trunk
    • Trunk – contains core codebase
    • Branches – used to segment into logical areas of responsibility (release/feature/programmer)
    • Tags – mark a specific state of code, a release
  • 3 main styles of branching
    • Stage Branches
      • new work is done against trunk
      • branches for staging/production/etc
      • when ready for testing, merge into staging
      • when ready for live, merge into production
      • fixes made into each branch eventually has to be made back into trunk, otherwise your changes may get deleted next time your merge from trunk to a branch
      • difficult to do parallel work (multiple people working on multiple features that may not be released together)
    • Feature Branches
      • New work is done in its own branch.  You never commit to trunk.
      • Easier to do concurrent development.
      • CON – branching might be difficult depending on your VCS.  and you have to do a lot of merging.
    • Release Branches
      • all new work done on trunk
      • create a branch for each version  when ready for release
      • easer maintenance and allows some parallel work
      • little merging
      • assumes that everyone is working towards a common goal / release
    • Pushing code live
      • Absolutely want to have a script – especially if you have a lot of servers.  Use that exact same script to push changes to testing and staging.
      • Have a way to roll it back – scripted and automated.  If something fails, better to roll back and debug in another environment.
      • Live SVN Checkout
        • it works and its simple, so its a very common practice
        • encourages conflicts, especially if some has been editing on live/production
        • hard to automate and difficult to rollback
      •  SVN Export & Rsync
        • use dcn export to make a copy of the code, use rsync to transfer changed files to live
        • simple and easy to scale & automate
        • export gets a copy without .svn directories
        •  rsync is not atomic so some hits might get partiallly updated codebase which is likely to break.

Habari Project impressions

I have to admit that i jumped over to using Habari for my blog mainly based on how well designed and obejct oriented the underlying API seemed from the documentation. Coming from looking at Drupal code all day, which is painfully NOT Object Oriented, yes with capitals, the code is more readable and, so far, less mysterious.

Don’t believe me? Go read the instructions for Creating a Content Type. Like Drupal, it depends on function name conventions for some hooks, but beyond that everything else is nicely encapsulated in a proper class.

But I haven’t developed my own plugins yet, although I have an idea for one. My main impressions are from installing it and using it.

The installation itself is very straightforward, at least on par with WordPress. If, like me, you find yourself installing it multiple times, one can Predefine configuration settings and not have to manually enter them each time.

The admin interface is elegant and useful, certainly less cluttered than Drupal’s admin pages. A simple pull down menu in the top left corner of the page lets you add posts, configure plugins, and access other admin functions.

The plugin system is in a state of flux, due to a change in how plugins are defined/discovered by the system between versions 0.6 and 0.7. This means a lot of plugins are available for the former, but maybe not the latter. It’s also difficult to track down a solid list of plugins, so I’ve been using with svn:externals to install and update plugins.


The new "Bytes in the Margin"

Its time to relaunch my blog as Bytes in the Margin. I like the new name, which is not an anagram of my own name. I was inspired by all the notebooks I have from school and work meetings, which are decorated with pen and pencil doodles in the margin.

While the title is new, the content won’t really change, and I’ve left the Feedburner feed at RecordAsIAm still enabled, so hopefully I don’t lose any subscribers.

This also gives me a chance to check out a new blogging/content management platform – Habari Project, which, from looking at the code, looks like a very nicely designed PHP blogging framework. Given that my major point of reference is Drupal, that may not be saying much. If you’re particularly geek, learn Why Habari? or look at how they’ve implemented Plugins