Wednesday, January 26, 2022

6075 Tagging

One of my favs from the kilted master himself, Robbie B. Served as inspiration to another of my favs Johnny Steinbeck


Wee, sleeket, cowran, tim’rous beastie,
O, what a panic’s in thy breastie!
Thou need na start awa sae hasty,
          Wi’ bickerin brattle!
I wad be laith to rin an’ chase thee
          Wi’ murd’ring pattle!

I’m truly sorry Man’s dominion
Has broken Nature’s social union,
An’ justifies that ill opinion,
          Which makes thee startle,
At me, thy poor, earth-born companion,
          An’ fellow-mortal!

I doubt na, whyles, but thou may thieve;
What then? poor beastie, thou maun live!
A daimen-icker in a thrave
          ’S a sma’ request:
I’ll get a blessin wi’ the lave,
          An’ never miss ’t!

Thy wee-bit housie, too, in ruin!
It’s silly wa’s the win’s are strewin!
An’ naething, now, to big a new ane,
          O’ foggage green!
An’ bleak December’s winds ensuin,
          Baith snell an’ keen!

Thou saw the fields laid bare an’ waste,
An’ weary Winter comin fast,
An’ cozie here, beneath the blast,
          Thou thought to dwell,
Till crash! the cruel coulter past
          Out thro’ thy cell.

That wee-bit heap o’ leaves an’ stibble
Has cost thee monie a weary nibble!
Now thou’s turn’d out, for a’ thy trouble,
          But house or hald,
To thole the Winter’s sleety dribble,
          An’ cranreuch cauld!

But Mousie, thou art no thy-lane,
In proving foresight may be vain:
The best laid schemes o’ Mice an’ Men
          Gang aft agley,
An’ lea’e us nought but grief an’ pain,
          For promis’d joy!

Still, thou art blest, compar’d wi’ me!
The present only toucheth thee:
But Och! I backward cast my e’e,
          On prospects drear!
An’ forward tho’ I canna see,
          I guess an’ fear!

Capture the Flag

WHo can get an ad to show up here?

Monday, July 15, 2013

Googleversary

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 (http://google-engtools.blogspot.com/)

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()

First:
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"?>
<configuration>
 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedruntime version="v4.0.30319"/>
  <supportedruntime version="v2.0.50727"/>
 </startup>
</configuration>

Now Powershell can run with both 2.0 and 4.0 assemblies.

Second:
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 http://go.microsoft.com/fwlink/?LinkId=155569 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"?>
<configuration>
 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedruntime version="v4.0.30319"/>
  <supportedruntime version="v2.0.50727"/>
 </startup>
<runtime>
 <loadfromremotesources enabled="true"/>
</runtime>
</configuration>

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.


select
  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
from
  [OpQueue].[Op]
where
  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: http://msdn.microsoft.com/en-us/library/ms187928.aspx.
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 .war.zip 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 (http://hudson-ci.org/). The file was hudson-2.0.0.war.zip. 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 (http://superuser.com/questions/159260/in-mac-os-x-how-can-i-unzip-a-zip-file-without-unzipping-its-contents) on how to unzip a file without unzipping its contents. Now I have a

hudson-2.0.0.war/

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 hudson-2.0.0.war.zip

on the original file, which worked. I renamed hudson-2.0.0.war.zip

$ mv hudson-2.0.0.war.zip 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