Tim Tabor referenced the NSA Guide to Securing XP in the Win Tech: Off Topic list.  Craig Andera referenced Keith Brown's PasswordMinder project, a great utility for managing your passwords.  Many people resort to using the same password for many systems, or they derive some pattern using the system in question (guilty!) for the password.  The trouble with the former is obvious, the trouble with the latter less obvious; that is, until someone discerns the pattern.

Robert Scoble commented on Alex Hoffman's thoughts on "The Missing Future."  He writes:

One last thought. My family just went out to dinner. On the way back we passed by our favorite coffee place. Named Victor's. Hey, wait a minute. This is Redmond. Not far from Starbucks' headquarters. In Eric's world, Victor would never be allowed to sell coffee.

Every day Victor reminds me that someone can beat "the dominant corporation" and deliver a better product.

We have recently become inundated with Starbucks, but there are still several local franchises and autonomous unknowns that serve superior coffee.  The best coffee is served at these unknowns, and many coffee pundits know this; however, does this mean they have beat "the dominant corporation?"  Lets face it, Starbucks is pervasive; the overwhelmingly trendy atmosphere and Starbucksisms ("Can I call bar?" the cashiers say to the "barista" two feet from their position) will, in most cases, elicit enough coffee drinkers to dominate the smaller company that has a superior product.  Some argue the same for Microsoft, that they are a better marketing machine than software company.  Just for the record, I disagree with these people. 

Lets say we have a small company "A" and a large company "B", people won't acknowledge "A" as beating "B" unless the size of "A" > "B."  Out-of-sight is out-of-mind.  Victor's may serve great coffee, but I've never heard of it, so it looks to me that Starbuck's is winning because I can walk down the street and get a vinti latte.  Some of these smaller companies persevere and overcome the best, some are assimilated by the best, and still some are unsuccessful at doing the former and refuse to do the latter.

The coffee metaphor holds true for the software world as well.  I see great ISVs with great ideas that founder for their market share is consumed by the promulgator of a lesser product.

I read Eric Kidd's "The Missing Future" earlier today, and I just read Robert Scoble's response thanks to Julia.  These are uplifting words considering the somewhat morose (but excellent) content of Eric's article.  Robert talks about finding the Cold Stone Creamery of the software world, and my most recent read implies that Microsoft is aware of a potential Cold Stone Creamery.  A few quotes:

"If we make the wrong decisions, everything we've built over the last twenty-five years could be history."

[Quoted as Bill Gates -- p. 56]

"One day, somebody will catch us napping.  One day, an eager upstart will put Microsoft out of business."

[Quoted as Bill Gates in his book Business @ the Speed of Thoughts -- p. 56]

"Our next competitor could come out of nowhere and put us out of business virtually overnight."

[Quoted as Steve Ballmer -- p. 56]

"If we don't continue to innovate to keep up with consumer needs and technology advances, we can be unseated at any time, by anyone."

[Quoted as Jeff Raikes -- p. 57]

It almost sounds as though Microsoft is paranoid and histrionic, but it just demonstrates their belief that the missing future isn't really missing at all.  I obviously can't confirm whether or not this is the true mentality of Microsoft, but the speed at which they move certainly supports this.

Scott Watermasyk blogged about his new Metablog API-supporting blog tool called Blogert.  I fired off an email to Scott requesting a copy, and I received a response within a few minutes.  What I like about it:

• It's community code.  Blogert is an amalgam of free and .NET libraries/code.  It's nice to see a tool that embraces this idea without reinventing the wheel only to implement an inferior library. 
• It's closer to the philosophy of functional orthogonality that I very much appreciate with respect to tools.  It's "lighter" than w.bloggar; interface is simple and clean, and I'm not inundated with options.  I fired it up and within a few seconds I was able to post (save for the few hours I was at dinner with friends).
• It's written in .NET.
• It's written by Scott. 

Perhaps not very compelling reasons for some, but it's everything I'd want in such a tool (mostly the ability to post to my blog without fearing the backspace).

Also, rather than creating a "Testing [insert name of blog tool here]" post that seem to be ubiquitous when a new blogging tool is released, I am posting my initial thoughts on Blogert from Blogert.

I love regular expressions. Any tool that helps me more interactively construct my expressions is a Good Thing indeed. I thought I'd list some of the tools I use for those that might not yet be aware. Note that these tools don't attempt to help teach your regular expressions; however, they could almost certainly help in the learning process.

All the tools below support what I consider core features: the ability to specify match options, the ability to perform a match or a replace, and the ability to display matched groups in the results. Each respective tool has its pros/cons, and each has some very creative features. Rather than provide a breakdown of the features for each, I suggest you try each independently and decide which works best for you.

Chris Sells' RegexDesigner.NET (Source code)

Darren Neimke's RegexSnippets (Source code)

ActiveState's Komodo (an IDE, but a great regex toolkit is included)

The Regex Coach (Tim Tabor posted this in the Win Tech: Off Topic list today)

All of the tools are free with the exception of Komodo. If anyone is aware of any other tools similar to the above, please let me know.

With all of the talk in blogspace about Mozilla's Firebird, I decided to give the fruit of the Mozilla project another taste. I admit that the flavor of this release is considerably more palatable than the last few I had tried. The pages load extremely fast, the tabbed windows make me more productive [1], and the overall look-and-feel is quite nice.

I was met with the following message whilst attempting to post this entry using the admin interface:

You must be using IE 5.5 or above to use the Web Admin Interface

Understandable, really, considering all the rather slick DHTML facilities used on the admin interface. This gave me more reason to finally start using w.bloggar consistently; old habits are hard to break indeed.

Will I be replace IE with Firebird? I obviously can't obviate the need for IE, but I believe Firebird has become my default browser.

[1] XP's ability to aggregate like windows into a single taskbar entry is nice, but tabbed windows mean I can simply CTRL+T my way to the appropriate window.

Don Browing comments on using Subversion or CVS in place of VSS.  Peter Provost started a lengthy discussion in the Win Tech: Off Topic list on Moving to CVS from VSS; great tips for those wanting to make the switch to CVS.  As you'll see in this discussion, Brad Wilson is always a great source of information for using CVS in the context of .NET, and just CVS in general.  Methinks he should aggregate all these tips/ideas into a book.

I've been happily using CVS for quite a while now thanks to the productive TortoiseCVS, but based on Don's recommendation I'll be looking at Subversion as well. 

I use SQL Server DTSs to import data from flat files exported from various systems, and recently a need came up to allow the end-user of a Windows Forms application serving up ActiveReports reports to control this process (previously scheduled with SQL Agent).  I've done this quite easily in the past using the COM component, but not yet in .NET.  I googled for PIAs for SQL Server with no luck; however, I happened upon this useful resource which includes a free cookbook on using DTSs within .NET; a worthwhile read for those who haven't worked with DTS packages outside of Enterprise Manager before.  

What I would really like is the ability to execute a SQL Agent job asynchronously and be notified when it was completed.  In the past I executed the job with sp_start_job and polled the results of sp_help_job for that particular job to see when it was completed. 

I purchased this book after a couple of bloggers recommended it (apologies, I don't remember who) on Saturday and almost finished reading it today.  This is the first non-technical book I've read in quite a long time, and I actually forgot how pleasing it is to read a book where you're not in a constant concentration mode (save for some of the puzzles).  

I've always been intrigued by stories of the early Microsoft, Bill Gates, and the culture that surrounds them; Pirates of Silicon Valley is one of my favorite movies.  The book is actually more than I expected as it discusses the "puzzle interview" origins, the origins of IQ tests and its imposed value in companies, and some Bill Gatesisms that I found humorous.

The author talks about preparing for these "puzzle interviews", but I really don't think this is the point of the book; certainly isn't why I bought it.  Preparing for them rather negates the purpose, and I'd quite honestly rather be ignorant about the specific type of questions asked.  I work better when I feel those who ask me questions know that my response is not contrived.  Then again, it's certainly easier to derive an answer to these puzzles when you're not on the Microsoft campus under the observation of the interviewer.  

I think those who finish reading a book like this will fall into two categories: those who really want to work for Microsoft, and those who don't... at all.  I definitely fall into the former category. 

On more occasions than I like, I've been asked by pointy-hairs why my initial efforts in a given project take "so long" [1].  My mentality with regards to almost anything development-related is to put forth more effort initially so that I can put forth less later on.  If you compound the time savings for subsequent uses of your project, your initial efforts will look very small. 

A recent example of the above would be a small tool that I wrote to convert a bill-of-materials data file from a client's business software and convert it to a tabular format for use in a relational database.  A lot of older business software platforms seem to like using monolithic data structures with all the information for a given record on the same row; makes it difficult to generate reports.  It took someone else a little over a half an hour to perform the conversion.  It took me a little over an hour to build a tool in C# to perform the conversion.  It takes the former a little over a half an hour each time.  It takes me less than 2 minutes each time using my tool.  You can easily see the time savings here, but that is not what is at issue.  This is a fundamental difference in thought process, and the perception of those who would rather repeat a task every time will always perceive those who hack out tools as being slow--at least initially.  This applies to almost all facets of development, not just tools.  

Even when there is a need to develop a "disposable" tool, a tool which is ostensibly useful only a single time, they seem to find a way to recycle themselves in the future.  I'd say it's a conscious decision on my part to always build a recycleable tool even for remedial tasks, but it's not; I can't think any other way.  I believe most developers are this way, and so does Steve McConnell:

Suppose you're given five hours to do the job and you have a choice:

1. Do the job comfortably in five hours, or
2. Spend four hours and 45 minutes feverishly building a tool to do the job, and then have the tool do the job in 15 minutes.

[Code Complete p505]

When I was thinking about this, I remembered reading the above in Code Complete many years back, so it seems a lot of what I read really did stick with me.  A lot of technical books I assimilate then expunge. 

I will stick with my current mentality.  If I do one task more than once and the second time around it takes the same amount of time as the first, something is wrong. 

[1] The perception of "so long" is usually without reference to the equivalent that takes less than "so long", so it's entirely subjective.