Mr. Softwarepants

Normally I would absolutely no interest in Disney buying Marvel. Well, that's not true, it kind of sucks for the number one agitator of bad copyright law to accumulate even more valuable IP.

But outside of that I wouldn't care, except for the fact that I'm working on a Marvel-based game, so I guess we'll see how that changes things, if at all.

Update: Yep, no real change; Disney plans to review contracts as they come up for renewal, but that's SOP for anyone.

I'm taking a DB schema that's back-formed from an XML representation and trying to get it into Django, so content can be edited and served back out as XML documents.

There's a certain amount...satisfaction that's missing from this exercise, since the objects being edited are ultimately more "document like" than relational. I suspect some amount of proxy models or abstract inheritance will be needed.

I would say "hopefully the schema itself is pretty stable", but I think it's early enough here that it's not, which will mean "fun" database migration work in the future.

There's got to be a better solution for this... but what?

Our automated builds at work are split into two sections, the "Build" phase and the "Deploy" phase.

But it turns out that there are actually three divisions of work. The hidden middle one is "Stage", and it's lumped at the beginning of Deploy instead of the end of Build.

Like most things build related, I'm pretty sure I knew this at one point, but forgot it. After all, builds run unmodified for weeks or months at a time, so why keep all that minutiae in your head?

The "Build" steps generally involve compiling source files. The "Deploy" steps involve sending new versions over to a live server. "Staging" is everything in between, basically, copying build files from the compilation folders to staging folders, which are the source folders in for Deployments.

I'm pretty sure that Staging should be done immediately after Builds in Phase 1, rather than before Deployments in Phase 2. How else can we be sure that we're sending the right junk off to the live servers, other than after-the-fact?

Bad news: The automated QA build broke today, trying to update the database schema. This on apparently no actual schema changes.

Good news: I was able to fix the build by resetting the the database compare options.

Bad news: But we updated the compare tool before the last successful build, so I don't know why changing the settings mattered this time.

Good news: ....coffee?

Update: Thinking about this, the first build than ran after the upgraded succeeded, but then put the database in a state where the next build wouldn't, without the option changes. A non-idempotent change happened. So I guess the fact that it all of a sudden happened is less troubling. Though I still wish I knew why changing the options worked.

(Though maybe I'm just doing it wrong.)

An NUnit project file is a list of .dll assemblies to test. These .dlls are loaded into a single "AppDomain" based on the project name.

So if your NUnit project is named "TestTheseThings.nunit", it will load into an AppDomain called "TestTheseThings". This in turn will cause the .NET framework to look for an Application Configuration file named "TestTheseThings.config".

This is why we had a file in the root of our solution named "App.nunit": because we also had a shared "App.config" that was shared between 5 separate .csproj projects.

Silly me, I started to break out our single "App.config" into per-project configuration files. The client needs different things than the server, for instance.

When running unit tests locally through ReSharper (in Visual Studio), things still worked because each .DLL to test was loaded into its own AppDomain, which picked up the per-project .config files in the bin\Debug folders.

Running either the NUnit GUI or console app broke hard, because the previous App.config was out-of-date, then missing.

The fix in this case was for our NAnt script to pass in the individual .DLLs to test instead of using an NUnit project.

The upshot here is that now our .config file are separated out, which will make certain other upgrades and changes much simpler.

An Outlook add-on is no longer compiling on my machine, I'm getting "'CommandBar' is ambiguous in the namespace 'Microsoft.Office.Core'" and related errors. This was, of course, working months ago the last time I was in this code.

It's basically impossible to figure out what the problem is, since various Windows, Office, and Visual Studio hotfixes all conspire together to much with your dll versions. This is an Office 2003 add-on, and having some Office 2007 products installed too can't be helping matters.

Writing and deploying Office add-ons is a death trap.

Update: Adding a COM reference to the Office 11 core components redirects to the version of the PIA .DLL in the GAC. This is "expected behavior", except that after it goes to the GAC it finds the Office 12 (aka 2007) version instead of the Office 11 version.

MASS FAIL

Update 2: Deleting that reference entirely lets the project compile and run. WTF? Then why was there a reference in the first place?

I'm plodding along, slathering Django's ORM on top of this "legacy" database at work. It's not really legacy so much as "external to Django".

Let's say you have Events and Tasks, and they can be associated with each other. You'll end up with something like an "Event_Task" table that holds the associations. Django (and Rails) can set up (or be configured to know about) these tables, also known as "many to many" relations.

In your typical business app, the M2M table has additional columns for data about the relationship, and at either end of the relationship you'll probably have to join in a bunch more stuff to get anything useful going.

It's looking like I'll have to define a bunch of web-only views to maintain my sanity; one of the points of using Django is to make getting stuff out the database super-easy, but that's not possible if you have to join across three tables to get the data you want in the right order.

At work we keep our database schema in source control. This lets us easily rebuild an empty database from scratch, run tests against it, and manage schema changes in a controlled way.

The way it's setup is a huge bunch of .SQL files for the tables, views, sprocs, indexes, and whatever else is in there. Our NAnt script has a task that walks through all the appropriate folders sending .SQL files through sqlcmd.exe.

It takes a few minutes to totally rebuild the database... and I have a sneaking suspicion that it could be a lot faster. There's got to be some overhead associated with launching sqlcmd.exe a thousand times, I assume it's making and breaking connections each time.

Also, if you check in a breaking change to the database you're kind of out of luck tracking it down; the line number that SQL reports the error on bears no relationship to actual file line numbers (do to "GO" commands)... and you don't get the filename that the build broke on in any case.

Once again I'm looking into NHibernate as a replacement for our home-grown ORM/DAL... and once again every time I try to read something about NHibernate my eyes slide off the screen and I end up staring at the desk or cube wall.

If we were starting from scratch on a project, I'd have to strongly consider it, but as we're not adding new tables all willy-nilly, and what have actually works and is tested, there's not a lot of impetus to change for the sake of change.

But anyway, the biggest question I have is where do free-form searches and DataSets fit into the NHibernate world?

All of our search screens return DataSets instead of live objects, because search results (A) generally include joined columns from other tables and (B) can't wait for lists of child objects to load per row in the search results; we don't do any lazy-loading of child collections in our DAL.

The whole point of using an ORM, it seems, is to not have DataSets flittering around your tiers, because you want Actual C# Objects with actual domain logic. Which is fine... except when it isn't.

Note that we never do any logic on DataSets; clicking on a search result causes a for-real C# object tree to load out of the database. But again, those joined-in columns...

I keep coming back to the concept of "manual content" on the new websites living in the file system. Manual content lives in the file system of the current websites, through a process that turns uploaded HTML files into ASP files, which are then directly executed via their URL.

In the new system (that only exists in my head), manual content is still contained in files. But those files only have the "inner content", instead of being full-fledged URL responders. And instead of living in the file system directly, somewhere under the web root, they'll live as files but in a Subversion repo.

Instead of uploaded content being transformed to ASP pages, it will get checked into a repo, which is then gotten down to the website when it's ready to be published.

I'll have to think this out a lot more, though; all the pieces haven't fallen mentally into place.

Using Capistrano to Deploy Django Apps

Oh, deployments. A platform can be super-great for development, but then you get to deploying stuff and where are you? In deployment-land, that's where.

Rolling out new versions of our WinForms app is pretty slick. There is potentially some more automation that could be done... and it might be worth it, if only to learn some new automation tools.

I'm not sure what's involved in walking out changes to our existing websites, since I never do it. But rolling out changes to the new websites has to be easy, even in the face of database schema changes and the like.

Things to think about.


(I should note that Capistrano is written in Ruby, which isn't a problem for me. And it also doesn't deploy-to-Windows, which is a problem, so I'll have to think about that too.)

Labnotes: Office 2.0 conf, and why document standards are a blast to the past.
In fact, the whole point of standardizing on office software by indirectly standardizing on a document format is a moot point. ODF wrestling OOXML is as relevant today as Data General and DEC racing to build the best minicomputer.

This analysis is far too dismissive. It would be nice if we could just do things "on the web", whatever that means, but document interoperability problems are the bane of one of my coworker's existence. And that's just among various PDF generators and versions of Adobe Reader (especially as a plug-in across browsers and platforms.)

And if you need chemical formulas and engineering diagrams, you're pretty much stuck rendering out to PDF... unless you want to rend out to paper and FedEx that around.

Though perhaps that's less of a concern for plain-old "boring" business stuff like, uh... I have no idea.


Jon Udell: XML documents: flavors versus essence.
Look at a TeX authoring set-up, run away screaming. At least, that was my experience, but I never really needed to use TeX for anything.

TeX, probably with LaTeX on top, is both your document and the 'source code' to your document: the instructions to a renderer on how your formulas (and other stuff) should look.

Yes, you can layout complex formulas with the Microsoft Formula Editor. It's really useful if you have to stick a couple into a .DOC for some reason. But it's a royal pain in the ass if you have a lot of formulas and you are versed in TeX.

This sort of technical writing does render out to paper, or at least virtual paper (PDFs formatted for printing instead of on-screen reading) because the ultimate destination is often... a print journal.

As journals move online, there might be a (slow) move away from multi-column magazine style layouts to something else more screen-friendly, but you're still going to have to come up with concrete examples of how bringing in XML formats and toolsets actually helps someone's document creation and publishing process.

Automating things is real work. It's not always just a matter of "putting the manual steps into a script" and running the script. To get this remote executing working properly, I also have to do up some infrastructure.

* I created a new NAnt project that has (A) a task that uses psexec against the build server to call the very same NAnt project using (B) another task that actually writes out the new BuildLabel.txt file.

* I checked the new .build file and psexec.exe into the build support area of source control.

This is the point where "infrastructure" comes into play. Those 2 files won't magically appear on the build server. And it's a bit of a pain to RDC in and use the TFS command-line tools to pull them down, but more importantly, I want any changes to this new script (and any additions to the /tools folder) to come down to the build server automatically.

This means adding a new CCnet project that watches the paths in question in source control, gets them when they change, and then do no actual tasks. The "get latest files" is all the work that needs to happen.

So I edited the master ccnet.config file to add the new project and checked it in. The cool part is that this file already has its own bootstrapping CCnet project; changes to the ccnet.config file are watched by a CCnet project that gets the new config and bounces the server. You have to be a little careful here, because bunging the config file means that CCnet doesn't start back up. Your subsequent edits to fix it won't come down automatically. But another cool part: I already thought of that, and there's already a .bat file in the folder with ccnet.config that tells TFS to do a manual get.

So... well, it seems a little baroque, but it really works, and it makes more sense if you see the files and folders and structure. And as a bonus, all the other non-version-controlled build tools can now be auto-updated by source control check-ins.

At some point I'll write up a "real article" on setting up CCnet bootstrap projects this way.

There's a script at work that crawls our websites (staging or production) and checks for various bad things. Mostly this means checking links and images for broken URLs within our sites (and ignoring broken external things, for the most part.) It also does some structural checks, making sure that all "content pages" have a headline defined, that sort of thing.

The script has intimate knowledge of the site structure built-in, and needs to be kept up-to-date in the case of any major changes (like the rebranding project that finished recently.) So for instance, in order to reduce the number of redundant links checked, the header, footer, and common navigation DIVs of retrieved HTML are stripped before looking for checkable links.

Yet another behind-the-scenes piece of the puzzle that needs to be taken into account (ie, rewritten.)

The place I work has released its redesigned websites.
(I wasn't involved with this effort, as I'm on other projects.)

I'm turning into the "Build Guru" at work. By which I mean, I'm going from "in charge of the builds, but don't really know how they tick" to "in charge of the builds, and drastically remunging the CCnet and NAnt build scripts."

The projects I'm in charge of aren't nearly big enough to justify having a dedicated build team (or dedicated not-me build guy.) But hey, being agile means being a jack-of-all-trades, so that's fine.


We don't have an application-level DBA on this project either; I'm currently "in charge of the database" too. (We do have people here, not me, who know how to configure and administer SQL Server boxes.)


I don't mind knowing all this stuff, but it does make for some time randomization every once in a while. My last code change turned out to be (much) bigger than expected, which led me to find an orphan check-out on the build server. Blowing away the build's TFS workspace involved finally getting admin privs to source control. Doing a rebuild-from-scratch of that project uncovered some possible ccnet.config changes. Because of where the ccnet.config was in source control, changing it forced builds, which interfered with the dependent build I was trying to do in the first place. Setting up a separate CCnet project to monitor the CCnet.config file, well, then I got into some fun involving the ccnet user and folder privileges.

And on and on, but I think I'm on the downward slope of the build changes now, which means I can get back to the code changes, which means I can deploy a new QA build hopefully next Tuesday.

Visual Studio is consistently crashing trying to open one of our .sln files. Yay? I'm hoping it's just the ReSharper 3.0 alpha, as opposed to something I have to fix in a .sln or .csproj with a bare text editor.

Update: Yep, ReSharper. Or at least, when I uninstall it VS doesn't crash on this solution anymore. Back to 2.5.x I go.

Notes: ReSharper 3's install is improved over previous versions. Fewer pointless "OK" and "Next" buttons to click, quicker overall. And the download is only half the size (though I think the 2.x versions include some pack-in Visual Studio QFEs that aren't needed for 3.0. I wonder if 3.0 assumes SP1?)

(Unfortunately, I can't just package up the entire solution and send it off as a repro case, what with it being work related and all.)

We have a class that manages grids displaying lists of records.

This class started out as a sort of definition class: you define what columns the grid should have and later apply the class to an actual GridView to create the columns.

It wasn't long before this class started getting support methods used why the grid is visible.
The class it up around 750 lines now, and it seems like it ought to be split again, into a class that just defines the columns and a class which has the support behaviors.

Granted, this isn't going to happen on the last day before a week-plus of holiday vacstion.

I figured out a way to remove a bunch of dinky classes from the project at work. Once again, generics to the rescue.

MF Bliki: BigScreen.

I'm debating getting a widescreen monitor for work.
I'd really rather not, but on the other hand, I do have to look at it all day.

Only one monitor for work because I'm on a laptop with only one (VGA, ugh!) output.
Matrox makes some devices that let you connect 2 or 3 monitors to a single laptop port, but as far as I can tell you can only go up to 1280x1024 on a single monitor, which isn't enough.

Refurbished 2007WFP are going for $290; I have 2 of these at home (both refurbs.) and this is a better price than I paid in July.