Twitter recently added the ability to force HTTPS, thereby thwarting wireless traffic sniffers like Firesheep.
Log into Twitter, go to your account settings page, and check the box at the bottom marked “Always use HTTPS.”
While you’re at it, go set Facebook to use HTTPS only and enable two-factor authentication on your Google account.
I was recently sent for a week to Sydney, Australia on business for a week. Having only been out of the US twice before (once to Aruba, and once to Canada, which doesn’t really count), I wasn’t really sure what to expect. Plus, it being a business trip, I didn’t expect to have much time for tourism. Luckily, we got a little more time than I expected to enjoy the area.
When I left home, it was snowing and icy, enough that I had to take the train to the airport rather than getting dropped off. It’s the end of Summer in Australia, though, so I checked my coat with my luggage and made the flight to LA, where, after a six-hour layover, I got on the 15-hour V Australia flight to Sydney.
The flight actually sounds worse than it is. V Australia has little individual screens in the back of each seat and a library of movies, TV, music, and games to entertain you. It wasn’t a short flight, but I had enough to keep me busy between that and my Kindle that the time went by faster than expected.
I and my coworker, Derek, left on Thursday, February 24, at 11:40a and we got into Australia on Saturday, February 26, at 6:15a. You lose a lot of time on the flight, plus you cross the international date line, so you lose a day there.
We took a taxi from the airport to our hotel, the Sydney Harbour Marriott at Circular Quay. We were lucky in that they already had our rooms ready, so we were able to check in and take a rest before heading out and taking advantage of our weekend for tourism. My room had a view of the Sydney Opera House, which made it very nice to wake up and peek outside in the morning.
After dropping off our stuff, we headed over to the Sydney Opera House and took a tour of the inside, learning about the architect, Jørn Utzon, and the way in which it was constructed. It was a very interesting tour and you get to see a lot of stuff that you don’t normally see since most of the time the views are of the outside, not the inside.
I think the thing that I found most interesting was the set of tiles on the outside of the Opera House. When you see it on TV, the Opera House looks totally white, but the tiles are actually a mix of white and cream color, so when you’re up close, there’s a different pattern to it. There are 1,056,006 ceramic tiles in a sort of chevron pattern. They’re self-cleaning, with the rain doing all the work. They’ve never had to replace a tile since construction completed in 1973. And there are no gutters on the building - the rain washes into the spaces between the tiles, runs down the outside, and back into the harbor.
The rest of Saturday was spent sort of milling about the city, just getting a feel for things. We had lunch at the King Street Brewhouse, walked past the botanical gardens, but generally didn’t have a destination. The heat and humidity took some getting used to, with the air thick like molasses and having hopped pretty much straight out of snow and ice into summertime.
Sunday morning I got up early and made it over to Sydney Wildlife World as it opened at 9:00a. It was a little cloudy and rainy, so the heat and humidity was accentuated quite a bit. Wildlife World was actually really cool and you get to see everything from butterflies (in an enclosure, flying all around you) to wombats and cassowaries. I got there as the koalas were being fed, so while normally they are asleep from 18-22 hours a day, I got to watch a couple grabbing eucalyptus branches and eating breakfast. I also got to pet one of the koalas (named Sid) and get my picture with him. Finally, after the rain started settling down, they put some food out for the kangaroos and they hopped out to eat… and they let us pet the kangaroos, too. The kangaroo I petted was named Merv. (I didn’t get my picture with Merv since there was quite a line to come up and pet him, but I did get a picture of Merv.) The keeper in the exhibit mentioned that Merv has a pretty playful attitude and has been known to hop over the knee-high fence in the enclosure and wander around where the guests are.
After Sydney Wildlife World, I headed up to The Rocks area in Sydney to do the Sydney Harbour Bridge Climb. It’s not a cheap endeavor, but it’s definitely worth the time and money. Derek went as well, and we had a group of five climbers (counting us and the tour guide, Simon). We went all the way up the bridge on the inside arch, climbed to the very top, and then came down the opposite inside arch. We got to see quite a bit about the inner workings of the bridge and the views of Sydney were brilliant. It’s reasonably exhausting, though, taking 1400 steps and burning roughly 500 calories (per Simon).
We had lunch after the bridge climb at the Lord Nelson Brewery. I had a fairly tasty porter called “Nelson’s Blood” and a pizza with shrimp on it.
We wandered around for a bit more, but after the bridge climb, we were pretty much toasted, so we took a break until dinner. We thought we’d try the bar at Luna Park, since it’s supposed to have a nice view of the harbor, but they don’t really have a menu as such, so after having taken the train there, we caught the ferry back and had dinner at the Opera House Bar.
Monday was our first day at work, but after work we headed over to Manly Beach on the ferry and had dinner at a local place, the Steyne hotel. At least, I think it was that; I am sort of blanking on the name of the place and Google Maps street view is telling me Steyne, so… there you go.
Tuesday after work we headed out with another coworker, Mike, and we had dinner at The Local Taphouse. They have a ton of local beers and you can get a “tasting paddle” where you get a small amount of five different ones to try. I had that and probably one of the best burgers I’ve ever had in my life. Very good, highly recommended.
Wednesday after work dinner was at Redoak Boutique Beer Café where I had some pretty tasty bangers and mash. We did a little more trinket shopping, but generally speaking, we took it pretty easy.
Thursday was our last full day at work. After work we went out with our co-worker, Tim, who makes the trip regularly. He showed us a nice place called the Belgian Beer Café for dinner, where I tried kangaroo. Tastes a lot like beef.
Friday being our last day (well, half day, since it was primarily travel), I got up early, had breakfast, and made one last trip around the Circular Quay area and the Sydney Opera House again. Then… train to the airport and the long flight(s) home.
My “I never travel” uneducated impression: Sydney really reminds me of a combination of Portland, Seattle, and Victoria BC. I felt very much at home walking around, the city looked like walking around downtown Seattle, and some of the historic buildings felt a lot like Victoria BC. It was a laid back atmosphere, nice and easy going. Oh, and there’s a nice bridge (like Portland!) and an Opera House (well, not like Portland). I had a great time checking things out and saw a lot of things I’d never seen while still being in a comfortable, familiar environment. I will definitely have to go back someday on vacation and spend more time not only seeing things around Sydney but also venturing out to other locations around Australia.
I posted a bunch of pictures of the stuff I saw over in Picasa (but only a fraction of the 550+ photos I took). Go check that out if you’d like to see more.
From a conversation at today’s staff meeting…
Dev 1: I’ve been catching up on all the old James Bond movies recently. We just watched Dr. No last night.
Me: Oh, that’s a good one. Hey, which is your favorite Bond? Actor, not movie.
Dev 1: Well, let’s see, there’s Sean Connery, George Lazenby, Roger Moore, Timothy Dalton, Pierce Brosnan, Daniel Cra-
Dev 2: Chuck Norris.
Me: What?
Dev 2: Chuck Norris. I saw this web site that says he can do anything.
So, folks, there you have it: Chuck Norris is the best James Bond.
I’ve blogged before about getting Typemock, NUnit, and NCover all working together in MSBuild. Though that’s admittedly a tad stale, with a bit of tweaking the contents of that article still apply.
I got a question about running tests that use Typemock Isolator outside of Visual Studio, though, so I figured I’d post this article with some additional info and clarifications.
First, the setup:
If you have different versions of these tools, you may need to tweak things. Also, I’m building on a 64-bit machine, so you may see some paths referring to 32-bit over 64-bit tools because MSTest is a 32-bit runner so you need to use the 32-bit NCover to get coverage.
When you have Typemock Isolator installed, running tests through the built-in Visual Studio test runner “just works” because Isolator installs a Visual Studio add-in helper. To get coverage, you can use TestDriven.NET to “Test With -> NCover” and it works great.
If you want to run coverage outside of Visual Studio, though, there are a few things you might think to try, some of which work and some of which don’t.
THE BIG TAKEAWAY: You have to start things in a specific order.
If you don’t start things in the right order, your tests won’t work and you won’t get the expected results.
WHY IS THAT ORDER REQUIRED?
The way Isolator works, it’s sort of a “pass-through profiler.” NCover is a profiler, too, which is how it takes coverage statistics. You can only have one profiler running at one time. The cool “trick” Isolator does is that it “links” with other profilers so calls pass through Isolator first, your mocks get inserted, and then pass along to the linked profiler like NCover. You can actually watch Typemock switch registry entries around on the fly when you start and stop it - it’ll temporarily put itself into the registry where you’d expect to see NCover, so if you “start NCover” you’re actually starting Typemock, which then chains in NCover.
However, if you try to start the other profiler like NCover first, the linking doesn’t happen so your mocks don’t show up when you expect them. Problems.
Given that, let’s talk about ways to run Typemock Isolator and get coverage when outside of Visual Studio.
Running things through a build script is the most common and recommended way of doing things. It allows you to automate the whole build process and use the same script on a developer machine and in a continuous integration server.
Let me drop some code on you and then we’ll walk through it:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="All" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<PropertyGroup>
<!-- Coverage logs and such will be placed here. -->
<LogDirectory>$(MSBuildProjectDirectory)\log</LogDirectory>
<!-- Build configuration (Debug or Release). -->
<BuildConfiguration>Debug</BuildConfiguration>
<!-- Path to the NCover 32-bit installation (MSTest is 32-bit). -->
<NCoverPath>$(ProgramFiles)\NCover\</NCoverPath>
<!-- Path to the NCover build tasks (different path than NCover 32-bit on a 64-bit machine). -->
<NCoverBuildTasksPath>$(ProgramW6432)\NCover\</NCoverBuildTasksPath>
<!-- Path to the Typemock Isolator installation. -->
<TypemockPath>$(ProgramFiles)\Typemock\Isolator\6.0\</TypemockPath>
<!-- Path to the unit test assembly for easier test execution. -->
<UnitTestAssembly>$(MSBuildProjectDirectory)\CoverageDemoTests\bin\$(BuildConfiguration)\CoverageDemoTests.dll</UnitTestAssembly>
</PropertyGroup>
<!-- Get the Typemock and NCover build tasks. -->
<Import Project="$(TypemockPath)\TypeMock.MSBuild.Tasks"/>
<UsingTask TaskName="NCover.MSBuildTasks.NCover" AssemblyFile="$(NCoverBuildTasksPath)Build Task Plugins\NCover.MSBuildTasks.dll"/>
<Target Name="All" DependsOnTargets="Clean;Compile;Test" />
<Target Name="Clean">
<Message Text="Removing build output artifacts in preparation for a clean build." />
<RemoveDir Directories="$(LogDirectory)" ContinueOnError="true" />
<RemoveDir Directories="$(MSBuildProjectDirectory)\CoverageDemo\bin" ContinueOnError="true" />
<RemoveDir Directories="$(MSBuildProjectDirectory)\CoverageDemo\obj" ContinueOnError="true" />
<RemoveDir Directories="$(MSBuildProjectDirectory)\CoverageDemoTests\bin" ContinueOnError="true" />
<RemoveDir Directories="$(MSBuildProjectDirectory)\CoverageDemoTests\obj" ContinueOnError="true" />
</Target>
<Target Name="Compile">
<Message Text="Compiling the solution." />
<MSBuild Projects="CoverageDemo.sln" Targets="Build" Properties="Configuration=$(BuildConfiguration)" />
</Target>
<Target Name="Test">
<MakeDir Condition="!Exists('$(BuildLogDirectory)')" Directories="$(BuildLogDirectory)"/>
<CallTarget Targets="Test_BuildTasks;Test_CommandLine" />
</Target>
<Target Name="Test_BuildTasks">
<Message Text="Testing with Typemock and NCover build tasks." />
<TypeMockStart Link="NCover3.0"/>
<NCover
ContinueOnError="false"
ToolPath="$(NCoverPath)"
TestRunnerExe="MSTest.exe"
TestRunnerArgs="/testcontainer:"$(UnitTestAssembly)""
IncludeAssemblies="CoverageDemo"
LogFile="$(LogDirectory)\Test_BuildTasks.log"
CoverageFile="$(LogDirectory)\Test_BuildTasks.xml"
IncludeAutoGenCode="false"
RegisterProfiler="false"/>
<CallTarget Targets="__TestFinally"/>
<OnError ExecuteTargets="__TestFinally"/>
</Target>
<Target Name="Test_CommandLine">
<Message Text="Testing with Typemock and NCover command lines." />
<PropertyGroup>
<!-- Path to Typemock Console Runner. -->
<TMockRunner>$(TypemockPath)TMockRunner.exe</TMockRunner>
<!-- Path to NCover.Console Runner. -->
<NCoverConsole>$(NCoverPath)NCover.Console.exe</NCoverConsole>
</PropertyGroup>
<Exec Command=""$(TMockRunner)" -first -link NCover3.0 "$(NCoverConsole)" //x "$(LogDirectory)\Test_CommandLine.xml" //l "$(LogDirectory)\Test_CommandLine.log" //a CoverageDemo MSTest.exe /testcontainer:"$(UnitTestAssembly)"" />
</Target>
<Target Name="__TestFinally">
<!-- Make sure we stop Typemock whether there's an error or success in the tests. -->
<TypeMockStop/>
</Target>
</Project>
Now, let’s walk through it.
The first thing we do is set up some helpful properties. This will make creation of the various command lines and such a little easier. In this case, it’s mostly paths to tools.
Next we include the Typemock and NCover build tasks. That way we can use those to run our tests.
The “All,” “Clean,” and “Compile” targets are standard fare.
The “Test” target creates the folder where we’ll dump our coverage logs and then fires off the unit testing.
Now we get to the interesting bit: Showing the two ways you can run tests with coverage.
The Test_BuildTasks target shows coverage using the provided build tasks. This is the recommended way of doing things since the build task interface makes your script a lot more readable and you get some “compile time checking” in case you mistype one of the build script attributes. Plus, in some cases the build script tasks make things a little easier to specify than the longer, more cryptic command lines. You’ll notice that we’re starting things and stopping them in the order mentioned earlier. That’s important, and it’s why this works.
The Test_CommandLine target shows coverage using a command line executable. Typemock Isolator comes with a program called “TMockRunner.exe” which is a lot like NCover.Console.exe that comes with NCover - it lets you start up a process that will have Typemock enabled on it. If you dissect that big long command line, you’ll see:
In the command line version, we don’t have to explicitly shut down Typemock Isolator because it’s only enabled for that one process, just as NCover.Console.exe only enables NCover for the one process it starts.
I showed you a command line in the build script example above, but you don’t have to use it inside a build script. It’ll work just as well outside the script environment. The only downside to using it alone is that you won’t be able to use the handy variables to make the command line more readable the way you can in the build script, but if you make a little batch file or something with the command line in it, that’ll work perfectly.
NCover Explorer offers a way to start an application and profile it from right in the UI.
This won’t work the way you think because NCover Explorer tries to start NCover first. Remember the critical ordering, above, where Typemock Isolator needs to be started first? That doesn’t happen here. NCover Explorer expects to start NCover straight away. So how do you get it to work?
Start NCover Explorer using TMockRunner.exe and Typemock will be enabled during your test runs. A sample command line is as follows:
"C:\Program Files (x86)\Typemock\Isolator\6.0\TMockRunner.exe" -first -link NCover3.0 "C:\Program Files\NCover\NCover.Explorer.exe"
When you run that, the console window where you started NCover Explorer will stay open. Leave it. Now when you set up your project, set the application to profile as MSTest.exe and set your “testcontainer” to your unit test assembly:
And for NCover Path, make sure you point to the 32-bit version of NCover.Console.exe because MSTest.exe is 32-bit:
Now when you click the “Run Coverage” button, things will work as expected because TMockRunner.exe has enabled Typemock Isolator inside NCover Explorer.
I know we’re using MSTest in this example, but I figured a quick note was in order:
If you’re using, say, NUnit and want Typemock to work inside the NUnit GUI, you need to do a similar trick as we did in NCover Explorer, above
Hopefully this helps you get your tests running with Typemock Isolator outside Visual Studio. Happy testing!
I came across this trick while perusing the Autofac code base with the new MVC3 integration. You no longer have to register the HttpModule that disposes of request lifetime scopes because they do it for you dynamically. Figuring out how they did it revealed two really cool little tricks I’ve not seen documentation on.
Trick #1:System.Web.PreApplicationStartMethodAttribute
.NET 4 adds a new attribute that allows you to programmatically do things just before application startup (that is, before Application_Start in your Global.asax). ASP.NET MVC3, for example, uses this hook to register build providers for the Razor view engine so you won’t have to do it manually in web.config.
To use it, first create a static class with a static method in it that contains your application startup logic. Be sure to guard against it getting called twice by having a flag indicating if it was called (sort of the way you track whether Dispose was called):
namespace MyNamespace
{
private bool _startWasCalled = false;
public static class PreApplicationStartCode
{
public static void Start()
{
if(!_startWasCalled)
{
_startWasCalled = true;
// Do your startup logic here.
}
}
}
}
You don’t have to call your class “PreApplicationStartCode,” nor do you have to call the method “Start,” but that seems to be the convention.
Once you have that class and method, mark your assembly with the attribute and point to your method:
[assembly: PreApplicationStartMethod(typeof(MyNamespace.PreApplicationStartCode), "Start")]
When the application starts, the
System.Web.Hosting.HostingEnvironment.Intialize() method calls
System.Web.Compilation.BuildManager.CallPreStartInitMethods() (all of
that is internal, of course) and magic happens - your application
startup logic runs.
Trick #2:Microsoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility.RegisterModule
The Microsoft.Web.Infrastructure assembly seems to have appeared along with MVC3 and WebMatrix. The DynamicModuleUtility.RegisterModule method is a ridiculously helpful and equally ridiculously undocumented method that allows you to add an IHttpModule to the request pipeline programmatically so you don’t have to put an entry into web.config. You just pass it the type of the IHttpModule implementation and it gets added to the pipeline:
DynamicModuleUtility.RegisterModule(typeof(MyNamespace.MyHttpModule));
The only catch is… you need to call it just before application startup. (See where I’m going with this?)
Tie it together: Call DynamicModuleUtility.RegisterModule() from inside PreApplicationStartCode.Start() and you can programmatically add HttpModules to the request pipeline.
Pretty nifty, huh?
Again, I saw this first in the Autofac codebase, so props to Alex Meyer-Gleaves (who added that code to the MVC3 support in Autofac) for figuring that one out.