• New Rails for PHP Developers Website Feb 18, 2008

    Posted by Mike Naberezny in PHP,Ruby   -   Comments Off


    Rails for PHP Developers is a new website that’s a companion to the new book by the same name. Like the book, it’s aimed towards PHP developers who have an interest in Rails and Ruby. The website features articles that alternate between Ruby and PHP focus, so PHP developers that aren’t interested in Ruby should still find it useful.

  • Supervisor Twiddler 0.2 Feb 17, 2008

    Posted by Mike Naberezny in Python   -   Post a comment

    Supervisor Twiddler is an RPC extension for Supervisor that allows Supervisor’s configuration and state to be manipulated in ways that are not normally possible at runtime.

    Changes in release 0.2:

    Renamed addProcessToGroup() to addProgramToGroup(). The method
    now supports program definitions with numprocs > 1 and will add
    all resulting processes from the program definition. It also
    fixes a bug where the process config was not added to the group
    properly. Requested by Roger Hoover.

    Added new method log() that writes an arbitrary message to the
    main supervisord log. This is useful for recording information
    about your twiddling.

    You can download the new version and read the updated documentation on the Supervisor Twiddler page of Maintainable Software‘s open source project pages.

  • Horde/Yaml 1.0 Released Jan 8, 2008

    Posted by Mike Naberezny in PHP   -   5 Comments

    Horde/Yaml is a PHP 5 library for easily working with YAML data. This is the package’s first stable release.

    Chuck Hagenbuch started the library as an adaptation of Spyc around six months ago. Since then, he and I have been quietly using and improving it. Along the way, we fixed many issues, added support for pecl/syck, and wrote a test suite with PHPUnit.

    There are a couple of other libraries also derived from Spyc, notably the sfYaml class from the Symfony framework. Since these efforts also found and corrected issues, we incorporated as many of these fixes as we could find and added them to the test suite as we went along.

    At Maintainable Software, we frequently use YAML files for configuring our custom applications because our clients tend to like the format more than the alternatives. We’ve been using Horde/Yaml successfully for quite some time so we think it should generally work well for you also.

    There’s a nice tutorial on working with YAML in PHP 5 over on the new Rails for PHP Developers website. It includes everything you need to get started with Horde/Yaml.

  • Supervisor at PyCon 2008 Dec 21, 2007

    Posted by Mike Naberezny in Python   -   Post a comment

    I’ll be presenting at PyCon 2008, together with Chris McDonough.

    Supervisor is a tool for managing UNIX processes. Supervisor starts arbitrary processes at its own startup and allows otherwise unprivileged users to start, stop and restart its subprocesses and view its subprocess’ logs using a command line or web interface. Other programs exist which do this, but what sets Supervisor apart is that it is written in Python and built with extension points that can be leveraged by Python developers. In this talk, we’ll look at Supervisor as a platform, and how Python programs written to run under Supervisor can use its unique capabilities.

    Our talk will cover basic usage but will focus on the more advanced features we’ve added recently, such as adding custom RPC interfaces and event listeners.

    PyCon 2008 will in Chicago on March 13-16th. From the list of talks, it looks like this is going to be a great conference. I am especially looking forward to pounding out some new code during the sprints following the conference on the 17-20th.

  • Rails Hackfest Winner Dec 5, 2007

    Posted by Mike Naberezny in Ruby   -   Post a comment

    I was pleased to learn today that I am a winner in the Rails Hackfest.

    The Hackfest is a contest where your ranking is primarily determined by how many of your patches get accepted into Rails core during the contest month.

  • Supervisor Extensions Released Nov 5, 2007

    Posted by Mike Naberezny in Python   -   Post a comment

    Supervisor is a process management system written in Python.

    One of the major features we added to Supervisor recently is the ability to extend its XML-RPC interface functionality by registering new top-level namespace factories.

    Today, I released two new extension packages for Supervisor:

    • Supervisor Twiddler allows Supervisor’s configuration and state to be manipulated in ways that are not normally possible at runtime.
    • Supervisor Cache provides the ability to cache arbitrary data in the Supervisor instance as key/value pairs.

    Both of these packages add capabilities to Supervisor through this new extensibility. Since they are the first packages available of their kind, they also serve as a template for building your own Supervisor extensions.

    Update: The extensions were featured on Chris McDonough’s blog.

  • Repoze: Retooling Zope Nov 1, 2007

    Posted by Mike Naberezny in Python   -   Post a comment

    During the last couple of weeks, the Maintainable team has been privileged to help out with Repoze, a new open source Python project. Repoze is “plumbing Zope into the WSGI pipeline” but also much more.

    I’m not a Zope developer but I’ve benefited from Zope indirectly in several ways. The most significant for me has been Supervisor, a process management system. It’s not part of Zope itself but it originated from a need to keep production Zope servers running smoothly. I started using it for other kinds of servers, and fast forward a couple of years and now I’m very involved and help develop it.

    Supervisor is interesting to many Zope outsiders. It might have grown out of the needs of running Zope servers, but it’s a tool that many others can benefit from using. I think parts of Zope itself also have similar potential for outsiders.

    Zope has been around for a long time and for many was thought to be the “killer app” for Python. Philip J. Eby wrote about the significance of Zope in Where Zope Leads, Python Follows. I’m interested in Zope not because of the application server as a whole but because it has many technologies like an object database, transactions, and object publishing that I’d like to explore.

    It seems that quite a few technologies that are gaining mindshare now through new developments have been available and stable in Zope for many years. As an outsider, I want to be able to consume bits of Zope technologies for other kinds of projects.

    The problem that Zope has is that its technologies aren’t accessible to outsiders in the same way as Supervisor. To the rest of us, the Zope world is largely a mysterious monolith. Projects like Grok make it easier to get started by bringing Rails-like conventions to Zope development, but many of the core Zope technologies remain largely inaccessible for new purposes without putting in a lot of effort.

    Repoze is changing that in a significant way. Repoze is packaging Zope technologies into components and middleware that can be easily deployed on WSGI servers. This is a win for Zope applications because it means better deployment options like Apache and mod_wsgi. Breaking up the monolith and providing more options will help the longevity of their platform.

    For the rest of us, a more modular world of Zope means that eventually, many of the interesting technologies that Zope has to offer will be closer in reach and more practical through a combination of WSGI middleware and better packaging.

    Repoze already seems to have great momentum and I’ll be watching it with interest. I look forward to exploring what the Zope world has to offer through Repoze.

    Update: This post was featured on Repoze Notes.

  • Zend/PHP Conference 2007 Sep 23, 2007

    Posted by Mike Naberezny in PHP   -   Post a comment

    I will be presenting again this year at the Zend/PHP Conference, together with Sebastian Bergmann and Matthew Weier-O’Phinney.

    PHP development by teams of developers introduces challenges beyond the mere coding of great algorithms. Agreements are needed about tools, specifications, architecture, design patterns, coding standards, testing, documentation, source code control, staging and deployment. This tutorial session aims to introduce developers to a set of best practices that will help them deliver applications fast and move them to deployment with confidence.

    We will present our full-day tutorial session, “PHP Development Best Practices”, on October 8th. I really enjoyed last year’s ZendCon and I look forward to this one.

  • New in Horde: Routes Sep 15, 2007

    Posted by Mike Naberezny in PHP,Python   -   4 Comments

    I’m pleased to announce the first release of Horde/Routes, a new URL mapping system for PHP 5. This package provides classes for mapping URLs into the controllers and actions of an MVC system, inspired by Ruby on Rails.

    There are already quite a few existing libraries that do this sort of thing for PHP. Horde/Routes is a compelling alternative.

    At Maintainable, we examined most of these PHP solutions and found them all inadequate for various reasons, particularly because we wanted RESTful routing, named routes, sophisticated matching, PHP 5 E_STRICT, and extensive test coverage.

    Since we do quite a bit of Ruby and Python programming, we surveyed the options in those languages and decided to do a full port of the Python library, Routes.

    Horde/Routes provides these features and more:

    • Supports route recognition and generation
    • Sophisticated matching conditions like subdomains
    • Named routes and RESTful route generation
    • PEAR-style naming and coding standards
    • PHP 5 E_STRICT compliant, web framework agnostic
    • A comprehensive unit test suite

    Maintainable decided to contribute the code to Horde’s Rampage project because Horde is one of PHP’s oldest and most successful projects. We’re using and contributing to other Horde libraries and we think Rampage is worth your attention.

    The Python version has been around for some time and is very popular with different Python web frameworks. We’re happy to be part of that ecosystem now and our full port has already resulted in patches being committed back to the Python version.

    At Maintainable, we’ve already used Horde_Routes on several applications. While Horde/Routes is relatively new, it is very feature-rich and well-tested.

    Currently, Horde/Routes is a beta release. Over the coming weeks, we’ll be making some minor changes to the API and adding more documentation, and then it will quickly move to stable.

    Update: The project now has its own pages on the Horde website and was featured on Chuck Hagenbuch’s blog.

  • Keep the Flash and Test it, too. Sep 8, 2007

    Posted by Mike Naberezny in Ruby,Testing   -   1 Comment

    The flash in Ruby on Rails is a special hash that is stored in the session. Its contents are available to the next request and cleared out immediately after.

    This makes is very useful one-time events, such as an item being added to a shopping cart:

    flash[:success] = "#{cart.items.size} items added to your cart."

    The flash[:success] will be available for the next request only.

    However, Ajax requests will also clear the flash. This can lead to the sometimes mysterious problem of the flash contents disappearing before their intended request because an intermediate Ajax request caused them to be cleared.

    The solution is to explicitly preserve the flash contents in actions that could unintentionally clear it. This is done using flash.keep:

    flash.keep

    The current contents of the flash will then be preserved for the next request. You can also pass a specific key such as flash.keep(:foo).

    On one application I work on, we make Ajax requests periodically on a timer. Putting flash.keep in these Ajax actions was a simple way to make sure they didn’t unexpectedly gobble the flash contents.

    Of course, once adding flash.keep, we also want to add a functional test for it. You might try doing this:

    def test_something_keeps_flash
  @request.flash[:foo] = 'bar'
  xhr :get, :something
  assert_response :success
  assert_equal 'bar', @response.flash[:foo]
end

    You’d be close but wrong. That would seem like a natural way to do it but unfortunately, the flash can’t be populated that way due to how TestRequest was built. It doesn’t have a flash attribute and the session doesn’t have a FlashHash. However, that won’t stop us from writing our test.

    We could try monkeypatching but I try to avoid clever things like that. This problem is easily remedied with a helper in test_helper.rb:

    def make_flash_hash(with_contents = {})
  returning ActionController::Flash::FlashHash.new do |flash_hash|
    flash_hash.update with_contents
  end
end

    Our test case now can now use the simple make_flash_hash helper to populate the request’s session with flash:

    def test_something_keeps_flash
  @request.session['flash'] = make_flash_hash(:foo => 'bar')
  xhr :get, :something
  assert_response :success
  assert_equal 'bar', @response.flash[:foo]
end

    In addition to using @request.session as shown above, you could also populate the session in the xhr method directly. I like the former for readability.

    Whichever way you choose to do it, writing the functional test will ensure that you’ll continue to preserve the flash when the application changes later.