WhosOnline has been deprecated
WhosOnline was an application that would scour the offline buddies of an AIM screename and attempt to discover those which were invisible. This software is long since non-working.
WhosOnline used a simple bug in AIM that would allow the presence information of someone invisible to be available through their profile. Simply requesting the profile and examining the response would allow one to determine whether someone was invisible or offline.
AOL has long since patched this bug, and WhosOnline is no more. There is no available download–but it wouldn’t discover invisible buddies anyway. This website is linked to, and I receive many requests for this application, but it simply doesn’t exist anymore.
Digsby Widget
I’ve been using Digsby since it came out in February, and I’ve had the Widget attached to my Facebook profile, but I’ve added it here now.
The Digsby Widget is a little flash application that allows users on a website to directly contact you via Digsby. This is my widget for this site:
When a user clicks the object to enable it, they show up on my Digsby contact list.
Just type into the widget to send a message!
It’ll show up on my computer, just like a regular IM window:
I’ve never seen anything like this in any other IM client, and although it’s not really all that useful for many people, it’s certainly a cool feature. Feel free to strike up a conversation with me!
Portland MAX: Black Mesa Transit System
Every time I get on the MAX and ride for more than a few stops, I hear this message, and it always strikes me as a really strange thing, and I couldn’t figure out why until a few days ago. The message is spoken by a woman:
Proof of payment and a validated fare are required on MAX.
A sentence that you might hear on any other transit system without strict access control (VTA, for example uses an honor system). I’ve been using the MAX twice (or more) per day since May 31st, and I’ve never had my fare checked.
Anyway, this voice sounds just like the woman that narrates the intro scene in the original Half-Life, I could completely imagine her swapping MAX for The Black Mesa Transit System. I can’t be the first person to have thought this, Portland is a pretty nerdy area, more than a few people have played Half-Life around here.
JavaScript object references behave strangely.
I spent upwards of an hour trying to fix this bug that I introduced in some ‘AJAX’ code I was working on.
Basically, this was my original (vastly simplified and error checking removed) code:
function GetData(string url) { req = new XHR(); req.open(url); req.onreadystatechange = function() { if(req.readyState == 4 ) { document.getElementById('home').innerHTML += req.responseText; free_XHR(req); } } req.send(null); document.getElementById('home').innerHTML += "Waiting for data..."; }
This worked just fine, until I changed it to remove the multiple calls to document.getElementById and turned it into this:
function GetData(string url) { req = new XHR(); home = document.getElementById('home'); req.open(url); req.onreadystatechange = function() { if(req.readyState == 4 ) { home.innerHTML += req.responseText; free_XHR(req); } } req.send(null); home.innerHTML += "Waiting for data..."; }
This had some really strange (or so I thought) effects. No errors were caused, but the home<div> was not properly written to. It would add the text to that ‘home’ object.. a copy of the home div that didn’t exactly exist on the page. For all subsequent calls to the GetData routine, it would copy the home <div> and then effectively pipe the data nowhere.
The kicker? req is still a correct reference object in the anonymous function that handles the readyState change., not a copy, but a reference to the req object created in the GetData call. I’m still not exactly sure why this happens, perhaps it has something to do with the HTMLElement class not being passable in the same way that XMLHTTPRequest is.
Digsby-ToGo current issues
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!
Dynamic Defense Part 1 – Reasoning
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.
| Switch 1 (2*Switch) | Switch 2 (1*Switch) | Active Mode |
| OFF | OFF | 0 |
| OFF | ON | 1 |
| ON | OFF | 2 |
| ON | ON | 3 |
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.
Intel vs. IBM: My experiences as an intern
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.
Back to blogging!
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.
WMP11 Full screen “locking” – is that a joke?
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?
Digsby ToGo, and Digsby URL resolution!
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!