Recently in OpenNMS Category

This Week in OpenNMS, Friday December 19th

| No Comments | No TrackBacks

It's been a pretty busy week here in OpenNMS land.

Project Updates

  • Stable: RT Ticketing Plugin

    Jonathan got his RT ticketing updates finished, along with some OTRS cleanup. These have been merged back into trunk and the 1.6-testing branch, so should be ready pending a review, for the 1.6.2 release.

  • Stable: More Vendor Traps

    Jeff spent some time adding more SNMP collection, graphs, and trap events for a number of agents, including SNMP Informant and AIX.

  • Trunk: IfIndex Persistence

    Antonio committed a small change to the event and alarm persistence code to allow Trapd to extract IfIndex from varbinds if it is available.

  • Trunk: Provisioning

    We continued to focus on the new provisioning daemon and API, with a lot of design work and pair programming going on, especially on Matt's part. We all spent time this week breaking the work up into smaller chunks so we can get a better idea of what our progress is.

    Donald continued to work on the detector code, adding more detectors, tests, and cleanups to the existing code.

    I've been working on creating the model for the configuration that will drive provisioning, including changing the default plugin behavior, defining custom behaviors for determining which IP and SNMP interfaces will be managed (as well as what categories the nodes will be put into). I've been learning much about JAXB along the way, which gives us an alternative to all of the intermediate wrapper code we tend to have to put around our existing Castor model objects.

    David's been working on mocking up some code that will allow the provisioning system to automatically update a dynamic DNS server with information discovered during provisioning.

  • Trunk: WMI Support

    Matt Raykowski continued to work on putting some finishing touches on the WMI support. There's some more to do, but he's hoping to get a first drop of it released into trunk any day now.

  • Trunk: RANCID Integration

    Guglielmo committed the starts of what will become an implementation with RANCID, a tool for doing change management and configuration on Cisco devices.

    The first part wraps the existing (Tcl-based) RANCID tools with a web-services API. Next, we will be writing a plugin for the new provisioning API that can be called when managed node information changes.

  • Other: Laszlo Maps

    Matt Raykowski also spent some time in a branch he and Joed have been working on to create network topology maps using OpenLaszlo. It's not yet ready for integration into trunk, but a lot of good low-level work has been going on in that branch alongside the maps work.

  • Other: Web UI Work

    Rob Moore committed some updates to Matt's sandbox "expenses" application (a codebase to test out new technologies) which include a data grid and a sample query interface using JOSQL. We saw a preview of this at Dev-Jam this year, and it looks pretty sweet. Hopefully we can get it integrated into the OpenNMS web UI in the future.

Upcoming Events

Note: The OpenNMS Group is running a special until the end of the year. Sign up for basic support and get one basic training voucher, sign up for enterprise support (including upgrading from basic) and get a combined basic/advanced training voucher. See Tarus's "Forget TARP, Take COVER" post for details.

If you have anything to add to the events list, please let me know.

'Zat You, Santa Claus?

That's it for this week.

The OpenNMS Group is off from Christmas to the new year, so things will probably be quiet next week. I want to wish you all a happy non-denominational, non-specific, non-offensive, winter solstice time celebration day!

As always, feel free to drop a comment my way if you have any suggestions, love- or hate-mail, or anything at all.

This Week in OpenNMS, Friday December 12th

| No Comments | No TrackBacks

So far the response has been positive to TWiO, so it's time again for another chapter.

Project Updates

  • Stable: Ticketing Updates

    Jonathan Sartin worked more on the OpenNMS trouble-ticketing API, finishing up a change to allow ticketer plugins to be able to raise exceptions when errors occur. In addition, he resurrected work on an RT (Request Tracker) ticketer plugin. Both will be merged to the 1.6 branch when they're ready.

  • Stable: Bug Fixes

    I spent a little time this week cleaning up some bugs, mostly exceptions, simple bugfixes, and other minor changes.

  • Stable: Windows Updates

    Bobby Krupczak was kind enough to lend a Win64 machine with Visual Studio so I could get 64-bit binaries built. They are available now on SourceForge. (Copy the jicmp and msvcr90 DLLs to your system directory, don't forget to rename them to remove the -win64 bit.)

    In the process of working on that, a reasonably serious bug was found in the JICMP libraries on Windows. Windows passes around HANDLEs instead of file descriptors for the purposes of file I/O (and socket I/O). We were treating them as if they were normal file handles (ie, integers), which just happened to work on Win32, not because it was correct, but because we didn't try to access the filehandle from Java directly. :) The code has now been cleaned up to treat socket operations on HANDLEs (well, SOCKETs) properly on Windows, and the new DLLs in the JICMP 1.0.9 binary release contain these changes (win32 and amd64).

    Additionally, it was determined that Windows XP, at least, is pickier about reading from raw sockets than other platforms, and requires that at least one packet is sent out the socket before reading any in (even though we're just listening for any ICMP packets on the raw socket, so it shouldn't really matter). This is fixed in the jicmp.jar in the 1.0.9 distribution; until 1.6.2 comes out, it is recommended you copy this jar over the one included in $OPENNMS_HOME/lib if you are running on Windows.

  • Trunk: More Work on the New Provisioner

    Donald continued implementing "detectors", the equivalent of Capsd's protocol plugins, including a new asynchronous API which will allow us to interact with services at a much more granular level.

    Matt has proposed we use more agile development practices, and towards that goal, he started working on a document describing the current desired featureset of the provisioner. We've broken it up into chunks which will then be used to do code sprints so we can do a better job of divvying up the work. We're working on going through and cleaning up the documentation and hopefully we'll get it into the wiki soon.

  • Trunk: Refactoring Maven (Services)

    Right now, one of the biggest chunks of code in our source tree is "opennms-services". It's kind of a dumping-ground of all of the high-level code that isn't webapp code, and it's a bit unweildy. I've started a branch to attempt to refactor at least some of it into smaller chunks (splitting out capsd, collectd, config, eventd, mock, notifd, poller, threshd, trapd, xmlrpcd, and so on). Work will be ongoing, but hopefully eventually we'll have things a bit more manageable.

  • (Almost) Trunk: WMI Support

    Matt Raykowski has been finishing up work on his WMI (Windows Management Instrumentation) monitor and collector and we hope to be merging it into trunk in the near future. There are just a few more finishing touches to put on it, and then it will be ready for inclusion in the future 1.8 release.

Upcoming Events

(Or, as Tarus calls it, Git Yer Learnin' On.)

If you have anything to add to the events list, please let me know.

Development: A Brief Interlude

It's time for a little aside on some of the tools we use for development.

Maven is an awesome tool, but with a large project like OpenNMS, checking repositories and other things are actually a significant drag on the build process. To help alleviate this (and to speed up building and sharing artifacts on our Bamboo continuous-integration server) we set up a Nexus proxy at the office. It worked so well, I set one up at home too. =)

If you'd like to set up your own, I've documented what we did on the OpenNMS wiki. Feel free to update it (and/or ask questions) if you run into any issues.

And on the subject of Bamboo, I realized I haven't yet publicly thanked Atlassian for their generosity. They've generally been very generous to open-source projects, offering free licenses for their tools (continuous integration, bug tracking, etc.) OpenNMS has a very large build, and it can take a long time to work it's way through the continuous-integration process even with a fast machine. They were kind enough to extend our open-source license to allow for more than the usual number of agents, and we're now burning rubber with our entire set of classroom machines acting as build agents. No longer do we have huge queues of waiting builds, we get very timely Jabber notices when we break the build. Hm... maybe that's not such a good thing after all. ;)

Anyways, thanks again to Atlassian for the license upgrade, it's working great!

That's It for This Week

That's it for now. I hope you're enjoying these updates. If you have any questions or comments, or if you've done something cool with OpenNMS that you'd like included, please let me know.

This Week in OpenNMS, Friday December 5th

| No Comments | No TrackBacks

I was recently remembering fondly the oldskool "OpenNMS Updates" that Shane O'Donnell used to do, and I thought I'd take a crack at reviving the tradition. So, without further ado...

Project Updates

  • Stable: Current Release: 1.6.1

    OpenNMS 1.6.1 seems to be holding up without any huge bugs reported. There are no immediate plans for a 1.6.2 release but I would expect we'll look into doing one in a month or so just to roll up any bugfixes that have happened, if nothing else.

  • Stable: Configuration Tweaks

    David did some configuration changes that will be in a future 1.6 release which automatically roll up SNMP LinkUp and LinkDown traps into an alarm. Also, Jeff added a bunch of IETF and vendor MIB data collection and graphs to the 1.6 branch.

  • Trunk: Provisiond

    Development is still churning along in trunk, with the focus on the Capsd rewrite. Since this is the first (of hopefully many) TWiO, I will go into a bit more depth.

    OpenNMS has always been written with scalability in the forefront of our minds, but JVM technology and development methodologies have moved a lot since we first started the project 9 years ago. Since the OpenNMS 1.2 series, and even a bit before, many of the subsystems of OpenNMS have been tweaked, cleaned up, and even rewritten for performance and other reasons. One of the things that's needed attention for quite some time is Capsd, the part of OpenNMS that figures out what devices are on your network, and what those devices' capabilities are (hence, Capsd).

    Matt Brozowski has been working on a complete replacement, called Provisiond. One of the benefits of the OpenNMS architecture is that it's event-driven structure with distinct daemons for different subsystems makes it easy to make new implementations without breaking existing things. Thus, Provisiond will be installed (disabled, by default) alongside Capsd in 1.8, and in 1.10 (or 2.0), it will become the default capabilities scanner, with Capsd deprecated but not yet removed.

    The Provisiond architecture is such that a very robust threading model has been introduced to allow scanning huge numbers of resources in a very efficient manner, and the API has been written to make it very simple to implement new "detectors" which detect services and resources.

    Eventually this new architecture can (and should) be extended to polling/monitoring and data collection, but... one thing at a time. ;)

    Anyways, Matt has been rockin' the Java working on Provisiond, and I've been pairing with him off and on. I really like the way this code is shaping up. Donald in the meantime has been making tons of detectors so we can cover the large range of services we already detect with Capsd.

  • Trunk: Mobile UI

    Alexander Finger started work on a simple mobile UI that gives you the outages summary on a single page (at least on my iPhone <g>).

    OpenNMS Mobile UI

Upcoming Events

If you have anything to add to the events list, please let me know.

From the Discussion Lists - Cartographer

[original thread]

Bobby Krupczak has created a tool called Cartographer which "implements a novel approach to managing distributed systems by automatically discovering and tracking the relationships between its component systems and applications." In addition to the Cartographer protocol (XMP), software, and agent, he has written a collector plugin for OpenNMS which allows the collection and graphing of Cartographer XMP data. Very cool!

Hopefully soon we will get the collector integrated into OpenNMS proper and a future release (1.6 if it's not too invasive, or at the latest, 1.8).

That's It!

So that's it for this week. Let me know if you think this is a useful thing for me to do, if there's anything you'd like me to talk about that's missing, or, well, if you have any comments at all. Until next week...

PostgreSQL 'IPLIKE' Plugin Available for Windows

| No Comments | No TrackBacks

Since we (regrettably <g>) support a couple of customers running OpenNMS on Windows, I spent some time yesterday getting IPLIKE built on it, finally. You no longer have to rely on the slow PL/PGSQL version of it, and can instead use the nice speedy native C version instead.

For details, see the wiki page for IPLIKE.

As far as I'm aware, there is not a win64 version of PostgreSQL, so I've punted investigating what it would take to get stuff built on it, but I would like to get a 64-bit JICMP built at least. Does anyone have a win64 development environment that could get it building for us? I have no Win64 licenses, much less development environment. A little investigating dug up a MinGW64 preview, but I have no idea if it would actually work or not. =)

If you run into any problems with it, let me know!

OpenNMS 1.6.0 Is Out

| No Comments | No TrackBacks

...and it features a ton of changes since the last stable release. Here's what I put in the release notes as an introduction to the 1.6.0 release:

Release 1.6.0 is the first stable release in the OpenNMS 1.6 series.

It's been 3 and a half years since the last OpenNMS stable version, 1.2, was branched and released as production-ready. In that time, OpenNMS as a project has changed tremendously, the community has grown exponentially, and massive numbers of new features have been incorporated into the "unstable" 1.3.x series.

In that time, the unstable codebase solidified to the point that The OpenNMS Group supported it as if it were stable; it was at least as stable as 1.2.x was, but many users held off on upgrading because of the unstable moniker.

After a lot of work, and a renewed focus on getting the next stable release out the door, we are now prepared to declare OpenNMS 1.6 release-candidate-ready.

Why 1.6 instead of 1.4? 3 years is a lot of time, and a lot has happened in that time. We're not ready to call it 2.0, we want to redo the web UI first, but 1.4 didn't really do the massive changes since 1.2 justice. So: 1.6 it is.

Since it is a lot easier to do a release than it was in the 1.2 series (now that the native code is moved out into separate packages, and OpenNMS itself is distributed as pure-java sources), the goal is to continue to be on a much faster 6-month or year cycle for new releases.

Please, let us know if you have any problems at all in our Bugzilla bug tracker.

To give an idea of what's changed, I put together a list of major changes since 1.2 with a couple of the other OGP folks.

Architecture and New Subsystems

  • Alarms: The largest architectural change from a user point of view is the addition of the concept of Alarms. Events mean so many different things in OpenNMS, it made sense to have a higher-level "event" which represents significant happenings in the system. Alarms fill that role, and as we move towards 2.0, events will be de-emphasized in favor of alarms for reacting to significant events. The new alarms system will allow important events to be "reduced" into alarms. If an event comes in with the same "reduction key" as a previous event, the alarm will increment the "count" of events, yet it will still only take up a single line in the alarm browser. Clicking on the count will bring up the event browser with just the events that have been reduced.
  • Automations: It is now possible to do a variety of automated actions through "automations". For example, say you have an alarm with the severity of Minor that has not been acknowledged in the last 20 minutes you might want to escalate the severity. Vacuumd has been enhanced with a configuration that now allows configuration of processes we're calling Automations that are defined by Triggers and Actions.
  • Windows: OpenNMS now runs on Windows.
  • PostgreSQL: OpenNMS supports running on top of PostgreSQL 7.4 through 8.3.
  • Syslog Improvements: The syslog daemon included with OpenNMS has been significantly enhanced, including regular-expression matching and back-reference support.
  • Model Importer: OpenNMS can now import node, interface, and service information from an external provisioning source. This facility can augment or replace the discovery functionality provided by Capsd.
  • Categories: Nodes can be assigned to one or more categories (eg Production/Test, Datacenter A, Datacenter B); these categories can be used in filter rules. This permits to selectively forward Alarms into certain destination paths based on the node category: "Send Alarms for Production in Datacenter A to Team A, Send Alarms for Test Systems in all Datacenters into the Maintenance Queue".

Polling and Data Collection

  • Generic-indexed data collection modeling makes it easy to collect, graph, and threshold on multi-instanced performance data, such as values residing in SNMP MIB tables.
  • SNMP4J: In addition to the existing SNMPv1 and SNMPv2 support provided by our in-house JoeSNMP Java library, OpenNMS now supports SNMP v1 through v3 using SNMP4J. The SNMP4J strategy is enabled by default, but you can go back to the JoeSNMP one if you have a specific need for bug-for-bug compatibility with OpenNMS 1.2's SNMP behavior.
  • JMX: Support was added for polling and data collection.
  • HTTP Collector: Support was added for data collection via HTTP.
  • NSClient: Support has been added for NSClient (and NSClient++) polling and data collection.
  • Data Export: It is now possible to export RRD data through the web UI.
  • Windows Service Monitoring: Windows services can be monitored through the NSclient support and via a special-purpose poller monitor that uses SNMP.
  • Mail Transport Monitor: It is possible to monitor the complete round-trip availability of a mail system, from sending to checking a mailbox.
  • Page Sequence Monitor: Support has been added for monitoring a complete transaction against a web site, including cookie storage, form submission, and checking the results of the output of a URL.
  • Distributed Monitoring: There is now a distributed monitor that allows you to do service monitoring from multiple locations reported to a single OpenNMS instance.

Thresholding

  • Thresholding for collected performance data is now performed in-line with collection by default. This change makes threshold evaluation virtually instantaneous while drastically lowering the CPU and I/O overhead associated with thresholding. Thresholding for latency data (data from the poller monitors) is still done in the old asynchronous fashion.
  • Absolute Change Thresholds: A new type of threshold useful for monitoring the values of such variables as radio transmitter power (in dB) where a relative change of a given magnitude may not be noteworthy, but an absolute change above some threshold is considered significant.
  • Expression-Based Thresholds: A new type of threshold allowing the user to specify an expression, in standard mathematical terms, involving one or more data source names, operators, and constants.
  • Custom Event UEIs in Thresholds: The types of events generated when thresholds are exceeded or re-armed can now be specified on a per-threshold-definition basis, allowing for much more flexibility in using thresholds as the basis of alarms and notifications.

Notifications

  • Roles: OpenNMS now supports on-call roles. If you have, say, an On-Call role where the users change over time, this feature allows you to schedule them in advance and OpenNMS will manage that schedule for you.
  • Group Duty Schedules: Works like normal duty schedules, except if a Group is listed as a target in a destination path, the duty schedule will apply to the whole group (individual users and roles also in the target are not affected).
  • JavaMail: JavaMail is now the default API used for sending e-mail notifications. This change eliminates the burden of installing, configuring, and troubleshooting a local mail transport agent such as Sendmail or Postfix on the OpenNMS server.
  • Path Outages: A basic path outage capability has been added. This feature addresses the need to suppress notifications for nodes that appear to be down to the OpenNMS system due to a failure in the network path between the nodes and OpenNMS.

Integrations

Web UI

  • Jetty: OpenNMS has a built-in web server (including AJP support), and no longer requires Tomcat for the web UI (although it can still optionally be used)
  • JFreeChart Support: OpenNMS now supports a JFreeChart integration which lets you add charts to the web UI.
  • Zooming: It is now possible to interactively zoom in on graphs.
  • StrafePing: OpenNMS includes an implementation of SmokePing.
  • RSS Feeds: Support has been added for RSS feeds for notifications, outages, alarms, and events.
  • New Look: The OpenNMS web UI got a face lift.

OpenNMS 1.6.0 On the Horizon

| No Comments | No TrackBacks

So I just finished getting OpenNMS 1.5.98 out the door. This is the first release that we've left a few (small) known issues in because we're in hard freeze.

I am so ready for this release to be out; there have been a ton of improvements since 1.2.x and the sooner we can get folks to the current codebase, the better.

Of course, while I was in the process of writing this blog post, Dave found a small but not-insignificant bug that is worth doing another RC for, so here comes 1.5.99! ;)

OpenNMS 1.5.94/1.5.95/1.5.96 Released

| No Comments | No TrackBacks

After a few issues with an annoying poller bug and some cross-site scripting issues that ended up triggering a series of quick releases over just a few days, things are settling down again in the wake of the OpenNMS 1.5.94-1.5.96 releases.

Let me start by saying, holy crap we fixed a lot of bugs, and we're on track to get 1.6 out the door in the next month or so. There's only a few bugs left, and we're pretty much 100% focused on finishing those off.

For the first time in a while, this is more than just a suggested update, since a number of cross-site security issues were fixed. If you're running anything in the OpenNMS 1.3.x or 1.5.x series, it is very strongly recommended that you upgrade to 1.5.96.

As always, feedback is encouraged, please let us know if you run into issues, awesomeness, or anything inbetween. ;)

OpenNMS 1.5.94 Coming

| No Comments | No TrackBacks

So I'm getting really excited about the next OpenNMS release on the road to 1.6. We've got over 100 more bugs closed since 1.5.93, and only 22 left before we can release a 1.6 release candidate. We're holding off on 1.5.94 because of a rather interesting bug that can cause strange outage results for nodes not using the "critical service" functionality. Matt's worked out a unit test for it, so hopefully we'll have it wrapped up shortly and get the release out this week.

That said, if you're interested in helping us wrap up the bug-search for 1.6, feel free to try out the "1.6 testing" snapshot RPMs by following the yum installation instructions for the "testing" release and giving it a shot, and open a bug if you find any issues.

One of the big blockers holding up a real release is consolidating the installation documentation in one place, be it the wiki, or the out-of-date install guide. If you have suggestions on things that could be clearer for installation, configuration, or anything else, please open a bug! At this point OpenNMS is pretty solid, it's arguably more important to get documentation cleared up where it's confusing.

OpenNMS Dev-Jam 2008 Developer Journal

| No Comments | 1 TrackBack

So I've been meaning to do a Dev-Jam 2008 summary since we got back last weekend, and I can put it off no longer.

In summary: Dev-Jam 2008 was a huge success!

We loaded up in the Dev-Jam Express and started the drive from North Carolina to the Georgia Tech campus. After plenty of rest stops, food breaks, passing water towers that look like giant spanked butts, and picking up of supplies, we arrived.

We got settled in, got room keys, met with the other folks who had arrived, and recuperated from a long drive.

Tarus started out by welcoming everyone and doing a "State of OpenNMS." Since last year we blew away our goal, "2007: The Year of 4 Releases". Development has increased dramatically, despite the fact that off and on, OpenNMS regulars have been busier than ever with non-OpenNMS projects. Of course, new regulars have joined in the fray. (Does that make us "more regular"?) Anyways, OpenNMS has gotten easier to install, more robust, and just plain better in every way since the last Dev-Jam. Not only that -- we had 17 people come this year. Awesome!

Next, Matt talked about how things have progressed through the different Dev-Jams, and how we learned from each of them.

At Dev-Jam 2006, Spring was introduced, and while it was an educational experience, people spent too much time without really being able to dig their hands into the code, much less have fun with the other jammers.

Conversely, at Dev-Jam 007 (licensed to... er, GPL?), we had a very free-form conference. People hung around and worked on whatever took their fancy. Plenty of coding happened, but a number of things never wrapped up (and are still sitting in the devjam-007 branch waiting to be completed).

This year Matt proposed a hybrid of the two. Things were still free-form, people picked a project they felt like working on, and invited others to help out, but we were asked to spend a little time each morning talking about what we've done and getting input from the other folks. In the end, sometimes it was almost not morning by the time we did it (grin), but I think it helped add a little structure to the '007 style, and we all did better for it.

As for development, people were mostly just getting started.

  • Matt had been preparing a RESTful framework so it would be ready (or at least, almost ready) for Dev-Jam.
  • I had been meaning to work on cleaning up the remote poller code to not be different across the command-line and GUI interfaces, and to unify the webstart and jar-based versions of the remote poller startup code, so I started in on that.
  • DJ and Mike started playing with turning snmp-graph.properties into XML (actually continuing some work DJ did along those lines some time ago).

Things started picking up on Tuesday, as people settled into what they were working on.

  • Matt worked on upgrading our Spring code to Spring 2.5.
  • Jonathan started the first of many commits finishing up his work on OTRS ticketing integration.
  • Craig and DJ both committed some bugfixes and other updates to the 1.6 and trunk branches.
  • Alejandro and Matt both worked on the RESTful interfaces some, in a new branch dubbed the Jersey branch.
  • Joed started in on a new map based on OpenLaszlo that is shaping up to be pretty sweet! It features RESTful integration as well.
  • Paul helped out fixing a bug or two, and also helped out on Debian packaging issues, which he's done a lot of great work on in the past months.
  • I got the code pretty much finished on the webstart work, although I continued to hit strange Maven issues with bad plugins and the like.

Lots of commits, but mostly Joed setting up some directories for the OpenLaszlo maps. SourceForge was kind enough to announce Subversion downtime only 5 hours before it was scheduled to happen. Intermittent timeouts and other issues kept most people from doing much before the outage deadline.

  • Joed worked on the OpenLaszlo maps.
  • Jonathan spent more time on the OTRS integration, approaching completion.
  • I continued to fight with Maven, finally getting things to work shortly after SourceForge shut off SVN. =)
  • Alejandro did more good work on the RESTful interface, adding REST support for nodes, IP interfaces, SNMP interfaces, and services.

Lots of progress in a number of areas, and with Subversion back up, people could actually... commit things. ;)

  • Jonathan worked on wrapping up his OTRS integration.
  • I was able to commit my webstart code that I finished on Wednesday. Usage is documented in the wiki. I spent the rest of the day splitting out the trouble ticketing API into it's own module, as well as brainstorming with Matt on what the future "perfect codebase module layout" would be when we've had time to refactor everything. (Hah!)
  • Tarus worked on cleaning up bugs, in preparation for trying to get a 1.6 release candidate out the door.
  • Jeff played around with something in trunk relating to Windows? I dunno what that's all about. :)

A few new projects were opened, and a few completed. By Friday, commits were chugging along pretty nicely.

  • David (along with Walt from Hitachi, and a little help from Matt) spent the day working on a TL1 interface for OpenNMS.
  • Craig merged the existing work from the Jersey branch into trunk.
  • I spent some time cleaning house and merging useful work done in trunk back to the 1.6 branch.
  • Joed continued to fill out the OpenLaszlo map support.
  • Alejandro worked on the RESTful interface more, adding a few features and fixing bugs.
  • Craig M. also handed Alejandro a keychain as door prize for making the 10,000th commit!

And, officially, Friday ended Dev-Jam. We had a nice dinner and people started traveling. On Saturday, we made our way back to North Carolina.

Thanks to everyone who made Dev-Jam possible. I had a great time, and we got a ton of stuff done!

Edit: It's important to pay more attention to your calendar when reconstructing the dates that things happened. Turns out Dev-Jam started July 27th, not August. ;)

So if you've followed my blog for a long time, you might have noticed me mention that I have, on occasion, written music.

Finally!

I've finally found some time to really work on getting everything set up again so I can write more music (and, in fact, I've got a guitar on the way as a birthday present from my wife!). This past month, I've worked really hard to do something I've meant to do for a long time: release an album.

Now, my music has always been freely available, it's a part of the demoscene culture, not to mention my open-source roots, working with OpenNMS, Fink, and tons of other stuff. One thing that's very hard to do, however, when writing tracked music, is get that "finished" sound.

I've spent the last month going through my catalog, dumping everything to Garage Band and ProTools, and re-mixing, remastering, and all-around cleaning up my tracks.

Without further ado, I announce my first single, Pointillize, available immediately on Amazon MP3 download, and soon on iTunes, Rhapsody, and other music download services.

On May 20th, my album, Finally, will be available as well.

Full versions of the songs from Pointillize and Finally are available for preview on last.fm. Just click on the album and hit play.

It's been a long time coming. If you like it, tell your friends; if you don't, um... well, don't tell anyone! Special thanks to Cynthia for putting up with me obsessively listening to these songs, over and over again, and spending way too much time mixing and remixing them. ;)