Thursday, July 10, 2014

Rondo and ritornello, Must All Be Veiled

(From a letter to a friend:)

I think my use of the term, "ritornello" was incorrect, after you (as I recall) correctly described the form of my anthem, Must All Be Veiled as a "rondo."

As support, below are some descriptions of rondo and ritornello which you might enjoy reading from Theodore M. Finney's 1935 (rev. 1948) work, A History Of Music:

On p. 88-89, in a section entitled "Musical Forms" of a chapter entitled "The Beginnings of Secular Music" which covers the 1000s through the 1200s:

"[Troubadours, et al] made the first distinct beginnings of purely musical form...From the time of the Troubadours until the present, the words aubade (alba), serenade (serena), pastorale, canzone (canzonetta), carol, rondo, and ballad (ballata) are constantly to be met as titles of short compositions...[I]n at least one case, that of the rondo, the basic idea of an important musical form was present.

"The rondo as we now know it depends for its structure upon the reiteration, after digressions, of the beginning subject matter. Its ancestor is the Troubadour rondet de carol, a dance song in which, as its name implies, the dancing chorus sang a refrainlike strophic song between the repetitions of which solo verses were sung and danced. The formal principle of repetition after contrast, which here becomes evident for the first time, was destined, after later tonal discoveries had enlarged and better defined musical resources, to become all-important in musical structure."

I see the above structure, called rondo or rondet de carol, contains an identical repeating element.

On p. 118-119, in a section entitled "The Madrigal" of a chapter entitled "Ars Nova [New Technique]" which covers the years of the early through mid-late 1300s:

"Another important fourteenth-century form was the madrigale or mandriale. The madrigal was a secular composition which spread during the fifteenth and sixteenth centuries to the whole of Europe and became, with the motet, one of the two great choral forms. At the time of its first appearance in Italy it was an exceedingly simple structure consisting of two main portions. One part was composed for several stanzas of text and the other part, called the ritornello, using new music and a different rhythm, came immediately after each stanza. This form will be seen to be closely related structurally to the older Troubadour rondet de carol, mentioned in Chapter 8 [quoted above]. It may be diagrammed as follows:

"Stanza A, Ritornello B, Stanza A, Ritornello C, Stanza A, Ritornello D.

"The fourteenth-century Italian madrigal is important not only as the beginning of an important choral form, but as a connecting link between the older rondet de carol and the later rondo."

I see the above structure diagram of a Trecento madrigal includes multiple ritornellos, which differ (musically) each time.

On p. 364, in a section entitled "The Rondo" of a chapter entitled "Musical Form At The Death Of Bach: 1750":

"The rondo form, an A B A C A structure, was often combined with the characteristic rhythmic procedure of a dance..."

I see the above structure, called rondo, contains an identical repeating element.

Finally, Wikipedia on Ritornello says:

"A ritornello (Italian; 'little return') is a reinviting passage in Baroque music for orchestra or chorus. The first or final movement of a solo concerto, concerto grosso, or aria may be in 'ritornello form', in which the ritornello is the opening theme, always played tutti, which returns in whole or in part and in different keys throughout the movement. In these visits to different keys, ritornello form differs from the rondo.

"The final section of a fourteenth century madrigal had previously been called the ritornello and a similar technique had been employed by Giovanni Gabrieli in his 16th century motets. The instrumental interludes in early Baroque operas were also termed ritornelli.

"Ritornello construction faded with the advent of the new sonata form but received renewed interest in the 20th century."

I see this distinguishes a ritornello, which changes key, from a rondo, which does not.

My piece does not change key, so I think you are right to call it a rondo. :)

Also, in using a rondo form, I had intended to produce an antique feeling.

In this, my purpose was to express the ever-presence of a certain problem which George Herbert and I described. This problem, of miscommunication between expert speakers and ordinary listeners, has existed always.

As usual in creativity, my impulse to express this fact arose preconsciously—in other words, it felt right, somehow. :)

Ars_nova – Wikipedia
Madrigal_(Trecento) – Wikipedia
Ritornello – Wikipedia
Rondeau_(forme_fixe) – Wikipedia
Rondo – Wikipedia

Copyright (c) 2014 Mark D. Blackwell.

Tuesday, January 7, 2014

GitHub should ease line-specific links to the latest commit while browsing master

While (naturally) browsing on branch 'master', GitHub currently requires three(!) clicks to generate any line-specific link for future (permanent) use. These clicks are: History, Browse code (at the top of the history list), and (again) clicking the desired line.

But (only) rarely do people follow these three (extra) steps.

You can blame people (posters) for not following these extra steps, but (as a matter of human nature, IMHO) we can't expect most people actually to follow them, because currently (as they observe it) their gathered links are correct. They merely become obsolete over time.

In practice, this screws up blog and StackOverflow posts, etc. which contain links to specific locations inside source code (on GitHub). For most of these links, their reasonable use is to point to source code (sometimes source lines) visible in the latest commit. Yet these posters (almost always) gather links which actually point to an evolving branch (usually 'master'). As source code evolves, these links quickly become obsolete.

This obsolescence is especially bad with line-specific links, but also happens for file-specific ones.

Here let me say that GitHub's wonderfully good UI is GitHub's greatest and best feature! :)

But the clumsiness of this detail of GitHub's UI (here) is at fault IMHO for this problem. :(

I tried to enlist StackExchange's help to argue this case with GitHub, but to no avail. Also, I asked GitHub directly. We shall see.

This screwup (of obsolete links in people's posts) is apparent, bothersome, and quite frequent!

As a solution, GitHub should consider implementing the following UI improvement:

Make generating such permanent, line-specific links (in browsers' address bars) much easier for their users by adding a button (to all source-display web pages on branches). This button (with a single click) would:
  • Switch from viewing the source code (including a line reference) on a branch, to viewing that source code (including the same line reference) in a blob. To be helpful, that blob must be the latest commit of that branch.

GitHub already distinguishes branch heads from blobs. This is apparent in GitHub's sometime use of the word 'blob' as an URL path segment name (versus the words 'commits/master').

Therefore, GitHub seems easily able to find the latest commit SHA1 for a given branch and do what is desired here: that is, redirect the browser to the corresponding line in the latest commit.

UPDATE: Just four(!) hours later, this nice reply came back from a GitHub staffperson:

"Great idea, thanks! There is a shortcut key "y" that you can hit on any code page to change the URL to the permanent link. But you're right that people may not always choose to do that.

"I've added your idea to our internal Feature Request List. We can't say if/when we may add a feature, however your feedback has definitely been recorded."

Although GitHub's pages don't present this feature in an obvious way, GitHub's Help here further describes their 'Y' shortcut key's hidden access (to it) that she's talking about.

UPDATE: StackExchange support replied with:

I'm not entirely certain what you were trying to accomplish with that post. First, it was on, where users go to talk about Stack Overflow itself. We discuss features, community governance, file bugs and similar activities on meta.

However, your post would not have been on topic for Stack Overflow either, it's a complaint about how Github works, as far as I can tell, not a question. We're not a typical forum, we're a Q&A site. To get a better idea of how our engine works, take a brief tour of the features.

Sorry that you had a bad experience, but there's not much we can do about it at this point. If you've got a succinct programming question where the problem can be demonstrated with a short code snippet, you're more than welcome to ask on Stack Overflow. If you have a question about Stack Overflow itself, how it works, or an idea to improve it - then feel free to post on meta.

Stack Exchange Team

I replied to StackExchange support with:

Hi, Team,
> it was on, where users go to talk about Stack Overflow[.]
> about Stack Overflow itself, how it works, or an idea to improve it -
> then feel free to post on meta.
> it's a complaint about how Github works, as far as I can tell, not a question.

Yes, this is about StackExchange.

If you think about it, permanent links, including those to, comprise part of the business value of the StackExchange family of sites.

Your reply doesn't answer my suggestion that it's in the interest of StackExchange, the company, to try to encourage GitHub, the company, to improve their GUI, so that permanent links are easier (and less error-prone) to make.

I'm sure there are ways the staff of StackExchange can convey this interest (of the StackExchange company) to the staff of GitHub.

I cast about for how I can communicate this (I believe helpful) idea to the staff of StackExchange, and the two methods I tried (which you already know about) came to mind. Yes, I have contacted GitHub about this, but I am suggesting that StackExchange do this for itself, as well.

Who else can I contact, besides the StackExchange support team? Do tell!

> Sorry that you had a bad experience

To me, that has little importance. Much more important is the business suggestion for StackExchange, and (as you know) to improve the world, if I can.

From a reply from GitHub, I learned that hitting the 'Y' key switches their webpages to permanent links, easily.

For StackExchange, the problem is that accessing this GitHub switching functionality by hitting 'Y' is not widely known. So, in questions and answers on StackExchange, many people (perhaps) are sharing transient GitHub links.

GitHub may be reluctant to use a half-square inch of real estate on their webpages to make this functionality visible, since that visibility wouldn't help them directly.

But as good neighbors (or something like that) GitHub may be willing to "do the right thing," especially if StackExchange and Wikipedia, et al, ask them to. That's what I think.

Who knows whether GitHub might actually respond? Why doesn't StackExchange try? (i.e., for the purpose of aiding StackExchange's own business interest).

With warm regards,
Mark D. Blackwell

Copyright (c) 2014 Mark D. Blackwell.

Monday, July 8, 2013

Use file extension ".yml" for YAML

Generally, YAML files should be referred to by extension ".yml" (instead of ".yaml").

Currently, any remaining use of extension ".yaml" seems (in my view) slightly silly.

Commonly the letter X is used for a great variety of meanings including "cross", "extensible", "variable", etc. (e.g. in XML). Contrarily (on the other hand) Y (e.g. in YML or YAML) carries no such extra baggage. Relatively speaking, Y's use is rather uncommon. Its use in YACC ("Yet another compiler compiler") comes to mind; but even YACC (as a term) is rather similar to YAML. Historically (as you may know) YAML was an acronym for "Yet another markup language".

Linguistically speaking, therefore, the acronym "XML" has (in a way) only two informative letters. "YML", instead, has three. Indeed, the existing set of acronyms beginning with Y seems extremely small. By implication, this is why a four letter YAML file extension feels greatly overspecified.

Also, from the Ansible project:

> Three letter extensions owe historical relevance from DOS.
> They also save typing.

Information from the website dates the organization's most recent activity to 2009 (approximately). Evidence of this comes from:

> © 2001-2006 All Rights Reserved

> [The latest] News:
> 20-NOV-2011 -- JS-YAML, a JavaScript YAML parser by Alexey Zapparov and Vitaly Puzrin.

> [The latest] YAML Resources:
> YAML 1.2 (3rd Edition):

Their latest specification (1.2 above) is from 2009, presumably before much of YAML's worldwide adoption:

> YAML Ain’t Markup Language (YAML™) Version 1.2
> 3rd Edition, Patched at 2009-10-01

Even their latest news item, the above-referenced JS-YAML uses (BTW) the extension '.yml":

> var doc = require('/home/ixti/example.yml');

Therefore the staleness of's information should greatly lessen today's impact, from the recommendation in their FAQ:

> Is there an official extension for YAML files?
> 1. Please use ".yaml" when possible.

Maybe the public should complain. Maybe would listen!

Here is a URL for web-searching usage of the two YAML data file extensions (.yml and .yaml). I found timewasting discussions here, here and here.

The only counterexample I have found (using ".yaml") comes from cPanel (in their EasyApache interface)—cPanel is somewhat "stuffy" and old-fashioned. Per cPanel's EasyApacheHowToMoveProfiles:

> Profile are located in the /var/cpanel/easy/apache/profile/custom directory. The filename will be identical to the name you save it with, plus the .yaml file extension.

Here are merely some (of the many existing) usage examples of the shorter extension ".yml" in common use:


> -- NOTES:
> -- 1. The YAML file extension usually is ".yml"


> If you want a YAML file extension of .yaml (instead of .yml), you have to configure that.


> The default YAML for most projects seems to be .yml, instead of .yaml.
> In NetBeans in particular, the YAML wizard only allows creating a file with a .yml extension


> All mapping documents should get the extension ”.dcm.yml” to identify it as a Doctrine mapping file.
> $driver->setFileExtension('.yml');
> The Symfony project sponsored a driver that simplifies usage of the YAML Driver. The changes between the original driver are:
> File Extension is .orm.yml
> Filenames are shortened, “MyProject\Entities\User” will become User.orm.yml
> $driver->setGlobalBasename('global'); // global.orm.yml
> As a quick start, here is a small example document that makes use of several common elements:
> # Doctrine.Tests.ORM.Mapping.User.dcm.yml


> NOTE: YAML files more often use the .YML extension.


> Configuration files should end in .yml, not .yaml
> That's the standard file ending, and should be consistent with expectations.


> Posted by cweagans on March 6, 2013
> .info files are now .info.yml files

Copyright (c) 2013 Mark D. Blackwell.

Wednesday, July 3, 2013

Use Ruby-like Mirah to develop for Android

I have minimal experience in Android development—I have set up its development environment and merely compiled something that another has written. I work mainly in Ruby on Rails.

However, for the intrinsic joy from developing something on an Android device, I'm particularly interested in the language Mirah created by Charles Oliver Nutter (the developer of JRuby). I keep Mirah in mind, for whenever it will become practicable to use in Android development.

Perhaps Mirah is ready now—a Google search shows plenty of people using Mirah on Android.

Back in 2011, Nutter wrote an article about Mirah in Dr. Dobb's Journal. To sum up, this is a Ruby-like language designed in such a way that, for any program feature (or user feature) a programmer desires to implement, she would create a new keyword or plugin for the language (somewhat directly in the compiler—this being Mirah's main point of departure) rather than add a new Java package. And, it compiles to the JVM.

Therefore in Mirah (unlike in JRuby-based approaches such as Ruboto) no program needs a package or library beyond what is already in standard Java and Android. Programs written in it are extremely tiny (due to running without huge, additional language libraries) and they load and run (both) extremely quickly on Android devices (with their Dalvik Java virtual machine).

To use Mirah to build an Android app, see the Pindah project.

In order for someone to use Mirah (essentially syntax sugar on top of Java) BTW not only should they be familiar with Ruby, but they must also know Java well.

There's more about Mirah here:

For Android development, other JVM languages, Scala, Clojure, etc., as well as Ruboto, are also interesting.

Various StackOverflow questions relate to Android development using Mirah, JRuby, Ruboto, etc.:

Copyright (c) 2013 Mark D. Blackwell.

Friday, June 28, 2013

Ongoing open-source Rails secret_token vulnerability

Today I was re-alerted to a somewhat dangerous insecurity for open-source Rails apps if their Application.config.secret_token is kept under version control. The relevant file:


Rails itself generates this file in this way (without an entry in .gitignore) but it's still dangerous. There's lots of discussion here.

Presumably easily an environment variable could be set in config/application.yml (often kept out of version control) and retrieved at run time into config/initializers/secret_token.rb.

Remembering this would seem the only way to solve the problem and protect one's apps into the future from this known security vulnerability.

Here are Ruby on Rails Security Guide's recommendations:

'[P]lease secure your database configuration, e.g. config/database.yml, and your server-side secret, e.g. stored in config/initializers/secret_token.rb. You may want to further restrict access, using environment-specific versions of these files and any others that may contain sensitive information.' — per its Environmental Security section.

'If you have received an application where the secret was exposed (e.g. an application whose source was shared), strongly consider changing the secret.' — per its Session Storage section.

BTW, newly, Rails 4 has added Application.config.secret_key_base (described in the previous link and Guide for Upgrading Ruby on Rails' section, Action Pack).

'If you happen to share your code publicly, make sure your secret_key_base value is kept private.' — per this blog post.

Presumably, however, this new variable name setting does not remove the current security vulnerability either in Rails 3 or 4 since the Rails secret_token still is under version control.

Copyright (c) 2013 Mark D. Blackwell.

Wednesday, June 19, 2013

Raspberry Pi hobbyist computer

Just now (albeit belatedly) I came across a small, fun $35 computer for hobbyists: the Raspberry Pi.

Have you heard of it?

This recalls _why and others' passionate advocacy of "The Little Coder's Predicament" with projects such as hackety-hack that provide hackable computers again for children.

BTW, Raspberry Pi runs Debian Linux (wheezy).

Copyright (c) 2013 Mark D. Blackwell.

Tuesday, June 4, 2013

Blog posts' date position

Just now I was reading a blog to avoid emailing its author with questions they already blogged about. Like others with this purpose, I read it reverse-chronologically (i.e. from the top).

While reading a blog purposefully to learn the current status of a fast-changing software system it seems important to gather a quick sense of time context for each post.

Inevitably I observe myself sliding my browser window downward to the bottom of each post to get a sense of how long prior to the post above it each was released—just in case the time interval is much, much longer than those above.

Then I slide the window back, indeed with resulting uncertainty that I have recovered the proper beginning of the proper post.

Some blogs may never have a delay of more than two weeks between posts.

If I knew this were the case always I wouldn't even look. But since I am not sure, I find myself looking at the dates.

Viewing a blog's archive helps somewhat (and furthermore I can read a whole blog by clicking its posts in an archive list; but this seems less natural).

So the minor suggestion here, for blog formatters' consideration, comprises the usefulness of placing the date of each post immediately below its title.

Copyright (c) 2013 Mark D. Blackwell.

Monday, May 27, 2013

Robin Hodson compositions

A acquaintance of mine, Mr. Robin Hodson, has composed quite a number of choral and chamber works worthy of note. Not 'modern' music, these are quite listenable.

One can hear them free of charge on ScoreExchange. Just click the tab labeled 'Scorch plug-in', and install it if necessary. (BTW, Sibelius recently has made their plugin work better):

Truly quite excellent (especially harmonically) are:
  • 1993   Wind Quintet (1: Martial Fugue & Western Wind)
  • 2002   Verbum Caro Factum Est
  • 2003   English Missa Brevis
  • 2004   Ave Maria (SB duet)

Here's a chronological list (attempting to be complete) of his compositions (which are available on ScoreExchange):
  • 1986   This Is The Day
  • 1988   Missa Sancti Pauli
  • 1989   There Is No Rose
  • 1990   Death, Be Not Proud
  • 1993   Diaphonic Mass (organum)
  • 1993   Wind Quintet
  • 1997   Ave Verum
  • 2000   Funeral Sentences
  • 2001   Magnificat (Maryland Service)
  • 2002   Elegy for Strings
  • 2002   Nunc Dimittis (Maryland Service)
  • 2002   Verbum Caro Factum Est
  • 2003   English Missa Brevis
  • 2004   Ave Maria (SB duet)
  • 2004   Ave Regina Caelorum
  • 2004   Regina Caeli Laetare (Soprano, Piano, Cello)
  • 2008   Psalm 111: I Will Give Thanks Unto The Lord

Also I should mention the several CD releases (of steadily increasing quality) of his own popular music compositions. The 2008 album is uniformly excellent. Particularly excellent from his 2003 album are:
  • Hold Your Candle Over Me
  • Never Coming Home Again

Copyright (c) 2013 Mark D. Blackwell.

Tuesday, April 30, 2013

Essential jQUERY

Recently, I picked up the bare essentials in jQuery from the book, jQUERY Visual Quickstart Guide by Steven Holzner, Peachpit Press, 2009.

However, a word of warning: the book is somewhat badly edited, and there is no corrected edition (still as of this writing).

From the core jQuery source code, this page also is useful. Here are my brief notes:

JQuery refers to a certain syntax $(thing) for any thing as 'jQuery-wrapping'.

The keyword $ is an alias for jquery. Both are used in the following ways:

  • $(function)  –  Append a function to the list to be run when the document is ready: a shortcut for $(document).ready(function).

  • $(CSS-selector-string)  –  Select some nodes in the document.

  • $(HTML-string)  –  Create HTML for insertion.

  • $(DOM-node)  –  Like saying simply DOM-node, but change the value of this and set context (an attribute used by jQuery). Examples are:
    •   $(document)  –  The document.
    •   $(this)  –  this.

  • $.method  –  (This one has a dot and no parentheses.) Run a utility method.

The jQuery methods selected for explanation in the book are:

  • Methods on jQuery-wrapped collections of HTML elements:
    • addClass,  after,  alt,  animate,  append,  attr,  before,  bind,  clone,  css,  each,  (event binder methods),  fadeIn,  fadeOut,  fadeTo,  height,  hide,  hover,  html,  is,  (jQuery-UI methods),  length,  load,  one,  serializeArray,  show,  size,  slice,  slideDown,  slideToggle,  slideUp,  text,  toggle,  toggleClass,  unbind,  val,  width,  wrap

  • Event binder methods:
    • Keyboard   –   keydown,  keypress,  keyup

    • Mouse   –   mousedown,  mouseenter,  mouseleave,  mousemove,  mouseout,  mouseover,  mouseup

    • The rest   –   beforeunload,  blur,  change,  click,  dblclick,  error,  focus,  load,  resize,  scroll,  select,  submit,  unload

  • jQuery-UI methods:
    • accordian,  datepicker,  dialog,  progressbar,  slider,  tabs

  • Methods on jQuery-wrapped HTML strings:
    • insertAfter,  insertBefore

  • Utility methods:
    • ajax,  browser,  each,  get,  grep,  inArray,  isArray,  isFunction,  makeArray,  map,  post,  support,  trim,  unique

Copyright (c) 2013 Mark D. Blackwell.

Thursday, April 25, 2013

Meetup authentication & email addresses

As part of its OAuth authentication process with other apps, Meetup doesn't provide email addresses of its users. (I refer to this official Meetup forum question, and to this page in the Meetup API docs—search the page for 'email'.)

Twitter doesn't provide email addresses either. However, Meetup seems nicer than Twitter.

People use multiple Twitter accounts (I know some who do). But people don't use multiple Meetup accounts (at least supposedly not).

When registering new users through this difficult class of OAuth authentication providers (those which don't supply an email address) one might ask each new user directly for some email address, or might not. Requesting this is normally recommended.

If an app uses Meetup authentication (and it doesn't request and confirm an email address during user registration), and uses another form of authentication also (even added later) then there's no way to identify the same user, if or when they sign on by a different way.

So Meetup authentication (without email) is only good if the app is forever limited to using Meetup authentication alone. With that permanent limitation, in such an app, nobody (mysteriously) will run into the problem of having more than one account.

Of course, having Meetup as the single method of authentication is useful, reasonably, only to apps which are already limited to Meetup users.

Keeping the UI simple (by not requesting an email address when people register) means the app might never have email addresses. But that might be okay if an app uses Meetup authentication alone, forever.

Then one need not bother people with asking for their email address when they first use an app. The ease of that emotional UX moment when new customers are forming their first impression of an app (and making their initial commitment to it), from the standpoint of building a customer base—depending on the app—could be considered more important than ever knowing their email addresses.

BTW, omniauth-meetup is a good gem for doing Meetup authentication in Rails.

Copyright (c) 2013 Mark D. Blackwell.