Log4net is a popular logging framework, and amongst the various logging “appenders” it includes one for sending emails – the SmtpAppender. The documentation for the SmtpAppender’s To property says it contains a semicolon-delimited list of email addresses.
However if you try to do that, you won’t see any emails being sent. Add the following to your app.config file to enable log4net’s debug logging:
<add key="log4net.Internal.Debug" value="true" />
You’ll then see this internal error message in the log4net.txt file:
System.FormatException: The specified string is not in the form required for an e-mail address.
at System.Net.Mime.MailBnfHelper.ReadMailAddress(String data, Int32& offset, String& displayName)
at System.Net.Mail.MailAddressCollection.ParseValue(String addresses)
at log4net.Appender.SmtpAppender.SendEmail(String messageBody)
at log4net.Appender.SmtpAppender.SendBuffer(LoggingEvent events)
This shows that the SmtpAppender is leveraging the .NET Framework’s System.Net.Mail.MailAddressCollection class. The ParseValue method is not public, but Add(string) is, and if you scroll down to the remarks, you’ll see the following text:
If multiple e-mail addresses separated with a semicolon character (";") are passed in the addresses parameter. a FormatException exception is raised.
So it turns out log4net’s documentation is misleading, or at least out of date. Change your email addresses to use the comma and everything comes good again.
I’m pleased to report that it appears the biscuit drought has broken. We’re seeing good falls of assorted creams as well as the good old family assorted again.
That is a relief!
One of the nice things about my current workplace – they provide tea, coffee, Milo (but not Bonox!) and usually once a week if you’re lucky you’ll find some bickies in the kitchen, presumably left by the biscuit fairy.
Death March (2nd Edition) (Yourdon Press Series) - published by Prentice Hall, 1997
When I first began reading this book, I thought it would be all about the team that came before us… the one that spent a lot of time delivering something that didn’t work. But the more I read, the more I found myself identifying our current team with the descriptions in each chapter. Curious as the title doesn’t sound that positive! As Wikipedia defines it, a death march project is one that is destined to fail.
One point that comes out repeatedly is that while in some ways “Death March” projects are not intended to be the norm, more often than not they end up being the de facto way that many IT projects are run.
In Ch. 1, characteristics of a “Death March” project are listed as including:
- Tight schedules
- Small team
- Limited budget
- More features
- Smaller scale
Hmm.. that sounds familiar!
In subsequent chapters he goes on to cover topics such as Politics, Negotiations, People, Processes, Tools & Technologies and finally the idea of “Death March” projects as a way of life.
In Ch. 3, the topic of Estimation is examined, and the value of having an experienced project manager who can estimate slightly better than just “gut feeling”, and that there are software estimation tools that can improve forecasting accuracy. I reckon Steve McConnell’s Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) could be worth a read to learn a bit more about this topic. I’ll add that to my wish list!
People can make all the difference, and our team certainly bears this out. I can’t agree with the comment that 80 hours a week is ok though.
Yourdon also espouses the importance of good workplace conditions – in particular quietness and privacy (eg. separate offices). There’s certainly empirical evidence to reinforce the productivity benefits, which flies in the face of the current trend of “open” office space, cramming as many people into tiny cubicles as possible.
Triaging tasks/bugs are critical, and allows you to prioritise what is important.
When this book was first published, there wasn’t much in the way of “Agile” development practises, but I think Yourdon is alluding to this when he makes mention of using RAD tools (refactoring), mini-milestones (iterations) and daily builds (continuous integration).
One thing I did find annoying was Yourdon’s use of a monospace font when listing the emails in each chapter’s list of references. This made them very hard to read and I mostly ended up skipping over them as a result.
Overall I came away inspired by this book. Yourdon highlighted the many pitfalls that await a team who are engaged in a “Death March” project, but does offer hope that under the right conditions, you can achieve success.
We had a blast last night. It was great fun. We ended up performing about 10.40pm, and seemed to be well received. The stage was a little small but we managed to fit all 7 of us there (and Billy-Bob said they once had 14 so we’re not the largest group to play there).
The quality of the other bands playing was very good, but I think we held our own. No word from any record companies wanting to sign us up yet.
We all got a free drink voucher, but curiously they insisted the voucher was good only for a schooner of beer, even though all I wanted was a “raspberry” (surely soft drinks cost less than beer?). I bought one instead, but had to tell the girl how to make it - “just raspberry cordial and lemonade”. Yum.
On an final note, I also discovered that “pub rules” for playing pool do exist – fortunately I wasn’t the one who failed to pot any balls :-)
I’ve decided we need to get a new printer for home/home office use. The main requirements are for black & white, with some colour printing (but not necessarily photo-quality). We’re happy to continue to get our digital photos processed commercially (eg. when Harvey Norman has a special!)
We’ve previously had a old Canon BJC-2100SP, which was never that impressive. More recently Gary gave me a second-hand HP LaserJet 2100, which does a very nice job except when it jams (which is becoming all too frequent).
One thought was to get two printers – a B&W laser and a cheapish inkjet colour printer, but talking to the guys at work yesterday, Timothy pointed out that if you don’t use the colour regularly then it can dry out. So maybe a colour laser printer might be a good option. The idea of having a network-enabled printer is attractive, though obviously you do pay more for that feature.
Here’s a few of the models I’ve been considering, and a rough calculation of the cost per page for black and white printing.
Maybe the network option isn’t really necessary. Going on the figures above, the Canon 5200 does look like a good compromise between upfront and ongoing consumable costs.
Any other suggestions?