Week 24 at an Unbootcamp

Whither the Guild?

Learners Guild in Oakland continued, during my just-ended 24th week there, to reassess how it is and will be organized. After giving its Learners a couple of weeks to put proposals together, executives and Learners gathered in mid-week to review and discuss those proposals. They included novelties such as:

  • a turn from well-entrenched web-development technologies to bleeding-edge ones like blockchain development
  • commercial sponsorship of Learners with individualized studies aimed at placement with the sponsors
  • an emphasis on the retraining of discharged United States military personnel for civilian employment in software development with support from government grants
  • the redefinition of the Guild from an educational establishment to a software-development firm and of its Learners to apprentices

The Guild has already made 2 announcements in response to Learner input:

  • Current Learners will not be required to advance from phases 1, 2, and 3 to the next phase within a maximum of 8 weeks. As a result, some Learners may reach the ends of their Learnerships without having reached the final phase.
  • Phases 4 and 5 are being combined into one phase. This creates a phase involving an array of real-world-based activities, including creating and improving applications for regular use and getting ready to find post-Guild employment.

We don’t yet know what more fundamental decisions the Guild will make about the submitted ideas, but it seems clear to me that the people in charge have paid close and respectful attention to them. My guess is that something significantly innovative will emerge from the process.

Meanwhile …

Life goes on in the Guild as it is. Although I spent some time writing and presenting one of the above-mentioned proposals (the apprenticeship one), most of my life during week 24 was focused on continuing to contribute code and documentation to the ESLint project, which I described last week. By now I have submitted 12 “pull requests” (formal submissions of changes for inclusion in the running software), and 9 of them have already been “approved” (endorsed by decision makers) and “merged” (incorporated into the active software).

At week’s end I was in the midst of work on one of ESLint’s 208 open “issues” (it has 5,321 closed issues). The issue I chose was a request to make ESLint emulate one of the rules of JSCS, another linter. The people running JSCS have decided to fold up and ask their users to use ESLint instead. So there is pressure on ESLint to do at least everything that JSCS can do. One of the JSCS rules that ESLint doesn’t yet emulate is named “disallowObjectKeysOnNewLine”. Let me explain this.

JavaScript programs package information together into “objects”. Here’s an example:

const congress = {
  creator: 'constitution',
  branch: 'legislative',
  houses: {
    senate: {
      size: 100,
      yearsInTerm: 6
    houseOfRepresentatives: {
      size: 435,
      yearsInTerm: 2

This code defines congress as a variable whose value is an object. That object has 3 “properties”. Each property has a “key” (or “name”) and a value. For example, the first-named property has the key creator and the value 'constitution'.

You can see that other objects are embedded in this object. The houses property has an object as its value, and that object has 2 properties, each of which has an object as its value.

After defining such a structure, we can tell a machine to look up information in it, by using expressions such as congress.houses.senate.yearsInTerm, yielding 6.

Machines don’t care how an object like this is laid out, as long as it has the braces, commas, colons, and quotation marks where required. Thus, a machine would be just as happy with it all on a single line:

const congress={creator:'constitution',branch:'legislative',houses:{senate:{size:100,yearsInTerm:6},houseOfRepresentatives:{size:435,yearsInTerm:2}}}

But we write code for a mixed audience: machines and people. We want it to satisfy both. That’s why we use linters. They let us impose requirements on our writing so that it is syntactically correct and also so that humans will enjoy it.

The JSCS rule mentioned above, “disallowObjectKeysOnNewLine”, prohibits the first format shown above, allowing only the second format (although spaces may be inserted). JSCS also has another rule, “requireObjectKeysOnNewLine”, that does the opposite. ESLint already has a rule like the latter, but has no rule like the former.

Who, you might ask, would ever want the “disallow” rule? Who would want human-impenetrable code? Why should anybody spend time emulating a noxious rule?

Actually, there could be a good reason for using the “disallow” rule. There is a shorthand syntax for representing property keys and values that works in some situations, and if all of your code uses that syntax then you could have objects looking like this:

const address = {number, street, apt, city, state, zip};

If that’s how the code in some application is designed, you might reasonably decide to require yourself to keep all the properties of each object together on the same line.

Anyway, the person who created this issue proposed that we modify the existing ESLint rule so it can not only require properties to be on separate lines, but also prohibit them from being so, thus emulating both JSCS rules with a single ESLint rule.

Easier said than done. In working on this issue, I discovered that the existing ESLint rule does not completely emulate the JSCS rule requiring line separation. For example, the JSCS rule says that

const member = {

is compliant, but

const member = {
  , lastname
  , age
  , email

is not. You may think that nobody would put commas before items in a list, but some programmers do that, and, as I said, machines don’t care.

The ESLint rule, however, deems both of these formats compliant. At present, ESLint’s documentation says that its rule is compatible with the JSCS rule, so I am addressing a couple of problems:

  1. Correcting the documentation to describe the discrepancies.
  2. Doing something about the rule to permit users to emulate the JSCS rule if they wish to.

I am also revising the documentation to add missing information, adding tests to check for possible faults that the existing tests don’t cover, and pondering whether it makes sense to take a prohibitive rule and make it also mandatory, instead of creating a new rule.

Luckily, we contributors have quick access to veteran ESLint authorities for judgments on whether and how to resolve such problems, and interested users can chime in with their opinions.

My most enlightening lesson from this activity is how low the barrier to entry is. The whole ESLint software and documentation package is about 170 million characters in size and contains about 20,000 files. That includes others’ packages that it incorporates into itself. How could a JavaScript novice improve such a package within a few days of deciding to help out? Learners Guild tells us that the main skill we are learning is “figuring things out”. That includes figuring out what we don’t need to figure out. What I have needed to figure out for this work is an infinitesimal fraction of ESLint. That fraction keeps growing, but only gradually. The system is modular enough, and the code is intelligible enough, to let learning and contributing progress hand in hand. A good thing. If one needed to spend months or years learning how it all works before starting to participate, I don’t know anybody who would.

3 Responses to “Week 24 at an Unbootcamp”

  1. Peter Catalano says:

    oh, that changes everything! :)

  2. Slight correction: ESLint merges revisions into the “master” branch of its software, but “releases” the latest batch of revisions only every few days or weeks. Regular users who download the software can get the last release. Only my first 5 revisions had been released by 26 October. They are listed in the release document at https://eslint.org/blog/2017/10/eslint-v4.9.0-released .

  3. Peter Catalano says:

    yup, def not a field for me.

Leave a Reply