http://www.koreus.com/files/200501/proximity.html
Hexagonal grid, numbered tiles, interesting atack-and-defend mechanism. The AI seems good, but beatable with some practice.
January 31, 2005 – 4:07 pm
http://www.eyezmaze.com/grow/v3/index.html
My high score after three tries is 9600. I’m going to keep trying until I max them all out, though.
January 31, 2005 – 1:41 pm
Since my last post, I’ve taken a job on the MSN Search team. It’s a pretty interesting problem space to work in, but it’s tough to stay objective about which search engine is the best one around. I want to see us ship such a cool product that everyone prefers us hands down, but before I wanted that, I was quite a Google fan.
So in order to keep my sanity, and so I can tell exactly when it’s time to start telling everyone I know that we have not only shipped a great search engine (which I think we can already claim with what’s running at search.msn.com today) but that we’ve shipped the best one in town, I’ve written myself a little tool that lets me compare how useful MSN’s results are to me vs. how useful Google’s are.
I won’t go into details in this post on how it works, but it has taught me at least one interesting thing: as I use MSN Search more over time, Google’s results are losing their relevance. Sounds a little strange, and possibly even un-objective, I know. Here’s what I mean: when I used to search for something, say “flight simulator”, the results that Google returned would emphasize the sites that it had scored as most relevant, using the scoring algorithm that they have developed over time. Over time, I learned which of those sites I considered most relevant. So as I scanned search results for a different, but related query, say “flight simulator add-on airplanes”, I would notice the results that pointed to my favorite sites. The sites that were my favorites because they were the best ones I had been introduced to. Not necessarily because they were the best sites out there.
This meant that when I started using MSN Search for flightsim queries, it had a handicap to overcome–namely that I was expecting results from a certain set of sites. It returned some from them, but it also returned many other results as well. Those others, at least initially, appeared to be “less relevant” simply because I wasn’t accustomed to them. Overall, Google was formerly beating MSN Search for me about 2 times in 3, but the margin has recently slipped to only 3 in 5. To the best of my knowledge, it’s not because Google’s returning worse results…
December 29, 2004 – 8:17 pm
I’ve heard many instances in the last 5 years of people joking that something is "soooo 90s" indicating a passe taste or trend, but last night for the first time ever, I overheard someone use the phrase "back in the 90s" without a trace of humor in their voice. The conversation went something like:
"Didn’t you use to work here?"
"Yeah, but that was back in the 90s." (implying that it had been ages ago)
Now that we’re _almost_ 5 years into the decade of the oughts (as opposed, I guess, to the shoulds), it probably makes sense that the 90s is finally truly becoming a historical era, but that just sounded odd to my ears. I’d better get used to it, though.
I haven’t posted in a while because I spent all of last week in Boston, MA, the latter half of which for the annual convention of the National Puzzlers’ League. The convention was fun, and I’ll make some time soon to tell you more about it and the other sorts of puzzling I do in my Copious Spare Time [tm]. For today, however, I’m going to tell you about something I learned at the convention that isn’t really related to puzzles at all.
First, a little background info: there were fewer than 200 people in attendance at the convention, and most are regular attendees. So even near the start of the convention many of us already knew nearly everyone there. By the end of the convention, even if I couldn’t name everyone, I could recognize them. So when someone showed up around lunch on Saturday that I didn’t recognize and was wandering around somewhat lost trying to find a name tag, I figured I’d introduce myself and try to make him feel welcome. So I did. The conversation went extremely awkwardly, even considering how socially awkward your average puzzler is. Something just didn’t feel right. He cut the conversation very short, and ended up telling me to go away immediately before leaving the room himself never to reappear.
This got me to thinking about possible explanations. One thing that I came up with is a scam: confidently walk into the National Ball Bearing Manufacturers’ Convention and act like you’re supposed to be there. Chances are you’re just one of a hundred people that any one person doesn’t know at the convention, and while everyone else is eating, you can steal free food. This breaks down and becomes detectable in cases where the convention-goers all know each other fairly well, but even then, I can’t claim that I was ever confident enough that they were really strangers that I was willing to call their bluff.
After I started watching for it, I noticed other random people walk into the room up to the food, grab something, and then leave. Others milled around looking nonchalantly under tables (perhaps looking for purses or other valuables?). I sure don’t want to believe that all of the strangers were thieves, but I made it a point to keep my eyes out for these people at Convention functions later in the weekend, but never saw a single one of them again.
Its amazing what sorts of things happen all around without ever going noticed.
Every once in a while, I think I know exactly what the code that I’m writing is doing, and then I discover, often through some catastrophe, that I didn’t quite understand all the details. One particularly instructive (or would that be destructive?) example that comes to mind is a T-SQL mistake that ended up deleting every row in a table instead of just the three or so that I was expecting to delete (feel free to play along on your own SQL Server using the Northwind sample database):
delete from Suppliers
where ContactName
in
(
select ContactName
from Shippers
where ShipperID >= 3
)
What happened is that ContactName is not a valid column name in the Shippers table, but even inside the parentheses the ContactName column from the Suppliers table is in scope. In fact, just because you mentioned a column that only lives outside the parentheses, SQL Server is happy to treat this as what is called a “correlated subquery”, and it’ll go to the trouble of doing a cross join on the two tables to give you every possible pairing of rows. Needless to say, this result set includes every ContactName under the sun even after being filtered against the where clause, which means the delete statement has the full authority to drop every row in the Suppliers table. Ouch!
I really wish that I could ask SQL Server to give me some sort of warning in cases like this, as it seems to me that most people who haven’t done much with the ‘in’ syntax would, like me, not expect SQL Server to even cooperate if the stuff inside the parens doesn’t parse when taken alone. But now I know better. And try as I might, I just can’t stay upset as I had a backup from earlier in the day, and it sure made for a good puzzle.
Stupid Remote Desktop trick #1
- Connect to a remote machine using Remote Desktop.
- In device manager, right-click on your network card and choose “Disable“.
- Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and re-enable your network card.
Stupid Remote Desktop trick #2
- Connect to a remote machine using Remote Desktop.
- Press Ctrl-Alt-End, and choose to shut down your machine. (It seems that Windows Server 2003 warns that you may be shooting yourself in the foot, but Windows XP Pro doesn’t.)
- Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and turn the machine back on.
Stupid Remote Desktop trick #3 (most recently discovered, and all-time favorite)
- Connect to a remote machine using Remote Desktop.
- Get prompted to change your password while logging in (i.e. log in while it’s nearing its expiration date).
- After typing your old password, but before typing your new password, accidentally hit Enter instead of Tab.
- Windows will congratulate you on your new password.
- Windows will tell you that you can’t log in because you have a blank password.
- Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and change your password to something that’s not blank.
- Set group policy to prevent blank passwords.
Let’s begin with a simple experiment that you can perform on your own computer:
-
Count the number of icons in your Taskbar Notification Area, including any rarely used icons that Windows XP may have hidden under the little blue less-than button. The Taskbar Notification Area is that part of your Windows taskbar near the clock where lots of little icons go.
[1]
-
Kill explorer.exe. (If you’re a command line type running Windows XP or later, “taskkill /im explorer.exe /f” will do the trick. If you’re a GUI type, start Task Manager (Ctrl-Shift-Esc or your preferred method), choose explorer.exe and choose “End Process”.)
-
Restart explorer.exe. (From a command line: “explorer”. From TaskMan: File->New task… “explorer”.)
-
Once your taskbar is back, recount the number of icons in your notification area.
Chances are enormous that you have fewer notification icons than you started with. On my computer, the number went from 10 to 4! (Only Outlook, Windows Messenger, eTrust Anti-virus, and the Windows volume control survived. Lots of stuff didn’t.)
Those icons will probably stay gone until you stop and restart the program responsible for each of them. Where did they go? Why did they go there?
It turns out that explorer.exe [2] loses all information about what icons were displayed there when it dies (and who can blame it for that?). It is up to each application that wishes to use the Taskbar Notification Area to remind explorer.exe’s reincarnated self what it wanted displayed. The method by which your application properly gets notice of the reincarnation of explorer.exe (or, more specifically, the creation of the Taskbar) is described by MSDN Library as follows:
With Internet Explorer 4.0 and later, the Shell notifies applications that the taskbar has been created. When the taskbar is created, it registers a message with the TaskbarCreated string and then broadcasts this message to all top-level windows. When your taskbar application receives this message, it should assume that any taskbar icons it added have been removed and add them again. This feature generally applies only to services that are already running when the Shell begins execution. [Search for “Taskbar Creation Notification” at [3]]
This obscure little MSDN Library gem makes it sound like there’s no reason a normal app should care about notification that the taskbar was just created, but as we just saw, real apps can be affected in a case where explorer.exe crashes or gets killed. While explorer crashes are not a terribly common occurrence in modern Windows releases, they are not unheard of. There is little reason not to get this behavior right considering that you can probably implement it by adding 6 or fewer lines to your window proc as shown in the example code in the above-linked MSDN Library article.
Excuse me while I restart so as to get back my other notification icons…
Footnotes
[1] You may know this as your “tray” or “systray” but Raymond Chen explains why you might think that, and why you would be wrong.
[2] The Windows process responsible for drawing much of the Windows desktop, including the taskbar.
[3] inline link to MSDN Library article
Tribal Librarian? What on earth does that mean?!
To understand where I got such a strange name for my blog, we first need to understand “tribal knowledge”. iSixSigma.com defines tribal knowledge as “any unwritten information that is not commonly known by others within a company” [1]. For our purposes here, I’m using it slightly more generally to refer to any information (either correct or not) that is “known” by the people close to a particular subject, but is otherwise hard to come by. I notice cases of tribal knowledge all the time. It happens at work in the form of going on a hunt for the right person instead of the right reference document to answer some trivial question that I know has been asked a hundred times before me. It happens in my spare time in the form of encountering the same pitfalls that ever other consumer of some API has encountered during his first use of it, but that even still no good documentation exists to explain. Everywhere I encounter tribal knowledge, it just bugs me.
With this blog, I want to help stamp out tribal knowledge to the extent that I can, and that’s where the “librarian” part of the title comes in. Calling myself a librarian probably misses the mark a bit. After all, a librarian technically does more along the lines of managing a collection of existing knowledge than collecting new knowledge. But “tribal documentarian” and “tribal blogger” just don’t sound as nice. Besides, I hope to be in the position of managing a good-sized collection of existing knowledge here soon. In the meanwhile, I’ll get to work doing the collecting.
[1] http://www.isixsigma.com/dictionary/Tribal_Knowledge-488.htm
Postscript–something about me
I figure since this is my first post in this blog, you might want to hear a little bit about me. I’m a developer on the Windows Client Performance Team, and have been at Microsoft for nearly five years. I love working here because of the cool people and the cool projects that surround me on all sides. Aside from computer technology, my interests include writing and solving puzzles of most any kind, reading (mostly sci-fi with a little bit of fantasy thrown in), and studying language (natural and constructed, human and computer). I also enjoy hiking, camping, and backpacking, though I do less of these than I would like to admit. I expect to include articles from time to time on all of the above and probably some other stuff too. Let me know if there’s anything in particular that you’d like to hear more about.
Until next time when we’ll talk about the systray taskbar notification area, let’s contemplate it on the tree of woe.
