Looks like even Google isn’t perfect. Check out this screenshot Rich Wareham took when he came across an internal server error while searching on Google. I’ve never seen an error on their site before, so it’s pretty amazing to see this…
Author: mike (Page 18 of 26)
Tiger is finally out, and today been great for Dash Monitors. Dash Monitors has been featured on multiple sites, and it’s currently ranked #2 in the top 10 Widget downloads on Apple’s download site (ahead of Delicious Library Mini Shelf, woohoo!). The downloads for Dash Monitors today have completely trumped any other release of XRG or Seasonality (on average, one download every 10 seconds since midnight), so it looks like the product will be a hit.
The thing is, Dash Monitors 1.1 is still a preview release. I wish I would have finished 1.2 before today, but I haven’t. It’s going to be a pretty big priority to get that taken care of though. I’m working on some new images to improve the look of the widget a bit, and I’m trying to condense things down so it doesn’t take so much screen real-estate. We’ll see how it goes.
If you are one of the people who has downloaded Dash Monitors, thanks for making the release a great success.
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.
Well, Apple finally announced a release date for Tiger (April 29th). Going back to our release date estimates at WWDC last year, it looks like Joe got it, but I was only 17 days off. 🙂
Can’t wait to get a final copy of it here–it should be a great release.
Brent Simmons writes: “Are you a closer, minimizer, or hider?”
If I didn’t have virtual desktops, I would be a hider first, and then a minimizer. I almost never close windows that I’ll get back to in the next several days.
But I do have virtual desktops, and that makes my life so much easier. I have 8 desktops in Desktop Manager right now. Here’s what I use them for:
- News Desktop: NetNewsWire is always open here and I can get my news fairly quickly just by switching to this desktop.
- Chat/Seasonality Desktop: This is where I have my iChat windows displayed, so they don’t get lost in the shuffle. Since those don’t take up too much space, I also have Seasonality displayed on this desktop for quick weather checks.
- Email Desktop: ‘nough said, Mail.app’s window(s) are on this one.
- Web/iTunes Desktop: I usually try to keep all my Safari windows on this desktop, but since I hit the web from random tasks so often, I usually have Safari windows all over the place. I try to keep all web pages relating to one task in a single tabbed window. This way, if I want to come back to a task later, I can just minimize one Safari window and it’s all there for when I’m ready to work on it again. This is usually the desktop that iTunes gets thrown on as well.
- Development Desktops 1-4: These are the desktops I use for application development. Xcode will take 2-3 desktops, depending on how I am using it. Usually I’ll have my projects (Seasonality is one app project, and two Framework projects) open on one desktop, and the API reference open on a second desktop. If I am looking at code in another project as an example, I’ll open that project on a third desktop. Why 4 then? Well, when I do graphics work, sys admin stuff, or update the website I’ll sometimes need 1 or 2 more desktops to work with.
I don’t use Expose much, except on my development desktop with Xcode windows. Xcode opens so many different windows for debugging, run log, SCM, etc (and this is without opening separate document windows for each file), that it’s often difficult to keep track of everything. I have F13 mapped to the Expose command because it’s the largest F-key on the Apple keyboard which makes it easy to find. When Tiger comes out, I’ll probably have that mapped to showing the Dashboard, so I guess I’ll have to get used to hitting F12 instead.
As far as my dock is concerned, I have it displayed on the left side of my screen justified to the top. I would rather have the bottom of the screen for taller code windows and widescreen displays offer plenty of horizontal space. Finally, I turned off dock magnification because when I’m going for an icon I don’t want it to move on me all of a sudden.
Hmm… This ended up being a lengthy answer to a seemingly simple question. 🙂
Ever since ripping all of my CDs into iTunes, I’ve been looking for a good way to control what I’m hearing. Since I’m using Desktop Manager to have virtual desktops on my G5, I don’t want to go hunting for my iTunes window on a different desktop just to play/pause or change a track. The best solution I’ve found so far is to just use the dock menu for iTunes, but I want something that’s always there.
That’s where SizzlingKeys by Yellow Mug Software comes in. Not only does SizzlingKeys give you the option to set hotkeys for all kinds of operations built-in to iTunes (play/pause, previous track, next track, volume up/down, mute, show/hide iTunes), but it also adds quite a bit of functionality on it’s own. First there’s the “Floater” window that shows the current artist, title, album, and album art… I have mine displayed all the time, but you can toggle it with a hotkey or choose to just show it when the song changes. There are also hotkeys to bring up a window to search for songs to play or another window to pick a new playlist to listen to. Overall, it’s packed with features, the interface is pretty nice with all pop-up windows being nice rounded black transparent displays, and it’s free to boot. I give it two thumbs up, so check it out.
Well, the latest Gaucho Software website design has been posted. I think it looks a lot better than the old site…definitely worth all the effort.
Seasonality 1.0.1 is nearing release. It’s mostly a bunch of bug fixes, but there are a couple of new interface changes. The big interface change is with the graph view. Previously that interface was all coded in OpenGL (back when Seasonality was going to be a screensaver and not a full application). However, some users started reporting problems where text wasn’t being displayed in the view (on machines with less than 16Mb of VRAM, I’m thinking it was running out of texture memory or something), so I decided to rewrite it in Quartz. It ended up making the graph look a lot nicer too because anti-aliasing is built-in (I never did get it working correctly in OpenGL), and it should be easier to maintain in the future. Anyway, look for a release sometime near the end of this week or early next week.
This weekend, I spent most of my time designing a logo for Gaucho Software and updating the web site template. The web site hasn’t been finished yet, but I thought I would post an image of the new logo. It took maybe 6-8 hours to create and I’m pretty pleased with the results.
Look for an updated web site sometime in the next day or two. I’ll post it here when it’s ready.
Just made my airline reservations to go to WWDC 2005. I’m pretty excited about this year’s conference with Tiger finally making it out the door pretty soon now. Last year they introduced the 2.5Ghz G5s and the new line of Cinema displays (both of which are sitting on my desk :-))…wonder what this year has in store. G5 Powerbooks would be nice, but I’m not betting on it.
As far as sessions that will be cool to go to… I’m excited about the Core Data sessions. Core Data is going to be a really nice addition to the OS, and last years session just touched on it briefly. It will be nice to learn some more advanced information about how it’s implemented, and how they are planning to allow migrating to new versions of software with database modeling changes. I would also like to go to a couple of Web Kit sessions since Seasonality is really an online application and the possibility of having features implemented through Web Kit in the future is pretty good. Finally, I want to learn more about Automator/AppleScript, gcc 4, and I wouldn’t mind going to the “What’s New with File System” session to learn how to use the ACLs in Tiger.
Buzz is putting together another Weblogger Dinner this year. Last year’s dinner was a lot of fun, and I’m sure this year will be the same.
Anyway, if you’re planning to go and want to meet up, let me know.
Gus posted a very cool SQLite Objective-C wrapper, complete with sample code. It looks like the methods he has in there are pretty handy. Seasonality uses SQLite as it’s database engine, though at the time I was developing it, the only good wrapper I found was for SQLite 2.8.x, so I went for that. I might end up switching to SQLite 3 in a later version, but we’ll have to see. Since the database files are a completely different format between SQLite 2.8 and SQLite 3.x, there would definitely be some work involved in the upgrade.
I figured this would be a good opportunity to talk more about the database aspects of Seasonality. Seasonality actually uses 2 SQLite databases, one of them is the location database in the application bundle, and the other is stored in the users Application Support directory (~/Library/Application Support/Seasonality). The database in the application bundle is really only used as a read-only database, and it contains all of the locations and their associated data values. When you start typing in a zip code to add a location in Seasonality, the app is actually just running a quick SELECT query from the string you’ve typed so far. There are a few different tables in the location database to associate zip codes to ICAO weather locations and radar locations, but overall it’s a pretty simple database. This is actually a subset of all the data that I’ve mined over the past several months…the master is residing in a PostgreSQL database on one of my servers here, and I wrote a Perl script to select subsets of the data from Postgres and insert them into a new SQLite database to include in Seasonality.
The second database in Application Support is used to store all the saved weather data. There are several fields that are saved for future functionality if needed. Other than the temperature, dewpoint, wind and gust speeds used for the graphs right now, Seasonality saves the air pressure, relative humidity, and the visibility along with the date that data is associated with. This brings up a minor complaint of mine…SQLite is typeless, which means that it treats all values you put in the database as the same type. Integers, Floats, and Dates are all inserted as simple strings. They claim this is a feature, but when it comes to date processing it’s a major pain.
When selecting data to build a weather graph, I want to select data that is between two dates. Unfortunately, if I just use a standard date string like Tue Mar 22 22:45:16 EST 2005, it will choke when I try to do a date comparison because it will look at it as a string and, for example, Fri Mar 25 22:45:16 EST 2005 would be seen as happening before the first date because F in Fri is alphabetically before T in Tue. One way around this is to use a very large integer for the date string: 20050322224516. This works fine, and is the method that Seasonality uses to keep track of dates, but it’s slightly inconvenient because all values are above 2^32, so you need to remember to use 64 bit integers to pass dates in and out of the database.
Back to the second database, that’s all there is at the moment…just that one table with a ton of rows in it. Each row takes maybe 100 bytes, and with an average of around 30 rows a day per a location you end up with a database that is about 1Mb after a year’s time (per location). Not bad at all for the amount of data being saved. Searching it is pretty quick too…my database at the moment has about 11,000 rows in it (data for 5 locations back through the beginning of February), and searching through it takes a fraction of a second. In later versions of Seasonality, I might add a way for users to manage this data a bit better. For instance, exporting the data seems like something that user might want to do, and maybe add some AppleScript handling as well. We’ll see where it goes…