I remember when one one of my grandchildren helpfully decided reorganise a bookshelf whilst by himself. Upon being discovered, sitting in front of an empty shelf with books strewn all around him, his instinctive reaction made me feel proud to be his grandpa. He looked up and said, “Oh dear! Oh dear! what happened?”, as if this calamity had occurred spontaneously, astonishing him as much as the angry parent who was going to have to tidy it all up. It is hard to hide amusement when you watch your kids have to deal with their kids.

Advanced Disaster Management Strategy for Grandchildren and Programmers

You see, he had acquired the first step in Advanced Disaster Management Strategy for individuals who have caused the disaster and know it. Display Of Surprise, is good for buying time, creating a flicker of doubt in the prospective accuser, and allowing the next phase to be implemented. Such is the lot of us amateur programmers, who in attempting to display what they had felt was a masterpiece, are discovered having produced mangled unintelligible rubbish. The ever-helpful Perl programming community are able to step in and gently point out that usingperl-untidy was not such a good idea.

The next phase in ADMS in any project, is to Identify Someone Else to Blame. At first glance it might appear difficult in solo projects, but inevitably all projects have dependencies, and one can always say “If only $target_for_blame was able to cope with my advanced needs…”. This target could be a module on CPAN or the language itself.

But eventually you get found out. You get found out because the people you are sharing the code with know a lot more, have experienced bad coding practices, and spoken out against these before. Personally, I have a sneaky suspicion they have done dodgy coding themselves, no matter how much they deny it. But here we are, red-faced, mumbling, shuffling feet and looking at the floor. The next phase starts. You start Justifying the Errors. The old “feature-not-a-bug” strategy. “I wasn’t trying to create obfuscated code…I was trying to make it more compact”.

The eventual “recovery phase” requires a reluctant re-write. It is true that Paella v0.07 grew in size by 80% to v0.09 without adding any significant functionality. This was purely to try and make the code a little more legible, object-orientated, structuring subroutines into packages, such that it may be easier to reuse elsewhere, perhaps allow others to re-spin the code and many other potential benefits. I tried to do this, without grumbling all the time. It was difficult. You see the purpose of the project was discovery, but progress was being held back by the desire to satisfy the tidy-minded observer.

“Mummy is being really Mean, grand-dad,” said the little monster.
“It’s ok, mate,” I tell my offsprings offspring. “Mummy is only grumpy because she doesn’t understand. Her mummy is the same with me.”
“Does gramma tell you off too?”,
“You betcha!”
“I was only trying to fix it, like you said”, sniffles follow.
“Shhhh! I know, but hey, who needs to keep things tidy, when we have more important things to do…?”

You almost feel obliged to encourage the little beggars.

Over the years that I have existed in four dimensions, I have come to accept that time is not a linear concept heading inexorably in one direction at a uniform rate. It didn't take an Einstein or Hawking to convince me either. Time is as malleable as the distortions applied by our consciousness, or imposed by those around us. Consider my youngest daughter's essay due to be handed in on Tuesday, a task assigned 4 months earlier. At 4,000 words, it represented roughly 6 words an hour allowing for eating, sleeping, work, weekend fun, and other essential time-devouring activities. Yet the "I have got plennnnty of time, chill, dad!" of a few months ago, has now turned into cries of despair, as she has to do an all nighter at her desk instead of being at some selfie-rich event critical to her mental well-being and social standing.

The same happens at work when I get hauled over to the management because something I have no control over happened that shouldn't have happened. It seems that the eternal role of some such individuals is to improve efficiency and productivity without actually doing anything efficient or productive themselves. A strategy that some favour is to highlight trivial events, hold someone responsible, persistently bring this up at various encounters and thereby have justification for their existence, rather than allow access to the time machine that would enable correction of this past undesirable event.

One thing that might help these recurring, seemingly totally avoidable, but absolutely inevitable episodes, maybe be a set of rules. I have recently discovered RRULES, EXDATES and RDATES that can be embedded into iCal objects to define repeats of events. Some may be be repeated forever, some being confined to certain days of the week, each represented in a human readable form but parseable by machine. In order to achieve as much flexibility as possible, the rule structure is as complex as it is comprehensive.

One has two options when encountering a novelty such as this. One could look through the extensive experience and expertise of the Perl community who would naturally have some way of parsing these rules; easy, efficient and most likely to work. Work such as iCal-Parser by Cedric Cellier and Data::ICal::DateTime by Flávio Soibelmann Glock. On the other hand, one could try and build one one's self.

RRULES can become complicated,

# every year forever
"FREQ=YEARLY",       

# every other week forever
"FREQ=WEEKLY;INTERVAL=2",

# first week every month excluding weekends until                               
"FREQ=MONTHLY; BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1;UNTIL=20141129",

#  every three years on the first Tuesday of October that is not the 1st of October
"FREQ=YEARLY;INTERVAL=3;BYMONTH=10;BYDAY=TU;BYMONTHDAY=2,3,4,5,6,7,8",

Parsing this kind rule can become rather difficult. Generating them reliably to do what you mean without ambiguity is similarly tricky. Feeding back this rule to the user in plain English is something that can also be challenging. It helps to steal other peoples ideas, but often one is trying to crowbar these rules into a project that has already been started, and a more eye-opening, time-consuming failure-ridden approach is required.

Finding time to do the research is difficult when you have a day job and many other demands on the time. I am sure the reader will have many experiences of temporal field manipulation, or perhaps are experts themselves. Time is infinite, but the time allocated to us is finite. We may choose to rush through life collecting as many experiences as possible, maximising the utilisation of this limited resource to earn, spend, learn, teach, give, take, create or destroy. I am told I waste a lot of time. I write code other people have done better for no return other than the same joy my grandson may have from drawing something unintelligible to show me. Sometimes I do it just so that something else more important can be forgotten, for even a little while. One could (or perhaps should) choose to do nothing other than to savour time that we do have, giving ourselves time to do nothing more than be alive.

Time may be precious but it will not be contained, disappearing from our grasp whatever we choose to do or not do with it. For me whatever you with it, time is never wasted. As one who has someone very dear to his heart going through a serious illness, time spent just being with someone you love is the most precious, irreplaceable time of all. Wishing you all happiness, love and peace.