Monthly Archives: January 2009

I Just Need a Date

How hard can it be to get a date?

Today is 15004 in PICK internal date values. I now know that I can add 46385 to this to get the internal MUMPS date.  It is probably somewhat telling that I have this number memorized. 

In our application we will often be working with dates and times. When I know I’m going to work with dates, I have to warm myself up to doing so. Date-handling is something I have had the luxury of successfully delegating, with some exceptions, since about 1984. It might not be a coincidence that my youngest child was born that year. Babies can have a way of turning all else into minutia.

After many years of date “stories” such as handling the decade in Pr1me COBOL programs in the 1970’s with a constant of “7” sitting in WORKING STORAGE, given that the system date had only 5 characters (I kid you not), then subsequently upgrading everything once we got that 6th digit for the decade in time for 1980, in some ways I feel like I’ve done my date time (or is that timedate?). I don’t hate date-handling, but it tires me out. In advance, it seems like it should be small, but in reality, getting your act together on the time and date fronts across the board in your platform can very time (and date) consuming.

I have avoided doing anything with dates that wasn’t absolutely essential for accuracy until now. All of the dates in Build 20 of our not-anywhere-close-to-ready-for-prime-time SnupNow software application are currently shown to and collected from users in ODBC format, such as 2009-01-25, although we get a nifty drop-down calendar component for free from our Zen AJAX platform, so users need not enter them that way. I recently made an exception with two read-only dates so they looked USA-pretty as mm/dd/yyyy.

My intent was to ignore all of the output and input formatting issues first, using only that which came packaged in our tool set, until we were certain we could put dates in the database accurately, retrieve them successfully, compare them accurately, and qualify queries based on dates. Until we have confidence in the accuracy of the dates when working with our AJAX framework, I didn’t want to obscure the effort by messing with formats. 

Now, you might think that I set the bar pretty low with the initial date work, but when we upgraded our pre-release database server so that dates before December 31, 1967 (PICK Day 0) could be handled by our AJAX framework, allowing me to finally get my birthday into the system through a web page, we seem to have adopted an, uh, undesirable feature in another area as it relates to MV Dates. I have worked on addressing three separate date issues this week (two down, one to go), so I’m sensing this was a wise decision on my part. Dates are not just hard for me to address as even solid, long-time, quality software companies can have problems with dates.

Once you start down the path of figuring out how to handle dates in your platform and application, you can end up spending hours of time working to standardize such work. So far, both Ken and Tom have done some date work, as have I, but none of us has been up for nailing this down for reuse in the platform. [With an agile approach to software development, at what point do you stop doing date one-offs to meet the application requirements at hand?]

We now have a need for date manipulations in 3 languages: JavaScript, SQL, and MVBASIC, plus one: MUMPS, even if only when something is amiss. For every language and related “native format” for a date we could have conversions to and from a variety of external dates, plus a need to translate dates between every two of these “native formats.” Three is probably tops for writing routines to switch between every two of the formats. Once you get to four, and that’s where we are, it is time to switch to the hub and spokes approach. So, which date format should be our hub?

Date handling in MultiValue is pretty easy. You can subtract dates and it gets the right answer. That is one of those “you don’t know what you got ’til it’s gone” features in MV. You can handily compare dates and do date manipulations. Doing such with SQL is anything but standardized across vendors, with each database vendor having their own proprietary functions. Date handling in JavaScript is still a bit of a mystery to me, being in seconds since 1/1/1970, but obviously people have figured out how to use it and there should be enough resources out there for us. A date like 1294595536005 is too long a number to want to work with regularly, if you ask me. I can eyeball a PICK date and readily know if it is far in the future or well in the past. MUMPS (COS) dates look very like PICK dates, but if you ask a question about date-handling, someone might give you an answer like $ZDT($H,3), so I’ll not be hanging my hat there.

I guess it is no surprise that for the hub, in this hub and spokes approach to date conversions, I’m going with the MV date, the PICK date. That means we need to switch between every type of date and MV Dates, non-standard as they might be. I used to work with ANSI Julian dates, but given that those have no role to play in anything I’m doing right now, it would be silly to introduce them simply for the purpose of having a hub date format with which more people (perhaps mostly COBOL programmers) are familiar.

There really are plenty of details to consider when working with dates. At least it makes me feel young when I think to myself: how hard can this be, I just need a date!

Cache’ Zen for our AJAX Platform

Violating the rule of thumb about saying something nice first, my last blog entry talked about how the Cache’ language based on MUMPS, COS, does not resonate with me. Now for the good news regarding the platform I selected for our software…

Zen is a framework for doing AJAX with MultiValue BASIC as the server-side language and JavaScript as the client-side language. This permits us to use a richer data model than an RDBMS like MySQL, PostgreSQL, SQL Server, and many others. MultiValue is a platform that has proven (even if only through many, many anecdotes) to be a high productivity environment. We are starting this project with developers who have worked in the MV space, several of them for decades. 

Other languages can be used on the server-side with Zen too, with the most common one being COS. So, not only is this a MultiValue AJAX platform (how cool is that?), it is not limited to the MV space. It makes the umbrella bigger for those of us who have been working in MultiValue.

Cache’ is a highly scalable platform. While in the first ten years we might still have a typical amount of data and use, our software needs to scale up for significant use. We need a platform that can offer us all of the -ilities: scalability, maintainability, reliability including those that don’t end in “ility” such as security and performance.

Additionally, Zen comes with reusable components and a community that is adding to these. These can be specified in a “Zen page” using XML so you might include in your source code a form with a field that is bound to a model, such as a MultiValue file (or logical file).

<dataController id=“source” modelClass=“My.File”  />

<form controllerId=“source” id=“myForm” 
    groupClass=“snupform” enclosingClass=“snupencform”>

<text label=“MyField” id=“MyField” name=“MyField” 
    onvalidate=“return zenPage.validateMyField(zenThis.getValue())” 
    invalidMessage=“This is not a valid MyField value”  />


This should prove to be a very valuable AJAX platform both for developing and maintaining software. The Cache’ toolset that blends MultiValue and AJAX is named Cache 2008.2 and was generally available last year, so it makes some sense that we are just getting out of the gate, although we have been using it for more than a year. There is a learning curve.

The most difficult part in gearing up, other than the fact that this is a sweat equity endeavour and only a couple of people are actually coding so far, is that we are learning to speak MVBASIC enhanced for object-oriented programming, combined with JavaScript and XML specifications (as above) with the examples and documentation primarily written in Hebrew. OK, maybe it’s not Hebrew as we need not read it from right to left, but equally as cryptic to me.

There is another difficulty, which I thought I had better in hand when I started. I had given a couple of talks about AJAX, such as this one. I had written a few examples of AJAX using OpenQM, an open source MultiValue database, and PHP on the back end. I had an initial understanding and a bit of a feel for writing AJAX applications using the prototype library. For me, understanding this client-side framework did not translate handily into using a server-side framework. People who started with a server-side framework for their web pages, even for non-AJAX work, such as JSP, ASP, or Cache’ Server Pages, CSP, are likely further along for using Zen than I was with my prior client-centric approach that reaches in to use server-side services.

You can see that I am justifying my slow start-up with Zen. I have been working to learn and write in this new environment for more than a year, along with trying to teach what I have learned to others, and I have developed nothing resembling a year’s worth of code. No one on the project is to the point where they feel they can pound out code, but I definitely feel more confident in that regard now than I did a year ago. Please note that I have no doubt that if we were each working full-time developing software for SnupNow, we would be much further along, so existing companies with paid software developers are not likely experiencing the learning curve to the same extent that we are. 

Now that we understand this framework a little better and are further along with our application platform, we need to make some more reusable code that can help both our developers and hopefully also others who are using Cache’ Zen with MultiValue. The bottom line is that the gear up has taken a while for reasons that are still somewhat mysterious to me (although I have a list of possibilities), but that I am still committed to and excited about using this platform for the long haul.

Perhaps it was in Peopleware that DeMarco and Lister quoted a restaurant menu saying “Good cooking takes time, if you are made to wait, it is to serve you better.” Maybe it was another book that I read more than two decades ago, but I don’t feel like scanning my bookshelves to check. While I am not purposely coding slowly, I’m pretty sure it was Aesop who indicated that the tortoise won the race.

I hated JavaScript before I got MUMPS

While there are both old and newly-minted ways to extend the browser run-time environment with various add-ons, several coming from some very big players, if you want to write software and keep to the browser as your client-side run-time platform without such add-ons, then JavaScript (ECMAScript, to be precise) is your only choice.

I avoided JavaScript for a long time. I was initially appalled by the name of the language, first because of the word “script” in it (had we not gone beyond procedural languages?) and then with the word Java in it, when there was no Java to be found. I read some code written in the language way back when and wasn’t impressed.

Later I gave it a try. A few years back I had an opportunity to write a little JS code and, son-of-a-gun, I liked it. It felt comfortable. Were it not for things like closures, it might even seem as straight-forward to write as BASIC and Fortran. Why did we move beyond procedural languages again? No, don’t answer, I’m not in the mood for that discussion.

I’m not a language theorist nor even an expert connoisseur of a wide variety of computer languages, but I have used several in production code and I’ve taught four languages at the college level.  I have not been all that picky in some respects, as I have liked most languages I have tried. Now I even like JavaScript. That’s good, because we are using it in this project. I hope to learn it better over the course of the next few years.

My initial distaste and subsequent appreciation for JavaScript has led me to be overly incautious when jumping into Cache’, I suspect. We are writing the software that runs on the server-side using MultiValue BASIC enhanced by InterSystems for object-oriented programming. The libraries we are using are all written in another language-Cache’ Object Script (COS). This language is pretty much the old MUMPS (aka M) language enhanced over time and also enhanced with OO constructs.

In Java it might be

Dog myDog = new Dog();

In COS if Dog were delivered for use by us in programming, that would be

Set myDog = ##class(%SystemPackage.Dog).%New()

This is but a small hint at how funky characters are strewn throughout the language. Before I give any more of my two cents about COS, I better note that I am very happy working with InterSystems and with the people who work there. The MV, Zen (AJAX), SQL, and other teams have been very helpful. They hire very intelligent people, many with more patience than I will ever have. The MV implementation is solid, especially for being the newest major implementation of MultiValue. I’ll admit that I’m sucking up (hey, they know the answers to my questions and I’m gonna continue to need their help), but I am not exaggerating. 

Our biggest learning curve has come from working with Cache’ in places that extend typical MultiValue functionality, where COS/MUMPS-like thinking seems to be around every corner.  When I looked at COS originally, I didn’t like it. Recalling that I did not like JavaScript at first either, I figured it would be fine, I just had to try it and warm up to the language. Plus I only had to learn to read it enough to understand examples or for debugging purposes, not to write it, I figured, since we are writing our source code in MultiValue BASIC for the server-side and JavaScript for the client-side, combined with XML specifications for web page components.

Anywhere in Cache’ that a developer can write COS, we should be able to write MVBASIC instead, in theory. This has mostly panned out, except in some places in Zen, the AJAX framework, such as those where the code being written is a parameter value that must be written in COS. I didn’t want to have any COS in our source code, but there is a little bit at this point.

Well, shucks. I have been looking at COS code for more than a year now and I hate to say it, but I like it even less than I did when I started. It seems to be the reason why in Zen “everything compiles and nothing runs,” as one developer put it. It is also dog ugly (no offense to canines), with tons of non-alpha special characters to make the language far from Grace Hopper’s vision for computer languages, I suspect.

Most AJAX examples distributed by InterSystems are in COS. Most of the doc assumes you know COS. I feel that this language keeps getting in the way of us coming up to speed in writing MV BASIC web-based software. I want it to go away. If the delivered examples and the libraries of delivered components were written in MV BASIC and JavaScript, just like we will be writing them, that would cut the learning curve for the team down considerably,  I would think. Over time, we should have enough examples in our code to help anyone new to the project get off the ground without reading much COS, knock on wood.

I thought perhaps if I wrote some COS myself I would like it better, just as I did with JavaScript. Well, I’m not at all proficient in COS, but I did write a little and I’m not there yet. I like the Cache’ data model, on top of which the MV data model is written, but the COS language still messes with me when I see it. In addition to all of the funky characters are words like “kill” in common use. I don’t want to read the word “kill” while I am working. While the language has not yet resonated with any of the male developers on our team either, I can’t help but wonder how many women in the world are drawn to this language.

I’m guessing I should go for some immersion therapy and really try to learn it rather than sticking with my avoidance stance, but for now I’m putting “MUMPS skills” in the same category as great artistic skills–I’m not able to drum them up myself, so someday I might have to pay for them.

Look and Feel: From Great to Unacceptable

Somewhere on the path between “green screen” terminals (I favored amber) and today, I tanked with “screen design.” It now takes a professional graphics designer, an artist, to be involved with this aspect of software. I really cannot deploy any web pages written exclusively by me, if I want them to be great.

Even with this blog, I settled for “acceptable” rather than aiming for “great” with the look of it. I selected a template, then did a quick thing in photoshop, carving myself out of a picture. I chose the picture because it was taken at a baby shower for my granddaughter, before she was born, and the original shows me with my two daughters. I was happy. It was me. That isn’t a highly professional reason for choosing a picture. The picture itself was not taken by a professional photographer. The skills used to extract me from that picture are even less professional. Heigh ho (as Vonnegut would say).

I told someone that I opted for two secondary storage “devices” from different eras in the header for this blog. He replied “you mean three, right?” Yup, three. So, the header here is creative, tells a story, aligns with the blog name, and looks OK. The template for the blog was done by a professional web site designer, I’m guessing, which is what makes it all look passable. My customization is fine, it isn’t great.

Software that is delivered via web pages to a general audience of people who can choose to use the web site or not does not require a graphic designer. taught us that. I don’t like using craigslist, however. The look of the site detracts from my experience.

I am simply not satisfied with what I am able to create as far as web pages go. While I can imagine someone using a site where I did the graphics design, I cannot imagine being really proud of it or considering it a huge success. I want our software to be great, so from my perspective it cannot be software where no graphic designers were involved (harmed?) in the making of the site.

Until this point, I have always been very pleased with the look and feel I have designed into software.  I have done screen design by a variety of names, since 1977, even before using the entire 23 rows x 80 columns. I wrote code that put labels with a colon on the screen, then accepted the value from the user. In response to whatever the user typed in, the software sometimes showed a message, such as “Alice, you know that has to be a number without any alphabetic characters in it” before re-prompting with the same label again. Our users loved it.

In the early to mid-80’s, the screens were more sophisticated, using all of the screen real-estate. I recall in the mid-80’s when the company newsletter published an article about our new 4-color database. We had new color terminals. The colors depended on the attributes of what was written out to the screen. I loved the addition of color, as well as the newsletter writer’s impression of the origin of the color.

It is great to be able to tweak software to the point where the user has not just a good experience, but a great experience. In the past, this has often meant that the screen looked good and the user was unaware of their experience, it did not get in their way. Even with client-server UI’s before the UI was in the browser, I could make screens both attractive and highly usable. That is no longer the case.

It is unfortunate that I have not yet found a sweat-equity graphics designer for this project. I talked to a prospective one on the phone last week, so I’m crossing my fingers. I’m pretty bummed that I cannot complete this aspect of the look and feel of the software we are writing on my own. While artistry is only one of the many skills I lack to go it alone, look and feel used to be one of my strengths.

I used to be great at designing the look and feel of software. I am not an artist, however, so what I am capable of doing now is simply unacceptable. I’m making my way through the stages of grief.

Metrics: 50 degrees warmer

One area where I know I could improve is what to measure and what metrics to communicate.

This paragraph contains some terms that some of you might want to google. I will put those in bold. I would like to measure burndown, as is typical if one is using Scrum project management techniques. We are using trac for requirements, design, construction, and bug-fix tasks.

There is a plug-in for trac that probably makes sense at There is also a trac plugin for Scrum at 

To give you a sense of how I think about such decisions as whether to put a plug-in in place for a burndown report, I will tell you that in spite of knowing about the first of these two plug-ins before writing this (the second I just found when looking for the first, showing me again how writing might help a project), I have not requested it.

Sierra Bravo, who hosts our server and does system administration as an angel hosting site for SnupNow, has been very good to work with and right now I am paying them only a percentage of this company, current valued at zero dollars. So I do not want them to mess around with anything unnecessary, and I know I have done that already. I have root access but don’t want to add that plug-in myself, because I want it done right, to keep from having too many cooks, and because every time I use a linux editor or type the characters :q! in a row, it subtracts a day from my projected lifespan.

Summary: I really do want to be sure it is important and that I will use it before I put in a request for this trac plug-in.

In spite of my resonance with data and information, project metrics have been problematic for me. It is important not to measure the wrong things. It can be easy to focus on some detailed metrics and miss the bigger picture. “Yes, she has 10 fingers and 10 toes” is not necessarily important if she has no heartbeat, for example.

It is even possible to measure something that tells you something relevant, and that seems to be very relevant, but really does not make much difference. It was 20 below zero Fahrenheit here this morning. My husband told me that the good news was that it was supposed to warm up 50 degrees in the next two days, but the bad news was that it would still be below freezing. If it were to warm up 50 degrees from 20 degrees to 70 degrees, now THAT would be fantastic. From -20 to 30, well sure, it is relevant, but when it is below freezing, I am outside as little as feasible. It just isn’t as big a deal to me that it will warm up 50 degrees in the next two days, in spite of what the numbers might lead one to believe.

I would like to measure what a user can do with our software at any given point in time, and how much more they can do at a later time. 29 and 129 do not seem like answers to that question. But having no numbers seems even less helpful. Even if we could measure this, however, that doesn’t quite get at how much more likely a person or company would be to use the software in light of new features, nor how successful they would be in using the software, nor how satisfied they would be in having us as a vendor.

Are project metrics important? Sure, I definitely think they are. Which metrics are important? I dunno. Maybe something is simply better than nothing, although that brings up the fingers and toes example. I like that burndown report, however. It seems like a good idea. At least it makes me feel 50 degrees warmer.

I have .NET with Curves

Recently a colleague was surprised that I did not have MS .NET installed and assumed that I was paranoid about it and was doing something to keep it off from my computer. That is not the case, however. I have narrowed my attention to the .NOT world, as it is simply impossible for me to stay current in both.  I simply had no reason to install .NET…until today. I just installed it.

Should I be concerned about this adversely affecting my computer in some way? Will it take longer to boot now? I am pretty clueless when it comes to .NET.

I am helping out a friend who owns the Curves I go to (I often refer to it as “the gym” just to make me sound less like a suburban housewife or, more accurately, like a small town, middle-aged woman). I am evaluating two software products for use by her franchise.

The one that costs less also installs in a heartbeat, compared to the one installing on my computer right now. This one first installed .NET, then required that I reboot the machine, and is now installing SQL Server 2005, after which I would guess it will install the application.  So far this installation has lasted a half hour longer than the other, including me having to close all of my open applications to reboot, and it is not completed.

The other software runs a database by Sage Software Canada named Providex. I have not researched the company, but I did look at an example of their code. I was delighted to see that it was some derivative of Dartmouth BASIC, as is the MV BASIC we are using on SnupNow. BASIC is a curious language in that it was never standardized when it was popular. There are numerous languages that stem from BASIC, with Visual Basic being the most well-known. This list of BASIC dialects seems as good as any 

I did a talk once on business intelligence tools entitled “The Music Isn’t In the Piano.” You cannot simply roll a piano up to just anyone’s workstation and think you will hear lovely music. Tools matter, but they do better when in capable hands (I hear InterSystems employees snickering now, given that I seem somewhat less than capable with their toolset at this point). You get the idea–I was indicating that tools are just tools.

While I plan to compare features, pricing, and many other aspects of these two software products, now with the installation of the second software application wrapping up, I cannot help but also think that the platform really does matter. Tools might just be tools, but not all tools are alike. Some very BASIC ones from small companies can be less bloated than some fancy ones from big vendors.

Are you sensing that I already know which software application I will choose? Nah, I’ll admit that my aversion to .NET, about which I know so little, might not be entirely rational (while I will also claim that it is). The platform is also just one factor, even if important for the life of the software and those who use it.

Let’s Add a Basement: Agile Development

At the end of last week Tom and I made a change to one of the files in the system (that would translate to one or more tables for you relational types) so that it was keyed by an auto-increment key rather than the one I originally designed. How much fun is it to change something like the primary key to a file when you have software written that reads and writes it, and test data already populating the file? Well, yeah, not a lot.

I’ve read Refactoring Databases: Evolutionary Database Design by Ambler and Sadalage. Fortunately, it is typically easier for us using Cache’ or any MultiValue database to do most types of database redesign required, than with a typical RDBMS (Relational Data Base Management System).

It isn’t necessary to nail down a complete database design in advance of other development efforts, as some teams have attempted. With an agile approach to development there is a focus on coding only those aspects of the software required to add the specific user functionality tagged for this iteration of code. There are probably as many strategies and philosophies in this regard as there are developers, and I bounce among a few of them.

My goal right now is that while being agile in our efforts (we aren’t, but we are trying), we not proceed to build a house with a slab foundation and then find that we need to add a basement later. It makes sense to me to add another bedroom if we need one, perhaps replace the roof, if required, even to “refactor” the plumbing at some point, and surely to swap out the appliances and countertops, but I really don’t want to have the cost and risk of digging and pouring a basement for an existing house that lacks one if we can avoid it.

There are so many unknowns, however, that I do not think my i’s are dotted in this regard. I think we will have many times in the future when someone will ask for an enhancement that will sound to me like they said “Hey, let’s add a basement.” I have to encourage myself to move forward with an agile approach anyway, in spite of all of the possible basement-like requirements that might be headed our way.

We have high level use cases and many open tickets, but in spite of our scrum-like Saturday meeting (with one week in our project equal to one scrum day), as a team do not have a really clear set of features to be added this coming week. I wanted to get there, and those working on web pages have a better sense than those assigned to Amazon e-commerce, which right now is a cloud for us. [By the way, if you ever wonder whether I am playing with words, I likely am.]

I think I need to be better at jumping in and doing something, specifically right now on the e-commerce front, rather than thinking too hard about it. Perhaps instead of working to avoid large amounts of rework in the future, I should embrace the notion of pouring basements at the point when we realize that a basement needs pouring?