Monday, July 15, 2013


One year ago tomorrow I started my job as a Software Engineer for Google. It has been an amazing year so far, and I can't wait to get back to work tomorrow. I'm not supposed to reveal all the engineering trades secrets, but there are a few things that I can talk about that have really impressed me.

  • One codebase. The vast majority of Google's engineers check their code into a single trunk. I am continually amazed that so many engineers can work together without stepping on each other's toes.
  • Code reviews. Almost every single line of code that is committed to trunk is code-reviewed. While it's true that bugs do make it into the codebase, these code-reviews keep a consistent style while preventing errors and cross-functional issues.
  • Craftsmanship. Everyone here seems to have it, and it is contagious. Even working with simple code, I find myself writing better, cleaner code.
  • Engineering happiness. When you have this many engineers, every small improvement to the engineering process pays huge dividends. Because of this, Google spends some serious time an energy improving the engineering process.

This is just a quick sampling of what makes Google, Google. For more reading, there are some good explanations on the eng-tools blog (

Techstumbler started as a way for me to catalog all of the tech problems that I "stumbled" across, but couldn't find a good answer for elsewhere. Since joining Google, my output here has basically gone to zero for two reasons. First, while I was swimming in the deep-end for C#, .NET, Powershell in my previous job, I've had to strap on my swimmies and resign myself to shallower waters in the Java/Linux stack. Second, many, many of the tech problems I run into now relate to the Google infrastructure itself, which I can't really talk about, and wouldn't be useful to anyone not on that stack anyway.

All that said, I would like to start writing here again. I might try to post some thoughts about some of my other interests, but I'll try to keep things for the tech audience. We'll see what I come up with.

Tuesday, January 10, 2012

Loading Remote Assemblies in Powershell with .NET 4

We recently updated our entire codebase to .NET 4.0 from 3.5. There are plenty of blog posts about that process in general, so I'm going to keep this one specific to our Powershell deployment scripts.

We build our code to a central server and then use Powershell to install those build on our Development server. The upgrade to .NET 4 caused 2 problems with Powershell when we called [Reflection.Assembly]::LoadFile()

Powershell by default runs in .NET 2.0. When we tried to load our new 4.0 assemblies, we got this error:

Exception calling "LoadFile" with "1" argument(s): "Could not load file or assembly 'file://\\buildServer\Application\assembly.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
At C:\Scripts\Deployment\Deploy.ps1:XX char:XX
+ $assembly = [Reflection.Assembly]::LoadFile <<<< ($file); + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : DotNetMethodException

We need to tell Powershell to run in .NET 4.0 mode. To do that we need to create an app.config file for Powershell. In our case the file was created here: C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe.config, but YMMV based on Powershell's location. The new powershell.exe.config file looks like this:

<?xml version="1.0"?>
 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedruntime version="v4.0.30319"/>
  <supportedruntime version="v2.0.50727"/>

Now Powershell can run with both 2.0 and 4.0 assemblies.

The security features are a bit different when running 2.0 vs 4.0. This difference caused a problem when running assemblies from our Build server on our Development server:

Exception calling "LoadFile" with "1" argument(s): "An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See for
more information."
At C:\Scripts\Deployment\Deploy.ps1:XX char:XX
+ $assembly = [Reflection.Assembly]::LoadFile <<<< ($file); + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : DotNetMethodException

Now we simply add the loadFromRemoteSources switch to the powershell.exe.config file we just created so that the entire file looks like this:

<?xml version="1.0"?>
 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedruntime version="v4.0.30319"/>
  <supportedruntime version="v2.0.50727"/>
 <loadfromremotesources enabled="true"/>

Now we are successfully loading remote .NET 4.0 assemblies in Powershell. Hope this helps.

Friday, August 26, 2011

Safari User Agent Detection in JavaScript

Here's a quick snippit for detecting if a browser is Safari version 4 or 5. It works for both desktop and mobile (iPhone, iPod, iPad) versions.

function detectSafari45()
  var safariRegEx = /Mozilla\/5\.0 \([^\)]*\) AppleWebKit\/\d+\.\d+(\.\d+)? \(KHTML, like Gecko\) Version\/[45]\.\d+\.\d+( Mobile\/\w*)? Safari\/\d+\.\d+(\.\d+)?/i
  var match = safariRegEx.exec(navigator.userAgent);

  if (match !== null && match.length > 0)
    return true;
  return false;

Tuesday, May 10, 2011

Averaging Timespans in T-SQL

I'm doing some work with an operations queue. All of the operations are added to a small table on our SQL Server instance. We have a start_datetime and a stop_datetime for each operation. It took me a little time but here's a select statement for profiling the wait times for operations in our queue.

  CONVERT(VARCHAR(13),creation_date,120) as [hour],
  CONVERT(VARCHAR(8), max(stop_datetime - start_datetime), 108) as MaxWaitTime,
  CONVERT(VARCHAR(8), min(stop_datetime - start_datetime), 108) as MinWaitTime,
  CONVERT(VARCHAR(8), cast(avg(cast(stop_datetime - start_datetime as float)) as datetime), 108) as AvgWaitTime
  start_datetime > '2011-05-07'
group by
  CONVERT(VARCHAR(13),start_datetime ,120)

Here are a few things to note.
This statement will spit out the min, max, and average running time for operations in the queue that start in the same hour.
The third argument for convert is pretty handy for DATETIMEs. Here is the page where it is described:
The AVG() function doesn't work for DATETIMEs, so we need to convert it to a float and then back again to get what we are looking for.

Here's the graph we ended up with.

Seems like it's time to invest in some more processing power.

Friday, April 22, 2011

Running Hudson from OS X: the Fiasco

It took me a while to figure this out and maybe it's just because I'm not a java guy, but I couldn't figure out how to start the Hudson continuous integration tool on my Mac. I downloaded the 2.0.0 version from the Hudson site ( The file was The instructions say to run

java -jar hudson-2.0.0.war

to start up the service. I unzipped the file and ended up with a bunch of .class files and no .war. Ah, looks like I also unzipped the .war file. So then I found this nice post ( on how to unzip a file without unzipping its contents. Now I have a


directory. I ran

$ java -jar hudson-2.0.0.war
Invalid or corrupt jarfile hudson-2.0.0.war

Hmm, not sure what to do next. Somewhere in my search I read that a .war is basically just a zip file. So I tried

$ java -jar

on the original file, which worked. I renamed

$ mv hudson-2.0.0.war

and I was off and running.

So I hope this helps some other java n00bs who may have run into this. The moral of the story is .war == .zip

Friday, December 10, 2010

Moving Replicated FullText Index in SQL Server

We needed to move the location of our full text index (FTI) on a subscriber. I thought this would be a pain because the replication, but it turns out to be pretty straightforward. Here's the system I am working with:

SQL Server 2005
Transactional Replication with an Updateable Subscriber.

Here are the steps I took:

0. Make sure you have appropriate backups.
1. Point all of the apps to the Publisher because we will need to take the Subscriber offline.
2. On the Subscriber, open the synchronization status by right-clicking on Replication->Local Subscriptions-> ans selecting View Synchronization Status.
3. Stop the Synchronization Service. (This really just pauses updates).
4. On the Subscriber run SELECT name FROM sys.database_files WHERE type_desc = 'FULLTEXT'; to get the name of the FTI.
5. On the Subscriber run ALTER DATABASE [DB_NAME] SET OFFLINE;
6. Move the FTI where to it's new home.
7. On the subscriber run ALTER DATABASE [DB_NAME] MODIFY FILE (Name=[FTI_NAME], Filename = "'new/location/on/disk/');
8. On the Subscriber run ALTER DATABASE [DB_NAME] SET ONLINE;
9. Start the Sync Service in View Synchronization Status.

That should be it. Hope this helps.

Wednesday, November 24, 2010

T-SQL Query: Tables Without a Primary Keys

I used this when I was setting up a Transactional Replication system on SQL Server. I needed to figure out which tables did not have primary keys assigned.

  sys.schemas s
  join sys.tables t on s.schema_id = t.schema_id
  left join sys.indexes i on i.object_id = t.object_id and
                             i.is_primary_key = 1
where is null
order by ('.'+ asc;