TechStumbler
Notes from my RandomWalk in computing.
Wednesday, January 26, 2022
6075 Tagging
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 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
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
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
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