Older blog entries for wez (starting at number 47)

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.

EvilDesk now on BitBucket

I've opened up the code behind EvilDesk, my Windows Shell replacement, and made it available on BitBucket under the terms of the GPLv2.

Enjoy!

http://bitbucket.org/wez/evildesk/

Syndicated 2009-06-08 04:00:31 from Evil, as in Dr.

CouchShare now on BitBucket

A few of my friends and associates may have heard me talk about the media server I've been running in my basement; I used to automatically transfer content from my tivo to a hard-disk in my basement so that I had more space for recordings on the tivo.  Since most of the recordings that I want to keep are now available via Hulu, I haven't had much call to use it in the last 6 months.

So, what is CouchShare?  It's a UPnP server that can share content from folder to an XBox 360 on your network.

It's written in PHP (and requires a tiny PHP extension to enable multicast support) and is written using the eventing framework that is part of the Alexandria codebase.

I wrote the code back in 2007 and it has served me well for a couple of years; it felt like it was about time I got off my backside and shared it with the world.

It is by no-means a polished bit of code; I think it's probably the sloppiest code I've written in quite some time, and it may well need a couple of tweaks to make an easier application out of it.

continue reading …

Syndicated 2009-06-08 02:56:48 from Evil, as in Dr.

toshiba hotkeys on solaris

Update: moved code to http://bitbucket.org/wez/toshutils/

Friday evening I sat down and wrote my first piece of solaris kernel code and an associated user-space application that activates the brightness up/down hotkeys for the LCD on my Toshiba Satellite M30.

I implemented a tosh_hci driver that can perform Toshiba Hardware Configuration Interface traps via an ioctl(2). This driver is really simple; the hardest part being the intel assembly needed to perform the trap (technically an inb instruction, not a trap).

The userspace code is a really slimmed down version of the code that I previously made available in my patch to the linux acpid. It currently only handles the LCD brightness keys because none of the features that the other hotkeys are supposed to invoke are currently supported by solaris/opensolaris.

Anyhoo, I've made the source available, under the CDDL, in a bundle here for any other toshibans that might like to get a bit more comfort factor back when running solaris.

Syndicated 2009-06-08 01:13:22 from Evil, as in Dr.

Dead laptop disk == more linux hacking

Update2: moved code to http://bitbucket.org/wez/toshkey/overview/

Update acpid now handles the brightness controls, displays the battery status in the ps list and emits power warnings once you're down to 15 minutes of power. I've also added a little non-root acpid client that will allow you to run your own stuff in response to hotkey events.

I suffered a dead (nearly; it's on its way out) laptop disk almost a week ago, and have been clawing my way back to normality.

As a side effect, I now own a Toshiba Satellite M30, which apparently has slightly more linux friendly hardware than my other Satellite (the one that's having issues).

One of the cool things is the toshiba_acpi module; it works in this model and allows access to the hotkeys so you can map them exactly as you like. Since running a standalone daemon for this sucks (you can choose either a python script or a slightly-overweight fnfxd), and since there was a feature request on the ToshibaAcpiDriver page for it, I've written this patch that adds toshiba key support to acpid (1.0.3).

continue reading …

Syndicated 2009-06-08 01:09:27 from Evil, as in Dr.

Whirlwhind review of php|tek 09

It's been a simultaneously long and fast week for me. I flew into Chicago last Sunday, ready for the PHP core developers meeting that we had planned for the Monday and Tuesday. My journey went like a charm; perfect timing had me parked at the airport, immediately on the shuttle bus to the terminal, straight through security and to my gate just in time to start boarding. The only minor hiccough was in finding the shuttle from Chicago to the hotel; it was extremely poorly sign-posted.

Anyway, I got to the hotel and ran into the British contingent of the conference, and we eventually found our way to a Mexican restaurant not far from the hotel, and then to the bar across several lanes of traffic from the hotel, where a fair quantity of alcohol was consumed by all.

The next day we headed downtown to the Microsoft offices for day 1 of the core developer meeting, where a number of internals issues around PHP 6 were discussed. This was a very productive session, and we earned the drinks that followed at the Map Room, although I opted out of the bulk of those and headed back to the hotel (yes, I'm getting old)

Tuesday was day 2 of the core developer meeting, and thankfully was held in the conference hotel; the journey downtown took the better part of an hour and I was glad to skip it. The agenda for this day was to look primarily at what we could clean up in the code for PHP 6 and whether we might need to introduce a PHP 5.4 to aid in that transition.

We also touched on PDO 2; the short of it is that it might be about time to see if the vendors are willing to play with us again, and where the original plan was to have all the major vendors on board, we may well be looking at cutting out the less flexible vendors from the baseline PHP distribution. I'll do what I can to help facilitate a PDO 2, but don't anticipate having much free time in the coming months.

continue reading …

Syndicated 2009-05-24 07:03:42 from Evil, as in Dr.