September 2003 - Posts - Jon Galloway

September 2003 - Posts

AppSettings - External Config File

We've been using this for several months to distinguish between Dev / QA / Prod settings - it's worked very well. This makes it easy to keep config files in source control - there's one folder (config) with dev.config, qa.config, production.config, and any others as needed. The folder is maintained in source control so it's versioned, labeled, etc. Web.config is different from server to server (refers to a different config file depending on environment), but doesn't contain any settings.

One slight difference with this approach is that changes don't go into effect immediately. The ASP.NET process monitors web.config for changes and restarts when it changes (actually, it caches web.config and changes to the file invalidate the cache), but that doesn't cascade down to referenced external config files. A simple hack to force the reload is to add / remove whitespace in the web.config file to force a refresh.

     “I recently discovered that the app/web.config file can reference an external config file to get some or all of its appsettings. .. “

      [Paul Wilson]

Posted by Jon Galloway | with no comments
Filed under:

Keeping Required Field Validators quiet when using a Summary

If you've got RFV's in a datagrid (or on other special occasions) you may want their error messages to only show up on the Validator Summary. If you don't have any text set for a validator, it displays the entire error message.

One trick to keep them from displaying (and messing up the formatting) is to give them harmless (no space) html tags to display. "<NOBR></NOBR>" works well, or you could just as easily use "<I></I>". The <NOBR> tag isn't used very often, but it's pretty handy - especially with webforms where it's tougher to position everything since .NET is writing most of the HTML. Anything inside a <NOBR></NOBR>block will stay on one line if possible.

Posted by Jon Galloway | 2 comment(s)
Filed under:

IUI / Web Clients vs. "Rich Clients"

If you haven't read about Microsoft's Inductive User Interface (IUI) initiative, check this out.

This should be ruffling some feathers - I've heard people talking about how they can't wait for .NET WinForm “rich clients” to end the reign of the ubiquitous web “thin client”.  The IUI approach is basically saying that web user interfaces are easier for users to learn than most desktop apps.

The model is Microsoft Money, which feels like a web app and has to be one of the friendliest apps I've ever used. Desktop development allows developers quite extensive options for UI design - enough rope to hang ourselves. Web apps, on the other hand, are constrained by both a smaller UI toolset and an implicit requirement to keep each screen simple (slow and unreliable connections dictate that user interaction is concise and incremental). Users of a web app perform one simple task per screen rather navigate their way through all their tasks on a complex screen. We've always assumed that our goal was to design a powerful UI for power-users, then make it as painless as possible of users to work their way up to power-user status. The MS Money team discovered that most users never make it to power-user status, and keep struggling with overly complex and powerful UI's they never fully utilize.

In the “real“ world, if you want to fly to Denver you talk to a travel agent who asks some simple questions, one at a time, then makes sure that you're flown where you want to go. The traditional rich client approach would drop you at the controls of a 747 with a grinning paperclip to talk you through the flight. Which makes more sense?

On a slightly related note, I heard a great quote this week: “If you ask an engineer the time, he'll tell you how to build a clock.”

[ot] Galloway.Items.Add(new Galloway("Esther"));

Baby and mother doing great.

:-)

 

Posted by Jon Galloway | with no comments

Automated error handling in .NET

VB/Rig was a popular add on to Visual Basic which automated the insertion of error handling into VB code. I've worked with other add-ins for VB that did similar things, but haven't seen anything similar for .NET - c# specifically. I realize this wrapping code in Try / Catch / Finally blocks is more complex than just throwing an error handler at the end of every sub and function, but with the amount of free addins and macros people have been cranking out I'd bet one exists...

Posted by Jon Galloway | with no comments

Mount Fuji Book Report

I recently finished How Would You Move Mount Fuji? - a book about the puzzle interviews ("Why are manhole covers round?") that Microsoft has made famous. I very much enjoyed it. If you're one of the folks that hasn't read it, this short book report is for you:

Main points in book (not necessarily in book order):
1. History of the puzzle interview (including the history of the IQ test, which also attempts to use puzzles to determine intelligence.
2. Coverage of the Microsoft interview format
3. Why puzzle interviews? Because traditional interviews are a sham - he goes through several studies that indicate that most interviewers make their decision in the first few seconds of the interview, before the first question is asked. Puzzle interviews dispense with the sham formalities of traditional interviewing (Q:What would you say your worst quality is? A:I work too hard.) and at least bring things to an objective level. Very interesting, but I disagree - more later.
4. Tons of cool puzzles - what I bought the book for. Yeah - I got a lot right, but I blew a lot of them too. Good thing I've got a solid job in sunny San Diego. More later here, too.
5. Some more stuff in conclusion - how he thinks you should interview. He says puzzle questions are okay for certain jobs, but if you're not going to make a hire/no hire decision based on the question, why ask it?

We hired three engineers for a high profile project right as I was finishing up the book, which got me thinking... (rant follows)

I didn't ask a single one of these puzzle questions on the interview - I really didn't feel they'd give me information. I was aware of the fact that subconscious factors were at work in my hunches, and I realized that hunches are okay. We make decisions about people all the time based on hunches: Do I trust what this person is saying about his used car? Do I want to marry this person? Is this person lying to me? I think that's a good thing. I've hired based on questions before (right after I got my MCSD I was full of trivia), and been badly burned by it.

Let's take some of the major qualities that determine an employee's success - raw intelligence, specific knowledge, people skills, common sense, and work ethic, to name a few. Raw intelligence (solve a difficult logic puzzle quickly) and specific knowledge (How would you join a string of comma separated values in SQL? If garbage collection automatically cleans up after you, why would you close a database connection?) are both measurable to a certain extent, but I've found that people who can spout off answers quickly often make poor decisions because they spout off answers too quickly. And a minimum level of specific knowledge is important, but with Intellisense, groups.google.com, codeproject, etc., it's often more valuable to be able to find information than to have it memorized. The only useful thing I learn from specific knowledge questions is a rough idea of experience. Having been burned by hiring trivia experts who couldn't code, I now ask questions that reveal battle scars. I look for rueful grimmaces - “Oh, man, yeah, I got burned by that one. It works fine in development, but has problems when you migrate from server to server.“

Blah, blah, blah... Anyhow, I think it's important that workers have a minimum level of intelligence and experience required for the job, but work ethic isn't something you can determine by Q&A. Work ethic, on the other hand, is one of the most important factors in determining how useful an employee will be. Will they do the job they've been hired to do? For me, that's usually (a) doing what I asked of them, (b) raising concerns about issues they encounter during step a, and (c) making recommendations for improvements - in that order. If you can't perform your job, your feedback on how to improve things is suspect. And the point is, that's not something you can guage with a few simple questions. You pretty much have to try them out and see how they work, or go with a hunch. I feel that, although I couldn't explain it, my intuition has improved markedly (through negative reinforcement, no doubt). In the case where hunches failed, a question about dwarves with colored gems on their foreheads and their demon captor (read the book - p.85) wouldn't have helped.

So I arrived at the same conclusion Poundstone did, although for slightly different reasons. This begs the question - why has it worked for Microsoft, who is obviously successful in what they do? Well, they've got a flood of qualified applicants, and not only can they afford to thin out the ranks of applicants - they have to. I'm sure arbitrary puzzles have cut some otherwise qualified applicants, but who cares? They obviously don't hire on puzzle performance only.

As for the puzzles - some different types:
1) “Fermi questions“ - How many ping pong balls can fit in an airplane. The point of these is to systematically make asumptions and figure out a logical best guess. Having been through the Naval Nuclear Power program, these seemed frighteningly familiar.
2) Trick questions - Your first guess is wrong. Pretty easy to spot - if it seems easy, you're wrong or Richard Feynman. I got impatient on most of these and looked at the answers too early.
3) Reverse trick questions - Much simpler than they appear once you spot the trick (e.g. any finite number multiplied by zero is still zero). For questions that seem ridiculously complicated and aren't Fermi questions, there's probably a trick. Question each assumption one at a time - the author has a really good analysis of these.
4) Design questions - Thought process is key here. Don't assume design is easy, take a logical approach, and look for out of the box innovations.
5) Recursive logic questions (my favorite) - These are so great! These usually involve “Purely Logical Beings“ (PLB's, in the author's parlance) in a complex logic driven puzzle. It's easy to figure out what happens first, but the fun is the domino like logic that causes delayed reactions several steps later. A more indepth explanation is here. This was by far the coolest part of the book - the meta-meta-logic stuff is way cool - but there's no way in hell I'd ever get one of these on an interview unless the interviewer straight up told me the answer.

Anyhow - it's a great book of cool puzzles that the author fluffed up with some interesting stuff about technical interviews.

[Now Playing: matmos - civil war - zock]

Cross Browser DHTML libraries

I've used DynAPI in the past: http://dynapi.sourceforge.net/

It's based on some work by Dan Steinman; it's pretty mature and has a nice object base - I was pretty suprised by the OO capabilities JavaScript offers.

There are lots of widgets available, as well: http://dynapi.sourceforge.net/dynapi/links.php?op=viewslink&sid=5

When you write websites, you are always looking at the same problems, like having your site working with different browsers.
.Net is good for the job from a server side perspective only.

I used different libraries for my client side scripts, and recently I found the solutions offered by
Cross Browser very powerful and up to date.

Cross-Browser.com features two cross-browser DHTML Javascript libraries. They support IE, Gecko (NS6, Mozilla, Phoenix, Galeon, etc.), Opera, Konqueror, NN4, and any other browsers with similar object models. The CBE library implements the DOM object tree, the DOM2 event model, and other DOM2 interfaces. The X library is a small but powerful library developed as a result of my experiences in developing CBE. Both libraries use object-detection, instead of browser-detection, as much as possible. Extensive documentation and examples are provided on this site. A free download package is available which contains the libraries, examples, and documentation. CBE and X are distributed under the terms of the LGPL. Please read the license before using either of the libraries.

Posted by Jon Galloway | with no comments
Filed under:
More Posts