While I was at DevConnections last November, I was introduced to a new class of computing devices, these are called “Ultra Mobile Personal Computers” or UMPC for short.  In my ever humble opinion, these are going to play a huge role in the evolution of the mobile workforce.  Over the New Years weekend, I added to my inventory of computers and purchased a Samsung Q1, although the device came with Windows XP tablet edition on it I was assured by the Employee at an electronics store; whose initials are the same as a type of not very deadly toy gun I had growing up; that all the drivers are available for Vista, I give him about a 50/50 change of being accurate ;)

Currently I’m using an HP TC1100 tablet PC and I just love it, some people like the convertible type of tablets that are both a tablet and a notebook computer, however in most cases when I’m using my notebook, I want a fairly high-end machine and when I want a table I want something really portable to do things like capture notes or manage my emails.  A notebook is just really overkill and too clunky.  My first tablet was a Toshiba convertible, I picked it up the first day a Tablet PC was every made available in a retail store.  I liked it because it had a 14” screen and a keyboard, I guess my experience may have been tainted in that after about the first six months a one inch portion of the screen went dead, but I just never really liked this as a table, the screen was just too big and had to always position it to use it in the best way for taking notes.  In addition even though Beth is still using this today, it just really seemed fragile.

So why am I excited about the UMPC?  Well I guess mainly its size.  I have considerable experience in the mobile space with PDA’s, but depending on the application/usage, a PDA isn't always the best solution for any sophisticated conversation with your computer.  The tablet or I guess the word for what I like is “slate” without a keyboard is a good solution; however in most cases, you don't need all the real-estate and for mobile the smaller the better.  In addition UMPC’s are to have a price point between $400-$700 which really makes them attractive to users that may not want to drop the $1200-$1500 on a slate or convertible.

-ec

Back in Business Again (4 monitor configuration on Vista)

Over the past year, I've really been addicted to using my four monitor configuration within Windows XP.  In October, I made the switch to Vista for my main desktop system and have had a difficulty running in this configuration.  First with a couple of ATI X1300 cards, where when I go into 4 monitor mode, one of the screens was half black half green (with RC2, but not fixed in RTM Vista) Then I purchased a couple of NVidia cards, a 7900GS PCI Express card, and an FX 5200 PCI card, I was able to get these working, however I wasn't able to rotate the screen into portrait mode, which is really almost a requirement unless you want to constantly be tweaking your neck to view all the monitors.  The native drivers for NVidia (at least version 9.6.8.5 dated 10/9/2006) did not support any mechanism for doing rotation so I found this very kewl program called iRotate from an excellent company EnTech Taiwan. The following post describes how to tweak your registry to allow for iRotate to work with the NVidia driver.  They have another very cool program called PowerStrip that allows you to do some pretty amazing things with your video card.

Here's a picture of my development workstation...

The most important part of this setup is just to the left of my keyboard (coffee mug).

I think that 4 monitors is actually an excellent environment for doing development, let me explain my setup

From left to right:
1) 900x1440 Monitor - This is really my system dash board, I run Outlook, keep my IM window open, SysInternals (or I guess Microsoft's) Process Explorer and while really "getting into it" I may start an instance of DebugView or CEDebug view on top of those windows.

2) 900x1440 Monitor - Tool windows for VS.NET, I usually have the following configuration, the screen divided from left to right in about 2/3 on the left and 1/3 on the right, the left side is divided just about in 1/2 with the top having the Output and Error List window, the bottom has properties and a couple of cool VS.NET addins I created using the DevExpress DXCore product (if you have any interest in building add-ins for VS.NET you MUST look at this Free, yes I said Free product, it takes care of all the plumbing so you can focus on your task at hand), one addin allows me to bill time and the other has a bunch of metrics like how much time I've spent on classes, methods, billed against clients as well as the number of builds I've performed.  The right side of the screen has my solution explorer from the top to bottom so I can quickly open files.  In my attempt to free myself from using the mouse, I've started to use hot keys to open files, but the jury is still out on if this is more efficient than just using the mouse.  In addition there is a tab on the right side that allows for access to the Team Foundation Server explorer.

3) 1200x1600 Monitor - This is where the "magic" happens, this is my current port between me and the computer for translating the designs I got from my brain into what ever language I'm using (mostly C#)...still think there is a better way to do this, but that's another post for another day...

4) 1200x1600 Monitor - Work space, this is where I test the application I'm working on, open up IE windows, open up file explorer etc..

The idea with this configuration is really to allow for very efficient context switching, it's much easier to turn my head, then open a window, check it out and get back to my main task

Other "stuff" in the pictures:

I just love my Microsoft Natural Ergonomic Keyboard 4000, it took a little while to get used to but I started without the detachable support on the front that raises the front up about 2" and moved to that after about a week.  I wish it was wireless and had a finger print reader built it, but I've got two of these and feel that I'm at a disadvantage when I can use it.  This is really a good tool to increase the "TX Baud Rate" between the brain and the computer.

I'm impressed with the Logitech mouse line, I had one of the rechargeable ones, but many a time I've been feverously working on a project, the low battery light came on and I didn't have time to recharge before it went dead.  I'm currently using the Logitech MX610 Laser Cordless mouse and like it.  It has a number of feature I don't use, but I like the way if fits in my palm and the battery life is excellent (besides when the battery gets low I just need to grab a couple AA's from my battery drawer and I can continue on with life (instead of get my old corded mouse out while my other one recharges).

PDA Collection

My old workhorse (very powerful processor & lots or memory) the HP iPAQ hx2750

My current phone (jury is still out on this one) the Motorola Q (Smart phone not Pocket PC phone)

And finally my i-mate JasJar, I like this device, in my line of work (not a mobile user) it just isn't a good fit.  I use this for testing VGA resolution applications on mobile devices.

And finally you can see my tablet PC hp TC1100 to the right of the monitors in the first pix, I love this tablet, it's a pure tablet, not a laptop wannabee/tablet wannabee, when I want a laptop, I'm usually using it for something completely different than when I want my tablet.  To my wifes joy, I think I'm going to be upgrading to a UMPC as soon as the right one comes out and she get's the coveted tablet.

- ec

Flexible Systems Integration Architecture

I may have a couple of large projects next year where I need to build up a great deal of functionality that easily needs to be integrated with existing systems.  What we want is some sort of clean very usable portal concept where a user can work with a predefined set of business objects.  The idea here is not to create some sort of "holy-grail" of a development environment where a business analyst can sit down and drag a few objects on to a page and wire them up.  So now that we took the whole "build a system without one line of code" marketing statement out of our vocabulary we can safely say we do need to write code and figure out the best way to do this to:

1. Get a high-level of reuse among different implementations
2. Do programming at the right level to minimize defects tedious coding
3. React to changes very quickly
4. Provide a clear upgrade path
   

First let's define the three aspect that are present in pretty much every system we are going to build, probably in the order of importance and from the most static to the most dynamic:

Data - In each problem domain there are a core set of data that describe the "world" of the domain.  For a sales system, this is going to be something like Customers, Products, Sales People, Sales Orders, Invoices etc...each of these has their unique set of attributes that describe them.  I would venture to say that in most sales system you are going to have at a minimum the above set of objects with probably 85% of the attributes on those objects remaining consistent.  For these type of objects the definition of these attributes probably remains fairly constant with respect to time.  That is to say the description of the objects is probably the most "static" part of your system.  I guess this is pretty much the premise of OO.

Business Rules - Objects by them selves might be interesting however to do anything with them you need to implement some sort of business logic, something like a sales person "CREATES" the order etc...these are really the functional requirements of your system.  In our sales system, although the objects and their attributes are probably about 85% the same across different systems, the actual functional requirements and business rules are probably much less consistent.

User Interface - Well now we have our data in our objects and we have methods so we can make them do something interesting, unless we are building a batch processing system, we need some sort of user interface.  If we look at this in terms of our sales system, there are really three components of our User Interface: 1) Simple CRUD stuff (Create Read Update Delete) 2) The buttons you press to make it do something like create a new order 3) Work flow.  The first two items are really pretty basic, get data from the business object display it on the screen, validate it and dump it back to the biz object as well as react to a button to launch a screen.  The third item is what really differentiates one system from the next, the work flow that's wires up the user interface to the business rules.

Let's talk a little bit about some concepts to solve these problems with a high-level of reuse and integration into back end systems.

Data - As we defined above, we will want to create some sort of rich object model based upon the domains we are building the system for, these should contain the attributes the core attributes that we defined above that are similar between different implementations.  These objects would then in turn be "bound" to the underlying data objects to provide the basic CRUD functionality.  This would either be through the use of implementing interface contracts in a high-level language or creating stored procedures in the underlying database that would bind our objects to the data.  We might implement our Customer object to execute a stored procedure on an Oracle database and return some sort of result set for one implementation and write code to execute a Web Service method call to retrieve the customers attributes in another, either way we let the specific implementation provide the data and bind it to the attributes on the business object.  Our objects would also need to provide some sort of mechanisms return lists and collections that are implemented based upon the data assets within the organization.  The idea here is the business object in our object model provides a well defined set of services to the work flow and user interface layers, but the actual persistence of the data will be implementation specific.

Business Rules - OK now we have a way to load and persists business objects as well as return collections and lists of these.  Now we need to make them do something.  The "do-something" part really comes in two flavors, simple methods we can invoke to set status and send out notifications to more complex work flow with respect to time.  They are tied together, but it may help to think of them separately.  As with our data implementation, our core implementation needs to provide a key set of methods that do certain things, like create a new order, send an email etc...these should be customizable by inheriting form base class and overriding methods.  The next flavor having to do with behavior of the object over time is really considered work flow and this probably the area where now two systems will be a like.  I think the right way to do this is through some sort of Work Flow engine and it just so happens with .NET 3.0 Microsoft released one.  The exciting part of this (at least as far as I understand it so far) we should be able to create our objects that have our properties and methods, but then "wire" them up using XAML to make them behave in a custom way.  This is not say we can build our systems without writing any code, but it does mean we may be able to "wire-up" our apps to get 80% of the way there, and then be very flexible with respect to change over time.

User Interface - I believe that some sort of portal concept is the right way to go here, I'm very intrigued by Share Point Portal Services 7.0 as providing the plumbing to hold everything.  This area probably will require the most customization however this will probably just be starting out with some control templates, dragging a few additional controls on to the template then wiring those controls up to the business objects.  The portal "needs" to be built as a set of building blocks that can be assembled and "connected" at run time.  I think the right way to do this is through the use of Web Parts in ASP.NET 2.0.  In addition, it will be important to create some sort of role based security that controls access to the UI components/data not only to show/hide features and UI components, but also something to secure access to either groups of records or specific records.  It's also important to build and integration story that will leverage any existing credentials that the company may already have.  I would love to see the use of "Card Spaces" for this, but I'm not sure that's all that good of an idea.  This may however be on implementation of our security model.

More to come on this topic...I'm just starting to get my head into these efforts....

- ec

Microsoft Robotics Studio - Very KEWL!

This weekend I'm working at the "beach-house" (well our 28ft travel trailer parked at a campground right one the Gulf at Fort Myers Beach).  Since I've got most of my work deliverables caught up (I hate saying that since I know I'll jinx myself), this weekend I wanted to play a little.  From about 1991 to 1995 my job was to design hardware then write the software that ran on it to make the lights come up in the right order (well maybe make it do a little more than that).  I really loved this but since about 1995, I've been focused mainly on business applications...really a different world.  About once a year I try to spend a few days doing something hardware related so those brain cells don't totally die off.  A few years ago it was hacking an X-Box, then the last couple years it was working on W3, my home-brew robot based upon the BasicStamp chip that contained Sonar, Compass, X-10 Camera and an interface via WiFi on an old iPaq, this was a lot of fun but most of the effort here was actually constructing the hardware and writing the device interfaces.

That brings me to this years effort and MDEC (incredibly good conference) earlier this year I was introduced to the MS Microframework, they had a "Sumobot" competition, unfortunately at the time I was doing the conference in the day and "work-stuff" at night so I didn't get involved.  After browsing the MSDN site last week, I came across the Microsoft Robotics Studio, then saw that it supported the new Lego NXT robotics system...I had to have one of these.  It arrived on my doorstep Thursday and I was set for my weekend in Fort Myers Beach.  I spent Saturday "playing" with lego's and built up the robot you can see between my two monitors.

Next was to get it talking to the computer, this was actually pretty easy since the NXT has built in Bluetooth and the communications "stuff" happened in the plumbing of the MS Robotics Studio.  My prior solution was to hookup an RS232 serial port between my BasicStamp chip to the inputs on an iPAQ, then I used the WiFi card in the sleeve to do some lo-level socket stuff to talk to the desktop app.  This is much cleaner!

So now all the pieces are in place, I've got the robot setup, I've got communications up and running, now it's time to make it do something!  We have three little terriers in our trailer that don't like being left alone.  My goal is to hookup the sound detector on the robot to fire off an SMS message to my cell phone when the dogs start barking (so we don't get kicked out of anymore RV parks).  Then I want to allow some sort of PocketIE interface to manipulate the robot to take "correct actions", I think I should be able to hookup my software to my MCE that is in the trailer, then with some Text-to-Speech stuff, issue the "No-Bark" command to the pups and see how that works.  There is also a small wireless web cam I plan to get for this...I think that would be extremely interesting

-ec

Morse Code Reader

I was really brought back in time after reading the following post.  When I was a in junior high, I was I guess what you call a "early adopter" to being geek.  I got my HAM radio license and purchased a Heath Kit SB100 radio (Vacuum tubes and all).  I learned Morse code to get my license but was happy when I could interpret Morse Code at 13 words per minute and got my general class license and could actually use a microphone to talk to other folks.  In the mean time, I read an article in a Popular Electronics magazine that talked about how to build a circuit to digitize the tones from the speaker "playing" the code (using a Schmidt trigger if I remember right).  I was on my second computer after saving up enough to get a VIC-20 (after my Timex Sinclair) so I built a little chunk of code to convert the tones to actual characters on the display, this worked well!  The other chunk of functionality I needed was the ability to key the transmitter to send out code, I think I used a bit on the joystick port to drive a relay and I was set.  This brings me back to the original post from Ashish Derhgawen, he wrote an output from a parallel port on his PC to drive an LED (I didn't see the current limiting resister in his screen shot, but maybe this is one of those new fangled LEDS with it built in).  He had a challenge on the bottom of hist post to identify what the message he was sending, I had a difficult time reading the Morse code from the LED, so I had to write a little program to read the LED and turn it into dots and dashes I could easily read...I'm not going to give away the answer to his challenge, but if you know Morse code it should be obvious.  I wouldn't call this a very robust solution, but sometimes coding is just fun.

Anyway here is a screen capture of the simple program...

The SWF file just gets loaded up into an IE component on the form, then here's the snippet that reads the LED, the rest is a simple state machine...

-ec

Compact Framework Development Environment

Over the past year or so, I've been working on a large compact frameworks application.  Working on a device application presents a different set of challenges from doing web or desktop application.  Along the way I've found a number of tools/processes that really help me work as efficient as possible doing this type of development, here are some of those ideas:

1. Work on an actual device, it's much faster and gives you a better feel for the application you are developing than working on an emulator.
2. When developing your application it may make sense to put all your business logic AND the actual screens of your application into a different assembly than the main application.  What I did that worked out really well was to create a shell or host application that acts as a switch board that launches the individual screens that contains the functionality.  Then I created an additional version of this switch board that ran as a Windows Desktop application, what this allowed me to do was to do most of my development in a desktop app which is much more efficient, then once I got the functionality working, I wired that into the device host/switchboard application and tested it there.
3. There is an awesome tool from Laurent Docquir that allows capturing debug messages from your device on your development PC, this is similar what you could do if you attached the VS.NET debugger although it is much faster.  In addition this program allows you to launch the process you want to test as well as kill that process on the device.  Another nice feature is the display of the timing in the left hand column, this works awesome for doing performance tuning of your application.
   
   
4. Since it isn't much fun pulling out the stylus and entering text, clicking on the actual device, you should try to find some sort of program that will display the contents of the device on your screen that will allow you to manipulate the device, the best one I found to date is Soti's Pocket Controller Pro.  This also allows you to download skins from the different devices to get realistic screen shots of your application.
   

- ec

ASP.NET Under Vista

Vista is deployed with IIS 7.0 a cool feature that wasn't available on XP is the ability to create multiple web sites.  This means you can can configure IIS to look at the host name and map that to a particular web site...I explain...

First find and open your hosts file, this is in in \Windows\System32\Drivers\Etc add a couple of entries that point back at your local machine (127.0.0.1)

Next open up IIS and create a new web site, in the Host header section enter the name of "virtual host" you entered in your hosts file (also don't forget to set your app pool up to use the "Classic ASP.NET" pipe line mode)

Now you can browse to the site you are developing with just http://plinks instead of http://localhost/plinks

Although this seems like a fairly small deal, if you are working on multiple projects it's nice to keep things organized a little better not to mention a few less key strokes bringing up the page.

-ec

DataBinding in WPF - 101

Once you understand the core concepts, databinding within WPF is a piece of cake!

Here's what you need to do (this example assumes that are getting your data from a business object through some code behind the scenes).

For this example we have a grid (not a data grid, but it's more analogous to an HTML <table> structure. that is our container:
1) Define the template of how the items should be displayed.
<Grid x:Name="grdMyData">
   <Grid.Resources>
      <DataTemplate x:Key="tblTableTemplate">
         <StackPanel x:Name="lstTables" Orientation="Horizontal">
            <TextBlock x:Name="colTableName" Text="{Binding Path=TABLE_NAME}" Width="100"/>
            <TextBlock x:Name="colTableSize" Text="{Binding Path=TABLE_COLUMN_COUNT}"  Width="100"/>
         </StackPanel>
      </DataTemplate>
   </Grid.Resources>
.....

 2) Next within the grid container, we place the control that will contain the bound items.
<ListBox x:Name="lstColumns" ItemTemplate="{StaticResource tblTableTemplate}" ItemsSource="{Binding Mode=OneWay}" /

3) Also within the grid we can include a simple text box
<TextBox x:Name="txtTableName" Text="{Binding TABLE_NAME, Mode=Default}" />

4) Finally within our code behind, we can bind our data source (in this case a middle tier object that returns a System.Data.DataTable) to the grdMyData object.
   grdMyData.DataContext = ChaosFilter.DataLibrary.Database.DbEnvironment.ReadTable();

5) Here are some interesting observations of how this works

• At this point as soon as the DataContext of the grdMyData grid is bound, the list box will be populated with two columns.
• Since we bound this to the grid object not just the list box, as we move through the items in the list box, the text box you've added to your grid will follow the value selected in the list box. 
• If you make a change to the value in the text box, the data change is reflected back to the underlying DataTable object.
• Since the changes are reflected in the underlying DataTable object, you can easily invoke the .GetChanges() method on that data table and write those back to the database (this obviously is fairly naive in that somewhere along the line you need to do validation and any auditing).

-ec