<pre><code> 'HAL'.split('').map{|l| l.succ}.join </code>
I’m so glad Tiger included updates to Cocoa that added support for XQuery and XPath! It just makes using XML all that much easier.
While working on my Weather Plugin I realized that some stations include the latitude and longitude in their current observations XML. I thought it would be nice to help the user by loading these values into the Forecast preferences so they don’t have to hunt them down separately. So, instead of having to parse the whole document, I can just do the following (where xml is the NSXMLDocument I download):
<pre><code> NSString *xpath = @".//latitude/text() | //longitude/text()"; NSArray *nodes = [xml nodesForXPath:xpath error:nil]; if([nodes count]<1) { NSLog(@"Error"); } else { [defaults setObject:[NSString stringWithFormat:@"%@", [nodes objectAtIndex:0]] forKey:@"QSWeatherLatitude"]; [defaults setObject:[NSString stringWithFormat:@"%@", [nodes objectAtIndex:1]] forKey:@"QSWeatherLongitude"]; } </code>
For more info on using XPath and XQuery with an NSXMLNode: Querying an XML Document
Wow! That was easy! I have added dynamic icons for Forecast and Current Conditions1 notifications using Growl.
Download:QSWeatherPlugin-beta2.qspkg
1 includes weather, temperature, winds, visibility, etc.
Looks like my Weather plugin for Quicksilver was incompatible with QS beta44. I’ve reworked it and renamed it to QSWeatherPlugin because the old version still works with pre-beta44 versions of Quicksilver.
Since beta44 requires Tiger, I was able to exploit some the latest XML improvements. Namely, built-in support for XQuery. No longer do I need to do the sort of hackery I was performing to make this work.
Even more exciting is that the Weather plugin works seamlessly with the Growl plugin! Just make sure you check “Use Helper” in the Weather plugin preference pane and have your observations and forecasts displayed via one of the many Growl notifications!
I can set the icon in the notifications, so I’m going to try grabbing the current condition icon. But, in the meantime, download the beta>
Download: QSWeatherPlugin-beta.qspkg
I downloaded a gzip-ed, cpio archive yesterday (a .cpgz file) and couldn’t remember how to open it. I was logged into my Mac remotely and was scanning the man pages. When, before you can say Google, I tried the open command. It unpacked the archive without issue. From the open man page:
The open command opens a file (or a directory or URL), just as if you had double-clicked the file’s icon.
This is pretty obvious, but I was pleasantly surprised to encounter this little nicety.
ChuchoMUD has been updated!
One of the (many) outstanding issues with ChuchoMUD was that it was sort of gratuitously passing around entities. Well, this is great except that when the databases dump to YAML, they dump to different files. Thus more than one copy of a given entity would exist. Clearly this was not right.
I solved the problem by storing only “references” to the entities. This is pretty easy because each entity has a unique database ID and its type can be used to determine which database to check. Unfortunately, you get some yucky code like this:<pre><code> def entity db = case @entity_type when Character.to_s $character_db when Room.to_s $room_db when Item.to_s $item_db when Portal.to_s $portal_db when Region.to_s $region_db else $stderr.puts("@{entity_type} not found") nil end if @entity_logic!=nil then db.get(@entity_id).find_logic(@entity_logic) else db.get(@entity_id) end end </code>You might notice two things: one the “types” are getting stored as Strings (another issue with YAML) and there’s special code for “logic” modules. Basically, logic modules aren’t stored in databases, but are associated with an entity. They can, however, operate somewhat independently.
All in all, it works. Though, it “breaks” the previous YAML files. So, if you happened to create an entire MUD in the last few days, I apologize.
As a bonus, though, I added a day/night cycle example and a wandering, talkative NPC. See: I care.
See: ChuchoMUD
I’m sorry, but VSS is my choice for Worst App Ever. Let me enumerate some of the reasons:
But my number one problem with VSS is that it is totally unintuitive. I’ve used RCS, CVS and Subversion… so I’m no slouch when it comes to version control systems. It just doesn’t make any sense to me. Even simple things are confusing. More complex tasks like branching and merging get jumbled-up under names like “sharing” and “pinning”. Heck, even the MSDN docs say that merging is nearly impossible.
No doubt about it: Visual Source Safe is the worst app ever.
Queue fanfare!
Please meet my latest obsession: ChuchoMUD a MUD written in the wonderful, amazing Ruby programming language.
The goals of ChuchoMUD are as follows:I’ve been working tirelessly on ChuchoMUD for over a month-and-a-half. It was hard to just pause and actually upload the code—I kept wanting to add features. It’s still pretty barebones, though. No combat, for example.
ChuchoMUD is based off BetterMUD from Ron Penton’s MUD Game Programming book. It facilitates a very flexible system by encoding a minimal engine, then delegate most of the “game” logic to separate “logic modules”. The modules intercept queries and communicate via messages. Ruby is great for this stuff.
I also used meta-programming to create a domain-specific language for content creators. It lets you do some pretty cool stuff while ignoring the plumbing. I’ll post more about that soon.
Right now, I’ll just be uploading tarballs until I can get by Subversion repository online. In addition to being my first real foray into Ruby programming and MUD development, it’s also my first big project using Subversion. I have lots of experience with both CVS and VSS. Subversion leaves them all in dust!
I should also acknowledge Teensy MUD another Ruby MUD. My networking code experience is thin, so I decided to stand on the shoulders of giants. In this case, that means I incorporated the Teensy MUD networking core directly into my MUD!
Anyway, without further ado:
Download: chuchomud.tar.gz
For more info: Project Page
The company I work for is very process-driven. So much so, that it has patents on processes. But my current client (and former employer) is very much of the “Make it happen” mentality.
While I can see the benefits of both a process-driven and an informal, relationship-driven approach, I wonder how well the process-heavy schemes will hold up in an environment where the customer is not particularly tech-saavy. These business users are in the business of whatever it is their company does—not in the software business. They’re not NASA, either. Software exists only as a means to an end. That’s something that can be hard for a developer to swallow.
One of the tentants of the Agile Manifesto is “Individuals and interactions over processes and tools”. To me this means, the days when the business user would call you up on the phone or walk into your office and say, “make it happen” and you’d do it. That works great until it doesn’t. Often you end up with a lot of specialization and dependence on a particular individual. And there’s no transparency (and probably no audit trail). But here, I think developers can help themselves and each other: avoid the “job security” mentality, don’t be clever. Write quality, standards-compliant software using good practices. Write tests, use version control—this stuff isn’t hard.
The alternative is The Process. It solves the problem of specialization by abstracting the work to the lowest common denominator. And it creates an Audit Trail made out of paper and Red Tape. [ed. sorry for mixing metaphors] But it’s prohibitive and doesn’t otherwise add value.
And really, don’t we all just want to “make it happen”?