Friday, September 30, 2005 Check out this combination of Google Maps and live NYC traffic cameras. It's called NYsee and it's cool. posted by Kirby | September 30 10:40 AM | comments (0)
Monday, September 26, 2005 SMTP Diagnostics 1.4 Beta 1 is available for download. Click here for more information. posted by Kirby | September 26 07:03 PM | comments (0)
Friday, September 23, 2005 My small refactoring effort on SMTP Diagnostics turned into a much bigger effort but the end result is a much better code base. The exercise led to re-architecting most of the application. The GUI remains untouched but everything else behind the scenes has changed. After an 11 hour marathon session, I finally got a clean compile. I still need to re-wire parts of the GUI to the new object model before I can begin testing. But I did write unit tests (using DUnit) for all of the non-GUI code as part of the refactoring exercise. All of this re-work is definitely going to make it easier to add new features in the future.
Incorporating another New Feature
Speaking of new features, a fellow developer recommended I incorporate RSS feeds as a way to inform users of new releases within the program. I instantly fell in love with this idea mainly because it allows me to share more information with customer beyond just "a new release is available". By using an RSS feed, I will be able to let users know about new releases, show the list of enhancements and bug fixes, send out tips, and possibly a newsletter some day.
Of course the user will have the option to turn off the feed feature, or to display the feed on demand. But I think this is a great use for RSS that I plan to incorporate in all of our products going forward. posted by Kirby | September 23 10:42 AM | comments (0)
Thursday, September 22, 2005 According to EBgames.com, the official street date for the Xbox 360 is November 22, 2005. I pre-ordered my 360 with overnight delivery, but given that the 22nd is only a couple of days before Thanksgiving I should have requested standard ground shipping. Chances are good I will be out of town when the shipment is delivered. Oh well. posted by Kirby | September 22 10:00 AM | comments (0)
Have you read this?
Robert Coates made an offer to buy Delphi and Deploy (whatever that is) from Borland for $150,000,000. Yep, $150 million from a company valued at $242 million (a difference of $92 million). And Borland's Board of Directors said "No".
On top of that, this article includes a number of quotes from Borland's chief marketing office Rick Jackson, none of which include Delphi, such as ".NET developers who want to make use of Borland Together modeling tools and its CaliberRM requirements offerings do so in Visual Studio, using Borland products designed for Microsoft?s development environment." So Delphi.NET developers cannot use the Delphi IDE with tools like Together and CaliberRM?
I've never really worried about the future of Delphi, but now I'm wondering what Borland is thinking. If Coates is right and members of the Delphi R&D team leave, what does this mean to the future of Delphi? And if Borland is not welling to sell it for what I feel is a more than reasonable price, is it possible that the product life cycle will come to an end within the next few years?
I for one love Delphi. In my opinion, it is the best development language, environment, and platform for Windows-based applications. 3rd party support for the language through components and such is incredible. And while C# is on my list of top 2 favorite languages, I can't imagine doing Windows development without Delphi. I spent the last 4 years working in C# and I can't begin to explain how happy I am to be working in Delphi again.
[Thanks to Nick Hodges for pointing out these URLs. And be sure to read these additional comments from Nick's blog site.] posted by Kirby | September 22 12:57 AM | comments (0)
Wednesday, September 21, 2005 In a recent blog posting, I talked about convincing a client it's time to refactor. Well, I have spent the last few days convincing myself that it is time to do some refactoring of SMTP Diagnostics.
For those who don't know, SMTP Diagnostics is a mailer program enabling you to troubleshoot problems with outgoing email and assist with configuring outgoing (SMTP) servers.
I have been putting off refactoring while still adding new features. I did this to "save time" but the code base has reached a point where it is now more time consuming then it should be to add new features. I can put it off no longer.
What's fun about this exercise is that I get to build from the knowledge obtain thus far. Version 1.0 did not have a solid object model and a lot of the code was specific to this one project. Version 1.2 and 1.3 moved away from that by incorporating common code, or a common framework, that I'm using in a second product code-name Vertigo. Version 1.4, which is the next release, will finally have a reusable object model that will make adding new features much easier. For example, adding command line support will be a snap once the new object model is in place.
Look for the beta release for version 1.4 in a few days. posted by Kirby | September 21 10:35 AM | comments (0)
Monday, September 19, 2005 We are happy to announcement the new SMTP Diagnostics web site. Find the latest download, purchase your license, view the FAQ, and more.
http://www.smtpdiagnostics.com/ posted by Kirby | September 19 02:29 AM | comments (0)
Tonight I discovered an interesting Visual Studio.NET 2003 bug. Seems devenv.exe will throw an unhandled exception when the constant in the sample code below is compiled. From what I can tell, it looks like devenv.exe chokes on the length of the contant. Remove line 73 (LEFT OUTER JOIN...) and the exception is not thrown.
The exception only occurs when compiling the project from within VS.NET 2003 (devenv.exe). The command line compiler csc.exe does not have the problem. Also, the problem does not occur if you are using Delphi 2005. Makes me wonder what devenv.exe is doing during the project build process.
posted by Kirby | September 19 01:16 AM | comments (0)
001 using System;
002
003 namespace ConsoleApplication3
004 {
005 /// <summary>
006 /// Summary description for Class1.
007 /// </summary>
008 class Class1
009 {
010 /// <summary>
011 /// The main entry point for the application.
012 /// </summary>
013 [STAThread]
014 static void Main(string[] args)
015 {
016 const string SQL_FORMAT = @"
017 SELECT
018 1 AS Tag,
019 NULL AS Parent,
020 NULL AS [users!1],
021 NULL AS [user!2!strUSID],
022 NULL AS [user!2!strPrefixID],
023 NULL AS [user!2!strFirstName],
024 NULL AS [user!2!strLastName],
025 NULL AS [user!2!strUSName],
026 NULL AS [user!2!strAdd1],
027 NULL AS [user!2!strAdd2],
028 NULL AS [user!2!strTown],
029 NULL AS [user!2!strState],
030 NULL AS [user!2!strPostCode],
031 NULL AS [user!2!strCountry],
032 NULL AS [user!2!strTel],
033 NULL AS [user!2!strFax],
034 NULL AS [user!2!strEMail],
035 NULL AS [user!2!strLocked],
036 NULL AS [user!2!dtmLockedDate],
037 NULL AS [user!2!strSuspenseReason],
038 NULL AS [user!2!intLogonCount],
039 NULL AS [user!2!dtmCreatedDate],
040 NULL AS [user!2!strMedicalSpecialtyID],
041 NULL AS [user!2!blnChangePassword],
042 NULL AS [user!2!strInstitutionalUser],
043 NULL AS [user!2!strCreditCardExpDate]
044 UNION
045 SELECT
046 2 AS Tag,
047 1 AS Parent,
048 NULL,
049 Users.strUSID,
050 strPrefixID,
051 strFirstName,
052 strLastName,
053 strUSName,
054 strAdd1,
055 strAdd2,
056 strTown,
057 strState,
058 strPostCode,
059 strCountry,
060 strTel,
061 strFax,
062 strEMail,
063 strLocked,
064 dtmLockedDate,
065 ID_LoginSuspenseReason.strSuspenseReason,
066 intLogonCount,
067 dtmCreatedDate,
068 strMedicalSpecialtyID,
069 blnChangePassword,
070 strInstitutionalUser,
071 strCreditCardExpDate
072 FROM ID_Login Users
073 LEFT OUTER JOIN ID_LoginSuspenseReason ON Users.strUSID = ID_LoginSuspenseReason.strUSID
074 {0}
075 FOR XML EXPLICIT
076 ";
077 }
078 }
079 }
Tuesday, September 06, 2005 I recently changed the way perm links are generated for my blog entries. However, I totally forgot about making the change to my RSS feed. I guess that's what happens when you introduce a technology like RSS and it runs problem free for months if not years. Still, that's no excuse for overlooking the RSS feed with regard to the new perm links.
I will have a fix in place within a couple of days. Sorry it can't be sooner but my plate is full at the moment and since that has been no complaints it's not a top priority issue.
My apologies to those of you reading the blog through an RSS reader. posted by Kirby | September 6 01:04 PM | comments (0)
White Peak Software is donating 10 licenses of SMTP Diagnostics to Seth Dillingham's PMC fund raiser. The licenses along with other software that will be auctioned off in September to raise money for the Jimmy Fund. All proceeds from the auction will go to the Pan-Mass Challenge, and in turn to the Jummy Fund, for the research and treatment of cancer at the Dana-Farber Cancer Institute in Boston.
The PMC is a 192 mile bike ride across Massachusetts. This year's ride had approximately 4,000 riders. posted by Kirby | September 6 10:52 AM | comments (0)
Friday, September 02, 2005 You know what I dislike the most about doing client work? You see problems in the code, no bugs - things are working correctly, but the code itself is a problem. Finding code smells for example, and you know the best thing to do is refactor the code to save tons of time in the future. But some clients don't get this and the ones that do get it will still say no to refactor work.
You tell the client you want to spend a couple of days to refactor the code but the client says "No". To the client the code is working fine. Refactoring is going to cost more money and require more testing while providing little benefit to the end user. But the reality is ongoing maintenance cost for the code is going to cost more, which down the road could increase the cost to the end user, if refactoring does not occur. What is often overlooked is that maintenance costs can be lowered in the long term as a result of a refactoring investment.
Refactoring is something that should be embraced, not feared or viewed as an unnecessary cost. Refactoring improves the quality of the code and reduces code maintenance in the future and thus reduces cost.
A joy I have in writing my own software is being able to make the refactoring call myself. I don't always say yes to refactoring but when the time is right I refactor the code. I don't concern myself with the initial refactoring and testing costs because I know it will save me time and money in the long run.
So when is the time right? That's a hard question to answer because the right time can be different for each shop and software package. For me a right time is when working on a new feature I find a number of code smells affecting the quality of the feature. Assuming a refactor will only affect a small portion of the entire system and it will take no more than a couple of days to refactor and test the changes, I make the yes call to refactor the code.
Do I worry about breaking existing functionality as a result of refactoring? Absolutely, especially when refactoring occurs in a critical area such as processing a credit card transaction. This is why it is so important to have automated scripts and unit tests in place. Automated regression testing definitely helps ease concerns.
So how do I convince the client it is time to refactor code? I wish there was a magic answer to the question that could be applied to all cases but there isn't. Getting the client to okay a refactor takes having the client's trust in your abilities and decisions.
One way to gain trust is to know when to recommend a refactor. You should make a point not to scream "fire" each time you find code smells. If each time you are asked to implement a new feature and you come back with "Before I can implement the feature I need to re-write all this other code," your client's trust in you will most definitely drop.
You also need to be able to show the client the long term value gained by refactoring. For instance, make the client aware of the various code smells and discuss the impact the repeated (or similar) code has to maintenance should a bug be found or a business requirement changes in the future. Also, remind the client that the need is fresh in your head but 6 months later it is going to take more time research the impact. Plus, the number of smells may have grown between the time the problem was first identified and the time code has to change, resulting in higher costs.
Lastly, be mindful of the business side. Many times developers only think of the technical aspects with no regard to the business side of things. Understand what is happening on the business side of a project will help when discussing a refactoring effort with a client. This can also help you understand why the answer is "No" and could help you identify a better "right time" to refactor.
Convincing a client it is time to refactor is no trivial task but it is possible. posted by Kirby | September 2 01:18 PM | comments (0)
