I finally have my busted laptop back. I paved it and was in the process of reinstalling the important stuff when the storm hit. Since I’ll be moving back to that machine very soon, I figured I could break quarantine on the machine I’m currently using. Since the one thing you can’t run in Virtual PC is the embedded device emulator, I decided to install Windows CE. I stumbled across this article for DIY Wireless Access Points (from Wireless Hacks) which pointed me to a couple of embedded system vendors – Soekris and OpenBrick. I’d love to get CE up and running on one of those boxes and roll my own media client device, to learn about hacking embedded if for no other reason. I know Duncan has a cool homegrown audio PC project, but I was thinking something embedded would be even cooler.

There doesn’t seem to be much, if any, grass-roots community around building CE based devices. All the efforts on the embedded website seem to be geared towards large companies. For example, the US distributors of CE don’t list prices on their pages. I can only assume it’s a case of “if you have to ask, you can’t afford it”, at least for the individual developer. CE is not included in MSDN (though it used to be if memory serves). I can only find info on homebrew embedded hardware on Linux sites.

Where are there any other DIY or homebrew embedded sites that I don’t know about?

My team owns the architect track for TechEd 2004. We’re hoping to build on the very successful Architecture Symposium from PDC. As part of that effort, I own that community efforts for the architect track. I’m working on the plan now. Obviously, we’ll have “the usual” events: Ask the Experts, Birds of a Feather, Speaker Lounge, Attendee Party, etc. Any other suggestions? Please email me or leave a comment.

First Simon, then Ram, now another member of the .NET Enterprise Architecture Team is blogging. David Hill just started, but he’s already posted an article entitled “A Simplified Asynchronous Call Pattern for WinForm Applications“. In the article, David describes “how you can implement a simpler asynchronous call pattern which allows you to consume web services from a WinForm application without having to worry about threads ever again.” Cool!

I realized I wasn’t going into the office today @ 6am. My wife’s school called to let us know school was canceled. Given how hard it has been to get my email all day, I’m guessing I’m not the only one. Since I’m not at work or doing email, I figured I’d mess around with my new Longhorn machine.

I noticed browsing through the samples that Longhorn has a managed P2P API. The PDC build only supports PNRP and identities, which means you can’t acually communicate with another machine via P2P (yet), but it’s nice to see that it exists.

Christmas was crazy (my wife’s blog has the details), so I didn’t get a chance to blog about Sean & Scott’s desire for unification of objects and data, Erik Meijer’stwopapers on the topic, or Dare’s responses to both. Programming language evolution is something I’ve keenly interested in. When I first started this blog almost a year ago, one of my early posts was about a disruptive programming language technologies presentation from MS Research. Among the areas mentioned for improvement: were database integration and XML manipulation. Sounds like the Xen language demoed @ XML 2003 is a step in that direction.

When you read Erik’s papers, you’ll notice that one of the goals is to natively integrate XML into the language. He writes: “In our approach XML documents or document fragments become first class citizens.” What’s interesting about that is that if you take XML to mean pure-infoset-data (as opposed to angle-bracket-serialization-format) then you can argue that Data (with a capital D) is not a first class citizen of today’s Object-Oriented languages. Given that a lot of OO code has been written to manipulate data, having a language that explicitly distinguished between the two could be valuable (assuming it made the programming easier and the programmer more productive).

Note, this is the opposite approach from tools like O/R mappers and XSD.exe which attempt to hide the differences from the programmer. We’ve seen a similar evolution in the way we think about invoking objects across the network. Tools like DCOM and .NET Remoting attempt to hide the RPC and make it appear as a local call. But as the thinking evolves, tools like Indigo is designed to make the boundaries across apps and machines explicit. Initial thoughts on data access were to make it all look like objects (i.e. O/R mapping). But as the thinking evolves, maybe we need to make the boundaries between objects and data explicit (and easy) as well.