Working on a remote team

 Scott Hanselman gave my team a great talk today!

He's been a remote worker for a long time.  I've also been remote over the years, and have also led mixed remote/in-person teams, so am very interested in his ideas around that. I've found leading those mixed teams can be challenging. 

He blogs about this a lot - Here are some of the articles he's written that resonated with me on remote work

Tools

Looks like SQL Server 2008 has some Geospatial stuff that I could leverage to do some of this (Gawd I could have used this stuff back in 2003!). I've also been poking around at Bing and Mappoint, which have some pieces that I could use (but I don't see supporting what I need, as far as custom data goes - it's too limiting).

I'm also trying to figure out if Azure has any of this new stuff. At this point, it is my preference (and my hosting company only has SQL 2005).

Might be able to develop the rough grid stuff off of this:

• Equirectangular projection
• Universal Transverse Mercator coordinate system
• Maidenhead Locator System

The Maidenhead looks promising - smallest resolution is 3.5 x 3 miles - and the encoding (MM44NN55) would easily lend itself to very fast SQL lookups (Quick calc to convert lat/long to Maidenhead, and then could pick which pair to look at - so MM for the world-level grid, 44 for regional, NN national, and 55 for local).

And...

I could have two calcs here - if a fire is below a certain strength (90% of them will be, I think), they won't even be on a grid.

So do the calc of all fires within, say, 5 miles. Then do a calc using the combo technique below. So a majority of fires never get a grid entry, and would be calc'd using a simple Great Circle calc to figure out effect. The other ~10% would use the grid system to figure out which of them would have a effect. And... the top level wouldn't really need to be a grid here, as I'm not calcing based on distance (on the grid cells) - "Global" effecting fires could just be marked as such. Every requested temp calc would include a calc on them.

Combine?

So it occurred to me that I could combine both of these together - processing each "fire" to figure out any given spots given temp, and pre-calculating a grids ambient temperature when a fire is placed.

The problem with calculating what fires effect a specific spot is it could by ANY fire, any place on the earth, if the fire is big enough. If I have a million fires, even if only 500 of them effect a specific spot, because of the range-calc of each fire, I don't see any other way, using this technique, to figure out the temp then get get all million can calc which is having a effect.

Using the grid makes it much simpler - instead of looking at individual fires when a locations temp is calculated, when the fire is placed, all grid locations that that fire will impact have their temp recalculated. Several layers of grids work together on this and a fires effect is only calc'd on the largest possible grid.

So, combining these two - when a fire is placed, figure out the appropriate level of grid the fire will effect (Global, regional, local, small, etc) and instead of pre calc'ing the temp on that grid, in those cells, just add a indicator that the fire effects that grid (and cells). When a calc is requested, find all fires that effected the current grid(s) of the current location, and then do a calc against ALL fires that have entries in that grid.

This has two very large benifts that the first grid techinque didn't have - once the list of fires is know, a real distance calc (location of both calc location and fires location and radius of effect of fire) can be made - so this gets us back a true gradiant. It will also allow a fire to expire or reduce over time (based on the current date, on the calc modify the heat level of the fire by how old it is and how strong it intiall was).

So this Combo calc will have a lot more overhead, but by combining the two techniques, I think it's do-able - and gets what I really wanted to stat with in the first place.

More thoughts

So here's a visual of the optimum way of doing this, simplified (the values radiating from the center of each fire would really be something like 15, 14.9, 14.8, 14.7... to zero)



One way to go at this is from the other direction. When a fire is placed, there's no way I can pre-fill every possible coordinate that the fire could heat. But maybe if I simplify it...

Look at the world as several layers of grids. The largest would have few cells (12x12?). The smallest would have a huge number, and get down to very local info. Have limited number of layers (5?10?)

When a fire is placed, is would be sized to the largest possible layer (maybe if it contains a % of that layer. If no %, then go the smallest). It would ONLY be placed on one grid at a time.

When a temperature calc is requested, the system would find which grid the user is on for each layer, and sum the temps in those grids (so 5 layers would return a max of 5 cells to calc - for example: world wide, regional, state, city, and local. If no value had been placed in the local cell, then it wouldn't get a value for that cell (or it would be zero).

So ANY fire placed, no matter how large or small, would have a calc on a small set of cells. In the DB, only those cells that had been effected would actually have a value (so in the above, layer 1 would have 12 cells populated, layer 2 would have 121, and layer 3 would have 63.

Fires would normally be placed rarely, while requests for temps would be done requested very often - so this might work. The down side is that there's not a easy way to decrease the temp of a single fire over time (which I was planning on doing). Might be able to force a periodic refresh, but that would be annoying.

Above is for biggest fire, which would be world wide - The center is in on two of those big cells, so effect is highest there. Surrounding would be less.


Above is for a smaller fire - it's on a mid-level layer.




The last is on a small-level layer, with only a very local effect.

Didn't show it here, but I think as it goes down, it would effect more of the (smaller) cells.

Spin-off

Working on a spin off, kind of. Based on a idea I had when first doing AE the time, plus some MMORPG I've been mucking with since then.

Trying to brainstorm some ideas (thanks Mike!)

I'm doing something new, and am at a bit of loss on how to implement. Or even design it. I want to do something that swaps Great Circle around.

I want to have any number of points, and have those points have a radius of effect. Then, given a point (A), I want to find all other points whose radius of effect encompasses A.

So you can think of it as a bunch of fires that give off a certain amount of heat (the radius of effect). So given A, I need to find all fires around A that have some kind of effect on A – and in this analogy, what I really want to do is find out the temperature at point A. Some of the fires would have no effect (too far away), yet ones VERY far away may have an effect, if they are really big fires. So a small fire 500 feet away would have no effect. A small one 1 feet away would have a big effect. A really really massive one in Seattle would have a small effect on someone in Columbia.

And I need to do this on a sphere, be able to handle “fires” anywhere on the sphere, handle a large set of fires (many millions), and need to be able to do it fast in the DB.

I’m not sure even sure if I’m thinking about it correctly – maybe it should be some kind of heat map that’s laid on top of a sphere, and the map is changed when a fire starts, so given A I can just get that areas temp from the heat map. But on the other end of it, I can’t pre-calc every possible point on the sphere that the new fire effects.

AE mothballed

So it's really been mothballed since 2003. I think the idea was cool, but the hardware wasn't there. Kinda wish I had worked more on it, as I would have been waaaaay ahead of the location-aware pack that's now around.

The site was moved a while ago to the new dedicated server, and the SQL wasn't working. Spent some time tonight to get it going again, with a note the site is basically a archive.