*Coder Blog

This just went live in the last 24 hours. Along with working on my own Gaucho Software products such as Seasonality, Dash Monitors, and XRG, I also consult for other firms. I’ve been working with Jeremy and the rest of the DynDNS team on their Mac update client for quite some time. Just recently, version 2.0 of the project has reached a stage where it’s ready for public beta consumption. The interface, developed by FJ de Kermadec and his team at Webstellung is top notch, and does a great job hiding the complexity of everything going on behind the scenes. We still have some work yet to do before a final 2.0 release is ready, but I think the app is looking pretty good thus far.

If you use DynDNS services, check it out. If you aren’t using DynDNS services, give their website a look-see to determine if you should be using their services.

Just as an update of my MacBook Pro situation…I picked up a 2Ghz MacBook Pro at the Apple Store in Grand Rapids yesterday. So far, this model is an order of magnitude better than my last machine. Only a single noise problem still exists, and it is so much lower in volume that I don’t think it will be an issue at all. Furthermore, physically the machine feels like it’s built better. The trackpad button feels a lot nicer, and it takes more effort to move the screen on it’s hinge, which results in a much nicer feel. I’m a happy customer.

I came across a somewhat unfortunate hint when looking at the recently posted Developer Note of the MacBook Pro machines on Apple’s site. It looks like Apple no longer controls thermal profiles from the OS, so it’s unlikely that apps like XRG or Dash Monitors will ever be able to capture temperatures or fan speeds on these models. Here’s a quote from the Developer Note:

System Management Controller
The MacBook Pro uses an advanced system management controller (SMC) to manage thermal and power conditions, while keeping the acoustic noise to a minimum. The SMC is fully independent of the operating system.

Making the SMC completely independent of the OS is a very good thing. Without OS independence, thermal drivers for Windows XP, Linux, or any other OS you want to run on Intel machines would have to be written. This code can be fairly difficult to write, so really the SMC will make things much easier in that respect.

However, it would be nice if Apple provided a way to monitor what the SMC is doing…let the SMC do it’s job, but give me a way to find out how my machine is feeling.

Update: James Conolly and Cryptonome (from the source, InCrew) both mentioned SpeedIt in the comments, which made the news a few days after I wrote this post. I have yet to look into the full details of the implementation, but it looks like there might be MacBook Pro temperature monitor support in XRG afterall. While it probably wouldn’t make sense to include SpeedIt directly with XRG, if a user has SpeedIt installed, it should be fairly easy for XRG to pick up the temperatures and display them. Yet another feature to add to the next release. Thanks go out to the InCrew folks for making this possible.

Today I was pleasantly surprised when Edward Miller sent some screenshots of XRG running on his new Quad G5 system. This is the coolest thing I’ve seen in awhile, so I thought I would post a crop of XRG’s CPU graph on a quad-processor system…

XRG was designed to work with n-processor systems years ago, but I couldn’t imagine seeing more than 2 processors in a Mac for a very long time. At the time it wasn’t really something I could test either…it worked on 2 processors, but who knew what would happen when there were more than 2 CPUs. It’s really cool to see this feature in action on 4 cores, and I can’t wait to see it on 8 core Macs.

“Open Source Mac is a simple list of the best free and open source software for Mac OS X. We aren’t trying to be a comprehensive listing of every open-source mac app, instead we want to showcase the best, most important, and easiest to use. This page should be a handy reference and a useful tool for getting more people to start using free and open-source software.”

Cool, they listed XRG in the Quick Links section on the bottom of page 2. There are some really good apps on the rest of the list, so check them out.

XRG turns 3 today. XRG 0.1.1 was released on October 24, 2002. It’s been great working on the project, and I wrote up some memories and experiences when developing XRG on a separate page. I also spend some time talking about the early days of XRG, so definitely check it out.

Thanks to all the XRG users out there, here’s to several more years of XRG development.

Switxer Diaries: “Every now and again you encounter an app that is serious eye-candy. Sometimes, as is the case with XResourceGraph, that app is also useful.”

One of the many tasks I’m working on at the moment is taking some monitoring code from XRG and molding plugins out of each graph module. I want to make it easy for other developers to include monitors in their code, and I really believe that this is an evolutionary step in XRG’s development cycle. The resulting code is going to be called MTK, or the Monitoring Toolkit, and it will be the new foundation that XRG and Dash Monitors will be built on.

Just to give a little insight as to how MTK will work, each monitoring module will be a Cocoa plugin bundle. Right now I have completed plugins for CPU, Network, Disk, and Memory. The plugin is fairly simple, and at the moment must follow a simple protocol: the principal class must contain methods to return a plugin name, a plugin short name, and an NSDictionary of key-value data. The dictionary keys are the names of the data fields, and the values are, well, the values for those data fields. This gives developers a very generic interface to write their own MTK plugins to work with any application that uses the MTK protocol. Of course applications like XRG that do a lot of graphing or custom drawing can require plugins to implement other protocols to handle it’s view, preferences or other properties. I’m still working out the details of how to manage multiple protocols in a single plugin.

MTK plugins wouldn’t have any purpose if there wasn’t an application to use them, so when MTK is introduced there will be a command line application (mtk) that will make use of any MTK plugins. The app will simply take arguments to define the time interval between updates and a directory of MTK plugins, and will continually output data returned by the plugins in CSV format (the column names are just printed out once at the beginning of execution). Then, any app or script can parse this CSV output and do what they want with it. I’ve already opened some captured data in Excel and played around with it. Of course if you don’t want the overhead of running a separate executable to output CSV data, simply write some code to load MTK plugins in your own application. The mtk command line application will be open source, and it’s only a single class, so it should serve as a good example of how to use MTK in your own applications.

I’m pretty excited about the architecture, and I’m looking forward to having XRG completely migrated over to MTK. I would love to see other developers come up with their own modules and see where the project goes. I’m hoping to get the initial version out on the web sometime in the next week or two, but there are a lot of things going on right now so it might have to be put on hold for a bit.

What do you get when you cross an XRG release with Murphy’s law? I can understand yesterday’s bandwidth fiasco, which was mostly my fault for not planning better, but this is getting rediculous.

Wednesday, 1:30pm: The power goes out. First thought: Ohh, shit. Second thought: No problem, got the servers on a UPS, everything should be fine. Went downstairs to check, things were okay, brought an extension cord over to power the wireless modem on the UPS as well, link went back up fine.

Wednesday, 2:00pm: UPS power runs dry. Thinking first thought a lot more now.

So now I’m writing this blog entry on my Powerbook, hoping the power will come back on soon. The only saving grace is the XRG mirror download that I posted yesterday is listed as “Download 2″ on MacUpdate. Of course, if anyone is linking in from anywhere else, they won’t be getting anything.

So the lesson of today is… if releasing a software application, make sure you have your entire site hosted with a good hosting provider. Ohh, and the MacMini is still cool.

Update: Power came back on slightly after 3:00pm.

XRG 1.1 was released this morning. I thought I’d try out releasing the same day as the MacWorld keynote just to see how it goes. So far, it’s been going really well or horrible, depending on how you look at it.

The good part is that about 1200 copies of XRG have been downloaded during the past 6 hours. The bad part is that I severely under-estimated the amount of bandwidth required when doing a software release (hmm, 1200 * 1.2Mb/copy = 1.44Gb + normal web traffic). Since the beginning, I’ve hosted the XRG web site on my own machine, and offered the XRG downloads from a machine at Ephibian. This was never a problem, and my web server (at the time on a 40K/sec uplink) always had plenty of bandwidth to spare, so I thought that hosting both the site and the downloads in-house on a 90K/sec uplink would work out well. Oh was I ever wrong. Within an hour of releasing, my connection was completely saturated and the server was handling over 90 connections concurrently. The network connection remained pegged for about 4 hours after that, and has only now started to trickle down a bit.

At first, I couldn’t think of any way to handle it and thought I was pretty much screwed, then I thought of a few things that helped out a bit. The first thing I did was set up a download mirror back on the old web server with a 40K/sec uplink. This helped less than I thought it would because, unfortunately, not too many people choose to download from a mirror site. The second thing I did was turn off my web log analyzer, not because it was taking too much CPU (actually, the server never broke a sweat really), but because I have the analyzer configured to do DNS lookups on the IPs that hit the server so I can see a pretty graph on where people are coming from throughout the world. Usually, the analyzer runs every 2 hours, but I figured it could wait for awhile. This ended up helping more than I thought it would; I guess the number of DNS connections made would have been pretty high. This probably benefited the web page traffic the most, since a reduced number of connections on the network would improve the speed of short-term network connections dramatically.

So the lesson of the day is: If you release a software application, make sure you store the download(s) with a good hosting provider. I suppose the benefit of today’s events is that I’ll know this when releasing an application that I’ll actually be charging for. I’ll probably post a followup blog entry on the release in a few days.

PS: MacMini? Sweeeeet… If I would have had this choice a few months ago my computer purchase would have been a lot more difficult. A compile farm of about 5-6 of these things would probably work faster than my 2.5Ghz G5 could chug through compiling apps. And then there would have been the numerous possibilites… 2Ghz G5 + MiniMac, or 1.8Ghz G5 with 2 MiniMacs, etc. Maybe it’s better I did buy my computer before these came out.

Well, after a couple of months of hard work, I finished version 1.0 of XRG and released it this morning. I’m hoping to submit it as an entry in the Apple Design Awards this year, so I’ll be working on that next week. Here’s a description of the changes for this version:

XRG 1.0 contains many new features and bug fixes. The primary new feature is a new machine temperature graph that will graph the temperature of different locations in your computer. Supported CPUs include PowerMac G5s, Aluminum Powerbook G4s, and iBook G4s. Other new features include the addition of uptime statistics to the CPU graph, the ability to drag XTF theme files to the graph to set graph colors*, a re-designed preferences panel with new icons, and the option to hide XRG’s dock icon (through a new contextual menu for the graph title bar). A complete list of changes and bug fixes can be found at http://www.starcoder.com/xrg/changelog.shtml.

As always, comments and suggestions are welcome. Visit the XRG Homepage.

* I’m sure Robb Beal will be happy about this one. With Spring, drag and drop is taken to the extreme (quite nicely might I add), and naturally he requested this feature for XRG. Look for more drag and drop functionality in the future.