Random Thoughts of a Scatterbrain.
 Wednesday, May 03, 2006

Enterprise Library 2.0 Logging Quirks

5/3/2006 6:35:51 PM (Eastern Daylight Time, UTC-04:00)

So I've been working with Enterprise Library 2.0 (EL2) Logging Application Block recently and I've come across some quirks that are puzzling me.

First, I've been using log4net for most of my logging in the past.  Recently, I've taken a look at NLog due to the fact that log4net is currently under "incubation" and has been inactive for a loooong time.  The developers are still active as shown by the activity in the the mailing lists, but otherwise, the codebase has been kinda sitting there for quite some time (until recently) with no date on when it'll exit incubation.

Anyways, after checking out some performance numbers on EL2 vs. log4net, I was sold.  Easy configuration via the configuration GUI, easy to understand, tons of documentation, and it's first party Microsoft (easy to get team members and managers to buy into it).

So here I am working with it today and setting up my test code to automatically regenerate the database before each run and my application code crashes when the logging fails (exception).  I had mis-typed the path for one of my SQL files and the database wasn't created for the logging block, but still, I don't think that the right thing for EL2 to do is to allow that logging error to bubble up to the application code.  With log4net, if the connection to the log database is broken, the AdoNetAppender will simply fail but not cause the rest of the application code to fail. [Update: can't reproduce it, but I know this is what cause the error since as soon as the database was there, it was happy, but it's running fine now even without a database. Ugh, totally puzzling...]

Weird design choice.  I guess it's useful to know that your logging block is failing.  But what the heck, isn't that why there are multiple listeners so that if one fails, you have a fallback (i.e. log all critical errors to database, event log, and flat file)?

Secondly, as I'm looking at the database scripts for creating the procedures and database tables for logging included with the EL2 source code, I'm puzzled by the design choice.

Take a look at the code for adding a category:

First of all, why are the categories stored in a seperate table?  My guess is that the designers wanted to save some space in the log entry row by taking out the category from the log entry???  I can't seem to come up with another good reason for it since it's not like the categories in the category table are associated with an application identifier (and they must all be unique category names).  Profiler tells me that it requires at least 14 reads to write one entry into the log.

Not only that, the code to execute adding the category and adding the log entry are two seperate calls from the client since the WriteLog procedure doesn't receive category information.  I'm going to go out on a limb and say that the only reason that EL2 logging is able to outperform log4net is due to .Net 2.0 related optimizations.

So I think it's back to log4net for me.  I don't know how the rest of the team will take it, but it seems to be a better choice.

Random Happenings

5/3/2006 2:55:38 PM (Eastern Daylight Time, UTC-04:00)

Well, my pineapple died recently.

Yes, that's right, pineapple.  Sometime last year, I decided to start growing a pineapple plant after I picked up a weird interest in growing tropical plants (fruits in particular).

Why pineapples?  Well, I found out from various sites online that the pineapple has an amazingly rich history.  Plus, I love the taste of pineapple :-)  Besides, I figured it would be easier to try to raise a potted plant as opposed to, say a mango tree.

So I found some directions online on how to grow a pineapple and started to grow one from the healthiest crown I could find.

At first I was a bit skeptical as to how hardy the plant would be after reading the directions.  As it turns out, though, pineapples are amazingly hardy with regards to water and temperatures.  The plant survived sub-70 degree weather in my townhouse and office during the winter and wasn't any worse for wear.  But alas, it was not hardy enough for sub-50 degree temps.  I recently moved and since the weather was getting nicer, I started to keep the pineapple outside.  A couple of nights ago, I forgot to bring it inside only to wake up in the morning to find frost (!!!) on my car window.  Frost == dead pineapple :-S

It lived for over a year; not bad.  Quite an attractive plant, too.  I started to grow two more yesterday; we'll see how these two go.

On an unrelated note, I'm starting to suffer with "only" 1GB of RAM on my notebook (unfortunately, the max it can accept).  With VS.Net 2005 and ReSharper 2.0b running on a small project, it's taking up roughly 350 MB of memory.  To complicate matters, all of the 2005 apps (VS, SQL Management Studio, etc.) are such resource hogs, that there is noticeable lag when I use any of them.  I've had to shut down SQL Server for the most part (unless I really need it) and a lot of other services as well.

Merom can't come soon enough...

 Monday, May 01, 2006

Awesome Blog

5/1/2006 9:43:18 PM (Eastern Daylight Time, UTC-04:00)

Came across a great blog while looking for images of praying mantids.

Great links.

Including this one and this one.

Bookmarked!

TortoiseSVN Tip

5/1/2006 3:16:29 PM (Eastern Daylight Time, UTC-04:00)

Hey now! Our inaugural post for May!

Let's start things off with a tip for TortoiseSVN users out there.

First of all, did you know that you can right-drag objects in the Windows GUI? No? Neither did I. I felt like such a noob upon discovering this functionality as I've never, in my several years of Windows usage, ever known about this. Well, in any case, you can, and it's way better than the default left drag that we all know and love.

What's this got to do with Tortoise? Well, I went onto the SVN IRC channel trying to figure out if there was a way to move files in a "SVN-aware" fashion. After asking around and googling, I came across this article that mentioned right dragging.

Note that you will only get the proper context menu commands if the target folder is already under version control; if not, you will not get an option to perform a SVN-aware file/folder move.

tortoisesvn-move.gif

This is by far, much more convenient than left dragging and then manually adding the file to the repository in a new location (and removing the file from the old location).

 Saturday, April 29, 2006

Hole-y Cow....

4/29/2006 11:42:49 AM (Eastern Daylight Time, UTC-04:00)

Must see.

I think this pretty much speaks for itself....

 Thursday, April 27, 2006

Awesome Defined

4/27/2006 7:06:26 PM (Eastern Daylight Time, UTC-04:00)

Wow.  Trac just impresses me more each day.

Today, it's the peer review plugin.

If you looked up the definition of awesome in the dictionary, I'm almost positive that you'd find this mentioned somewhere in the entry.

It's a component that plugs into Trac and allows you to start peer reviews on code blocks in your repository.  Users assigned to the peer review can view the source code in the browser and make comments on particular lines of code.  There's also  a pass/fail mechanism to vote on how to proceed with the code.  The truly badass part about it is the GUI implementation.

Here's a screenshot of it in action:

trac-peer-review_t.gif

If this isn't the definition of awesome, I just don't know what is.

Great use of AJAX.  I did something similar for a different app I wrote recently:

arp-comment-screen_t.gif

I love this approach for web application design since it's so much less intrusive than opening a new window and offers far better customization of the look and feel of the overall UI.  The big problem is that it's probably not accessibility standards compliant; many screen readers will not properly pick up the change in the UI and the newly inserted HTML content.  If such domains are not a concern, then such a visual design pattern is definitely the way to go if you're building a web based GUI which requires multiple subscreens.

OMIGOSH!

4/27/2006 12:15:19 PM (Eastern Daylight Time, UTC-04:00)

I feel like a little schoolgirl (and a little perplexed).  I've been following Nintendo's next console quite closely for the last few months.  Going by the codename of "Revolution", Nintendo has taken what many seem to be a big gamble by going in the opposite direction of competitors like Sony and Microsoft.

Today, we see how Nintendo continues along a path of defiance of the norm; Nintendo's "Revolution" console will officially be known as.....


Nintendo Wii


Check it out for yourself here: http://revolution.nintendo.com/.

Introducing...Wii.

As in "we."

While the code-name "Revolution expressed our direction, Wii represents the answer.

Wii will break down that wall that seperates video game players from everybody else.

Wii will put people more in touch with their games...and each other.  But you're probably asking: What does the name mean?

Wii sounds like "we," which emphasizes this console is for everyone.

Wii can easily be remembered by people around the world, no matter what language they speak.  No confusion.  No need to abbreviate.  Just Wii.

Wii has a distinctive "ii" spelling that symbolizes both the unique controllers and the image of people gathering to play.

And Wii, as a name and a console, brings something revolutionary to the world of video games that sets it apart from the crowd.

So that's Wii.  But now Nintendo needs you.

Because, it's really not about your or me.

It's about Wii.

And together, Wii will change everything.

Wow.  Crazy and brilliant at the same time.

 Tuesday, April 25, 2006

The Little Things that Count

4/25/2006 9:35:28 PM (Eastern Daylight Time, UTC-04:00)

Maybe it's just me, but there are some little things that bug me to no end (my wife thinks I'm slightly OCD).

Lately, it's bad spelling and grammar.

I don’t know, I simply don’t think it’s acceptable in an age when a proper spell check is only a button click away, why people have to put up with misspelled words in professional documents and email exchanges.

It bothers me so much that once I see an email or document that has terrible grammar, misspelling, or punctuation, I am no longer able to mentally process the document as my mind shifts to pondering what could be so pressing that the person that composed this document before me couldn’t hit the spell check button.  Most likely, the author simply doesn’t care?  Such documents simply give the impression of a rushed reply with no concern for professionalism, craftsmanship, or interest.

Of course, grammar is probably the hardest aspect of written English, so I tend to not mind grammar errors as much unless they are obvious ones (use of “a” versus “an”, for example).

What’s worse is that I get emails like this all the time from recruiters regarding positions.  Not only from those who speak English as a second language (I can give some slack there as my mom has terrible spoken and written English), but it’s even common from native English speakers.

I don’t understand; in such a scenario, wouldn’t you want to be more professional in mannerisms and communications to assure the possible candidate of the professionalism of your organization?  I know I would.

As a side note, I'm thoroughly impressed by the written English of many Europeans who do not speak English as a first language, like SNE :-)

 Thursday, April 20, 2006

Random DevTools Entry: #010

4/20/2006 1:15:27 PM (Eastern Daylight Time, UTC-04:00)

Today's entry is Windows Installer XML (WiX for short), an open source project (the first?) from Microsoft that is used internally by Microsoft development teams for building installers for many of their products.

I first used it more than a year ago when I was at Merrill Lynch.  I had to build an installer for a Windows Serivce and I wanted the service to auto-start after installation.  I was totally baffled by how to do this in the VS installer projects (is it even possible?) and somehow ended up stumbling across WiX.  It worked great :-) It was a little rough going because there was so little documentation and Net knowledge regarding usage.

Since then, I haven't really had a reason to look beyond the built in VS installer projects, but I'm working on another complex installer scenario now and decided to check in on WiX again.  To my surprise, there still doesn't seem to exist a UI to design WiX installation packages (at least none that I came across via googling).

However, I did find a very well done tutorial.

Of course, Rob Mensching's blog is full of news and developments on WiX.

Rob mentions in his first post on the subject of WiX that:

Internally, teams such as Office, SQL Server, BizTalk, Virtual PC, Instant Messenger, several msn.com properties, and many others use WiX to build their MSI and MSM files today.  When someone encounters a bug, the community tracks the issue down and fixes it.  Now, via SourceForge.net, you have an opportunity to be a part of the community as well.

I guess it's also good to note that WiX just celebrated it's 2-year OSS status recently.

 Tuesday, April 18, 2006

Still Not There Yet...

4/18/2006 8:47:10 AM (Eastern Daylight Time, UTC-04:00)

I don't understand the fascination with using Word documents for internal development specs.

For one thing, a Word document is very inefficient when it comes to conveying matters of code and design.  No syntax highlighting.  It constantly warns me that I'm misspelling my words.  It wants to adjust my indentation and paragraphs for me when I put formatted code into a document.

Even more annoying is the fact that a Word document is essentially a snapshot of what was designed, at some point in time.  Past tense.  Unfortunately, designs change and details change as developers start to dig into the software at all levels; no one person can forsee all of the challenges in designing any medium-large software product; no one person can predict all of the different, possibly better implementations and architecture.  New changes mean I get a new document in my inbox.

Using Word documents, it becomes incredibly tedious to now maintain this constant state of change.  Everyone on the team has a copy.  Yet, in order to maintain any sense of order, only one person can be the source of all of the change.  Useless.  Inefficient.  Terrible.

There's a reason why typewriters were replaced by word processors.

Enter Trac.  It does everything right that Word does wrong for documenting software specifications.  The Wiki system links text to existing tickets, source code files, and other documents without effort.  It's infinitely malleable and entirely flexible; in a sense, it's "live".  It highlights code and allows full flexibility in formatting the code.  It offers a view into your source repository.  It has a system for creating milestones and linking tickets to those milestones.  You work on documenting your part in your Wiki page, I'll document mine in my Wiki page.  All the ideas, concepts, and thoughts now sit in a central repository that is constantly evolving as the project evolves.

In short, Trac is damn near the perfect software project management application and its usefulness spans the entire lifecycle of the project, from initial design to maintenance to continuing development.

Unfortunately, I'm the only one on my team using it :-S I don't get it.  What's the fascination with Word when an infinitely better solution is available?  I set it up and demonstrated it with the hopes that these tech-heads here would dig it and see the awesome potential it has for transforming how the development process proceeds.  And yet, here I sit, baffled by why such a tool is laid to the by-ways for Word.

I guess I'm still not there yet...

RSS 2.0 Atom 1.0 CDF