Main Contents
July 4, 2008
WordPress.com, the commercial blog hosting company that uses blog software from WordPress.org, is adding Google Gears support to their hosted blog service. Initially, this will only speed up use of the blog administration pages by caching the scripts and images locally.
This isn’t really the best use of Gears, since the browser will cache content as it’ is accessed, but it’s a reasonable first step. Clearly the longer term goal (in the upcoming WordPress 2.6 release?) is to support blog post editing and administration while offline. I imagine this prequel to full offline mode benefits WordPress.com (by reducing server traffic) more than end users.
Some of the comments on the WP.com blog post indicate little or no noticable performance boost for the end user. If you have a fast Internet connection, that’s probably going to be the case. It sounds like what WP.com is using Gears for (for now) is to prefetch the admin scripts, pages, and images to the local cache. WP.com bloggers who would see the greatest performance improvement would be those on a slow or crowded Internet connection.
I was surprised to see on other blog posts on this news comments expressing fear of “sending all their data to Google” and the like. That’s not what Gears does. Gears is a browser plugin to enable a web site (wp.com) to store data on the client. None of your WP.com data should ever be sent to Google, period. I don’t think WP.com even has to have a reference to Google to get the Gears JavaScript - the Gears JS code can be completely hosted on the WP.com server.
Some will raise the concern “What if Google embeds a trojan horse in the Gears code?” Well, it’s open sourced so somebody will see it if there is such a thing, so this shouldn’t be a real concern.
There is no issue of Google getting access to WP.com blog data as a result of using Gears.
Tags: blogging, Google, Google Gears, offline web apps, wordpress
Filed under: Web |
Comments (0)
July 2, 2008
The PicLens guys and gals have rolled out a new 1.7 release with quite a few new navigational aides and features. I’m a little late to the party with this post, as 1.7 went public a few weeks ago while I was distracted with bootstrapping the new job at Microsoft.
The three headliners for this 1.7 release are a new “discovery” mode for finding cool content you didn’t know about, an Amazon search feature, where you can search and browse photos of Amazon products, and a “return to PicLens” button that takes you from the browser back to what you were last looking at in PicLens.
Discovery mode is a feed aggregator - it pulls together content from all over the web into categories like news, sports, entertainment, and so forth. For those of you who love PicLens but were having trouble finding stuff to look at, Discovery is for you. ;>
The Amazon search & browse is pretty much what it sounds like. You can enter a search term and see results returned from the Amazon store. Click on an item and you go directly to the Amazon product page where you can purchase it or see reviewer’s comments, etc. (I wonder who gets the affiliate fee for sending you to Amazon? Hmmm…)
Return to Piclens is my baby - the last Piclens feature I worked on at Cooliris. When you click on the attribution link of an item in PicLens (the little blue globe in the caption bar of the selected item), PicLens opens the original web page containing that item in the web browser, and PicLens closes its full-screen display.
When your curiousity about that item has been sated, how do you go back to what you were looking at in PicLens? Prior to the 1.7 release, you had to fire up a new PicLens session, reconstruct the search query you used last, and then scroll back to where you were before you hopped out to the browser.
Now in Piclens 1.7, when you click on an attribution link to view a page in the browser, PicLens displays a translucent “Return to Piclens” button in the bottom right corner of the screen. When you’re ready to go back to PicLens, just click that button and the PicLens full screen display returns, showing exactly where you left off. You can even navigate around in the browser (click on links, view different pages) before returning to PicLens.
I think Return to Piclens is only implemented in the Windows versions of the PicLens plugins (IE and Firefox) - for the moment. The Mac guys were busy with another project while I was working on this, but they’ll get this return button implemented on the Mac side of the house soon I’m sure.
There’s also a navigation helper in PicLens itself that appears at the top of the display when you start a new PicLens session instead of using the Return to Piclens button. This is another handy way to go back to the site or search query you were last looking at in PicLens.
Congrats to the PicLens team! Can’t wait to see the next round of stuff. :>
Tags: Amazon, browser plugin, PicLens
Filed under: Work |
Comments (0)
July 1, 2008
I’ve just received a letter from Google that personal data of Google employees hired prior to December 31, 2005 may have been stolen in the May 26 burglary of Colt Express Outsourcing Services. No credit card numbers were in the stolen data, just names, addresses, SSNs - all the info needed for a thief to open new accounts using your identity.
Colt was an external contractor to Google handling HR functions such as benefits, 401k plans, etc. Google itself was not burglarized.
The letter from Google also offers to cover the cost of a one year subscription to a credit report and identity theft monitoring service. Well, that’s something at least. I appreciate Google’s gesture.
Tags: burglary, Colt, Google, identity theft, security breech
Filed under: Misc |
Comments (0)
June 30, 2008
There has been a bit of pot-stirring on the blogs this weekend. Dare Obasanjo reflects on recent migrations of Google engineers to Microsoft, using the “e” word (exodus). Dion Almaer fires back, pointing out that people move between companies all the time, hardly justification for the “exodus”.
Both are right, and both are wrong.
First off, I have to agree with Dion that Dare’s use of “exodus” is a bit excessive. A dozen or two Googlers joining Microsoft would be an exodus when Google was a few hundred employees, but a dozen out of 20,000? Perhaps noteworthy on a case by case basis, but not an exodus.
However, Dare does make some good points that Dion sidesteps by omission. Google’s interview and hiring process are infamous, both from those who didn’t make the cut and from those who did. Dare cites Sergey Solyanik as an example of a dispassionate Googler taking up the Microsoft yoke and Svetlin Nakov’s close encounter with the b0rg. Both mention the oddities of the Google hiring system.
From my personal experience, I’d say that Google’s hiring system is highly optimized for acquiring fresh college grads straight out of school - bright, idealistic, inexperienced, don’t know what they want to do with their lives, few or no time demands in their home life, and would be thrilled to do anything at a place as cool as the big G. The Google interview style - evaluating the person as a whole on intelligence and creativity, with no particular interest in experience and no particular job title in mind - reflects that.
A Google offer letter looks more like a college acceptance letter than a job offer: “Congratulations! You’ve been accepted. Your base pay is X. Please show up to orientation on Monday to receive your work assignment.” In many cases, you literally don’t know what project you have been hired into until you step out of orientation. As you exit orientation, you step into a sea of managers holding up signs with names on them, just like limo drivers waiting outside airport customs.
For new college grads, I’m sure this is all terribly exciting (and vaguely familiar to college life), but for old farts like me that have opinions about the world and know what they don’t want to work/waste time on, it leaves a lot of room for nasty surprises. The job you get can have little or nothing to do with the people you interviewed with or the topics that were discussed. Why? Because the people doing the interviews are in no way related to the job that needs to be filled. Matching new hires to job openings is done by a small committee dealing out cards to projects in priority order. Your name gets put into that deck only after you accept the offer blindly.
These odd procedures make for a very efficient hiring machine. It’s a great way to feed Google’s insatiable appetite for new hires, but it leaves those being hired feeling distinctly bovine.
On my first day at Google (Oct 31, 2005 - everyone was dressed up for Halloween), I met my manager after orientation and was informed what I had been assigned to work on. In the space of about 15 minutes, I decided that wasn’t worth the commute or the money and headed for the door. I give a lot of credit to my manager (Linus Upson) for being quick on his feet and catching me before I had a chance to slam the door. He asked if instead I might be interested in this other project that he had been trying to get off the ground. I was, and that became Google Gears.
If you’re a senior engineer looking for a senior engineering position in a particular topic at Google, don’t go through the front door.
Dare makes a few observations at the end of his post:
1. Startups don’t have career paths for employees.
Agreed. The draw of a startup is the chance to get rich when the company “makes it big” or gets bought by a bigger company desperately seeking innovation. But let’s face it - the days of employees becoming millionaires on company stock are long gone for Google, Microsoft, and Yahoo. I knew I was too late to the stock party when I joined Google in 2005.
2. There is no legacy code at a startup, so fast and loose rules the day.
Agreed. Startups often pride themselves on how many nights and weekends went into the latest release. They also often don’t know exactly what code went into that latest release.
2b. As organizations mature, they add PROCESS to protect against human failures and past pain points.
Agreed, but this is a double-edged sword. Some startups pride themselves on having no process at all, because if you have no process then you have clearly avoided the evils of bureaucracy that live under the process banner.
Microsoft’s greatest enemy is itself. As a company that has succeeded despite decades of litigation and human error, Microsoft has accumulated so much process that an entire employment category spontaneously evolved to deal with it: PM! Program Manager, Product Manager, or Process Manager? You decide.
I’m pretty sure I fall into the category of senior developers Dare mentions as having an appreciation of the value of process. I definitely value dedicated testing, repeatable testing, and comparing results over time. The last time I saw all of these was at Borland in the mid 90’s. I haven’t seen them since, in all my wanderings. Others have commented on Google’s lack of testing discipline. I’ll just add that Microsoft’s corporate commitment to process that Dare mentions is no guarantee of quality either. Processes created out of pain exist primarily to protect the corporation more than anything else.
3. There is less politics at a startup.
True, but not for Dare’s reasons of consensus. Microsoft is all about consensus. For startups, though, it’s not that startups can reach consensus more easily than a larger company because they’re smaller / have fewer people to bring to consensus, it’s that startups don’t have to bother with consensus at all. Startups can often trace their creative energy back to one or two key people, key decision makers who make decisions, be they right or wrong. In some companies these thought leaders are on the management side, in others they’re on the engineering side with support from management.
Gary Whizin, R&D manager of the Turbo Pascal / Delphi team during Borland’s heyday, made it clear and simple: “We value your input, we need your input, but let’s be clear: this is not a democracy.” Gary didn’t make the decisions, and he wasn’t overly concerned with building consensus, but he did have the uncanny ability to get decisions made by the people who needed to make them. Many times “all” Gary had to do was lay out options A, B, and C that the expert had discussed earlier and say “Ok, now pick one.” They’d squirm, they’d protest, but more often than not a course would be plotted by the time Gary left that meeting.
Microsoft isn’t ideal either
We can pick apart Google’s peculiar hiring process all day, but that doesn’t mean Microsoft’s process is beyond reproach. Many people in the Delphi community were surprised I went to Google and not Microsoft as many Borlanders before me had. Why did I choose Google over Microsoft in 2005? Because Google made an offer, while Microsoft continued to drag its feet.
Microsoft’s recruitment system is highly segregated - plenty of inside recruiters, but none of them talk to each other. A recruiter is responsible for filling the job openings of a particular team. If a particular candidate isn’t a perfect match for that team, the recruiter doesn’t seem to have much incentive to shop that candidate around to other teams, or to inform the candidate of other possibilities. In six months of off and on conversations with Microsoft in 2005, I often found myself informing Microsoft of what other groups within the company were looking for!
The main obstacle between me and Microsoft was that I had (and continue to have) no interest in moving to Redmond. Microsoft is extremely Redmond-centric. Google is even more MountainView-centric. Both place a lot of emphasis on face time - in meetings, meetings, and more meetings. It is extremely difficult to break into either of these companies as a remote employee. You have to find a team that is motivated to work with you even across the remote chasm and a manager who knows how to manage remote staff effectively. That requires time and perseverance. In other companies, the notion of having a remote team member is less exotic, even commonplace. Chad Hower runs his whole software team as a network of remote workers! A truly distributed system.
Microsoft is gradually warming up to the idea of remote workers. This is partly driven by the perpetual office space crunch in Redmond and the terrible traffic congestion in the whole Redmond / Seattle area. More of the corporate internal apps work over remote VPN connections now (compared to a year ago), and the VPN itself is a thousand times better (more reliable) now running on Vista than it was a year ago on XP.
Dare’s blog post will undoubtedly stir up a lot of responses, both from the Google-can-do-no-wrong fan club and from Google employees who still drink the corporate Kool-Aid. I do find movements of individuals between projects or companies interesting news to follow. Changing jobs is never an easy step to take, and often justified with emotions and reasons laced with disappointment or disillusionment with the old company and perhaps overly optimistic hopes for the new company. Rarely do such movements of individuals have a significant impact on a well-run company.
Tags: career, Google, jobs, Microsoft, recruitment, workplace
Filed under: Work |
Comments (9)
June 26, 2008
In the midst of writing some Silverlight code, something struck my funny bone: .NET has an Application.Current.
“Current” suggests “now”, and its existance suggests there was a need to distinguish “now” from something else. Does that mean there could be an Application.Next? Application.Future? Application.Past? Those could save me a lot of effort. How will I fix this in the next release? I’ll just take a peek at Application.Next…
Chuck chimes in: “No, but there is an Application.Torrent.” That must be the current that lets the application get away from the debugger.
Beware the Application.Eddy! I’ve had threads stuck in there for days.
A few minutes later Chuck answered a question with “Use SynchronizationContext.Current. And no, there’s no Future or Past!”
Tags: .NET, silliness, Silverlight
Filed under: Programming |
Comments (0)
June 25, 2008
In getting back up to speed with Silverlight, and in particular the new Silverlight 2 beta 2, I’ve been surfing through the many quickstart topics on various web sites. While skimming “Receiving Plain XML Messages with Silverlight” these words lept out at me:
note: The WebClient class does not currently support cross-domain calls.
Say what?
The article then proceeds to show how to make an XML call using Silverlight’s WebClient class, and oh by the way it’s a cross domain call.
Nice job, guys.
Here’s what that article probably meant to say, but managed to get lost in the words:
Silverlight’s WebClient class supports cross-domain HTTP requests *IF* the target server allows cross-domain requests.
It really is that simple.
To configure a server to support cross-domain requests, read “How to: Make a Service Available Across Domain Boundaries“.
Tags: cross-domain, Microsoft, Silverlight, XDR
Filed under: Programming, Web, Work |
Comments (0)
June 21, 2008
So here I am configuring my dev machine in Redmond from my laptop in my home office in Santa Cruz. I’m all VPN’d and security card authenticated up the wazoo, installing this and configuring that on the dev machine via Remote Desktop. (Praise be to RD!)
I get Hyper-V set up on the dev machine so I can create and destroy virtual machine configurations with impunity while developing and testing on beta stuff. I create a new VM in Hyper-V, allocate some RAM and HD to it, and tell it to boot off the network so I can install a stock Vista configuration from corpnet (corpnet does have some pretty cool services now and then). It boots up, and I can see in the little thumbnail that something is alive in there.
I need to open that VM in a console so I can drive it. Connect to Virtual Machine… bzzt! Nope. Unknown error. Try again a different way. Bzzt! Nope.
Hmm. Time to read the beta release notes. Sure enough, there’s a one-liner in the readme: Hyper-V does not support connecting to a virtual machine within the context of a Terminal Services (aka Remote Desktop) session. Nuts. Understandable, but not much help to me.
How to work around this? Hyper-V was built with server management in mind, so perhaps the management piece could be installed on my Vista laptop and remotely connect to the virtual machine on the dev machine? Bingo! I busily install the Hyper-V tools on my Vista machine, fire up the app, and tell it to connect to the dev machine.
Bzzt! “Not authorized.”
Uh-oh. That’s not good, because for me anyway it’s never a short path to resolve authorization issues.
A quick web search later, I discover with delight that John Howard has already covered this remote management of Hyper-V in exquisite detail, for several different machine and network configurations: client and server in a workgroup network, client and core server, client and server in a domain network, and a domain client connecting to a workgroup server. Fabulous info, with detailed steps on how to solve this situation.
Naturally, none of those scenarios match my situation. I have a workgroup client trying to connect to a domain-bound remote Hyper-V server.
I know exactly what the problem is. Hyper-V uses the current user on the client machine as the login credentials on the server machine. (This may be because my login on the laptop has administrator rights, but I’m not willing to give that up to run this vm thing) The problem is that my non-domain laptop login id will never be accepted by the domain-bound remote machine.
Or will it?
Most of John’s 4 scenarios are the same steps but with minor variations in where to apply what. John’s scenario #5, domain client to workgroup server, contains a key step that provided an Aha! moment for me in solving my scenario. John shows how to use the Win32 cmdkey utility to define a user id and password to use when making service API calls to a particular remote machine. That’s what I needed to get my domain-bound remote dev machine to accept Hyper-V management API calls from my non-domain local machine.
Here are the steps I used to get this working:
- Create a user account on the domain-bound Hyper-V server. This user account should be a local user to that server, not a domain user. It does not need administrator rights, and it does not need to match your login id on your local machine. For illustration purposes, let’s call it “hyperdan” on “devmachine”.Note that John’s example creates a new user group so that rights can be assigned to the group (and all its members) rather than for each user one at a time. Since this is my dev machine and I don’t anticipate ever needing to give anyone else Hyper-V admin rights on this machine, I skipped the group creation step.
- Enable Firewall WMI rules on server. Same as John’s step 2 in his Part 5 post.
- Allow authenticated DCOM access on server. Same as John’s step 3, using the “hyperdan” id created above.
- Allow authenticated users access to remote WMI namespace on server. Same as John’s step 4, except that I used the user id directly instead of giving the rights to a user group that the user id is a member of.
- Configure AZMan on server. Same as John’s step 5, except I used the user id directly instead of the user group.
- Reboot Server. Don’t skip this step.
- Create a firewall exception for MMC on client. Same as John’s step 6.
- Allow annonymous callbacks on client. Same as John’s step 7.
- Set credentials for the remote server (on client). Same as John’s step 8, using “devmachine\hyperdan” as the remote machine and user id.
- Run Hyper-V Manager on client. Same as John’s step 9.
If all you want to do is connect to a particular VM on the server, use vmconnect.exe in the Hyper-V program directory on the local machine. Enter devmachine for the machine name. Click on the Virtual Machine dropdown and wait a second or two for it to populate. Select the VM you want and away you go!
Connecting directly to the VM using Hyper-V’s vmconnect is great for doing machine-level stuff like installing operating systems or anything else that requires a reboot. Unlike Remote Desktop, which loses the connection when the machine reboots, the VMConnect console stays connected, showing you the BIOS POST and boot sequences. How can it do that? Because VMConnect is outside the virtual machine that’s being rebooted. You’re connected to the hypervisor, which is always on and always watching as long as the physical machine is not powered down.
However, VMConnect is not as smooth as Remote Desktop / Terminal Services, presumeably because VMConnect does not have the benefit of intercepting high-level APIs like RD and TS. VMConnect has only the BIOS and screen memory to track state changes in the VM. Cursor movement and screen updates are jumpier/chunkier and integration with the local machine’s mouse cursor is not as seamless as Remote Desktop. For example, VMConnect captures the mouse modally, requiring you to hit a keystroke to give the mouse back to the local (host) desktop. That’s fine for periodic maintenance and administration sorties, but for everyday operations that would drive me nuts.
But that’s ok, because a network-connected VM is like a normal machine in every way - including Remote Desktop connectivity. Once I get the VM into a usable network-accessible state, I shut down the VM connection and fire up a regular Remote Desktop connection to the VM. Here are the steps:
- Install the OS on the VM
- Reboot the VM on the new OS
- Join the VM to the corpnet domain with a new, unique machine name
- Disable sleep on idle in the power management options
- Enable Remote Desktop connections
- Add your domain user id to the list of users allowed to RD into the VM
- Close the VMConnection
- Fire up a Remote Desktop connection to the VM
Tada!
Many thanks to John Howard for laying out the many pieces needed to get this silly thing to work.
Tags: Hyper-V, remote management, telecommuting, virtual machine
Filed under: Work |
Comments (2)
June 18, 2008
Carnegie Mellon researchers have devised a photo analysis engine, IMG2GPS, that can make a guess as to the location of a photo based on similar photos found on Internet photo sharing web sites such as Flickr. The image analysis technique doesn’t dwell on identifying specific objects in the photo, but looks for similarities in lines and colors. Since many images on Flickr now have GPS tagged geocodes, the analysis engine can suggest that if your photo looks like these, and these are all in Utah, then perhaps your photo is of something in Utah as well.
PhysOrg.Com notes that even when the image analysis program can’t find a good location match for a photo, it often finds similar-looking locales. For example, it might not be able to name the beach in a given photo, but it is likely to note that it is similar to several other photos of beaches. Or given a photo of a narrow street in Barcelona, it suggests photos of streets in other Mediterranean towns but not American alleyways.
This is a pretty cool achievement, a step in the direction of imbuing computers with the appearance of some degree of common knowledge. My high school chemistry teacher coined the term ”a brillant grasp of the obvious.”
human: ”Where was this photo taken?”
computer: “Looks like a beach.”
Tags: computer vision, flickr, photography
Filed under: Web |
Comments (0)
June 13, 2008
Latest figures from CDF are 600 acres burned, 10 homes destroyed, currently 25% contained. CDF says it’s likely they’ll reach 100% containment by Saturday, unless there is a major wind change. The burned acreage number dropped from last estimate because the air spotters can see more of the fire now that the smoke has thinned out a lot.
Whew!
Tags: Bonny Doon fire
Filed under: Personal |
Comments (0)
June 12, 2008
For friends and family concerned about our proximity to the Bonny Doon wildfire: we’re ok. The fire area is about 5 miles south of our home (as of this writing) and heading south / southeast. It’s on the west side of Empire Grade Road that runs down the spine of Ben Lomond ridge, we’re on the east side and further north.
About 700 acres have burned so far, but CDF projects it may consume as much as 2000 acres before it can be contained, due to the steep terrain and dense forest. Their best option to contain canyon wildfires is to cut firebreaks at the ridges and try to keep it from spreading beyond its current canyon. About 1500 people in the Bonny Doon area have been instructed to evacuate. A few of them (a friend’s family and their cats and dogs) are staying at our place for the next few days.
Tags: Bonny Doon fire
Filed under: Personal |
Comments (1)