21. April 2006 20:43
The compact framework team has released a beta version of Service Pack 1 for the compact framework version 2. You can download the packages here: http://www.microsoft.com/downloads/thankyou.aspx?familyId=6548dd53-a418-42d9-a481-19ba3ceca1a6&displayLang=en&oRef=http%3a%2f%2fblogs.msdn.com%2fnetcfteam%2f. You can read the details here http://blogs.msdn.com/netcfteam/archive/2006/04/21/580901.aspx ; one of the highly anticipated features of this release is the ability to run CF2 applications on CE.net 4.2. I have one client who has been waiting on this feature for a long time due to a hardware investment that won't allow their converting to CE 5.
The package contains a Visual Studio patch as well as the standard device updater application.
17. April 2006 01:04
I just ordered a desk ( see here
) for the research lab in the new house. I am very much looking forward to doing some research projects and finishing some toy projects. It seems that I am very close to being utterly caught up with all of my side business clients, in which case I can move back to doing things for fun. I feel like I have been sorely neglecting the research and growth side of my career in favor of making $$ and maintaining the status quo. This is no good. It is whoring, not geeking, when every time you turn on a computer the billable rate is ticking.
14. April 2006 02:46
I am finally writing a post from my new house. My furniture is not here yet but I did have the foresight to take care of important things like making sure cable internet was h00x0r3d up. I had to hang out with the city inspectors for a while to get occupancy for this weekend but here I am. Over the next week I will be setting up my lab. One's environment has a large effect on the work one does and general effectiveness and frame of mind. I hope to be able to leverage this to produce a couple of cool research projects this year.
6. April 2006 02:56
RDA, sometimes so good, sometimes so bad. I post about data synchronization to mobile systems a lot because its one of those interesting problems to me. There are many ways to do it, Merge Replication is one. Merg Rep comes with so many drawbacks I could write a decent sized essay about it. For now I'll just say that if you are considering merge replication you should try to talk to someone with experience implementing it and make sure you want to go down that path. Synchronizing a read-only database is easy with merg rep or without using custom code. Synchronizing a read-write database with custom code is a non-trivial endeavor.
Having written and re-written such things several times I have tried various methods. After my first attempts at remote rebuilding a 100 meg database on a 200mhz strong arm over the internet using web services I decided that RDA needs to be a part of any solution. RDA allows one to pull down SQL Sever data in a nice binary format that automagically turns into an SQLCE table schema and table data as it streams down to a mobile device. You can push SQL data using RDA as well, but I don't like doing so for various reasons. Since RDA is streaming data over HTTP it also gets you around some ugly memory issues. Consider your woe when your XML message containing 10,000 rows of data is easily spit out by your server but runs the mobile systems out of memory every time. Segmenting large messages using many XML calls quite frankly feels dirty as well. As far as rebuilding that 100meg database over the internet, RDA is great.
On my current project we do frequent data synchronization over an AirLink modem. These things are truly great but they have data rates that are woefully slow in a world that has become accustomed to cable modems and burstable ethernet. We were having situations where in-office testing would have a sync time of say a minute and a half for a good amount of data. However in the field some locations were so bad (-110 db signal strength or worse) that this same data packet was taking 20 minutes to process. This is unacceptable. Since I happen to have a method to FTP the handheld log files to myself I started doing some log file forensics.
In addition to low data rate, these CDMA modems have high latency, 500ms ping and such. Every additional trip to the server was incurring large overhead in just making the request. My data sync that was making an RDA.Pull("select blah blah from blah blah where DateLastChanged > myLastSync") for each table that was fine in our office (where the connection SUCKS butt apparently not as suck as some of our remote locations) but not fine over a low data rate, high latency, in-a-black-hole parking lot where our trucks must operate. In testing with the SQL server DBA we have noticed an inexplicable overhead for each RDA operation that is about six seconds over a good connection and skyrockets exponentially on a bad one. While we work out issues with other modem providers (Sprint, Verizon, and Cingular are the big players, Sprint is currently working but connectivity sucks in many areas) a solution was needed. In the process of making my remote operationgs more "transactional" (after studying F# and what it's all about a tiny bit I dislike the common usage of the term idempotent, which I will explain in a future post) I ended up building multiple code paths for the data sync based on how much data was to be exchanged. A full rebuild or "very large messages" will still use RDA and execute one pull per table, but in many cases the data package can be sent and received as one large XML message. I had avoided this approach as long as possible due to the bloat of encoding everything as XML and the potential for memory problems on the clients. I've found that an "average" XML message is about 179kb which makes me nervous given the CF 1.0 max stack size of 640k and my assumption that the webservice client must load the entire message into memory before it can deserialize it. If this does become an issue I will do some column mapping such that <FuelDeliveryTransaction><FuelDeliveryTransactionId>12345</FuelDeliveryTransactionId><TotalPricePerGallon>$2.78</TotalPricePerGallon></FuelDeliveryTransaction> in a message becomes <FuelDeliveryTransaction><0>12345</0><1>$2.78</1></FuelDeliveryTransaction> and thereby saves many bytes of data over hundreds or thousands of rows.
I would say "Bring on the high speed wireless connection to every corner of the globe", but Johnny Mneumonic had a traumatizing effect on me.
2. April 2006 20:20
I will follow up on my solution for the "transaction" post later, however with that problem solved I have a more immediate need: I'm looking for a free Code Coverage tool for .NET. I found a lot of blog posts pointing to CoverageEye but I wanted to know if anyone is using anything else and having good experiences?