Jun 29
I’m not particularly happy with the direction the iPhone is going in… so I’m taking a break from WeatherMan.
In it’s place, I’m working on a fun project that I’ve been doing on-and-off called CoCoNES. If you guessed that this is an NES emulator written using Cocoa, you deserve a banana or something. I decided not to quite go whole-hog though… my original thought was to really try and keep things strictly Cocoa, which would have meant the opcode dispatch table would have been an NSArray of NSValues containing selectors for the methods. However, from a processor time standpoint, this is a horrible, horrible idea. Pulling up an object from an NSArray is more expensive than a standard C array, then I have to get the scalar value out of the NSValue object, then send the message to that selector… yeah, you get the point.
Instead, for the actual CPU emulator, I have a nice, elegant, FAST system set up. The opcode is an 8-bit unsigned integer. So, when we read the next byte with the opcode, we plug that into an array (opcodes[read_opcode]) of pointers to functions for each opcode. One step. From a computer time standpoint, this is probably 10x cheaper than sticking with Cocoa. Do modern computers need that time for a NES emulator anymore? I don’t know. I will find out though when I get to speed control.
This is going to be a really good learning experience–I get to learn the ins and outs of NES hardware; I get to learn CoreAudio for creating the audio, and (probably) OpenGL for the video, and Grand Central Dispatch for parallelism; my plan is to have the main thread basically just sending out ticks to the other objects (CPU, PPU, any other chips) which process on their own threads, and then when they’re done wait for the preappointed time (or if that time is past, start the next tick)
In addition, I’m probably going to blow the dust off of StudioMan. That’s one project I would really like to complete, and it shouldn’t be terribly difficult provided I can find the time.
May 19
I’ve been wracking my brain doing research the past several weeks on what the best options will be for me moving forward… I have settled on using PHP for the on-demand portions of the backend. This will offer the most flexibility due to the ubiquitousness of the LAMP stack and the large amount of developer support available for the platform.
I’m still trying to decide which language to use for the service portion of the backend. Simply from the writing-a-daemon perspective, C would be the logical choice. However, a good secure Telnet client library and a good MySQL implementation are already important (yes, I know I could write my own, but I’m a firm believer in not repeating the work somebody else has done unless I can improve on it). Everything else can be tacked on as needed, but at this point the service portion of the backend consists pretty much of something to read the telnet feed, something to get the info into the database, and something to send the push notifications. I am thinking about using GNUStep to kind of keep things on the same wavelength 
.
Apr 13
So, I wrote a decent backend in Java for WeatherMan last year. While the majority of my frontend code can be preserved, the backend is going to need a lot of work, for several reasons:
- There was a nasty infinite loop somewhere in the code that I was unable to nail down the root cause of; some condition in the WeatherWire parser was causing the issue
- I need to write a truly secure communications channel between phone and server; location information is stored and transmitted, and I want to make sure that is secure. Last year I was using a hashed and salted device token to authenticate with the server. However, the communications channel itself was unencrypted, and this required that the device send a token received from the APNS server, which is something I’d like to avoid doing.
- The backend was never really set up as a daemon; start/stop was manual and there was no external control.
Because of the significant rewrites required, I’m probably going to end up breaking the whole thing down, reusing the code that works, but rethinking the architecture. This got me thinking–is Java really the best language to use for this?
Here is what the backend must do:
- Keep a consistent connection via telnet to the WeatherWire server to pull down weather alerts
- Parse the data coming into the telnet connection to decide what is an alert and what isn’t, and to break the alert down into an object that can be stored in the database
- Keep records of all devices using the software and the locations they have requested to receive alerts for
- Each time an alert comes in, find the location of that alert, match it to the device database, and send an APNS notification to each device that wants to receive alerts for that location
- Connect to the NWS FTP servers to download data on-demand
- Act as a cache for on-demand information (forecasts, radar images) to reduce loads on the NWS servers
- Insert and retrieve all of this data from a MySQL database
- Expose an HTTP server over an SSL/TLS connection that will take POST requests for data and return JSON datasets (there shouldn’t be any actual binary data required, as even the radar imagery will be in a KML format that is parsed on the device)
So basically, whatever language is used needs to have good networking libraries and good text/string processing capabilities, and needs to be fast enough to process the WeatherWire data in realtime (there can be quite a bit of it). Also, the backend must be able to run on a Linux server, which immediately counts out Objective-C/Cocoa and .NET for the backend. Here is the list of languages that I’m considering, and what I feel the pros and cons are. Any comments would be appreciated.
- Java. Via the String class, Java has strong enough text-processing capability to meet my needs. Also, it has a large amount of open-source libraries available; I made extensive use of the Apache Commons libraries in the original version to implement telnet and FTP connections, and used the embeddable Jetty webserver to have a lightweight HTTP server to handle the JSON requests. Plus, while the JVM isn’t as fast as native code, it is generally going to be faster than an interpreter.
- C/C++. C is a little lower-level than I’d like to use for this application; being able to take advantage of class libraries that will handle the finer points of network connections and string processing is something I would miss dearly. This option would definitely win on speed, however the learning curve and heightened security risks make me wary.
- PHP. PHP would be the clear winner (at least in my experience) for the text processing and HTTP responses. However, the interpreted nature could cause slowdowns, and while I’ve seen a lot more non-Web platform PHP use recently, I’m not sure if the tools are all there (anybody ever seen a Telnet library written in PHP?). Plus, can it be easily daemonized?
- Python. I have no experience with Python, but I do know it has a fairly extensive standard library and a lot of developer support. The interpreted nature and potential difficulty daemonizing are a couple of potential pitfalls.
- Ruby. Another language with fairly extensive developer support that I do not have any experience with. Again with the interpreted nature and daemonization, though based on the Rails framework I could see some ease with the server portions of this.
- Go. Google’s Go intrigues me as a language. It seems to me that it would offer a lot of the benefits of C/C++ without a lot of the pitfalls (namely direct memory access). The newness of it is a turn-off though–specifically, there is no native connector for MySQL.
If you have any thoughts or insights I’d love to hear them. I’m up for learning something new if it will meet my needs in a better way than Java currently is.
