Moving on from SVN_ASP_DOT_NET_HACK

I noticed that I was running TortoiseSVN in SVN_ASP_DOT_NET_HACK mode (where Subversion clients use ‘_svn’ instead of ‘.svn’ directories) unnecessarily as I don’t have silly old Visual Studio 2003 installed anymore which caused this mess in the first place.

The _svn directories work just as well as .svn, but nevertheless (due to mild OCD?), I created a batch script that ripped through my project directory renaming all ‘_svn’ directories to ‘.svn’, so I could remove the SVN_ASP_DOT_NET_HACK mode. It uses the wonderfully flexible FOR command drive the whole process. We don’t need no stinkin’ Powershell round these parts…

Save this script as something like “SvnRenameDirs.cmd” in the root of your projects folder:

:: Make script directory current
pushd "%~dp0"

:: Unhide, rename and re-hide svn dirs
for /r /d %%D in (*) do @if exist "%%D_svn" (
   attrib -H "%%D_svn" 
   ren "%%D_svn" ".svn" 
   attrib +H "%%D.svn"
)
popd

rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl,0,3 

At the end click the Environment Variables button in the System Properties dialog and remove the SVN_ASP_DOT_NET_HACK environment variable and then log out and back in again (or restart explorer.exe and TSVNCache.exe).

CTRL+TAB switching between document windows in Visual Studio

Visual Studio 2008 introduced a document switcher window that pops up when you do a CTRL+TAB. Nice idea, inspired by ALT+TAB application switching  but I find that the little previews it shows you are pretty useless. One code window looks like pretty much any other at that resolution. I prefer the previous behaviour of just immediately switching windows.

Sara Ford’s excellent series of Visual Studio tips prompted me to restore CTRL+TAB’s previous behaviour. You can do this by using the Keyboard binding page in Tools Options. In Tools > Options > Keyboard locate Window.NextDocumentWindowNav and remove the CTRL+TAB binding, then go to Window.NextDocumentWindow and assign CTRL+TAB there instead. Same drill for CTRL+SHIFT+TAB for Window.PreviousDocumentWindowNav and Window.PreviousDocumentWindow.

Sharing Google Picasa Libraries between users on the same computer

After a few years of using Adobe Photoshop Elements, last year we switched over to using Google’s free Picasa for organising our photo collection. Consecutive versions of Photoshop Elements were just getting slower and slower mainly it seemed due to waiting for the ‘kewl’ interface to redraw itself. Picasa is really slick and fast on our 2.8GHz Pentium 4 home PC. It can also upload our photos for printing to PhotoBox, and share them online using Google’s own Picasa Web Albums.

Photoshop Elements keeps all of your photo tags and collections in a ‘*.psa’ database file (which is actually Microsoft Access database). The useful thing we found about this was that we could share all our photo collection settings and tags between users. Picasa, on the other hand, stores its settings in hidden Picasa.ini files in your photo directories as well as in your local app settings user profile folder (buried in ‘Documents and Settings’ on Windows XP or the ‘Users’ folder on Vista). The problem with this is that you can’t share your Picasa library between users on the same machine as Picasa is hard-coded to look in the currently logged on user’s profile directory, and can’t be coaxed to look elsewhere, such as a shared location.

So to workaround this, you can take advantage of a feature of NTFS called junctions, which allow you to wire up one folder to another (or symbolic links, I’m not sure what the difference is, but the end result is the same). Windows Vista has a command-line tool called MKLINK which will create these. On Windows XP you will need to use the Sysinternals Junction command-line tool. Here’s what I did:

  1. Copy %LocalAppData%GooglePicasa2 and Picasa2Albums to a shared location to which all users will have Modify access. (I chose C:UsersPublicAppDataLocalGoogle on Vista, it’d be something like C:Documents and SettingsPublic on XP)
  2. Rename %LocalAppData%GooglePicasa2 and Picasa2Albums e.g. “Picasa2.old” and “Picasa2Albums.old”
  3. Use MKLINK (Vista) or Junction (XP) to create a junction from
    %LocalAppData%GooglePicasa2 to
    <SharedLocation>GooglePicasa2
    and:
    %LocalAppData%GooglePicasa2Albums to <SharedLocation>GooglePicasa2Albums
  4. Repeat steps 2-3 for each user for whom you want to share the Picasa library

Of course this may break with a future version of Picasa, so proceed with caution and don’t blame me if it all goes horribly wrong.

Microsoft Search Server and FAST

Microsoft have a new server product: Search Server 2008. Well I say “new” but it seems to be based the same technology they’ve been pushing since the days of Site Server, on which I spent most of the late 1990’s travelling the world doing training and consulting. The same technology is used in Index Server, SQL Server Full Text Search, SharePoint, and even Windows Desktop Search.

It’s a workmanlike search technology, but I think people are so used to Google being so effective on the Internet that when they come to search their intranet using these technologies they come up short. You have to do a bit more wading through useless hits before you find what you’re looking for. In fact it’s a bit like going back the bad old days of AltaVista, et al before Google revolutionised search with PageRank.

This begs the question how good any intranet search solution could be (including Google’s own Search Appliance) on a intranet that consists of file shares and SharePoint document libraries containing mostly Word documents, Excel spreadsheets, etc, with nary a hyperlink in sight. How would you get something like PageRank, which relies on incoming links to help rank content, working with a “corpus” (in search parlance) such as this?

So, Microsoft have now pretty much admitted that their search technology needs some work, because they’ve just shelled out $1.2 billion for FAST,a Norwegian search technology company. Or should that be “bailed out” as FAST seem to have had some financial difficulties recently? It’ll be interesting to see if FAST’s technology, when they integrate it, is more effective than Microsoft’s current offerings.

Changing the font in Google Reader

I love Google Reader for reading blogs, but one thing that bugs me is the rather dull choice of font: sans-serif (Arial if you’re on Windows). If you have Vista or Office 2007 installed then you have a much better choice of fonts, one of my favourites being Calibri. If you don’t have Calibri, Microsoft ‘s trusty Verdana font is more readable online. Unfortunately, there’s currently no way to change the font in Reader’s settings pages. But, if you’re using Mozilla Firefox you can take advantage of user CSS and style any website however you choose, as long as you understand CSS.

Firefox’s user CSS lives in a file called userContent.css in the chrome directory within your Firefox profile which on Windows is somewhere like: %APPDATA%MozillaFirefoxProfiles<some alphanumeric id>.defaultchromeuserContent.css.

Create the userContent.css file if it isn’t there already (there will just be a couple of example files there initially) and add the following:

@-moz-document url-prefix(http://www.google.com/reader/)
{
    body
    {
        font-family:Calibri !important;
        font-size:105% !important;
    }
}

Tweak the font and size to taste.

Internet Explorer also allows user stylesheets, but there’s no ability to target certain styles for specific sites. It’s made possible in Firefox by the “@-moz-document” and “url-prefix” psuedo-selectors.

It turns out there’s quite a community with the same idea: that they can tweak sites to their own tastes. So check out http://userstyles.org/ and the Stylish extension, which makes it even easier to apply user CSS, and a huge repository of ready-prepared CSS for popular sites, which you can use if you’re not CSS-literate. Daniel Cazzulino has a great example of a pimped-out GMail courtesy of Stylish.

Adobe AIR and HTML Applications

My initial impression of Adobe AIR was that it was some sort of “Flash for the desktop” deal. Developing apps in Flash didn’t really appeal to me so I dismissed it (bad memories Flash development using early versions of Macromedia’s tools).

Fast forward to a few weeks ago, I started experimenting with Twitter (basically publicly broadcasted instant messages). In so doing I looked at a number of desktop clients, of which it turns out there are a several that run on the Adobe AIR runtime. One of the first AIR twitter clients I tried was Jonathan Snook’s Snitter. Being a Snook creation it looks great (and of course, lime green by default). It’s even got a little notification area (née systray) icon for when it’s sitting in the background minimised.

There’s nothing that belies the fact that this is really just an AJAX-y web application without the browser. It consists of just a bunch of HTML, CSS and JS files sitting in my Program Files directory (C:Program FilesSnitter to be exact). I had a bit of fun opening them up in a text editor and hack around with them and was pleased to see that Mr Snook is a also a jQuery fan.

So an AIR app is just a client-side web app: HTML and CSS for layout (oh and Flash if you want as well), JavaScript for your logic plus some platform interop library-type stuff provided by the AIR runtime all hosted in an implementation of WebKit, the standards-compliant rendering engine also used by Apple’s Safari. Oh and it’s cross-platform: running on Windows, Mac and Linux (eventually).

None of this is new though: Microsoft had the same idea about 10 years ago that you could develop desktop applications in DHTML, CSS and JavaScript/VBScript by hosting the Internet Explorer rendering engine in a bare window and allowing the script access to the host operating system. This technology was called HTML Applications, or HTAs. Many of the Control Panel applets in Windows XP (e.g. User Accounts, Help and Support Center) are HTAs and I think at some point even some versions of Microsoft Money were too. Interestingly, with HTAs, you can if you choose, package all the HTML, CSS, JS, images etc inside an EXE or DLL as resources (served up using the “res://” protocol) rather than having them lying around loose on the file system. To create an HTA: create a web page, rename it to have an *.hta file extension then double click it. It will be opened up by MSHTA.exe – essentially Internet Explorer without any menus or buttons and with a more relaxed security policy (insert cheap IE security jibe here). HTAs have been standard equipment on all versions of Windows since at least Windows 2000, so are a good choice for creating things like custom setup programs when you can’t be sure if the target system has something like .NET installed on it. Plenty of Microsoft’s product CDs use HTAs for their AutoRun launchers.

It transpires that Mozilla are also now getting in on the act with Prism, which makes sense as Firefox itself is a kind of an HTML application. Go to Program FilesMozilla Firefoxchrome crack open the browser.jar file with a ZIP utility and you’re presented with a bunch of markup (XUL rather than HTML), CSS and JavaScript.

AIR or HTAs give you HTML as your control surface which is so much more flexible than Windows Forms and without the learning curve and heavyweight runtime requirements of WPF. For the application logic: JavaScript is a great, flexible language which when coupled with something like jQuery is incredibly powerful for doing UI manipulation.

It seems that AIR really picks up from where HTAs left off with the added promise of cross-platform compatibility. The Adobe AIR runtime is impressively small (10MB), fast and easy to install. (This highlights a bugbear I have with the .NET Framework these days: it really needs to go on a diet, or become less monolithic. The .NET 3.5 runtime is over 100MB in total, whereas .NET 1.x was about 20MB.)

Anyway I digress. If you want to dig into creating AIR apps in more detail, Jonathan Snook has just written seasonal overview, which goes into topics such as data storage, file system access and application packaging.

Editing and testing scripts in SciTE

SciTE (the Scintilla Text Editor) is my text editor of choice. It’s fast, simple and lightweight. Not only that but it’s based on the Scintilla editor component which can be used in your own apps. There are a couple of versions available for download, my preferred one is Bruce Dodson’s version which amongst other things includes a Windows Explorer shell extension that adds an “Edit with SciTE” command for all file types.

There are plenty of other text editors available that are based upon the Scintilla core, such as Notepad2 and Notepad++, but they seem to lack the main feature that keeps me using SciTE. That is the ability to hit F5 when editing a script and have the console output appear in a separate pane in the editor window. I do plenty of batch file, VBScript, JavaScript scripting and with SciTE I can hit F5 to do a quick test. If any error occurs then the output window will jump to the offending line with a double-click if the error message follows the pattern:

<filename>(<line>, <col>) <error message>

…which is a fairly standard output format for most compilers and script interpreters.

The output window also supports standard input – which means if you have prompts in your scripts for input you can type them right into the output window.

SciTE can be extensively customised, as long as you don’t mind editing (albeit quite straightforward) configuration files. You can edit the core *.properties files in %ProgramFiles%Scintilla Text Editor, but you’d be better off opening your user options file which is stored at %USERPROFILE%SciTEUser.properties. I say this because there’s a better chance you’ll back up this file along with your user profile when you next pave your machine. There’s a shortcut to open or create a new the SciTEUser.properties file on the Options menu: Open User Options File.

Anyway, here’s what’s in my options file to help me develop Windows Scripting Host (*.vbs, *.js) scripts as well as good old batch files (*.cmd, *.bat) in SciTE. The key is to set the subsystem property to 0 so that all console input and output (stdin, stdout, stderr) end up in SciTE’s output window:

# *.vbs files
command.go.$(file.patterns.wscript)=cscript.exe //nologo "$(FilePath)"
command.go.subsystem.$(file.patterns.wscript)=0

# *.js files
command.go.*.js=cscript.exe //nologo "$(FilePath)"
command.go.subsystem.*.js=0

# Run batch files inside SciTE
command.go.$(file.patterns.batch)="$(FilePath)"
command.go.subsystem.$(file.patterns.batch)=0

Hope that’s useful for someone else.