Category: Gaucho Software (Page 1 of 8)

20 Years of XRG

October 25, 2022 / mike / 0 Comments

Today hits an important milestone for one of my apps: it has been 20 years since I published the first public release of XRG. XRG 0.1.1 was released on October 24, 2002 and was built for OS X 10.2, but also supposedly worked on OS X 10.1. The release DMG file was a whopping 169 KB.

XRG was the project I used to teach myself how to develop Cocoa apps using Objective-C. Over the years, the code has been refactored several times over, but I’m sure there is still some original code scattered about the project. When XRG was introduced, modern Objective-C features didn’t exist yet. Garbage Collection was a fad that I was thankful to never use, and ARC wasn’t even a figment of anyone’s imagination, so retain/release calls were everywhere. Of course I switched to ARC when it became available, and I’ve also refactored the code over the years to use Objective-C literals, dot notation for method calls, auto-synthesized object parameters, and object subscripting.

The one thing I haven’t done is add any Swift code to the project. I decided years ago that XRG will remain my love letter to the Objective-C language. Objective-C was the perfect language for the OS X versions of the day, and there’s just something about writing Obj-C code that feels comforting. I certainly wouldn’t use it for a new codebase for a multitude of reasons, but keeping XRG written entirely in Objective-C helps keep me proficient in the language, and also avoids all the headaches of a hybrid Obj-C/Swift codebase. To be honest, as long as Objective-C remains a first class citizen on macOS, I’m not sure I ever will refactor it in Swift.

Most importantly, I can thank XRG for jump-starting my career in Mac and iOS development. If I hadn’t created XRG, I wouldn’t have been introduced to the Indie developer scene that inspired me to create Seasonality. If I hadn’t created Seasonality, it’s very likely I wouldn’t be an iOS developer today. It just boggles my mind to consider what path I’d be on if I hadn’t started working on XRG.

Twenty years later, and it’s still the first app I install on a new Mac. Since I use it all the time, I’ve continued to maintain and improve it when time allows. It has been an amazing ride…here’s to the next decade.

Waiting for Review

May 9, 2015 / mike / 1 Comment

You have no idea how surreal it is for me to see this right now. For non-developers, this is what you see after submitting an application to Apple to review for the App Store. It always feels satisfying to click that final Submit button, but this time is a little more special for me. You see, Seasonality Pro has been the longest project I have ever worked on.

The ideas for Seasonality Pro started spinning in my head before the iPad even came out. In the fall of 2008, I was taking a synoptic meteorology course and thought how cool it would be to have an app that would show model data in a beautiful way that would be easy to use and offer completely customizable maps. Over the following couple of years, iPhones got faster, the iPad came out, and the idea of what the app could be solidified in my mind.

But I didn’t work on it… The task was just too large. Where would the data come from? What data formats would I have to parse? Where could I get the necessary custom maps and how do I draw them? How do you draw contours, and shaded layers, and calculate derived layers from several model data fields? How would it perform? There were just too many unknowns; I couldn’t start working on it.

And then I could… Over time enough of the pieces fell into place that I started an Xcode project in September of 2013. A month later, I had my first base map plotted. And the pieces started coming together faster when I started working on it full time in 2014. By the end of the summer, I had a pretty good app going (basic plots, etc), but there were still so many details left to be done. I had to take a few weeks break and spend some time updating my other apps before I could finish up Pro.

A few weeks turned into a few months, but by November 2014 I was back on it. I presented my work at the American Meteorological Society annual meeting in January 2015. The reception was good. It was a relief to finally show it to people who were in the target market and see their eyes light up. The project was even closer to being finished, but I still hadn’t run a beta.

The beta started in late January. Lots of bugs were squashed, and lots of adjustments were made to improve the feel of the app. The beta stretched for months longer than a usual beta. It was a complex app (close to 100,000 lines of code for even this first version), and finishing it felt like a big mountain to climb with the last 20% of the work taking 80% of the time.

So now we’re into May, but it’s done. Seasonality Pro 1.0 has been submitted. A labor of love for so many years, finally being realized. Will I make back the investment put into it? It’s hard to say. A lot of people think it would be crazy to work on an app longer than a few months, not knowing if it was going to make it in the App Store. For me though, these are the types of projects worth working on. Bringing a product like this to market advances the field of meteorology, and it’s not something that just anyone (or any company) can do. With millions of apps on the store, there is nothing else like it.

Here’s hoping for a speedy app review…

10 Years

April 1, 2014 / mike / 2 Comments

Today is the 10th anniversary of Gaucho Software. I registered the domain gauchosoft.com on April 1, 2004 and after moving to Michigan a couple months later, I started building the website and getting to work on product development.

Since then I’ve developed several apps, writing hundreds of thousands of lines of code and creating hundreds of graphics in the process. I can’t begin to count how many press releases I’ve sent out. And I’m proud to say Gaucho Software has participated in a number of fundraising efforts for worthy causes, from supporting the recovery after Hurricane Katrina and the earthquake in Haiti, to raising money to bring clean water to developing countries.

It’s hard to believe it’s been so long. Thinking back, my first development box was the then-brand-new liquid-cooled 2.5Ghz PowerMac G5. It was running OS X 10.3 Panther, and Xcode had just come out (previously it was called Project Builder, which I used to develop the first versions of XRG back in 2002). I suppose this is telling of the time that has passed.

I wanted to thank everyone who has supported Gaucho Software. Thanks to the companies who have trusted me with their contract work. A big thanks to everyone who has purchased my apps. And a very special thanks to my wife, Katrina, and the rest of my family for their endless help and support.

Here’s to the next 10…

GSGradientEditor

January 17, 2014 / mike / 0 Comments

A fairly significant feature in Seasonality Pro is the ability to edit the gradients used to show weather data on a map. When looking around for some sample open source gradient editors online, I didn’t come across anything I could really use. So I decided to write my own and offer it under an MIT license. I posted the source code (link below) on GitHub. Here’s what it looks like:

I’ve included a lot of documentation as well as a sample Xcode project to show how to use it over on the GitHub page:

GSGradientEditor on GitHub

I looked at quite a few different graphics apps when working on the UI. I wanted to see not only how other implementations looked, but how they worked. With iOS 7 being more gesture-centric, I wanted to make sure that interaction with GSGradientEditor was intuitive. I found the Inkpad app most helpful during this process. In the end, I like how GSGradientEditor turned out.

Enjoy!

GSShapefile

October 30, 2013 / mike / 0 Comments

It’s been awhile since I’ve open sourced any code (cough…XRG…cough) and I thought it was about time to contribute something new.

This code is a small collection of classes that will parse ESRI Shapefiles. As I’m getting further into the development of Seasonality Pro (which you can follow at the new Seasonality: Behind the Scenes blog), I thought it would be important to be able to show Shapefile data on a map. There are a few basic implementations out there (see iOS-Shapefile and Cocoa Shapefile), but I wanted a more modern code design, and something that was flexible enough to add expanded support in the future. So I dug up the Shapefile spec and got started.

The result after hacking on it for a few days is GSShapefile. It should work on both the Mac and iOS platforms, as long as you have ARC enabled in your project. GSShapefile takes an NSData object as its input, so it doesn’t make any assumption of whether the data is coming from a local file or somewhere online. After the file is parsed, you can retrieve the shape records and points associated with each shape. It really should be pretty easy to integrate with your own code.

I hope somebody finds it helpful.

Seasonality Updates

October 9, 2013 / mike / 0 Comments

I thought now might be a good time to post an update about how development is progressing in the family of Seasonality apps.

Seasonality Core

Seasonality Core 2.4 is going to be released sometime in the next week. This update has some nice improvements. One is an update to Particle Mode that makes it look much more impressive. It’s the same feature showing the same data, but in a cooler way. The mapping code is also gaining other improvements like allowing wrap-around at +/- 180° (New Zealand users rejoice!). The graphs aren’t being ignored, with a new hover bubble layout to make it easier to inspect the data. The hover bubble will also expand when you hold down the Option key on your keyboard and show all the conditions at the hovered time. It’s a really nice way to look at what’s happening at a certain time.

As far as future plans for Seasonality Core. The next major update will most likely be Seasonality Core 3.0. It’s too early to discuss features, but there are a couple of areas that I think need improvement. One is increasing the number of supported locations and making locations easier to search and configure. This is a lot of work, that requires server-side changes as well, so it’s hard to say when this will be ready. The second change I would like to make to Seasonality Core is to bring back some of the customizability from Seasonality Go. With Seasonality Go, it’s great how you can customize your own screen layouts. I would love for Seasonality Core to be able to do this as well.

Seasonality Go

Seasonality Go 2.2 was just released last month. We worked on the user interface a lot to start the transition to iOS 7, and I think it looks a lot nicer now. Another big new feature was the ability to select a color theme. Just head into the Tools (wrench) menu under Settings to choose a color that looks best to you. Beyond these visual changes, lots of optimizations were made to the code behind the scenes. The app runs a lot more smoothly now, especially when switching screens or switching between Seasonality Go and other apps.

The next major update to Seasonality Go will most likely have the same location changes I discussed above in Seasonality Core. I’m also planning to continue improving the interface to show less clutter and more weather. This will bring back some of the look and feel improvements I’ve been working on in Seasonality Pro.

Seasonality Pro

Seasonality Pro will be an iPad weather app for professional meteorologists. I’ve had the project on my mind for several years now, and over the past several months I’m finally finding more time to work on it.

I have been receiving a lot of questions about how Seasonality Pro development is progressing. It’s certainly taken me longer to complete than I was originally expecting. During the past several months I have been splitting my time a lot between Seasonality Core, Seasonality Go, and Seasonality Pro. There are quite a few features I’ve added to Seasonality Core and Seasonality Go recently that provide major underlaying functionality that will be used in Seasonality Pro. It has been a good way of making progress on Pro, while still providing updates to the other apps. Now that a lot of the foundation code is ready for Seasonality Pro, I’ve recently starting to switch gears. Instead of working on Seasonality Pro indirectly through features added to the other apps, I am now spending a lot more time directly working on the interface and layout of Seasonality Pro. Version 1.0 is still a ways off, but it’s looking good so far and solid progress is being made.

As always, if you would like to provide feedback about any of the Seasonality apps, please send me an email. There are email links in the Help menus in both Seasonality Core and Seasonality Go.

Overhead while using GCD

November 21, 2012 / mike / 0 Comments

Today I spent some time optimizing the Particle Mode simulation code in Seasonality Core. While doing some measurements, I discovered that quite a bit of time was spent in GCD code while starting new tasks. I use dispatch_apply to iterate through the particles and run the position and color calculations for the next frame. In the tests below, I was simulating approximately 200,000 particles on the Macs, and 11,000 particles on the iPad.

I decided to try breaking the tasks up into fewer blocks, and run the dispatch_apply for groups of around 50 particles instead of running it for each particle. After making this change, the simulation ran in up to 59% less CPU time than before. Here are some informal numbers, just by looking at Activity Monitor and roughly estimating:

	CPU Usage
Device	Before	After	Time Savings
Mac Pro (2009, Oct 2.26Ghz Xeon)	390%	160%	59%
Retina MBP (2012, Quad 2.6Ghz i7)	110%	90%	18%
MacBook Air (2011, Duo 1.8Ghz i7)	130%	110%	15%

iPad 3 (fewer particles)	85%	85%	0%

As you can see, the benefits from the new code running on the Mac Pro are substantial. In my earlier code, I was somewhat suspicious of why the simulation took so many more resources on the Mac Pro than on the laptops. Clearly the overhead in thread creation was a lot higher on the older Xeon CPU. This brings the Mac Pro’s processing times closer to what the other more modern processors can accomplish.

Perhaps an even more surprising result is the lack of a speedup on the iPad. While measuring both runs, the two versions averaged about the same usage. Perhaps if I had a more formal way to measure the processing time, a small difference might become apparent, but overall the difference was minimal. I’m guessing that Apple has built logic into the A-series CPUs that allows for a near 0 cost in context switching. Makes you wonder how much quicker something like this would run if Apple built their own desktop-class CPUs.

Using IOKit to Detect Graphics Hardware

October 21, 2011 / mike / 6 Comments

After Seasonality Core 2 was released a couple of weeks ago, I received email from a few users reporting problems they were experiencing with the app. The common thread in all the problems was having a single graphics card (in this case, it was the nVidia 7300). When the application launched, there would be several graphics artifacts in the map view (which is now written in OpenGL), and even outside the Seasonality Core window. It really sounded like I was trying to use OpenGL to do something that wasn’t compatible with the nVidia 7300.

I’m still in the process of working around the problem, but I wanted to make sure that any work-around would not affect the other 99% of my users who don’t have this graphics card. So I set out to try and find a method of detecting which graphics cards are installed in a user’s Mac. You can use the system_profiler terminal command to do this:

system_profiler SPDisplaysDataType

But running an external process from within the app is slow, and it can be difficult to parse the data reliably. Plus, if the system_profiler command goes away, the application code won’t work. I continued looking…

Eventually, I found that I might be able to get this information from IOKit. If you run the command ioreg -l, you’ll get a lengthy tree of hardware present in your Mac. I’ve used IOKit in my code before, so I figured I would try to do that again. Here is the solution I came up with:

// Check the PCI devices for video cards. 
CFMutableDictionaryRef match_dictionary = IOServiceMatching("IOPCIDevice");

// Create a iterator to go through the found devices.
io_iterator_t entry_iterator;
if (IOServiceGetMatchingServices(kIOMasterPortDefault, 
                                 match_dictionary, 
                                 &entry_iterator) == kIOReturnSuccess) 
{
  // Actually iterate through the found devices.
  io_registry_entry_t serviceObject;
  while ((serviceObject = IOIteratorNext(entry_iterator))) {
    // Put this services object into a dictionary object.
    CFMutableDictionaryRef serviceDictionary;
    if (IORegistryEntryCreateCFProperties(serviceObject, 
                                          &serviceDictionary, 
                                          kCFAllocatorDefault, 
                                          kNilOptions) != kIOReturnSuccess) 
    {
      // Failed to create a service dictionary, release and go on.
      IOObjectRelease(serviceObject);
      continue;
    }
				    // If this is a GPU listing, it will have a "model" key
    // that points to a CFDataRef.
    const void *model = CFDictionaryGetValue(serviceDictionary, @"model");
    if (model != nil) {
      if (CFGetTypeID(model) == CFDataGetTypeID()) {
        // Create a string from the CFDataRef.
        NSString *s = [[NSString alloc] initWithData:(NSData *)model 
                                            encoding:NSASCIIStringEncoding];
        NSLog(@"Found GPU: %@", s);
        [s release];
      }
    }
		    // Release the dictionary created by IORegistryEntryCreateCFProperties.
    CFRelease(serviceDictionary);

    // Release the serviceObject returned by IOIteratorNext.
    IOObjectRelease(serviceObject);
  }

  // Release the entry_iterator created by IOServiceGetMatchingServices.
  IOObjectRelease(entry_iterator);
}

Creating Seasonality Map Tiles

June 2, 2011 / mike / 0 Comments

In a weather app, maps are important. So important, that as a developer of weather apps, I’ve learned far more than I ever care to know about topography. When I originally created the maps for Seasonality, I had to balance download size with resolution. If I bumped up the resolution too far, then the download size would be too big for users on slower internet connections. If I used too low of a resolution, the maps would look crappy. I ended up settling on 21600×10800 pixel terrain map, which after decent image compression resulted in Seasonality being a 16-17 MB download. At the time, most apps were around 5 MB or less, so Seasonality was definitely a more substantial download.

That compromise was pretty good back in 2005, but now that a half-decade has passed it is time to revisit the terrain I am including in the app. Creating a whole new terrain image set is a whole lot of work though, so I thought I would share what goes into the process here.

First, you have to find a good source of map data. For Seasonality, I’ve always liked the natural terrain look. The NASA Blue Marble imagery is beautiful, and free to use commercially, so that was an easy decision. For the original imagery I used the first generation Blue Marble imagery. Now I am using the Blue Marble Next Generation for even higher resolution.

Next you have to decide how you are going to tile the image. I’ve chosen a pretty simple tiling method, where individual tiles are 512×512 pixels, and zoom levels change by a power of 2. Square tiles are best for OpenGL rendering, and while a larger (1024, or even 2048 pixel) tile would work, 512×512 pixel tiles are faster to load into memory and if downloading over the network it will transfer faster as well. From there, you have to figure out how many tiles will be at each zoom level. I’ve chosen to use a 4×2 tile grid as a base, so the smallest image of the entire globe will be 2048 x 1024 pixels and made up of 8 tiles. As the user zooms in further, they will hit 4096×2048, 8192×4096, 16384×8192 pixel zoom levels and so on. I’ve decided to provide terrain all the way up to 65536×32768 pixels.

Now that you have an idea of what tiles need to be provided, you need to actually create the images. This is the most time consuming part of the process. Things to consider include the image format and compression amounts to use on all the tiles, and these are dependent on the type of display you are trying to generate. Creating all the tiles manually would take forever, so it’s best to automate this process.

The Blue Marble imagery comes in 8 tiles of 21600×21600 each (the full set of images for every month of the year is around 25 GB). I start by creating the biggest tile zoom level and moving down from there. For my 65536×32768 zoom level, I’ll resize each of the 8 tiles into 16384×16384 pixel images. I use a simple Automator action in Mac OS X to do this. I created an action that takes the selected files in the Finder and creates copies of the images and resizes the copies to the specified resolution.

Now that I have 8 tiles at the correct resolution, I need to create the 512×512 tiles for the final product. For Seasonality, I also need to draw all the country/state borders at this point, because otherwise the maps are blank. I created a custom Cocoa app that will read in a map image with specified latitude/longitude ranges, draw the boundaries, and write out the tiled images to a folder. My app has the restriction of only handling a single image at a time, I’ll have to drag each of the 8 tiles in separately for each zoom level. It’s not ideal, but I don’t do this too often either. For the 65536×32768 zoom level, I end up with 8192 individual tile images. Smaller zoom levels result in far fewer tiles, but you can see why automation is helpful here.

It’s a lot of work, but in the end the results are great. For Seasonality, along with higher resolution terrain, I’m also bringing in the Blue Marble’s monthly images. If everything goes as planned, Seasonality will show the “average” terrain for every month of the year. Users will be able to see the foliage change as well as the snow line move throughout the seasons.

Packing in the inodes

April 13, 2011 / mike / 0 Comments

The new forecast server I’m working on for Seasonality users is using the filesystem heirarchy as a form of database instead of PostgreSQL. This will slow down the forecast generation code a bit, because I’m writing a ton of small files instead of letting Postgres optimize disk I/O. However, reading from the database will be lightning fast, because filesystems are very efficient at traversing directory structures.

The problem I ran into was that I was quickly hitting the maximum number of files on the filesystem. The database I’m working on creates millions of files to store its data in, and I was quickly running out of inodes.

Earlier today I installed a fresh copy of Ubuntu on a virtual machine where the final forecast server will reside. Of course I forgot to increase the number of inodes before installing the OS on the new partition. Unfortunately, there is no way to add more inodes to a Linux ext4 filesystem without reformatting the volume. Luckily I caught the problem pretty early and didn’t get too far into the system setup.

To fix the issue, I booted off the Ubuntu install ISO again and chose the repair boot option. Then I had it start a console without selecting a root partition (if you select a root partition, it will mount the partition and when I tried to unmount it, the partition was in use). This let me format the partition with an increased number of inodes using the -N flag in mkfs:

mkfs.ext4 -N 100000000 /dev/sda1

That ought to be enough. 🙂 After that, I was able to install Ubuntu on the new partition (just making sure not to select to format that same partition again, wiping out your super-inode format).

The forecast server is coming along quite well. I’m hoping to post more about how it all works in the near future.