hobodave.com

bundle-phu - minify, bundle, and compress your js/css in Zend Framework17 Jan 2010

I’ve used a few different CSS/JS bundlers, but none have ever fulfilled all that I needed. Specifically, I wanted one that could do all of the following:

• Bundle automatically with little configuration
• Optionally minify
• Optionally compress
• Allow the bundled files to be served directly by the webserver, instead of by PHP.
• Easily allow files to be served compressed, but without recompressing on every request
• Automatically detect modification the the source files, and update bundles as needed.

Thus, I created bundle-phu. Bundle-phu is a set of Zend Framework view helpers that do all of the above.

Bundle-phu is inspired by, bundle-fu a Ruby on Rails equivalent.

Before

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript" src="/js/foo.js"></script>
<script type="text/javascript" src="/js/bar.js"></script>
<script type="text/javascript" src="/js/baz.js"></script>
<link media="screen" type="text/css" href="/css/jquery.css" />
<link media="screen" type="text/css" href="/css/foo.css" />
<link media="screen" type="text/css" href="/css/bar.css" />
<link media="screen" type="text/css" href="/css/baz.css" />

After

<script type="text/javascript" src="bundle_3f8ca8371a8203fcdd8a82.css?1234567890"></script>
<link type="text/css" src="bundle_3f8ca8371a8203fcdd8a82.css?1234567890"></script>

Highlights

• Changes to your source js/css is detected, and bundles regenerated automatically
• Minification can be done using either an external program (YUI compressor), or via callback in PHP.
• Compression is achieved using gzencode()

Installation

1. Place the BundlePhu directory somewhere in your include_path:

    your_project/
    |-- application
    |-- library
    |   `-- BundlePhu
    |-- public

2. Add the BundlePhu view helpers to your view’s helper path, and configure the helpers:

<?php
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initView()
    {
        $view = new Zend_View();
        $view->addHelperPath(
            PATH_PROJECT . '/library/BundlePhu/View/Helper',
            'BundlePhu_View_Helper'
        );

        $view->getHelper('BundleScript')
            ->setCacheDir(PATH_PROJECT . '/data/cache/js')
            ->setDocRoot(PATH_PROJECT . '/public')
            ->setUseMinify(true)
            ->setMinifyCommand('java -jar yuicompressor -o :filename')
            ->setUseGzip(true)
            ->setGzipLevel(9)
            ->setUrlPrefix('/javascripts');

        $view->getHelper('BundleLink')
            ->setCacheDir(PATH_PROJECT . '/data/cache/css')
            ->setDocRoot(PATH_PROJECT . '/public')
            ->setUrlPrefix('/stylesheets');

        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
        $viewRenderer->setView($view);
        return $view;
    }
}

1. Ensure your CacheDir is writable by the user your web server runs as
2. Using either an Alias (apache) or location/alias (nginx) map the UrlPrefix to CacheDir. You can also do this using a symlink from your /public directory. e.g. /public/javascripts -> /../data/cache/js

Usage

As both these helpers extend from the existing HeadScript and HeadLink helpers in Zend Framework, you can use them just as you do those.

<? $this->bundleScript()->offsetSetFile(00, $this->baseUrl('/js/jquery.js')) ?>
<? $this->bundleScript()->appendFile($this->baseUrl('/js/foo.js')) ?>

Simple Nagios probes in ruby10 Jan 2010

I needed to write a custom nagios probe a few weeks ago. I googled for existing solutions in Ruby, but surprisingly found none. A nagios probe can really be written in any language, it just has to return a single line of output and an exit code of 0 (OK), 1 (WARNING), 2 (CRITICAL), or 3 (UNKNOWN). I chose Ruby because of the syntactical simplicity, as well as the ease of bundling it as a gem using Gemcutter.

You can view the source here.

Installation

# gem install nagios-probe

Usage

Simply create a subclass of Nagios::Probe and define the following methods:

• check_crit
• check_warn
• check_ok (optional - it is defined in the base class to always return true)
• crit_message
• warn_message
• ok_message

Example

class MyProbe < Nagios::Probe
  def check_crit
    true
  end

  def check_warn
    false
  end

  def crit_message
    "Things are bad"
  end

  def warn_message
    "Things aren't going well"
  end

  def ok_message
    "Nothing to see here"
  end
end

To use your probe you must wrap it in a begin/rescue block to catch any exceptions and accurately report the status to Nagios.

begin
  options = {} # constructor accepts a single optional param that is assigned to @opts
  probe = MyProbe.new(options)
  probe.run
rescue Exception => e
  puts "Unknown: " + e
  exit Nagios::UNKNOWN
end

puts probe.message
exit probe.retval

Moving to Jekyll & Disqus08 Jan 2010

I moved my blog to GitHub Pages today. I’ve decided to stop tinkering with new blog software every few months. I’ve gone from LiveJournal to Typo to Mephisto to WordPress to Chyrp; it was fun while it lasted.

While I enjoy the tinkering, it’s a time-sink, and I have never really enjoyed the post creation methods offered by any of them. With GitHub Pages I can just type my post in Markdown or Textile and ‘git push’ it to my repository. The conversion is done using Jekyll and then served statically. Losing native comment functionality is a side effect of having a static site, but I discovered a service called Disqus in the process of doing this, which seems to be just what I need.

It should be noted that I’m a terrible designer, and I’ve shamelessly used templates for my other blogs. However, with this I’m starting from scratch using a CSS framework called Blueprint. I’ve never used it before, but so far it seems extremely simple, and it doesn’t look like ass out of the box.

We’ll see, but I’m hoping this will serve as an impetus to posting more often. Perhaps I should take notes when I have a good idea for a post? I tend to just forget.