I want a Markdown "during-view"

I like that Markdown and its kin have been adopted by more than just the geek community. The simple inline directives do not take away the focus of writing the text and the formatting available covers most of needs. However, the trend to provide an immediate, fully formatted view of the text is misguided. These "previews" take away from the goal of maintaining focus on the text and not it's presentation.

However, I too like the comfort of a correctness that comes with seeing a full formatted document and especially so with regards to sections and lists. What Markdown editors need is not preview but a kind of WYSIWYG presentation that keeps the primacy on the text and secondarily on the structure of the text. A means of doing this is to present the inline directives with formatting and the directives too. Thus, when I type *emphasize me* it is shown in the editor as *emphasize me*. If I use a heading directive

A short work
it presented for editing as
A short work

I did once see this kind of editor in a Java wiki application, but I have long since lost my reference too it. Perhaps it will resurface again as the Markdown tools authors rediscover this style of editing.

I am not going to create another account just to use your feature

Dear Marco,

I really like the audio tools included in Overcast, but I am not going to create another account just to use them. I read the FAQ and while I understand that in general saving battery life is great, but, really, how much battery is used to check a few feeds once a day? So, good luck and keep me informed of the non-account version of Overcast.

What would one use programming for if programming were easy?

I stopped by Slashdot today and found Normal Humans Effectively Excluded From Developing Software. I read it and many of the comments and started to think about this problem again. In my mind the problem is if programming were easy then to what purpose would someone put programming too? I am going to assume that what is meant by programming is of a general purpose kind so that, for example, using R is not programming.

2014-07-10 Update: People collect and organize things and while they do that they share the experience, the lessons learned, and the things found. Would you program that?

To be continued...

Logging and the utility of message patterns

I wrote a logging layer over log4j sometime ago. The layer was to encourage our developers to log at any point in the code where they thought some extra context would help resolve runtime errors. And so the layer had to have a familiar API, be effortless to code, and cheap to call. This posting is mostly about the cost to call the logger.

When a message is not going to be used you don't want to incur the cost of creating it. How often have we seen logging code that looks like this

logger.debug("short explanation: v1="+v1+"; v2="+v2+";");
Here the logged message is composed before the call to logger.debug() and it is composed even if the logging level is above DEBUG. If v1 or v2 have a complex toString() implementation, then you add this compositional time to the calling cost too.

The simple solution is to use java.text.MessageFormat with the debug() method, for example

logger.debug("short explanation: v1={0}; v2={1};", v1, v2 );
In this way, the time cost to calling debug() is the time taken to push three values on to the stack, call the method, and pop the three values off the stack. No composition time (or memory) costs are incurred at all. (I handle exception messages the same way, that is, all exception constructors accept a message pattern and message parameters and the message string is not composed until it is actually needed.)

I have since replaced Java's MessageFormat with a (mostly) compatible local implementation. This local implementation does simple composition tasks like formatting numbers without commas and Unicode escaping all non-ASCII, and non-visual characters. However, the primary reason to implement a replacement was to expand the available format types and format styles.

The first new format type added was json so that now when a parameter is so typed its value is transformed to a JSON representation before adding to the message. For example,

Map<String,String[]> v1 = ...;
logger.debug("short explanation: v1={0,json}", v1 );

will convert v1 to a JSON string only if the log level is DEBUG

short explanation: v1={ "k1": [ "e1", "e2", ... ], "k2": [ ... ] }
(In hindsight it should have been a format style.) Today I added the string format type and two format styles. One format style specifies a substring of the value using a start index & length and the other a start & an end index. The start and end indexes can be given as numbers or as searches. For example, the style /foo/:10 specifies a 5 character substring starting where "foo" is first found, and the style /foo/../bar/ specifiers a substring between (and including) the two searches. The using search is particularly useful if you know that somewhere in a very long string is an identifier that would be useful to have in the log.

Basic human concern for the welfare of others

I had a surreal moment this morning while walking Milo at our usual spot. A car was found in the nearby pond. (I later found out that two cars were stolen last night and this was one of them.) I happened to encounter a small group of acquaintances running with their dogs. I told them what I knew and their immediate response was 1) having a car in the pond is not healthy for the pond and 2) why were the police leaving their cars idling. WTF! Not one of them expressed interest or concern for a person or persons that might be in the car. I was shocked at their lack of the basic human concern for the welfare of others. I will resist extrapolating this one data point to the causes of America's problems.

A gnuplot example

If you searched for Gnuplot in this blog you know I am a fan of the tool. It is easy to install, somewhat easy to use, and very likely someone has already had and solved the exact same problem you are having now and wrote a blog entry about it. This is my contribution to the globally distributed Gnuplot cookbook.

I want on a single chart the lines graphs of count of all queries, count of matching queries, and mean duration of all queries. This chart gives me the temperature of the previous day's query load which is a useful qualitative factor for capacity planning. The data retrieval results in records representing a 10 minute interval with counts of all queries, counts of matching queries, and mean durations. This is then plotted to give a chart like the following:

The file of records contains values that looks like

2014-07-07T00:10:00     10449   3850    934
2014-07-07T00:20:00     18445   5676    407
2014-07-07T00:30:00     18497   6507    535
2014-07-07T00:40:00     11419   4463    734
2014-07-07T00:50:00     11634   4454    724
2014-07-07T01:00:00     11960   5077    808

The Gnuplot script is

set terminal png size 800, 400 small interlace
set output "/tmp/chart.png"
set size ratio 0.5

set xdata time
set timefmt "%Y-%m-%dT%H:%M:%S"

set xlabel "Hour"
set format x "%H:%M"

set ylabel "Count"
set ytics nomirror
set yrange [0:40000]

set y2label "Milliseconds"
set y2tics
set y2range [0:4000]

set title "MetaData matching search counts and average durations (10 min intervals) for 2014-07-07"

plot \
  "/tmp/chart.data" using 1:2 title "Query count" with lines, \
  "/tmp/chart.data" using 1:3 title "Matching count" with lines, \
  "/tmp/chart.data" using 1:4 title "Request duration" axes x1y2 with lines

The chart is produced daily and it is useful to visually align several days of charts to look for patterns. For comparable charts this requires that the charts all have the same y-axes ranges. To do this Gnuplot's range setting is used. If you do not want a fixed range then remove the set yrange ... and set y2range ... lines.

I hope this helps someone else with their Gnuplot use.

Atlassian has forgotten that Jira is a communication tool

Atlassian has forgotten that Jira is a communication tool. Comments need numbers so the team can communicate with specificity everywhere. See Skype and development teams as it applies to Jira also.

No more chickens

The last of our chickens were attacked last night. Two dead and one so badly mauled that it had to be put down. Our home is once again without the soothing sounds of chickens humming their songs as they explore and sun-bathe in the garden's beds.

Restic to the flame

I bought a copy of Dreadball earlier this year mostly to have a sports boardgame that Henry and I could play. (Owen is happy playing non-sports oriented games.) The material used for the Dreadball figures is, what has come to be called, "restic" -- some combination of resin and plastic. It has a reputation of being difficult to prepare for painting. (For a counter experience read How to clean restic.) One piece of advice I read in the comments section of Seeking advice on preparing the minis for play was to flash the flashing with a cigarette lighter's flame. After too many hours of trimming with a knife I decided the give the flame a go. The basic approach is to warm the material enough so that you can smooth out the heavier flashing with your thumb and for the lighter flashing to burn off. And, after a little trial and error, it does work. However, for detailed, thinly molded elements of the figure you still need to just use a knife. Using the flame often ends with stumpy ears and hands. Even with the few errors the figures look fine after priming.

Walter Dean Myers and Henry

I was very sad to hear that Walter Dean Myers died today. While he wrote for young adults I enjoyed reading them as did my son Henry. It was Walter Dean Myers' books that got Henry to keep reading fiction outside of school.

Skype and development teams

My employer extensively uses Skype to coordinate and communicate. (Email is almost unused.) Within a software development team there are some regular annoyances that come from Skype's current design. I don't blame Skype or Microsoft for this situation as I think we are using the wrong messaging tool. However, using Skype in my team has clarified what the messaging tool needs. The changes that would make Skype better for software development teams are
  1. Use a fixed format font for sender and receiver because we still manually align tabular data and draw ASCII diagrams.
  2. Don't interpret any of the message text as emoticons, links, telephone numbers, etc. Most of the time the interpretation is inappropriate.
  3. Identify every message in a conversation so they can be referenced. We use specific identifiers -- file paths, line numbers, revision numbers, etc -- because specific referencing means that all parties in the conversation are using the same data. Use a simple initialssequence number identifier for ease of typing. (No UUIDs, please.)
  4. Includes images in conversations. Images are only slightly less important than text to a successful conversation.
  5. Show more messages on the screen. Do this not by making the font smaller, but by reorienting the message presentation to take advantage of monitors having more width than height.
What do you want to change?

Update: I would add tabular data to images as another first class data type. For example, I like how I can copy a SQL select result from DBeaver or SQuirreLSQL and paste it into Jira.