Archive for August, 2017

Week 13 at an Unbootcamp

Monday, August 14th, 2017

The basics

During my first dozen weeks as a beginning student of software engineering at Learners Guild, I had considerable discretion in selecting topics. I used that discretion to emphasize the “fundamentals” of web technologies: HTTP, HTML, CSS, and JavaScript, one by one. This was by choice, and it was also consistent with the Guild’s recent curricular reorganization, in which new Learners are gently steered toward fundamentals for the first 12–18 weeks of their study.

This means I forewent some opportunities to work on the many related technologies that tie these fundamentals together and power complex real-world applications. Instead, I strove to assimilate basic truths.

Truths such as: ['x', 'y', 'z'] is not equal to ['x', 'y', 'z'].

That’s right. They are not equal. You see, ['x', 'y', 'z'] is an “object” containing 3 properties, named 0, 1, and 2. 0 has the value 'x', 1 has the value 'y', and 2 has the value 'z'. Why, then, are the above expressions not equal? They sure look equal. Here’s why: The mere act of putting the expression ['x', 'y', 'z'] into one’s code causes JavaScript to create an object containing those 3 properties with those 3 values. But, if I ask JavaScript whether the objects represented by those two expressions are equal, I am putting them both into my code, since that’s how to ask it that question. I ask: ['x', 'y', 'z'] === ['x', 'y', 'z'], and JavaScript dutifully creates the 2 objects in order to process my statement. Since it has created 2 objects, storing them in 2 different locations, it considers my statement false, not true. (You and I may have the same iPhone, but we don’t have the same iPhone.) The === operator asks whether they are the same object, not whether they have the same number of properties with the same names and values.

Of course, there are methods for asking JavaScript whether the objects are identical in the names and values of their properties. But, unless we know that mere equality isn’t the relevant fact, we won’t look up those methods, and we’ll simply get the wrong answer.

In my 13 weeks at the Guild, I must have learned hundreds of such fundamentals. I have then forgotten many of them again, too, but repeated practice does, indeed, turn many of them into habits and intuitions.

Getting real

My week 13 ended on 4 August, and during that week I began to migrate, incrementally, toward practicality. I learned how to process forms that users fill out on the web, how to make a web page get information from a server, how to make a website read and write “cookies” on the computers of its visitors, and how to let users create encrypted passwords.

I began to learn, too, how to make a web page that behaves like a calculator. That project kept me busy for another week. I’ll blog about it in a subsequent installment.

In principle, all that emphasis on fundamentals should allow me to be more productive as the work continues to shift toward practical applications. But, in any case, I didn’t mind the immersion into abstract rules. Reality is overrated.

 

Week 12 at an Unbootcamp

Friday, August 4th, 2017

Packages

The week ending on 28 July was my 12th week of study at Learners Guild in Oakland. I worked on 6 different projects. Through them, I learned how to apply more basic techniques of JavaScript web application development.

Some of what we learn is the JavaScript language itself—a language that changes once per year, so that learning never ends.

But it seems that more of what we learn, and will increasingly learn, is packages. They basically do things that you, the programmer, could do with the raw languages and protocols of web programming (mainly HTTP, HTML, CSS, JSON, and JavaScript), but they (allegedly) make it easier to do those things.

During the week my projects required me to learn how to use these packages:

  • fs, which handles directories and files
  • http, which handles transactions between computers
  • cheerio, which interrogates and manipulates documents written in HTML
  • request-promise-native, which manages a computer’s requests to other computers
  • pg, which manages a program’s use of PostgreSQL databases
  • express, a system for combining programs into an application delivered on the web

Some of these packages, in turn, are entire ecosystems to which other developers have contributed packages. For example, the express package has about 12,000 related packages, and the express website names 12 “popular” frameworks built on express. It’s been dawning on me that learning to use packages is only part of the challenge posed by packages. Another part is figuring out which packages to learn to use. This is not trivial, because there are many to investigate, and it can take hours of study and testing before one discovers that a package is not as good for one’s purposes as it had seemed.

As a result, wise folks advise us to choose popular packages. They argue that popular packages are not only vetted by others, but also likely to stay alive long and be updated often. It’s not hard to learn which packages are popular. At the npm site, where most significant JavaScript packages are distributed, you can order the search results by popularity. In a search for “express”, express itself is at the top of that list, and you can see, today at least, that it has been downloaded 543,571 times in the last day. There are also surveys with published statistics on the popularity and “mind share” of JavaScript frameworks. If, however, you want to do something unpopular (e.g., innovative), an unpopular package may be best, or perhaps you should develop your own, or just write your code in the basic languages of the web.

The modules we work on at Learners Guild take various stances on packages, reflecting the diversity of environments we can expect to face in the outside world. They sometimes tell us not to use any package; or to use plain JavaScript to reimplement functions that a package performs; or to use a particular package; or to use any package(s) we may wish to use. In most cases, they prescribe particular packages that are widely used, and that we therefore should become familiar with.

Perhaps some have fantasies of “mastering” a language such as HTML or JavaScript. The more I learn of them, the less plausible such aspirations seem. But the idea of mastering the universe of JavaScript-based programming, including all its packages, is absurd. We are aiming to know a lot, but above all to know how to learn what we need but don’t know. And to ask for help in moderation, and to give help usefully. And to be good collaborators. That’s plenty.