Older blog entries for wez (starting at number 52)

OSCON 2010 Redux

Another OSCON is done. As usual, it was a great mix of folks and ideas across many different areas of OpenSource technology.

The most valuable track at these conferences (for me, at least) has become the hallway track. This is due in-part to my becoming a big-headed know-it-all; you pick up a lot of knowledge after you been to a good number of these conferences/conventions. But it is really important to me to be able to converse with fellow OpenSourcerors, whether they are working on the tools that I use on a daily basis or are working ...

Syndicated 2010-07-25 16:08:00 from Wez Furlong

Gimli at OSCON

Update: the session is complete; you can find the slides on slideshare.net and the code on bitbucket

I'm speaking at OSCON again with another new topic. This year, I'm spreading the news about Gimli, a Server Process Monitoring and Fault Analysis framework that I built at Message Systems and will be sharing with the world at OSCON.

In a nutshell, Gimli will supervise a process and capture an extensive crash trace (using DWARF 3 debugging information if possible) if the process crashes or wedges, and then restarts the process.

Syndicated 2010-07-25 16:00:00 from Wez Furlong

mtrack: roadmap RFC

I wanted to share some of my thoughts on future development in mtrack, and solicit some feedback. Some of these are driven directly from user requests, and others are things that I've been thinking about on-and-off for a little while.

I really want to hear your thoughts, whether they relate to ideas and feature suggestions, or whether you have some experience or anecdotes on these topics.

Custom Fields

I was hoping to avoid having to enable this as a feature, as I find the implementation approach taken in the original Trac to be sub-optimal, both ...

Syndicated 2010-07-10 04:53:00 from Wez Furlong

HTTP POST from PHP, without cURL

Update May 2010: This is one of my most popular blog entries, so it seems worthwhile to modernize it a little. I've added an example of a generic REST helper that I've been using in a couple of places below the original do_post_request function in this entry. Enjoy!

I don't think we do a very good job of evangelizing some of the nice things that the PHP streams layer does in the PHP manual, or even in general. At least, every time I search for the code snippet that allows you to do an HTTP POST ...

Syndicated 2010-05-23 04:00:00 from Wez Furlong

Gimli at OSCON

I'm speaking at OSCON again with another new topic. This year, I'm spreading the news about Gimli, a Server Process Monitoring and Fault Analysis framework that I built at Message Systems and will be sharing with the world at OSCON.

In a nutshell, Gimli will supervise a process and capture an extensive crash trace (using DWARF 3 debugging information if possible) if the process crashes or wedges, and then restarts the process.

For more details on the OSCON session, check out the session details at OSCON.com.

As ...

Syndicated 2010-05-23 01:01:37 from Wez Furlong

a new domain

I'm letting thebrainroom.com lapse this year after holding it for 11 years. For those that weren't with me back then, The Brain Room was my consulting company, providing graphic and software design services.

When I joined OmniTI, I chose netevil.org to use for my blog in a kind of self-mocking move; I equated my efforts at taking over the world with superior software with the effectiveness of Dr. Evil. A lot of people thought I was styling myself after Dr. Evil, which wasn't quite right, but close enough :-)

Since I've been going ...

Syndicated 2010-05-22 21:01:37 from Wez Furlong

mtrack: now with OpenID and reCaptcha support

Some of the feedback and questions that I've gotten about mtrack were around making it easier to deploy and use in an open or public facing environment.

To that end, I've added support of OpenID authentication and bot detection via reCaptcha.

To enable these features is quite simple; for OpenID, add the following lines to your config.ini file:

[plugins]
MTrackAuth_OpenID =

You should also remove any other Auth plugins that you may have there, as how they interact with OpenID is not currently defined.

continue reading …

Syndicated 2010-02-14 20:16:47 from Evil, as in Dr.

mtrack: a software development tracker + wiki

[Updated to add IRC and Google Groups links]

I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way.  They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).

We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes.  We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.

However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things.  As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.

Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow.  What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis.  It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.

continue reading …

Syndicated 2010-01-28 04:12:36 from Evil, as in Dr.

mtrack: a software development tracker + wiki

I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way.  They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).

We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes.  We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.

However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things.  As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.

Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow.  What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis.  It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.

I chose to implement mtrack in PHP rather than continuing to extend Trac in python.  My primary reason for this is that I've seen web apps written with Perl and Python, and while there are certainly guru developers out there that can build some awesome apps, those languages don't really lend themselves to web development and that limits the scope of potential contributors.  While I can probably persuade some of my colleagues to code python web bits, I'll find it much easier to persuade more of them to code PHP web bits.  I'm sure this property extends outside of our organization.

continue reading …

Syndicated 2010-01-21 16:12:40 from Evil, as in Dr.

Jumpstarting PDO

Lukas is making another attempt at jumpstarting PDO development.  I welcome this effort, and will do what I can to help fill in details and make suggestions.  Unfortunately, I'm just way too busy with work to be able to commit to more than that.

I also wanted to share some of my thoughts on why PDO has been in a holding pattern for a while, so that more people are aware of it and can work to avoid repeating the same mistakes.

The first thing to note is that the guts of PDO were hard to develop.  The PHP script facing API sounds simple enough, but the underlying libraries for each different databases work in different ways, and it was and is a challenge to build PDO in such a way that it can work in the most efficient way.

The second thing, which is really a follow-on from the first, is that the database libraries are complex and nuanced.  Some are relatively simple (especially SQLite and MySQL) and others are complex in divergent ways (ODBC and Oracle).  Making a great PDO necessitates having experts in each of those APIs and databases around as contributors, both for the core implementation and for unit tests.

Thirdly, there are a lot of databases out there. That requires a lot of resources for the PDO developers to do a good job; not just different database products, but also different versions of those products, need to be tested against.  This is also very time consuming.

continue reading …

Syndicated 2009-10-25 17:35:13 from Evil, as in Dr.