Friday (July 4th) was a mixed bag. It was hot during the day, as well as being really humid - so we lurked and watched Buffy for much of the day. Kris' Mom took us out for Mexican early afternoon, and I really enjoyed a Mexican ommlette (it made me very full, too!). Later on, Judy came over and we ate ribs, chicken, coleslaw and beans. The food tasted great, but was really greasy - so I couldn't eat very much, and it repeated for much of the night! Judy was talking a lot about her online gaming/chatting habit; I was overcome by a sense of dread as she started talking about how someone else she new could "make emotes in chat". Poor Kris was bristling, ready for the strike even more than I was. Finally, she asks "can you emote?" Ignoring the temptation to demonstate how bad I am at drama emoting (although my face is stretchy!), I tried to narrow the scope. Eventually, it turns out that in Yahoo! chat there is a method of emoting (that is, producing text along the lines of "Herbert strangles the stupid end user"), but it confuses Judy. Judy complained that when she examined it it was all gobbledegook, with thinks like "left bracket font right bracket some text left bracket" - stuff, and I quote, that nobody can read. (I write this in raw HTML, for the record!) :-)
Anyway, our brush with end users and an overdose of food hadn't left Kris or I in the greatest of moods. After more Buffy (waiting for darkness), we headed out to Rittle Bridge to set off fireworks. Kris's Mom brought along a lawn chair, and things should have been great... in fact, they started out pretty well, with lots of neat explosions, pretty lights and similar. Unfortunately, people started showing up - first a Sheriff (who was really nice!), and then some people making drug deals. Not good! We headed for the hills - and ended up in Walmart. As Kris pointed out in her blog, long periods of time in Wal-Mart are bad for me. General Waynesville-inspired-twitchiness, repeating food, horrid Wal-Mart light and an alarm that kept going off had me pretty close to the end of my tether. Nobody died, but I'm sure that I wasn't great company. :-(
After Wal-Mart, we went home, and went to bed. I slept surprisingly well until about 8am, at which point the dogs made sleep difficult by getting excited about, well anything, really. Not long after we got up, we drove home - a nice, uneventful drive. After that: a nap!
This afternoon, I've been experimenting with some C# programming. My programming has had two focusses: .Net remoting using semi-persistent objects with a PostgreSQL back-end, and creating a Windows Service.
Remoting with PostgreSQL Persistance
I was really torn as to how to approach this, and there isn't as much literature around on the topic as I would have liked. Remoting itself is easy: you build a marshalling object, make it available as a channel (using TCP binary channels, since I don't need webservices) and ensure that any object I send over the wire is easily serializable - about 5 lines of code on the server-side, and 2 (more if you want to tweak options, particularly for performance) on the client. Really, really sweet! The difficulty comes with deciding how to persist data. The options I could see were: (a) simply stream objects to a datastore, (b) write objects that match the back-end with load/store/storenew methods per object, and (c) the Broker/Controller model in which I stream DataSet and similar data types with all logic controlled from a Broker object on the server side. There are advantages/disadvantages to all three. (a) suffers from versioning issues - if the objects change substantially between versions, I have to figure out how to get the data out of the old binary format and into the new one. Ick. Even with XML transforms, that sucks - so i didn't go that route! (c) is what I tried with the last incarnation of the TSG Office Assistant; it works very well, but it is ugly, and I'm not sure I like having to rewrite huge chunks of code when the storage-tier changes. Also, DataSets are heavy, and DataSet updating proved to be less reliable than one would like; so I'm not pursuing (c) this time around. (b) suffers from creating a lot of objects, leading to heap fragmentation - and potentially poor performance under some circumstances. It also lends itself to elegant code; I greatly prefer having classes for each data item derived from an abstract class (forcing me to implement GetID/Store/Load/StoreNew, and adding serialization automagically). This is also the most OOP approach. So far, performance is good, the code is elegant (although I dislike writing all of the INSERT/UPDATE/SELECT queries and parsing necessary!). I'm thinking of adding unit tests into the mix, as opposed to broad testing. More on that in another update, when I've tried it!
Windows Services in C#
I always hated writing services (that is, processes that show up in Admin Tools->Services) in MFC/C++ - it was clunky and horrible! .Net has streamlined this process a lot, although it still isn't as easy as I'd like. The Windows Service Wizard creates the basic structure very nicely, but it completely skips the need for an Installer class - leading to services that work but cannot be installed/used without additional programming. Fortunately, I found some tutorials (via Google) that helped me figure this out. It is also clunky having to install services via the command line, and then attach to them for debugging - but it could be worse. I guess having service installation/uninstallation in the GUI could cause more problems than its worse - getting rid of rogue services in the registry is no fun at all.
On the upside, a windows service makes a great remote channel host - and performance is noticably better than a console based server.
Mood: curious
Music: Incubus Succubus: Goblin Jig
No comments:
Post a Comment