This is a list of the current known issues with DTG:

• When there are not any IM windows open, the contact list will be blank and offer no indication that there are not any open windows.
• When a window is closed locally, the remote client does not remove the page.  This functionality is expected, however the ability to Send still exists, even though is will fail.
• There is a case where a window cannot be located even when the window cache is built, I’m working to find this one.
• When another session is created, or the session is cleared, you may receive the You have been logged out. Message more than once.
• If there is an error contacting the web server (From the bridge), that message will be lost.  I am working to build a queue so requests are never lost.
• There is no visual indication in the IM window that DTG is active.  I’m working to build a solution that would show this visually without getting in the way.
• There is not any indication when a new IM comes in to the remote client.  I’m looking for a solution to this.
• Internet Explorer is not supported by the remote client:  This is expected, since the site is currently Gecko/WebKit specific.  I will be building a desktop-browser solution soon.  If anyone is willing to help with this (looking for someone experience in building pretty websites), let me know.
• The client constantly reconnects every X (likely 5 minutes) and checks for messages even though there isn’t any need - this is expected, but will be optimized to not do so soon.
• The bridge application opens slowly: this is due to connecting at startup, this will be fixed soon.  My web server isn’t exactly speedy, and sometimes connect times are relatively high.
• There isn’t any way to see more than 20 (or so) lines on the remote client:  This is expected, however I think I have found a solution which will allow the user to toggle between “functional” and “history” modes, viewing past lines.
• Emoticons are not supported: This will be coming soon, however I am not sure whether it would be best to convert to text, or convert to images, perhaps a setting.
• Login and registration pages don’t look good:  They are temporary, I will replace them with iPhone/browser specific ones when I can.
• UAC does not prompt for elevation for the Skin Installer under Windows Vista: A fix is in the works for this.
• Requests often get queued up on top of each other, and messages are added to the same window twice: I need to figure out how that is possible before I fix it.
• Status messages and “day change” time stamps are displayed strangely - I’ll have a fix for this soon.

With all these changes, I will soon be implementing a version check–you will need to be using the latest build every time you restart the bridge.

If you find any other bugs, please email or IM them to me so I can be aware–and fix them, as fast as possible!

It’s been quite a while since I’ve udpated this, but I’ve spent this weekend working most on the Digsby ToGo project.  I’ve opened it up for a limited beta.  Send me an email containing a user/pass pair if you’d like to get access. Register at the DTG homepage.

How to get Digsby-ToGo:

• Get your username and password. I’ll put a registration page up soon so you won’t have to contact me.
• Download the Digsby-ToGo package from The DTG homepage.
• If you are using Windows Vista, you will need to open the application as an administrator in order to run the Skin Installer.
• Run the Bridge application.

Before you login, run the Skin Installer to install the hooks in the skin that will get your messages into Digsby ToGo.

Select your skin from the menu - change the location if you didn’t install Digsby to C:\Program Files\Digsby\.  Once you select your skin, click Install Hooks.  Once this is do Make absolutely sure you restart Digsby. It doesn’t do any harm - but the results will be inconsistent and erroneous.  If your skin isn’t compatible with the installer, please let me know.  zip a clean version (i.e. no hooks install) without any extra images and email it to me.

Once the skins are installed, you can login to Digsby-ToGo.

The Log tab provides mostly debug information.  You can minimize of close the program and it will go to the tray.  Your IM’s will be routed to my webserver and you will be able to login on your iPhone or iPod Touch and access them.

Please note that there is not any encryption at this time.

It has been more than two years since the Dynamic Defense system was designed, but I’ve always meant to document it fully just for the sake of completeness and in the spirit of sharing information.

Dynamic defense was a system that we used on FIRST Team 195 in 2006 to configure and control the autonomous operation of the robot. From this point onward I’m going to assume the reader is familiar with the 2006 game, as well as the game mode flow.

Purpose

The traditional way of controlling the autonomous operation of the robot during FIRST games was always to use switches to select different modes.  This system did allow some flexibility and decisions could be made right up until the robot was dropped on the field before the match, but the decisions that could be made were limited to what had already been considered.

Using this scheme, it was possible to have many different modes stored and selectable.  It was simple to set the switches equal to a mode number, but not simple to remember exactly what each mode meant.  This was confused further by having a need to select a different stating position, requiring another 2 bits of data to select A, B or C.  There was, however, a workaround for this.  Using an analog selection dial, one was able to choose one of many different numbers on a single input.

these inputs could be placed either on the Operator Interface, or on the robot itself.  Once the inputs were selected, the code inside the robot would look much like this…

// Simplified for the sake of understandability
 
byte mode = (4*switch1) + (2*switch2) + switch1;
 
switch(mode) {
    case 0:
        // code for mode 0
    break;
    case 1:
        // code for mode 1
    break;
    case 2:
        // code for mode 2
    break;
    // .....
}

It’s not complicated, but it isn’t clean either.  Modes often have shared code (for example, 3 modes may have “drive straight 100 ticks” in them, and thus modes could be nicely combined like such…

// Simplified for the sake of understandability
 
byte mode = (4*switch1) + (2*switch2) + switch1;
 
switch(mode) {
    case 0:
        // code for mode 0
    break;
    case 1:
    case 2:
        // code for mode 1 and 2, since they share some of the same features
    break;
    // .....
}

So now two modes are tied together.  What happens when they differ at some point?

// Simplified for the sake of understandability
 
byte mode = (4*switch1) + (2*switch2) + switch1;
 
switch(mode) {
    case 0:
        // code for mode 0
    break;
    case 1:
    case 2:
        // code for mode 1 and 2, since they share some of the same 
 
        if(mode==1) {
            do_something();
        } else {
            do_something_else();
        }
features
    break;
    // .....
}

And what about that starting position selector?

// Simplified for the sake of understandability
 
byte mode = (4*switch1) + (2*switch2) + switch1;
 
switch(mode) {
    case 0:
        // code for mode 0
    break;
    case 1:
    case 2:
        // code for mode 1 and 2, since they share some of the same 
 
        if(mode==1) {
            if(start_pos==A) {
                do_something();
            } else if(start_pos == B) {
                do_something(SOME_CONST);
            } else {
                stop();
            }
        } else {
            if(start_pos==C || start_pos == B) {
                do_something_else();
            } else {
                stop();
            }
        }
features
    break;
    // .....
}

It started nice and simple, but how maintainable is that routine?  No matter how cleanly you try and write it, you end up with code all over the place.  This is what happened in 2005, and I figured there must be a better way.

Risks

Normally a team programmer would open the code loader, and send over a hex file serially which would replace the current program in the ROM.  If this process was interrupted, it would fail and the robot would lose all functionality.  This added increased risk into a last-second code download.  Code downloads could take up to 50 seconds, and a failure would mean the process would have to be repeated.  IFI_Loader (in conjunction with my serial-USB adapter) had also BlueScreened my laptop several times.  Dynamic defense solved this problem by only sending configuration data.  And although not implemented in the initial software, it would have been easy to add a safeguard, and a checksum.

Dynamic Defense was designed to solve these problems, along with others that we didn’t even realize they are problems.  In my next post about DD, I’ll discuss the system in more detail.

Now that I have worked at both IBM and Intel as an intern, I can compare my experiences.  I won’t touch on the differences in the teams I worked on, since I did like working on the DB2/VS team IBM, and I do like working at Intel on the LAD team.

First Day

At IBM, the first day consisted of going to the main campus (ARC), going through the paperwork for emdployment, and then proceeding to SVL (Silicon Valley Lab).  There were approximately 12 people starting that day.  Once I went over to SVL, we had lunch with the rest of the team.

Intel’s first day consisted of a full-out orientation about Intel, and general workplace practices.  Everyone (approximately 100 people) lined up in the lobby at the JF3 (Jones Farm - building 3) campus to get security badges.   Groups were then taken over to JF1 and given a packet containing paperwork for employment, and some other documents.

Orientation was 4 hours, including a quick lunch.

After orientation I met up with my manager and was introduced to the rest of the team.  I wasn’t scheduled to get my laptop until the next day (why..?), so I was setup with a desktop a former employee had used.  This turned out to be a good thing because now I have multiple systems.

Facility

Intel/JF seems to be quite a bit nicer than IBM’s SVL.  The campus is newer in some respects, and houses more employees.  There are two cafeterias at JF, and the food is of a higher quality than SVL.  Lines are short around lunch time, and I’ve yet to have the credit card reader fail.

Transportation

IBM provided a shuttle from SVL to the Santa Teresa VTA station.  The bus that came was much like a hotel/airport shuttle.  20 seats or so, it was never more than 6 or 7 people each time.  Routes were, like Intel, only in the morning and afternoon (7-10, 4-7).

Intel provides a shuttle van, which holds 12 passengers and is kind of a pain to get into.  As of recently, there have been far more passengers than the past (due to the cost of fuel possibly).  I’d like to see it switch over to how IBM worked, with the airport-style shuttle.  The intel drivers are very friendly though, I didn’t talk to the SVL shuttle driver much.

IBM provided a free annual VTA pass that was stuck to the back of the employee badge.  Intel used to do this, but now only subsidizes $30/mo for the monthly pass for TriMet/MAX.  Monthly passes for adults are ~$75, somewhat steep.  MAX transit is efficient and overall rated better than VTA.

Equipment

IBM gave me a T60, dock, mouse, keyboard and a single power adapter.

Intel gave me a T43, dock, mouse, keyboard and two power adapters.  My team got me a monitor and a desktop with a KVM.  My laptop is relegated to a meeting device, or for taking home.  I feel sorry for those that have to just use the slow T43 like I did.  It isn’t really an acceptable development machine.

Environment

SVL was an all-office environment, where as Intel JF is completely cubicles.  I prefer the high-walled cubes, since they foster collaboration yet do offer some form of privacy.

There are some other key differences, but I won’t discuss them here.

I’ve been inactive here for the last few weeks, this was due to finals week at RIT, and my one-week summer vacation.  I’m starting work at Intel tomorrow, out here in beautiful Portland Oregon!

I’ll return to daily blogging tomorrow after work.  I have much to discuss outside of the technological realm.  I’ll be covering some aspects of moving to, and living in Portland OR.

A new (or the first I’ve seen it) feature in Windows Media Player 11 is the ability to “lock” the player in fullscreen mode.  Sounds like a great idea, you want to allow the computer to be left unlocked so you can watch a movie–but also to keep it secure.

WMP allows you to enter a 4-digit PIN and disallow Full-Screen mode to be exited without unlocking with that PIN.  This would be great.. if it worked.  Just select Ctrl+Alt+Del -> Show Task Manager and the task manager window will appear.  Select the window and WMP will forcefully exit full screen mode.  How could this be overlooked?

I’ve been too busy the last couple of days to update, but I would like to showcase two small projects I have been working on.

First, is Digsby ToGo:

Digsby ToGo is a remote access solution, similar to Trillian Anywhere.  It allows you to access your current conversations from a web browser, and to interact exactly as how you would at the desktop.  This solution is seemless to the chat partner.

And the other project, is to have Digsby resolve URL’s in conversations.  So a link to youtube: http://www.youtube.com/watch?v=MgpzUo_kbFY - which carries no meaning, will replaced with the title of the page, far more descriptive.  This all happens in the background.

More to come!

I read a book recently by Larry Winget called It’s Called Work for a Reason!: Your Success Is Your Own Damn Fault.  The book was good, some things he talked about I disagreed with, and others I really liked.  One of his chapters was devoted to–what he referred to as–Workplace Superstars.   These Superstars are the people that seem to be exempt from the rules, the people that can do what they please, because they are invaluable–or highly valuable–to the company.  I’ve since returned the book, but I’ll loosely quote a passage where Larry talks about superstars working for him.

If you’re working for my company in sales, and you are outselling everyone else by more than double, then you’re a superstar.  I’ll let you do whatever you want to do, as long as you keep selling.  You can come and go as you please, wear whatever you want to work, do whatever you think will help you sell more.  And while you’re outselling everyone else, I won’t get on your back about the little things, I’ll let you get away with stuff.  But if you stop preforming–you won’t be a superstar anymore, and you’ll have to follow the rules just like everyone else.

–Larry Winget

This concept of a SuperStar wasn’t new to me, and probably isn’t new to many, we’ve all worked with, or maybe even been those people.  They’re an asset to the organization, and they are deemed to be of extremely high value (perhaps not invaluable, since rarely is someone).  Sometimes it’s not even that hard to become a superstar, you just need to fill in a void that is hard to fill, or hasn’t been filled by anyone before you.

Back in high school, I participated on a FIRST robotics team, I was pulled onto the team in my Junior year, and participated as a programmer for two years, taking over the role completely in my senior year.  I knew some of the people on the team before joining, and quickly became friends with most everyone.  As far as I knew, we were all treated the same.  There may have even been another superstar or two.

At our teams first competition of the season, I took over doing the actual program for the robot, replacing the other programmer who didn’t know how to fix a certain problem we were having.  I found and fixed this problem, and built a makeshift autonomous mode program.  This was the first time that I was “in charge” of the competition build.  I spent another twenty minutes working with a member of the drive team to simplify his controls and make some modifications to how things would be operated.  I thought nothing of either of these things, since I had been working with “clients” for several years.  Even the slightest of a change can make a big difference. If I feel that a feature is in poor taste–but the end user wants it–I’ll include it.  It’s not up to me to make arbitrary decisions about how the system should be used.  If it works for the driver, he can better do his job, and I’ve done mine.

At this point, I became exponentially more valuable, and perhaps in several minutes, earned the status that the 3rd and 4th-year team members had achieved.  I could do, and more importantly would do what nobody else was going to.  Having a more functional robot, or a simplified control interface meant that the team was more likely to be successful.  Perhaps I was given credit where credit was not due–I didn’t design that control board, I didn’t design most of the control software, I made simple modifications that should have already been done.  At this point, I became a superstar to the team advisers (think of the as management).

For the next year and a half that I was in high school, and on the team, I worked in much the same fashion.  I built the best software that I could, and in return, nobody ever had a problem with me doing what I wanted.  I found out this year (2008), that the team has had a “buddy system policy” since at least 2005.  Never once was I asked to “find a buddy” or “go somewhere with my buddy.”  I remember frequently moving from the stands watching matches, to the pit area to make changes or take a look at something.  Never once was it questioned where I was going, or what I was doing.  Others were accosted and asked questions just to go to the bathroom.  Maybe I looked trustworthy, or maybe I had superstar status.

5 Tips to becoming a superstar:

1. Please the right people. This may seem obvious, but realize that sometimes it’s better to have your peers talking about how great you are, than to have only your managers know.  Your managers can see your performance far more directly, it really says something about a person that is highly regarded by their peers.
2. Become invaluable. This is more obvious than the last, but it is just as important.  In order to become a superstar, you will have to be able to do something that nobody else can.  Be the absolute best at what you do, in every respect.
3. Make ethical and logical decisions. Being able to think quickly and make good decisions is important.  Someone that can consistently makes the right call is more likely to be given flexibility in making those calls.  Have a solid track record of making the right choice.
4. Know the strengths and weaknesses of those around you. This can’t be emphasized enough.  Being able to rush to the rescue when someone can’t come through is a great way to instantly achieve superstar status.  Being able to judge and estimate where someone might fail can be just as important, and knowing the right people to turn to when you need help is a safety net that will help you retain status.
5. Don’t make wanting to become a superstar your driving force. Superstars are naturally good at what they do, you can’t force yourself into it.  Having talent is important, and being smart can help–but not everyone is a superstar.

I ran into this article today over at TechSpot, and became immediately annoyed at the way they are nitpicking at the decisions Microsoft made on the release of SP3.

I put SP3 on my laptop last week, it installed much the same way that XP SP1 and SP2 did, it took around 25 minutes to install, and everything feels the same as before the update.  I have had problems in the past updating computers to SP2 and getting a blue-screen due to unexpected winlogon.exe termination.  Perhaps it’s just that I do like Microsoft, and I cut them slack and don’t expect everything to be perfect, or perhaps it’s because I work in the industry and know how complicated it can be to push an update of this magnitude.

Windows is really complicated.  It’s not as simple as it looks from a user perspective, there are very complex systems in Windows (this does apply to any operating system–OSX and Linux are just as complex), pushing an update can have an adverse affect on any one of those systems.

The Microsoft Windows operating system supports thousands of devices. More than 30,000 [as of October 2006] drivers have been released; more are introduced daily.

(Microsoft)

It is not a secret that the success of Windows in the recent years has been largely due to the massive hardware and software that are compatible with Windows, and only Windows.  Microsoft has certainly put a substantial amount of effort into ensuring that more software and more hardware works with Windows than any other platform.  When Apple releases an update to OSX, things break.  Users expect software to break.  Many applications weren’t compatible with 10.4 Tiger to 10.5 Leopard.  Apple sees this as acceptable, and perhaps necessary to build a rock solid OS over time.  I’m quite sure that the API for OSX has changed and evolved over the years, and is far cleaner and simple to use than Windows win32 API.  This backwards compatibility–something that Microsoft often gets flack for, is one of their strongest selling points, and the track record of compatibility is one that businesses can depend on.  Something written for Windows XP will still likely work on Windows 95, unless it is using advanced graphics, or has a dependency on the .NET CLR.

For these reaons, a service pack–or even an update can and eventually will break something.  It’s a delicate system, if you want massive hardware and software support, you will need to deal with some of the shortcomings.

The aforementioned article also mentions how SP3 won’t be installed on any computer with IE8 Beta–and that if you install on a computer with IE7, it will no longer be able to roll back to IE6.  This is because the components in IE (mainly the Trident Layout engine) are used in other parts of Windows.  If the service pack allowed IE8b installed, or to roll back to a time before the service pack, file version inconsistencies would be created.  There are many ways that this could happen, and it would have had to have been extensively tested.  This costs more, and benefits very very few users.  Most would not complain about the limitation.

Microsoft has provided a great utility since .NET 1.0 for doing quick I/O via websites.  The WebClient class provides basic functionality for downloading from and uploading to webservers.  the WebClient example on MSDN leaves a lot to be desired, especially for beginners.  I’d like to expand on that, as well as provide some example code.

C#: Using WebClient to fetch a page:

        // create a new instance of WebClient
        WebClient client = new WebClient();
 
        // set the user agent to IE6
        client.Headers.Add("user-agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705;)");
        try
        {
            // actually execute the GET request
            string ret = client.DownloadString("http://www.google.com/");
 
            // ret now contains the contents of the webpage
            Console.WriteLine("First 256 bytes of response: " + ret.Substring(0,265));
        }
        catch (WebException we)
        {
            // WebException.Status holds useful information
            Console.WriteLine(we.Message + "\n" + we.Status.ToString());
        }
        catch (NotSupportedException ne)
        {
            // other errors
            Console.WriteLine(ne.Message);
        }

(This code uses DownloadString, you can also use DownloadData for a more binary-friendly version)

This is great for fetching simple pages that have data encoded in the querystring, but there are some problems with the basic DownloadString method of WebClient.  It’s synchronous, so it will block until the operation completes.  So for slow connections, or large files, this would need to run in another thread.  There is a better way.  But first, here’s another example of another basic, but important, method, DownloadFile.

        // create a new instance of WebClient
        WebClient client = new WebClient();
 
        // set the user agent to IE6
        client.Headers.Add("user-agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705;)");
        try
        {
            // actually execute the GET request
            client.DownloadFile("http://www.google.com/","google_fetch.txt");
 
            // ret now contains the contents of the webpage
            Console.WriteLine("File Saved.");
        }
        catch (WebException we)
        {
            // WebException.Status holds useful information
            Console.WriteLine(we.Message + "\n" + we.Status.ToString());
        }
        catch (NotSupportedException ne)
        {
            // other errors
            Console.WriteLine(ne.Message);
        }

This example is almost identical to the above, aside from the client.DownloadFile method.  This will save the file to disk, instead of returning a string–often what you would end up doing with the string anyway.

But can I send POST data?

Yes!  Using WebClient.UploadString or WebClient.UploadData you can POST data to the server easily.  I’ll show an example using UploadData, since UploadString is used in the same manner as DownloadString.

            byte[] bret = client.UploadData("http://www.website.com/post.php", "POST",
                System.Text.Encoding.ASCII.GetBytes("field1=value1&field2=value2") );
 
            string sret = System.Text.Encoding.ASCII.GetString(bret);

UploadData returns a byte array (byte[]) which contains the contents of the page.  This can easily be converted to a string by using the System.Text.Encoding.ASCII.GetString() method.  You can also use the other encoding types in System.Text.Encoding (such as UTF8) to do the same.

Also note the use of GetBytes(), the UploadData method will only take a byte array as a buffer for the upload.  This works well if you are uploading a binary file.

What about the asynchronous methods of WebClient?

WebClient provides asynchronous methods for fetching webpages as well, they are named similarly to the synchronous methods, DownloadFileAsync, DownloadDataAsync, DownloadStringAsync, UploadFileAsync, UploadDataAsync, UploadStringAsync, and UploadValuesAsync.

In order to execute an Async request, you will need to attach event handlers before the method is executed.  Without these event handlers you will not have any sense of when the operation finishes, or what stage it is at.

C# WebClient Asynchronous call example:

void do_upload() {
   WebClient client = new WebClient();
   // add event handlers for completed and progress changed
   client.UploadProgressChanged += new UploadProgressChangedEventHandler(client_UploadProgressChanged);
 
   client.UploadFileCompleted += new UploadFileCompletedEventHandler(client_UploadFileCompleted);
  // carry out the operation as normal
   client.UploadFileAsync("http://www.daveamenta.com/up.php", @"c:\somefile.bin");
}
 
void client_UploadProgressChanged(object sender, UploadProgressChangedEventArgs e)
{
   Console.WriteLine(e.ProgressPercentage);
}
 
void client_UploadFileCompleted(object sender, UploadFileCompletedEventArgs e)
{
   if(e.Result != null) {
      Console.WriteLine(System.Text.Encoding.ASCII.GetString(e.Result));
   }
}

The call to client.DownloadFileAsync will no longer block the thread, and will execute in the background, periodically calling the event handlers to display progress.  The other methods can be used in this same way.