rlucas.net: The Next Generation Rotating Header Image

November, 2010:

Sun Beams, Snow Banks, and Small Businesses

Seattle was inundated yesterday by a steady snowfall during which it was cold, then warmer, then colder again: AKA, a recipe for icy road disaster (at least in a city of 142 square miles with 26 snowplows).

Today’s morning news and communications, then, were dominated by transportation-related issues.  “Schools are closed!”  “Courts closed!” “Clinics closed!”  “Stay home by all means!”

That wasn’t an option today at RevenueLoan — we had a closed deal to paper and two more to work on.  So I put on the hiking boots and the bubblegoose, and navigated foot-mobile through the mostly-closed Seattle streets.

And, while abnormality was the order of the day — 30 year old Seattleites sledding and sliding around like giddy 5th graders, hilly streets barricaded, and creep-crawling traffic throughout the day on main highways — what struck me most was the acute normality of the day for the small businesses I passed.

Local printing company — “open” for business.  Our caffeinated home-away-from home at Moka’s Cafe — check.  Tiny bookstore slinging used paperbacks and tacky tourist t-shirts — you bet.

The office windows across the street from mine, usually packed until 6 or 6:30 with yuppies at an Anonymous Top Online Retailer, are empty at 4:30.  A Major Local Operating System Vendor was beseeching people to stay home.  And, that’s fine — arguably most of the people out there driving today were assholes endangering themselves and others (at least if my anecdotal observations can be extrapolated).

But there’s something heartening about seeing that neon “Open” sign lit up — not the giant custom one in the corporate standard font, but the red-and-blue one you can buy at Costco when you’re first hanging a shingle.  Something heartening about the proud real-estate guy giving the walking tour to prospective tenants on pavement he just scraped and salted.  Something heartening about the beer distributor’s careful truck maneuvers as he pulls up to the corner bar to restock it for happy hour.

OK, fine, cynics: I know that these people are responding to the iron economic law that governs small business, and the simple reality that fixed costs don’t go away.  There is no East-coast failover data center for the guy who makes sandwiches on the corner, and there’s no corporate balance sheet to pay him his take-home if he no-shows.

But I think it’s more than that.  People doing their work because the work itself is valuable.  Yes, bonds have value.  Yes, big corporate edifices have power.  But imagine a world of 6 billion bondholder rentiers.  Who makes a tasty Jambo sandwich?  Who actually prints up your annual reports?  The work we do, cumulatively, is what makes humanity wealthy (and human, for that matter).

And those small businesses are the individual loci of non-abstractable human work.  The smallest functional unit that can deliver the value they do.  And they show up despite the snow.

So maybe it was the bright sun in the sky, reflecting off of the snowpack, and giving a blessed vitamin-D-blast on a Seattle winter’s day.  But something about the walk this morning, and the “open for [small] business!” that came to me from shop windows and storefronts, gave me a cheer.

Web.config and App.config file gotchas

If you try to use idiomatic .NET, and you have even modest configurability architecture requirements, you will almost certainly want to use the *.config system (App.config or Web.config). According to old hands at Win32 programming, this is quite a step forward from *.ini files or registry manipulation. Perhaps so.

However, the *.config regime is extraordinarily fragile and surprise-prone once you start trying to do more than just add name/value pairs to the <appSettings> section. The following are some gotchas that I hope you can avoid if you have to deal with this.

.EXE assembies get App.config, and Web DLLs get Web.config, but non-Web DLLs (e.g. tests) get App.config.

.EXE assemblies look for filename.exe.config, which is in App.config format.  Normally, DLLs do NOT get a config file; rather, they inherit / acquire whatever config is in place in their runtime environment.  But there are two important exceptions.  Web services / sites get built as DLLs.  Their execution environment (presumably IIS or the dev server) looks for Web.config and its format.  Test projects (of the MS type that Visual Studio 2010 makes by default) get built as DLLs, as well, but they get run by (mstest? vstudio?) an execution environment that looks for an App.config file.

So, to sum:

  • .EXE => App.config
  • .DLL Web project => Web.config, via its server runtime
  • .DLL Test project => App.config, via the test / IDE runtime
  • .DLL other => none, inherits runtime environment

Sections such as <appSettings> can be externalized into other files, but there are two subtlely different and incompatible ways to do so.

Specifically, you can add a “file” or “configSource” attribute to your appSettings section.  If you use “file,” that file will be read and will override default values that are set in that section in the .config main file.  If you use “configSource,” however, you must not set any values in your .config main file, and instead must entirely scope out that section (and that section alone, save for the XML declaration) in the file whose name you specify.

Frustratingly, “file” and “configSource” have different rules for what may be included (relative / absolute paths, parent directories, etc.).  Especially restrictive are the rules for Web.config, I believe, though I don’t have them straight.  Effectively what this means is that if you have several Web projects that require a shared configuration section, you cannot put your customSection.config in a parent directory and have your projects pull it in (thereby keeping a Single Point of Truth); rather, you have to propagate multiple copies out to all of the sub-Projects (ick).

For more on this: re: configSource, re: file from MSDN.

Web.config settings are mostly inherited from machine.config down through a hierarchy, but confusingly stop being inherited at the sub-directory level in IIS.

Sometimes, or at least most of the time by default, Web.config settings for a given directory are merged with those of parent directories, and are merged with machine-level config as well.  This can lead to somewhat unfortunate results if you have an app in a subdirectory of another app with divergent configruation requirements.  This fellow seems to have figured out how to resolve this.

Be alert, though, because not all settings *do* propagate properly.  First, a parent Web.config can indicate that its settings should not be inherited.  Second, collection settings are merged together, not replaced, by child specifications.  Third, some settings, just seem stubbornly not to propagate (see this MSDN article which suggests that “anonymousIdentification” does not propagate because it is a secret never-properly-set default magical element).  Finally, the above-quoted MSDN article raises the good point that Web.config only applies to ASP.NET stuff, and that there is an entirely different regime for static content and plain old ASP files.  So watch yourself, there, Tex.

Don’t bother with symlinks in Windows 7

Yes, in theory, Windows has rocketed into the 21st century with symbolic links. However, you can’t make them in Windows 7 unless you’re an Administrator, or unless you manage to give yourself “SeCreateSymbolicLinkPrivilege.”

Giving yourself this privilege is possible with Professional/Ultimate versions of Windows, but not Home Premium, via secpol.msc, which just doesn’t exist (and can’t be downloaded). (Funny, I don’t recall the comparison chart having a checkbox for “can actually use computer” that was missing from Home Premium.)

If you try to set this for yourself, don’t bother trying to use C# or PowerShell. You’ll need to manually wrap the unmanaged C++ advapi32 APIs, and pass all kinds of structs and pointers back and forth.

In the end, just give up on whatever it was you wanted to use symlinks for.

Lopsided Barbell of bank credit

At a fascinating macro talk this morning by a Goldman Sachs strategist, he mentioned a “lopsided barbell” of credit.

To the biggest firms with the best ratings — think IBM or MSFT — money is basically free, with coupon yields at sub-2%.

But to middle-market (say, $100M – $500M sales) and lower-end of middle market (let’s say $20M – $100M) companies, bank credit is simply not available at any price.

Interestingly, this week at a discussion with some regional commercial bankers, my partner Andy Sack heard gripes from the loan officers about extraordinarily tight credit conditions for single-digit-millions size facilities. (Of course, loan officers always gripe when “the credit guys” say no, but it’s worse now than usual, and importantly, not much better than 2008).

So: until or unless the big banks stop getting money for “free,” they’ll be quite content to sit on it and/or plow it for nearly-free into premium credits in large deals.  Don’t expect small business credit to loosen up until, paradoxically, rates have risen somewhat.

(Don’t expect us to have that problem over at RevenueLoan.  We’re funded by private equity investors specifically to prove out the royalty/revenue-based financing model, so A. our money costs us “private equity rates” and B. we’re on a mission to fund small businesses!)