MesoSynoptic Blog

Things are slowly coming along, and I’m getting really close to the point where I have the alert parsing and notification system ready for a stress test.

The stress test is necessary for me to get an idea of how my server needs are going to scale with increased user demand. In addition, it will be an opportunity for me to make sure the notification system is working correctly. Even a few extra devices will allow me to get an idea of scaling and to plan more carefully for server needs.

I have a few more things to finish up first (getting a few more alert types into the parser engine, a few more request types into the servlet engine, building a UI to display the alert text, and reimplementing the last two or three things that were already implemented with the “legacy” protocol). My guess is that iPhone OS 3.1 will be released before this work is finished, which will make life easier for the purposes of this test.

If you’re interested in helping me out with this, here’s what I need from you:

• First, you must have an iPhone or iPod touch running iPhone OS 3.0 or later
• Also, I’m probably not going to just take random people for this… if I don’t have some sort of connection with you, either personally or through a friend, I’m probably going to decline your assistance
• Contact me (in a PRIVATE matter!–either e-mail, Facebook message, or Twitter private message) with your device’s unique ID and an e-mail address where I can send you the provisioning profile and a link
• Once you’ve received the software, drag the provisioning profile and application on to your device in iTunes and launch. From that point, all you need to do is add some locations and let the alert system do its work.
• Let me know of any bugs you experience during use of the software (crashing, expected data not loading, not receiving alerts for a location you’ve registered)
• Also, be aware that this software is very, very, VERY rough around the edges. By participating in this test you understand this and agree that I will not be held responsible if the application manages to crash the OS and take your data out with it. Please BACK UP before installing and frequently during use of the software.

It’s not glorious work, but it is necessary, and should you offer to participate I sincerely appreciate your help.

So, a very necessary part of WeatherMan is having a ZIP code database available that customers can access when trying to add a location to their favorite locations list. The catch is, a lot of these have licenses against content redistribution.

Here’s the catch… is it redistribution if the database stays on the server end? If the iPhone sends a search request to the server and the server returns a result based on that data, is it “redistribution?”

It could mean the difference between a standard $30-or-so database and the $300 redistribution license many of them come with.

Opinions?

I’ve been through a lot of changes lately. In the past couple of months, the studio has changed names not once, but twice. The focus has changed. The knowledge has changed.

I think I’ve finally settled on a name that I can be happy with. One that appeals to my geek senses without being totally generic-sounding or completely out there. I think I can be happy branding my software with the MesoSynoptic label.

StudioMan has been put on indefinite hold. I want to see what Snow Leopard has to bring to the table. I need another fresh start with it, I let it grow too big and unwieldy (yet again) and then ran into an issue I would have to dismantle the whole thing to solve anyway. I still hope to accomplish it someday.

My focus right now is on WeatherMan. I’ve learned a lot working on WeatherMan. I’ve rediscovered why I love Java. I’ve rediscovered why I hate Java. I know more about sockets and TLS and JSON and AWIPS and WMO headers than I ever thought I needed to. Pretty soon I’m going to be learning about KML and shapefiles. It promises to be an interesting journey, hopefully one that is fruitful in the end.

Welcome to MesoSynoptic Studios. Hold onto your hats–it’s going to get a bit windy.

I’m still alive. And so is StudioMan.

It has occured to me that I’ve made a major design mistake and that it’s time to go back to the drawing board, in a sense. I made the wonderful source list view, and only planned on it being on the roster page. As I was sitting here, trying to design the UI for the schedule view, it hit me. Yes, the schedule view will have a big weekly iCal-like calendar. But I also wanted it to have a student-by-student interface. What I need to do is take the pieces apart and put them back together in such a way that the same source list view is the master- part of the master-detail interface for both the roster and schedule interfaces.

I’m trying to decide when this will happen. I’d love it to happen in Milestone 4, but it isn’t necessarily tied to that. I think I’ll definitely do it though, to get it out of the way before things get any more complex. I’m already getting to the point where I’m having trouble wrapping my head around everything that needs to happen. This change should simply things a bit.

Perhaps I’ll publish a milestone 3.5 with this change.

Hard at work on Milestone 4. For the attention-span challenged, the goal of milestone 4 is to deliver the calendar view. This view has a dual purpose — to allow for entry, editing, and viewing of personnel availability in the Roster view, and to display the instructor’s actual schedule in an iCal-esque format in the Schedule view. It needs to be reusable, as it will be used on both of those views as well as the instructor panel. I may try to package it up into its own little framework complete with Interface Builder plug-in later on, but that’s not for now.

Right now it is drawing the grid and labeling the days and times… looking pretty slick if I do say so myself. In fact, it’s looking slick enough that it may be time for the first full-window screenshot…

StudioMan M4 progress

I decided to take a break from StudioMan today and work on WeatherMan a bit. The new beta of the iPhone 3.0 SDK added some functionality to the Maps API which I was able to play around with today. There are some features that aren’t quite there yet that I hope make the cut, but I can’t really speculate or say anything about it that’s not already public information… gotta love those NDAs.

As far as the back-end goes, I’m trying to decide how I want to handle things. I’m going to need to need to learn how to write a daemon and decide how I want to host it–unfortunately I can’t run them on Dreamhost without paying a minimum of $15/month for their virtual private server service, and I don’t have a static IP with Cox (plus they also ban servers, although this hardly qualifies as a “server;” all it is going to do is listen to the NWS data stream and pick out the watches/warnings, and then send out notifications). I’ll need an SSL certificate, so however I program it will need to be able to handle those–ideally I’d like to do it through Cocoa but I just don’t think that’s going to be possible without having an OS X colo or something of that nature. Right now I’d have to sell 403 copies at $.99 apiece or 201 at $1.99 just to cover the absolutely unavoidable costs of providing the service if I use the Dreamhost option; and that’s not including taxes and anything unexpected that may pop up (or the need to purchase more than the minimum resources for the service… again something I don’t think will be necessary just because the nature of what the backend is doing means that the need for resources isn’t increased much per user).

I’ll need to sit and think about it and experiment some more. I have an old PowerMac G3 that I haven’t plugged in in awhile that may work as a testing backend. and maybe give me an idea of what kind of resources I’ll need depending on which method I choose. I can’t wait until this NDA is lifted and I can show everybody how the front-end is progressing.

Milestone 3 is complete and has been uploaded to Subversion.

Milestone 4 will be the calendar view.

Perhaps I should have switched the order like I was originally thinking of? I was planning on milestone 3 not being so intensive… that worked out well.

Still working on a bug tracker… each one that I’ve tried has a deal-breaker, so I’m still looking for a solution. If you are enterprising enough to download, test, and find a bug, just post a comment here.

And for the record… this is not an April Fools joke.

My edit from the last post hit the nail on the head.

From the developer docs:

When Core Data faults in an object, key-value observing (KVO) change notifications (see Key-Value Observing Programming Guide) are sent for the object’s properties. If you are observing properties of an object that is turned into a fault and the fault is subsequently realized, you therefore receive change notifications for properties whose values have not in fact changed.

Now that I know where the problem lies, I need to figure out how to get around it. Once again non-readers, thanks for being my virtual scratch pad.

edit://Bug fixed. I’m currently in the process of poring over the exceptionally large amount of new code I wrote for this milestone and documenting/cleaning it up, then Milestone 3 will be live. Man it felt good to solve this one.

OK, this bug is killing me.

It’s actually two. The first is that when I have the tree controller rearrange the objects to put them back in alphabetical order it loses the current selection. That’s no big deal.

The other bug is more annoying. For some reason when a person is selected FOR THE FIRST TIME ONLY in the source list, it seems to go back and make a change to the managed object that’s selected, throwing the source list and the bound fields for a loop. This only happens the first time the object is selected.

If you want to take a look, revision 60 is in SVN with this bug. Warning: the documentation is pretty poor, I’ve gotten a bit lax with that since this milestone ended up being so involved. I plan to go back through and make sure everything is properly documented before I post the final milestone.

edit:// is it possible that this could be due to the relationships faulting and the faults being fulfilled? Is there any way to check for that?

OK, so that one bug that I was working on? I fixed it and sprouted about three other bugs.

I’m going to keep working on it today, but if I can’t get it fixed here shortly I’m just going to revert the change and post Milestone 3 with the original bug in place.

Sometime after I had started this project BWToolkit was updated to version 1.1. I’d like to upgrade in the project, but I don’t know if I can deal with anything else breaking right now.