Archive for July, 2017

Week 11 at an Unbootcamp

Sunday, July 30th, 2017

The simple is not so simple

During the week ending on 21 July, my study of web application development at Learners Guild had me doing things that seem numbingly simple on the surface. I developed 2 “applications”:

  • One lets you look up the current temperature in a city of your choice.
  • The other lets you look up movies that have some relationship to some text that you provide.

Let’s make this more concrete.

Temperature application

The temperature application is a JavaScript program that runs when you ask it to. You use a terminal window, not a web browser, to run it. In the terminal, you enter a line such as:

node weather Nsoatre

In about a second, you get the reply, such as:

Temperature in Kelvin: 292.59
Temperature in Celsius: 19.44
Temperature in Fahrenheit: 66.99

What my simple application won’t tell you is that it looks up the city you asked for in the Application Programming Interface (henceforth “API”) of OpenWeatherMap, and when you give it a city name it gives you back a response that may or may not have anything to do with that city. Nsoatre is a small town in Ghana, apparently unknown to OpenWeatherMap. Instead of saying it doesn’t know about Nsoatre, OpenWeatherMap gives you the temperature for Saint-Martin-de-Beauville, France. (No joke.) If you name a large Ghanaian city, such as nearby Kumasi, then you do, indeed, get data for that city.

So, why does the Guild have us Learners creating such a useless (or worse than useless) application? As I understand it, the Guild trusts us to distinguish the practical usability of a project from its value as a teacher of fundamental technologies. This exercise helped familiarize me with:

  • Node, the world’s most widely used system to run JavaScript on computers (outside of web browsers).
  • The http module of Node, which simplifies the task of requesting information from other computers.
  • How the http module’s request() and get() methods (slightly) differ.
  • How an information request to an API is constructed.
  • How to show an API that the program has permission to get information from it.
  • How to use a JavaScript callback function to ensure that the program waits for the information from the API before it manipulates that information and sends a reply back to you.
  • How to screen out invalid requests (such as node weather, with no city).
  • The splitting of an API response into “chunks” and how to reassemble the chunks before processing the response.
  • How to round numbers to a particular number of decimal digits after computing them.
  • Debugging code.

Maybe it’s even better for my application to give you laughably unreliable information. Then I’m not tempted to spend time trying to make its answers correct, when that would only distract me from getting the intended benefits of the exercise.

Movie application

The movie application lets you look up information about movies. It’s similar to the temperature application, in some ways. You use a terminal to enter a request such as:

node movie-search Panchali

In about a second, you get the reply, such as:

Pather Panchali (1955)
Apur Panchali (2013)

This application sends your search text on to the Internet Movie Database (IMDB), gets back a web page (the same one, written in HTML, that you would get if you went to the IMDB website and entered “Panchali” into the search bar), analyzes that page to extract from it just the title lines, and sends those title lines back to you.

This application seems to give more reliable answers than the temperature application does, but not perfect. If, for example, you wanted to ask about movies featuring that small Ghanaian town Nsoatre, you would get references to 2 movies: a 1957 TV series titled “Alcoa Theatre” and a 2014 feature titled “Vadelmavenepakolainen”, about a Finnish man who “has dreamed of becoming a Swede since childhood”. I haven’t found any connection between them and Nsoatre, and I don’t intend to work on that problem, so, if you want to, be my guest.

This exercise reinforced most of the topics listed above, but the movie application’s technologies differ incrementally from the temperature application’s. This one helped me become more familiar with:

  • The widely used cheerio HTML parsing library, which simplifies the task of manipulating HTML web pages.

Getting movie title lines from an IMDB search-result web page is not trivially easy. The routine that I constructed to do this, in cheerio syntax, was:

const listCells =

This means:

  1. Find an a tag that has the name tt.
  2. Then find that tag’s parent tag.
  3. Then find that parent tag’s parent tag (i.e. the a tag’s grandparent tag).
  4. Then find all of the children of that grandparent that are table tags.
  5. Then find all of the children of those table tags that are tr (row) tags.
  6. Then find all of the children of those tr tags that are td (cell) tags with the class result_text.

So, because IMDB search-result pages are not optimally organized for programmatic analysis, I had an opportunity to spend a few hours learning and practicing the use of the cheerio HTML parsing library.

Of course, I didn’t get it right the first time; this exercise, like all of them, helped me learn how to find and correct my bugs. But debugging is a huge topic; I’ll save that for another entry.


Week 10 at an Unbootcamp

Thursday, July 27th, 2017

An unexpectedly short week

We Learners at Learners Guild in Oakland, California, are expected to be present, physically, at least from 9 a.m. to 6 p.m. Mondays through Fridays (with up to 1.5 hours for lunch). There are, however, exceptions.

As reported a week ago, the week ending on 7 July included 2 days of holiday, so it was abnormally short. The week ending on 14 July was a normal week for most, but turned out to be short for me, because of an upper respiratory infection that filled my week and the weekends bordering it. With 3 days of fever and other bothersome symptoms, day after day I was compelled to notify the Guild I was taking time off, a half-day at a time, for the Guild’s own protection.

In principle, a person can do nearly the same work at home when ill, but my condition clearly dampened my productivity. As witnessed by Github, I made 46 “contributions” the week before, versus only 27 during the week in question.

How does the Guild deal with such frailties? It offers a standard allowance of 8 days of personal time off during the 40 weeks of enrollment. Having just taken 4.5 days off, I was now left with 3.5 more days to last me through the middle of February. Once that time is exhausted and starts to be exceeded, a review is triggered. The Guild’s decision could vary from termination, in a case of callous truancy, to the granting of a leave of absence to permit recovery from a lengthy illness. I have, of course, not yet experienced such a review, but I know the people who would conduct it, and their capacity for sensitivity and empathy makes me a cold-hearted ogre by comparison, so I’m not worried.

The Guild is particularly responsive to emotional afflictions. Life can be traumatic, and life as a Learner can be particularly traumatic, given that some Learners have quit real jobs to join the Guild, most find it hard to make ends meet in the Bay Area even with stipends received from the Guild, and for many it’s a radical change from the kind of work and the kind of thinking they have done heretofore. Knowing that one is being periodically evaluated for one’s rate of progress and runs a risk of being found too slow to stay makes some Learners express insecurity. Some Learners have also testified that they have had trouble coping with disrupted expectations arising from the Guild’s recent curricular overhaul and those preceding it. The Guild holds discussions focused on stress, anxiety, disempowerment, the imposter syndrome, and other emotions affecting current Learner life and the future work lives to which Learners aspire. A psychotherapist on the staff offers group and individual counseling for all Learners.

But the Guild’s posture is also tough and demanding. While offering support to cushion the impacts of physical and emotional impairments, the Guild reiterates that its Learners must develop their own resiliance, adaptability, and skill in figuring things out for themselves, and they must participate in the delivery of support, not only its consumption.

Oh, yes, the work

My lethargic progress during the week was confined to one “module”, for which I developed a demonstration (to myself, really) of the use of “callbacks” in JavaScript to manage data in a file. The ostensible purpose of the application was to manage a list of tasks. The user can add tasks to the list, declare them completed and thereby cause them to be removed again, and display the list. A few other embellishments allowed me to give it my own personality.

But at the heart were “callbacks”, one of the main elements in the thought reform I’m undergoing at the Guild. A callback is a routine that waits for something else to finish before it runs. It has to wait, because it needs the result of the other process before it can do its work. Meanwhile, however, the main program is continuing to execute instructions. It is the callback that waits, not the program as a whole. This exercise allowed me to work on learning and obeying the rules applicable to callbacks and, finally, produce a simplified application in which callbacks operate properly. Given the tendency to forget the details (something widely admitted by Learners and not only the geezers among us), such a working template is a reassuring crutch we can return to when facing similar problems again.


Week 9 at an Unbootcamp

Thursday, July 20th, 2017

Second week under the new model

I’ve been reporting in this blog on life at Learners Guild in Oakland, California, a place where an experiment in a new model of deep, holistic, inclusive, and risk-shifting software-developer training is taking place.

To its credit, the Guild is willing to make major changes in its learning model, and it did that recently, as I reported in the previous entries. My 9th week at the Guild, ending on 7 July, was my 2nd week working under the new model, in what is called “phase 2”.

I’m writing this on 20 July, and that’s 13 days later. If you are like me, you have almost no idea what you did so long ago. What’s worse, whatever you learned to do 13 days ago you no longer remember how to do. Blog now, or forever lose your past. And even that won’t retain your know-how. If you think this is one geezer’s problem, no. “Retention” is a major topic of discussion among the mostly 20–40-year-old Learners here and their Learning Facilitators. That’s because retention (i.e. non-retention) is a problem for almost all of us. In that respect, I’m not an outlier.

But don’t give up quite yet. Now, thanks to this Guild that I’m blogging about, my life is being recorded more or less indelibly, every few hours or even minutes. Well, not my entire life, but the part that matters most, namely my progress in mastering the fundamentals of JavaScript programming.

Here’s how. We are not just reading, watching, and listening in order to learn. We are also coding. It’s the only way to know whether we are learning. And coding means screwing up, almost all the time. That, in turn, means revising code in order to make it stop crashing or misbehaving. And the revisions are more often bad ones than good ones, so we want to be able to unrevise at any time. Not to mention that, if we are coding with somebody else, we need a procedure for proposing, accepting, rejecting, incorporating, modifying, and undoing contributions to our joint code.

This batch of needs has given rise to a core discipline that is drilled into us here, namely frequently updating both the local and the remote repositories that contain our code. We do this at the Guild by using the git protocol, enhanced by a web-based platform offering developer-friendly options for reviewing our code and its history. Several times a day, or even several times an hour, we are “committing” our code changes to our local repositories and then “pushing” them to the remote copies.

As a result, I can now visit my site at Github and click on a day in history, and I’ll get a list of the contributions I made that day. I can then click on any of them to see details, down to the specific changes I made on specific lines of specific files.

In fact, you can do this, too, because my site is public.

So, this might mean that blogging is unnecessary, because my every mistake and correction thereof is now a matter of public record. I leave that judgment to you.

That Github history tells me that I devoted the week partly to finishing my quest for a grasp of how the programmer can control not only what happens, but also when. In JavaScript, this is more complex than in some other languages, because you don’t merely tell your program to go to sleep for 5 seconds before doing the next thing. Instead, you tell it to come back and do something in 5 seconds but do something else in the meantime. Managing multiple flows of interacting events requires a lot of what-if thinking and testing by people who are good at breaking things.

Github also tells me I spent much of the week working on a program that manages a toy to-do list. You can use it to add items to the list, declare them finished and therefore get them removed, display the list, and other things. There is an easy way to do this, but the specifications ordered us to do it the hard way instead. The hard way uses “asynchronous” functions, which start something happening and then let the program go on to the next step. So, if I tell the program to add an item to the list, the program needs to read the list from a file, create a copy of the list in its memory, add my item to its in-memory copy, and then write the revised copy back into the file. I must do this so that the reading is finished before the content is analyzed and expanded, even though the program, in general, keeps on running after it orders the file to be read. This exercise is aimed at giving us practice in managing events when using asynchronous functions. For me, this was major thought reform, and it took a few days before I made it my own. I say a “few days”, although the week in question was officially only 3 days long, since 3 and 4 July were Guild holidays.

My reliance on Github (like others’ reliance on Facebook histories) may make my memory atrophy even more, if Socrates was right that “they will not practice using their memory because they will put their trust in writing”. But in fact I am internalizing some skills. They are mostly those that I practice often until they become idioms for me. I have also noticed for decades, as you probably have, too, that it is foolish to rely on written notes, because they get lost, become unintelligible, and become hard to rediscover when needed. But code is not notes. Code is writing that actually does work and, once it has been pruned of its errors, keeps on doing it right. We are learning how to write code that is lucid, reusable in multiple situations, and available to anybody in the world to use for free. That’s a far cry from my scribbled course notes, whose most valuable function after being committed to paper has probably been to dry hands as recycled paper towels.

Week 8 at an Unbootcamp

Thursday, July 6th, 2017

First ordinary week under the new model

As reported in my previous post, Learners Guild in Oakland, California, recently made a major change in its software-development curriculum. The week ending on 23 June was a special week: All 120 Learners got evaluated for “sorting” into 5 “phases”.

I interviewed for phase 3, and was placed, as expected, into phase 2. Results varied greatly among Learners, but the theme was conservatism, with doubts resolved in favor of placement into earlier phases. As a result, phases 1 and 2 are now the largest, accounting for about 70 Learners.

The week ending on 30 June was the first ordinary week of the new model’s implementation. For most of us its main novelty may be its solitary study mode. We work through the curriculum in whatever order we want, at a pace of our choosing, one by one. This affects Learners differently. I think I’m thriving under it, continually absorbing what I need to know, because if I already know something I can skip it or review it briefly to confirm, and I can slow down to master a topic that seems crucial, without needing to reach agreement with a teammate. Some other Learners have voiced deprivation of the social aspect of their work, but most have voted to keep working alone when asked about a more collective interlude.

The other main difference I notice is in the quality and detail of expert support. The old model’s emphasis on near-peer coaching gave us ready access to more advanced Learners for help and reviews of our work. The new model gives us routine access to Software Engineering Practitioners (SEPs), members of the Guild’s staff with years of industry experience. The difference is unmistakable. I have requested and received 2 code reviews, and the comments by the SEP were much more expert than I had received from any prior coach. We can also attend lectures and office hours conducted by SEPs.

While proceeding through the curriculum, we may also easily contribute to it, by proposing editorial changes, ranging from typographic to substantive. I have made several such proposals, which the SEP staff has integrated into the working documentation.

For now I have decided to work through the curriculum in the recommended order, checking off claimed skills as I proceed. I’m reminded every day of phase-2 topics that I had never studied, had only superficial knowledge of, or had forgotten. While some say they want to quickly plug their knowledge holes and interview out of phase 2 in 2 or 3 weeks, I feel no such motivation. This is the fundamental stuff. It seems like a luxury to have time to study it in more depth than I have done before. A couple of examples:

  • One enters hundreds of commands as one works in a terminal. I hadn’t learned that one can find a previous command by typing control-r and then any part of the command. The terminal interfaces (such as bash) are sophisticated programming languages of their own, with many such time-saving features. The curriculum selects some of the most useful and says “learn these”, and some turn out to be techniques that would have been worth learning long ago.
  • Using JavaScript well requires internalizing new models of time, process, event, and agent management. I grew up writing computer-driven, sequential programs. They would do something and wait for the user to do something in response, then react to that. Now I’m learning to conceptualize the interactions differently, to accommodate situations in which multiple computers, multiple users, and multiple natural processes do spontaneous things and respond to one another’s actions. When I started programming, the computer’s and the user’s actions were textual. My programs would not know what a user was doing until and unless the user pressed an enter or return key to “submit” a response. Now I need to learn how to create systems in which actions can also be aural, graphic, and kinetic, and can vary continuously in addition to being discrete. I can, for example, write a program that changes what it does whenever the user slides a mouse in a particular direction or at a particular speed, an action that would have been invisible to my programs of yore. In the old days I thought of my programs as “running” on a “computer” and being “used” in a terminal or browser. Now I need to think of the server and the client as partner agents in implementing my code. I have to decide, step by step, whether it makes more sense for the server to do something or have the client (terminal, browser, mobile phone, etc.) do it.

Such changes in cognitive models of the computing universe are implicit in phase 2, at least for me, and it seems foolish to try to rush such a re-education. I want to keep putting this panoply of new tools and concepts to use until the alien becomes natural. Week by week, the Guild’s curriculum and staff are brainwashing me, it’s working, and it’s good.