As everyone knows, VBScript blows. However, on occassion, we sometimes are forced to work in it. One significant limitation is that VBScript does not provide a function to format dates with any arbitrary date format string. There are a number of solutions on the net but I have discovered one that provides significantly more power since it leverages the .NET Framework.

Public Function FormatDate( dDateValue, sFormat )
'PURPOSE: To format a date with any arbitrary format
'ARGS:
'   sFormat is the defined formats as used by the .NET Framework's System.DateTimeFormatInfo.
'       Note that this format is case-sensitive.
'CALLS:
'   1. System.Text.StringBuilder class in the .NET Framework.
'EXAMPLE CALL:  
'   Dim sFormatedDate
'   sFormatedDate = FormatDate( "1/1/1900 12:00 AM", "MM/dd/yy" )
'   Or
'   sFormatedDate = FormatDate( "1/1/1900 12:00 AM", "MM/dd/yyyy" )
'DESIGN NOTE:
'   This function leverages the fact that System.Text.StringBuilder is COMVisible.
'   Thus, we can call its AppendFormat function from here.
'   You can find more information about the format string parameters allowed at
'   http://msdn.microsoft.com/en-us/library/system.globalization.datetimeformatinfo.aspx

    Dim oStringBuilder
    Dim sSbFormatString

    If Not IsDate( dDateValue ) Then
        FormatDate = vbNullString
        Exit Function
    End If    
    
    'if an empty format string is passed, then simply return
    'the value using the default shortdate format.
    If Len(sFormat & vbNullString) = 0 Then
        sSbFormatString = "{0:d}"
    Else
        sSbFormatString = "{0:" & sFormat & "}"
    End If
    
    sSbFormatString = "{0:" & sFormat & "}"
    Set oStringBuilder = CreateObject("System.Text.StringBuilder")
    FormatDate = oStringBuilder.AppendFormat(sSbFormatString, dDateValue)
    Set oStringBuilder = Nothing
End Function

 

In a relatively recent post by Joel, he pines poetic about "duct tape" programmers that "just get stuff done." 

All business endeavors come down to cost-benefit analysis. Writing code with bailing wire and 3-in-1 oil is no different. The cost of writing spaghetti code is always in the maintenance and reporting not in the initial release. How many customers will have this code? If the application is purely one off for one installation point or one customer and will never be reported against, then the benefit of releasing "something" more than covers the cost. How often does that type of project come along: one installation point and/or one customer, zero maintenance responsibility, zero reporting?

Writing code that is difficult to maintain adds orders of magnitude to the cost. If there are many installation points, then the cost rises exponentially with the number of installations.

In my experience, the "just get it done" developers generally never look to the future. They never ask questions about maintenance or reporting. Typically, they swoop in, write the magic widget with no care about code quality or maintainability, bask in the warmth of hero worship for "getting it done" and move on before anyone has discovered the cluster f- they created. If your company is really unlucky, "the day" comes when it is realized that said duct tape developers' solution only "looked" right but in reality had several critical flaws that bring down the company. I have been a witness to this exact scenario (thankfully, it wasn't my code) and it wasn't pretty.

In my experience, I find that people that just want "get it done" developers do not account for all the things that actually need to be done.

The other data I was reading Joel Spolsky's article about start-ups. In short, Joel comes to a shocking conclusion that I have stated on many occasions:

Consider, for example, the sales chart for one of our products, Fog Creek Copilot. At first, we charged $10 a day, and every time a customer wanted to use the service, he or she had to whip out a credit card and type in those 16 digits or use PayPal. As the green line on the chart indicates, we had steady but unremarkable sales. Then, in December 2005, one of my developers built a subscription service so that customers could sign up to be automatically billed every month. We thought this would be a minor convenience for some users. Turns out, we had wildly underestimated the impact this new method of payment would have. As the red line shows, sales took off.

In short, he is reiterating something I have said many times: Don't make it hard for your customers to give you money. A more intereresting question is why does that help beyond the additional revenue? The obvious answer is cash flow and in this light we really see the two biggest, real killers of small businesses: lack of capital and lack of cash flow.

When I speak of capital, I am referring to all money needed until the business can sustain itself based on its own revenue. The reason any average Joe cannot start a car manufacturing company is that you need a factory to build the cars and that factory, and the people employed in it, require a tremendous amount of money in order to even begin to make products. In other words, you need millions of dollars before you can make your first penny. It can take anywhere from one to ten years or more for a company to become self-substaining. Most importantly, that initial capital is used to pay bills and employees until the company is able to generate sufficient revenue on its own. Most small business owners severely underestimate the amount of capital required to get the business to the point of self-sustaining. Even though many software ventures require less capital, unless the developers are trading time for ownership, you must have sufficient capital to pay them until your website or product can generate revenue.

Most small businesses also run into problems managing cash flow. Cash flow is what they use to pay their bills and employees. The landlord nor your employees want to hear that you are waiting for your customers to pay you in order to pay them. Their bill collectors will not wait and neither should they. I also have noted that many small businesses do not keep sufficient cash on-hand to accomodate occasional contractions in business. So, being a small business with a small number of customers, if they lose a customer or two, even from no fault of their own, their whole business suffers because they have no margin for error.

 

One of the many useful tools that comes with the XP Support Tools is a utility called TaskKill. TaskKill lets you dump a process that refuses to let you kill it from the Task Manager. On occasion, I have run into processes that would throw an "Access is denied" error when I try to kill it from the Task Manager. Once you have installed the XP Support Tools and have it as part of your path, simply type taskkill /? to get more information.

Dallas' red light cameras may face changes as revenue estimate drops Dallas' system works too well, eating into revenues, fueling possible changes. 

The Dallas Morning News

 

Municipalities should not depend on fines to generate revenue. It creates an obvious conflict of interest and this article is a clear example of those unintended consequences that derive from such a mistake. What are organizations such as the California Highway Patrol going to do if everyone actually obeys the speed limit? It may become possible in the future to devise means by which the populace does not break obvious revenue generating laws such as speeding and that will put a serious damper on their revenue stream.