Archive for September, 2017

Week 21 at an Unbootcamp

Friday, September 29th, 2017

Soft landing

During my first 20 weeks at Learners Guild in Oakland, studying to be a state-of-the-art software developer, more advanced Learners told about the incomparable difficulty they had experienced in transitioning from practice programming to for-real programming. For the first half to ⅔ of their time in this 40-week training program, they had learned by writing make-believe programs. For example, they built websites where (imaginary) users could order (imaginary) groceries from an (imaginary) store, choosing from an (unrealistically tiny) list of products. But then they suddenly got promoted and joined the team of Learners debugging, maintaining, and improving software in actual current use. It might be the Guild’s own software, used by its administrators and Learners. Or it might be other open-source software with users around the world. In either case, advanced Learners reported that the increase in software complexity accompanying this transition was traumatic, exacerbating or creating whatever amount of imposter syndrome they already had or didn’t have. No amount of prior training, they suggested, could have prepared them for the shock.

Well, I have just survived my first week in that phase, which the Guild now calls phase 4. If blood and guts sell news, the week ending today (29 September) was nowhere near as newsworthy as I had been warned to expect. Two of us Learners started phase 4 this week, and we both seemed to take it in stride.

Yes, indeed, there was a lot of new information and technology for us to begin getting familiar with. During my very first day in phase 4, I started learning the following concepts and techniques for the first time:

Why, then, was this not an overwhelming cognitive load?

I’d say the main reason is the Guild’s contagiously relaxed attitude about getting up to speed. During the week-end review of our work by the dozen of us in phase 4, my fellow cohort member said she was concerned that it had taken her 2 whole days to get her new software installed and running so she could start doing real work. When my turn came, I said it had taken me the entire week to do that, and this didn’t bother me at all. (In fact, I haven’t finished it yet.) This 3-to-1 ratio was due to our radically distinct strategies. She had in-person mentoring from the most advanced Learner in phase 4—somebody who derives obvious delight from coaching and brings to bear a phenomenal amount of know-how. By contrast, I eschewed such offers of help except in a few extreme cases, and instead pursued my own favored strategy: following the step-by-step written instructions and, whenever they were not correct and clear, editing them so that future entrants into phase 4 would not require much—or any—handholding.

What is notable about this is that neither our staff supervisor nor any of my phase-4 peers had any objection to either of these divergent approaches. She got started sooner with the work, but I helped make future onboarding more efficient. These styles were both treated as within the normal range. The installation instructions themselves plead with their readers to fix anything in them found to be deficient. The staff reiterated that. So I had no doubt that my investment of time in this activity was welcome. No pressure, no shaming, no hazing.

Let me also mention that figuring out what the instructions should say taught me a lot.

Making the system work—together

Learners Guild is known for its demographic diversity, but this incident illustrates its acceptance of cognitive and stylistic diversity, too. Making itself comfortable for those with diverse learning styles is an easy goal to proclaim, but not to achieve. The realization of this ambition is a work in progress at the Guild. Some Learners have made it clear that the curriculum and the learning process are not yet effective for them. It remains to be seen how wide a range of learning styles and needs the Guild can accommodate.

In the effort to make the learning environment work for a diverse clientele, the Guild has said that it wants Learners themselves to be co-designers. The intent appears to be genuine. This week the Guild began putting into place its plan to make the Learners true creative partners. The Guild’s CEO introduced Learners to the financial model powering the Guild as a business, financial results during its first year, and what-if projections with various assumptions. Learners will be grouping to make proposals for the Guild of the future. Because they will have the financial details, they will have the ability—and the moral obligation, one could argue—to justify the practical feasibility of their proposals.

Can students design their school? They’re about to try.


In California, 10,000,000 win while 60 lose rights

Thursday, September 28th, 2017

Two battles

I have been involved in 2 long-running battles to win some basic democratic rights for myself—and for 10 million other Californians. Recently both of these conflicts came to opposite ends.

Battle #1 was fought in the courts. It ran for 5.5 years, from early 2012 until late 2017, and involved 2 lawsuits, with a total of almost 700 legal papers filed in court.

Battle #2 was fought in the legislature. It ran for 4 years, from 2013 to 2017, and involved attempts to persuade the Senate and Assembly to adopt 2 proposed bills.

In both struggles, my allies and I were trying to win rights for members of what California calls “common interest developments”. If you are a California homeowner or tenant in a condominium association, housing cooperative, planned development, or community apartment project, then you are one of the 10 million Californians—a quarter of the population—living in common interest developments (CIDs).

The rights I was fighting for include:

  • Freedom of speech
  • Freedom of assembly
  • Freedom of association
  • Freedom of the press
  • Right to vote
  • Right to be a candidate for elective office
  • Due process
  • Right to witness meetings of governing bodies
  • Freedom of information (right to inspect records)

In essence, here is the problem: CIDs are private associations with somewhat governmental powers, such as the power to tax, to punish, and to deport. These powers come with nonpolitical names (such as “assess”, “discipline”, and “evict”), but courts have pointed out the similarities and, on that basis, recognized the state’s power to protect CID residents from the abusive exercise of those powers. The state has enacted protections for CID residents, mainly in two places: the Corporations Code and the Civil Code. But the protections are sloppily formulated, and questions often arise as to what they mean. On occasion, courts intervene to interpret them, or the legislature and governor amend those codes to resolve such questions.

Even to summarize the arguments for and against the claims about these rights would try the patience of almost any reader. You can find those in pleadings in the above-cited litigation.

Back, then, to the news.

Battle #1

The litigation came to an end in October 2016 with the court’s final approval of a settlement between Berkeley Town House Cooperative Corporation (BTHCC) and me. BTHCC is a housing cooperative in Berkeley, with 60 units (membership limited to seniors). The settlement, as I interpret it, was a compromise between my claims and BTHCC’s defenses, and it was so vaguely formulated as to invite post-settlement conflict. It secured a few rights for the 60 members, but only a fraction of what I had claimed the members were entitled to.

As could be expected, after the settlement BTHCC and I promptly began to disagree about whether BTHCC was complying with its settlement obligations. Most crucial was a dispute over BTHCC’s required disclosure of financial records. The settlement required BTHCC to disclose to me (so that I, in turn, could scrutinize them and further disclose them to the other BTHCC members) the “general ledgers” of BTHCC from 2010 to 2016. I argued that BTHCC’s disclosure had to include every income and expense transaction, with the payer or payee identified. But BTHCC claimed that it had the right to keep the income transactions secret, and, if it did disclose any, it could lump them together and conceal the identities of the payers. BTHCC makes about 30 payments a month, but takes in about 60 payments (of assessments by members) a month. So BTHCC claimed it could let me see about a third of all the transactions and that would count as total disclosure. I brought BTHCC back to court to enforce its disclosure obligation. BTHCC resisted. Lengthy pleadings set forth my arguments, and those of BTHCC, in detail.

Finally, the court issued an order on 22 August, giving a 100% victory to BTHCC in the disclosure dispute. Since it was not certified for publication (as some appellate decisions are), it cannot be cited as precedent in similar lawsuits, but it resoundingly denied to the 60 members of BTHCC the right to see who has been paying and who has not been paying to BTHCC the required monthly assessments. Has the Board of Directors been allowing itself and its friends to pay late? Has the Board been lax in enforcing members’ obligations to pay? Has money fallen through the cracks? BTHCC was preventing its members from answering such questions, and, thanks to this court decision, it will be able in the future, too, to keep the sources and amounts of its income secret.

Battle #2

Meanwhile, a legislative battle began in early 2013 with a failed effort by me to get the Civil Code amended. The proposed amendment would state, for the first time, that constitutionally guaranteed civil liberties apply inside CIDs. Any rule violating Article 1 of the California Constitution, where basic civil liberties are set forth, would be invalid. The procedure under which I made this proposal required unanimity among stakeholders, and there was no such unanimity. Attorneys who represent CIDs in disputes with their members argued, as they typically do, that CID members enjoy civil liberties outside the walls of the CIDs, but not inside. So my proposal gathered some opposition, and the committee considering it refused to endorse it for lack of unanimity.

Two years later I was a member of a group proposing a somewhat similar bill. This time it had a senatorial sponsor and did not require unanimity. This bill, SB-407, was less comprehensive but more explicit. It protected members’ freedoms of speech, assembly, and press in various contexts. For the first time, CID members could gather and discuss public and CID issues in a CID’s common areas without needing to get advance permission, pay fees, or buy insurance coverage. If a CID denied any of these rights, members could go to small-claims court to get an order and collect a $500 penalty.

Experience led me to expect vocal opposition to such an expansion of CID member rights. Amazingly, however, the initial opposition evaporated during negotiations over SB-407. It was amended during the legislative deliberations in such a way as to satisfy all the major stakeholders. In the end, it was adopted by both houses with near-unanimous votes. Two weeks ago, on 11 September, the governor signed it into law. So, as of 1 January 2018, all 10 million CID residents in California will be explicitly entitled to a new set of democratic rights.

Why did we have a relatively easy time getting this bill adopted? The sponsorship of Senator Bob Wieckowski and the indefatigable advocacy of the Center for California Homeowner Association Law were, by all appearances, crucial. The bill also got support from the American Civil Liberties Union of California, the California Alliance for Retired Americans, the California School Employees Association, the Community Associations Institute–California Legislative Action Committee, the Golden State Manufactured-Home Owners League, and the Non-Profit Housing Association of Northern California. There was no organized opposition.

Ironically, BTHCC, too, played a significant part in this bill’s adoption. Back in early 2013, during the litigation between BTHCC and me, I arranged a meeting in a BTHCC common area with invited expert guests to discuss—of all things—civil liberties in CIDs. The BTHCC Board of Directors (then composed of Almalee Henderson, Margaret Tuggle, Judith Wehlau, Lydia Gans, and Raymond Dirodis) hired an attorney, Stephanie J. Hayes, to threaten me and any visitors to the meeting with arrest for “trespass” if I did not cancel the meeting and disinvite the visitors. This threat was consistent with a position, then taken by the Board and since then never officially rescinded, that it had the sole power to decide who may meet in the BTHCC common areas and what topics may be discussed there. The Board has further claimed that it can require members to seek permission for any gathering at least 2 weeks in advance, and anybody who meets in a common area without such permission can be fined. (The Board has prohibited other meetings because of content, for example refusing to let a group discuss affordable housing. And it also prohibited interviews of BTHCC members by makers of a documentary on housing cooperatives.)

Three years after this threat of arrest, it backfired. The advocates of SB-407 gave the legislature a copy of the threat letter from the BTHCC attorney, and used it as the main item of evidence that some CIDs “stifle free expression”.

Morals of the story

“You win some and you lose some”. I lost the battle for complete disclosure of BTHCC’s finances to its 60 members. But, three months later, my allies and I won a battle to get specific freedoms of speech, assembly, and press guaranteed by statute for the first time to the 10,000,000 residents of CIDs in California. Yes, BTHCC defeated my efforts to secure disclosure. But its heavy-handed plan to bring police to bear on people for discussing civil liberties inadvertently helped convince the legislature and governor to write new protections into the law.

On the basis of these experiences, what can you do if you are one of the millions of CID members and you want full financial disclosure? After exhausting your in-house remedies, should you take your CID to court, try to get the legislature to make the law more explicit, run for a position on the board of directors, or just give up?

My choice was to take BTHCC to Superior Court, with attorney representation. This was due to special factors that would probably not apply to you. I was pursuing other claims, too. They resulted in BTHCC recovering over $200,000 from two contractors, BTHCC being forced to stop concealing seismic risks in its building from prospective members, and my own recovery of over $300,000 to pay for attorney fees.

If you faced a refusal to disclose CID records, you would have judicial options that I did not have. Starting in 2014, after I filed my first lawsuit, the legislature made it possible to sue for disclosure of records in small-claims court. So now, if you want to see records and your CID denies them to you, you can file a small-claims complaint at nearly no expense and pursue it without an attorney. Of course, your small-claims judge might rule the same way as the judge in my case, but there is no assurance of that. And you can ask for a $500 penalty as well.

You could also try to follow the legislative route, asking for a Civil Code amendment that would erase the ambiguity as to whether a CID must let its members see, in full detail, the records of all transactions on both sides of the ledger, income as well as expenses.

Then there is the political option: becoming a candidate in the next election for directors of your CID. Once you are a director, you have more unlimited rights to see records, and you are likely to be granted access to all the details. You can even propose a board resolution publishing the entire general ledgers of all income and expense accounts for access by all members.

If my experience is a guide, such activism, whether judicial, legislative, or political, is likely to interfere with your social life. You may be branded a traitor and face ostracism. You may be harassed. (I had blue cheese smeared on my apartment door, water poured onto my head, and posters posted calling me a “creep” and a “scorpion”.) Why? After all, you would be fighting for your fellow members’ rights. Paradoxically, most of them despise the right to full financial disclosure. Most want to be kept in the dark about whether their fellow members are paying what they owe. (Like my grandma, who said “If you ever start dating a non-Jewish girl, don’t tell me.”) They have the legal right to enforce your obligation to pay your monthly assessments, but they want to be denied the information that would make such enforcement possible.

For the same reason, I consider all of these approaches to be long shots. Your opponents in court will likely try to make your personality the issue, rather than their secret-keeping. Representatives in the Senate and Assembly will likely fear the wrath of numerous constituents. And a candidate for a directorship who seeks to open the books will have a hard time getting elected, unless the position is uncontested.

You do, however, have another option: to give up, by either ignoring the problem or moving out. Given the odds, this is tempting. Why not let only the directors know whether they are mismanaging the funds? Just trust them. Trust, clearly, is the easiest approach.

Week 20 at an Unbootcamp

Saturday, September 23rd, 2017

Getting real

Learners Guild in Oakland offers a 40-week program of project-based training in software development, centered around web applications written in JavaScript.

The training functions are distributed, with more advanced Learners helping less-advanced ones, as in the proverbial one-room schoolhouse. There are also ex-Learners serving on the staff as coaches, and professional programmers holding office hours, checking Learners’ code in group sessions, and giving lectures. Most of the time, Learners are figuring out how to build applications, either solo or with a partner, by absorbing documentation, tutorials, and other resources, then writing, testing, and revising code until it works.

I have just completed my 20th week there, and during the week I underwent an exam and a technical interview to establish my readiness to progress from “phase 3” to “phase 4”. The exam took me the 2.5 days allotted, and the interview was tough, resulting in a half-page of recommendations on further study to solidify my fragile competence in certain important pieces of web technology. But the evaluator decided that on the whole I had what it took to proceed to phase 4.

Phase 4 will involve leaving make-believe projects behind, and working on real open-source software, namely the software that powers the instructional system of Learners Guild itself. That software, as is always true, needs to have bugs removed and infelicities remedied. But Learners Guild is reinventing its curriculum, not only in content but also in structure, so the demands on phase-4 Learners include making improvements, often previously unanticipated ones, in the existing code, without introducing new faults into it.

Word on the street is that it is a shock to find oneself in phase 4, because the huge body of code with its many depended-on software libraries is far more difficult to make sense of than the self-contained practice applications we have been building in the earlier phases. I’ll be finding out shortly whether my reaction is the same.

Meanwhile, on Saturday I attended an orientation to another opportunity to contribute to open-source software, the Open Oakland brigade of Code for America. I began to learn which of its projects are still alive and which of those might be able to use my help. If, however, the immersion into phase 4 is as traumatic as rumored, my temptation to engage in such extracurricular volunteering may be postponed.


Week 14 at an Unbootcamp

Saturday, September 23rd, 2017

Week of reckoning

My 14th week studying web software engineering at Learners Guild was a week of reckoning—in a figurative sense and in a literal sense.

Figuratively …

Under the Guild’s new learning model, Learners undergo a progress assessment at least every 8 weeks. The first assessment, for all of us, was during my 7th week, starting on 19 June. It placed me into “phase 2”, out of 5 phases. Consequently, I was required to undergo another assessment no later than my 15th week, but getting assessed earlier was recommended, since by doing so a Learner could get re-assessed in the 8th week in case the initial assessment was unsuccessful. I chose to undergo my assessment (for admission into phase 3) during the week ending on 11 August, my 7th week in phase 2 and 14th week over-all.

So, it was a week that could send me on to phase 3 or keep me in phase 2 for another try a week later. The take-home-examination portion ran from Monday morning until Wednesday at noon, and satisfying all the requirements took me all of that. The interview portion lasted an hour, and mine was late Wednesday afternoon. Well-conducted, a technical interview of that length was enough to show that I had done my own work, I knew what I had done and why, and I could identify remaining gaps in my related knowledge. Within minutes after the interview ended, I got an official email congratulating me on my admission into phase 3.

Literally …

That left the rest of the week to my discretion, and I decided to keep working on phase-2 study that I had interrupted for the assessment. I had been in the middle of an exercise called “Mac Calculator Clone”, within a module named “JavaScript in the Browser”. The topic was making an application that your web browser can run all by itself.

Perhaps this exercise, like most, should have taken me a day to complete, and I should have moved on to the next module. But no. More than all the previous exercises, this one kindled my imagination and ambition. Why? Because the instructions told me to “clone” the Macintosh OS X “Calculator” application. As I began figuring out how to do that, I gradually changed my question to whether to do it and, if not, what to do instead.

This raises two obvious issues, so let’s deal with them.

  • First, do we, lowly Learners, have the authority to modify the specifications?
  • Second, why not clone the Mac calculator?

As to the first question, yes, we do. At Learners Guild, we learn to code, but we also learn to think. And to feel. And to exercise agency. In fact, we have workshops aimed at helping us be both more powerful and more responsible in the social situations programmers exist in. So, if we want to depart from the specs and we can justify doing so, nobody objects.

Moreover, we have a standing invitation to propose changes in the specs themselves. I have made dozens of such proposals, and the Guild has adopted almost all of them, sometimes on the same day. We are improving our own curriculum as we work through it.

Still, why not clone the Mac calculator?

I have often used the Mac calculator, but as a user I merely used it. As a cloner, I had to scrutinize it. The specs told us to make our calculator follow the same rules, so I needed to figure out what those rules are. Easy? Not for me.


Mac Calculator

If you start fresh with this Mac calculator and enter 6 0 ÷ 3 0 % 5 0 =, you get 1.2.

Entering 6 0 + 3 0 % 5 0 = gets you 110.

Entering +/- 8 = produces 8.

The result of 6 – = 9 = is 3.

Do you understand why? With enough reasoning, one may be able to infer the rules (for example, in the first two cases, the 3 0 % part is simply ignored). But most of us want a calculator, not a mystery. It became obvious that these rules are not my rules of arithmetic, and I doubt they are intuitive for anybody else. So I lost motivation to reverse-engineer the product.

Here is a list of some deficiencies:

  1. Some rules are unintuitive.
  2. As pointed out by Stephan Weber, the order of operations is not sequential: × and ÷ take precedence over + and . If you want 4 – 2 x 5 to produce 10, you can’t simply enter 4 – 2 x 5 =, because that will give you –6 instead. You must enter 4 – 2 = x 5 = to get 10. (For some users, this is a virtue. Tastes differ. Apple itself is inconsistent: While its calculator application gives precedence to × and ÷, its calculator widget on its Dashboard application does not.)
  3. The initial result is 0, although the user has not entered anything.
  4. When a term is entered, the previous one disappears, although it is still essential.
  5. Buttons that cannot be used don’t change their appearance and continue to flash when pressed.
  6. The 0 button is double-wide, wasting a space that another button could occupy.
  7. It is impossible to divide by the result, because there is no reciprocal button.
  8. The portrait layout forces digits to be shrunk earlier than a landscape layout would.

A better-than-Mac calculator

During the rest of the week, then, I worked on making a calculator that would be better than the Mac’s. Like the exercise specifications, my calculator relates only to the Mac calculator’s “Basic View”. Improving on the “Scientific” and “Programmer” views and on other features, including converters for weights, measures, and currencies, would be a much larger project.

Better-than-Mac Calculator

Better-than-Mac Calculator

As this picture shows, my calculator displays the entire statement that will be calculated, so you don’t need to remember what you entered earlier. Here the decimal-point button is dimmed, because after you have included one in your current number you can’t enter another decimal point. The reciprocal button (¹/) lets you divide by a result. The rounded-equal button () lets you round an existing result, one decimal digit at a time, or perform a calculation with rounding. The operations are simply sequential. Finally, I would argue that this calculator does more benign things with extremes than the Mac version. If you divide 5 by 0 on the Mac, you get Not a number. On my calculator, you get Infinity, and you can then take its reciprocal, add 10, and, properly, get 10, since 1 divided by infinity is 0.

But you don’t need to take my word for it, or view only a static picture. Try it out yourself, and let me know what still should be improved, or report any bugs you may find. Feel free to comment below. Or, if you are comfortable with git, you may post an issue on Github or make your own improvements.

The Learners Guild curriculum reminds us every day of how little we know yet. Still, after 14 weeks of JavaScript study, a solo trainee can claim, in at least some respects, to have improved on the work of armies of programmers and designers in a near-trillion-dollar company. Pure chutzpah, perhaps. You judge.

(Originally published 20 August 2017; revised.)

Week 19 at an Unbootcamp

Sunday, September 17th, 2017

Come let us reinvent together

The new curriculum at Learners Guild in Oakland, an alternative to the traditional coding bootcamp, has elicited much debate among the Learners, and the Guild has responded by slowing its adoption so that Learners have enough time and information to intervene in the adoption (or modification) process.

On 15 September, as my 19th week there ended, the Guild set up new communication channels to help organize Learner engagement in what appears to be the ongoing redesign of our institution. Learners were informed that efforts are under way to disclose to Learners more of the Guild’s business information—it’s a one-year-old B corporation, with a profitmaking purpose and a social mission—so Learner participation can be based on realistic estimates of constraints.

Learners’ recommendations on the principles of their engagement have been wildly diverse, ranging from electoral representation with mediation of nonconsensual issues to subsidiarity. One might colloquially simplify the endpoints of this range as “Gimme a vote” and “Gimme something to do”.

Extensive Learner participation in the gradual redesign of the Guild seems to be advocated by almost all parties, in principle, but it does face obstacles. Learners’ job 1 is to learn software development, and the Guild reminds them of this every few weeks by subjecting each Learner to a 2.5-day exam and a technical interview for progress assessment. Whether insufficient progress will bring a Learner’s membership to an end remains to be decided as the redesign process continues. But assessment anxiety is in the air. In fact, few Learners regularly try to influence the process; most keep their heads down and code away.

Transition time again

Speaking of periodic assessments, mine is now due. I have been in Phase 3 for 5 weeks, and at week’s end I received the Guild’s routine exhortation to get myself evaluated during the following week. I responded compliantly, so on Monday morning my exam will begin, and by the end of the week I’ll know whether I’m considered to be proficient enough to move into Phase 4. In that phase, Learners work on real software that is in use by real people.

Meanwhile, the week’s project required my teammate and me to test a web application that others had developed. We spent most of the week trying to figure out whether some software libraries, with names like Phantom and Zombie, which allegedly make such testing easy, really do so, or instead make it impossible. Vaporware and miserably documented (but still popular!) software libraries are plentiful, so one must adopt defensively. I obviously have yet to acquire the skill of detecting such libraries quickly. This skill, it seems, is of extraordinary value to developers who are responsible for choosing their own tools. Maybe I’ll suggest a training module on that very topic for inclusion in the Guild’s curriculum. But, realistically, the way to get something into the curriculum is to create it, not just suggest it, and how can I create it if I myself need it? If you have the answer, please comment below.


Week 18 at an Unbootcamp

Sunday, September 10th, 2017

Starting all over again—and again

Week 18 in my makeover as a state-of-the-art web software developer has just ended. The projected duration of that transition is 40 weeks, the standard term of a Learner at Learners Guild in Oakland, so I’m nearing the halfway point. On exit, the expected status of a graduate is “junior software developer”.

On Tuesday morning (since Monday was Labor Day) I voted for a module titled “Debugging Snapshot”, and the Algorithm assigned me to it. My job was not to create anything new, but instead to inspect a web application written (and deliberately broken) by somebody else, figure out why it didn’t work, and repair it. The module could use some calibration, because I finished correcting the bugs by the end of the first day.

This despite the fact that on Tuesday afternoon I hosted a talk by another visiting brother of mine, this one a venture capital investor in energy-efficiency and clean-tech industries. About 15 Learners engaged him in a lively Q&A session about combining dissimilar careers, startups as places to work, doing good while making money, and other topics. (My brother, ever the bearer of gifts, treated the attendees to chocolate and taramisu 75th-birthday cakes, too.)

Quick completion of the debugging module allowed me to resume work on the “Pizza Restaurant” module that I had begun a week earlier and was, as reported earlier, not close to finished. By the end of this week, I had made good progress, and the end was apparently in sight.

By tomorrow I may eat those words. The week’s work illustrates that my makeover (and I don’t seem to be alone in this respect) consists largely of repeated makeovers.

As I mentioned last week, I have revised the design of this application’s database many times. The two weeks have witnessed design revisions about daily. As one example, on Friday the professional in charge of my group (Phase 3) advised us never to design a system in which each person has a role. Does your model of a school give each person a role such as teacher, student, janitor, or parent? Bad! That design is destined to break as soon as anybody needs to have 2 or more simultaneous roles, and there will be many points in the code that must be revised to accommodate the needed change. Shame on me. Knowing this, I had nevertheless provided for sole roles in my design. I duly revised this, creating a table of role assignments so that anybody could have any number of roles at once.

Another kind of makeover is “refactoring”. I got all the pieces of my application to work together, and then, instead of basking in self-congratulation, I looked more critically at the code. Let’s face it: The code reeked of repetition. The parallel routines could, obviously, be combined and called on from multiple places. So, a few times, that’s what I did. The last of these refactorings consolidated 16 functions into 2.

This habit of finding my own work to need fundamental reorganization and compaction seems not peculiar to software development. In academic and other writing, what I have been proud of one evening has usually become an embarrassment the next day, and eventually could be shrunk by about 50% with a boost to its lucidity. While getting anybody else ever to read my writing has always been a struggle, being a student again confers a right to critical code reviews by professionals, and an expectation that peers, too, will comment on one another’s work. We Learners are awash in opportunities to discover and rectify our mediocrities. I hope to enjoy 22 more weeks of such bliss before my graduation into juniority.


Week 17 at an Unbootcamp

Friday, September 8th, 2017

Beating pizzerias into helpshares

My 17th week of study at Learners Guild ended on 1 September. On Monday I voted, as one does in Phase 3, for my 2 most preferred modules to work on for the week. As has almost always been true, the Algorithm gave me my first choice. In this case it didn’t assign anybody else to work with me, so it was a solo project. I did confer often, though, with another Learner who had been assigned to the same module.

The module was titled “Pizza Restaurant: Relational DB With CRUD API”. Let’s start by unpacking that for the general reader. A relational database (DB) is a collection of data organized into interrelated tables. For example, a database for a pizza restaurant could contain tables of ingredients, pizzas, customers, employees, suppliers, etc., and other tables combining these (e.g., a table recording which pizzas contain which ingredients). An application programming interface (API) is a service that provides to programs the ability to do things with such a database. And a CRUD API is an API that lets programs create (C), read (R), update (U), and delete (D) data.

The module told the Learner to create a relational database and a CRUD API for an imaginary pizza restaurant. The instructional value of the module did not depend, however, on us modeling that particular kind of business. Therefore, the module’s author had wisely invited Learners to feel free to model anything else instead. As you might imagine, I took the author up on this offer. I decided to model not a business at all, but rather a community of learners who help each other acquire skills. I tentatively named the project “helpshare”.

The most important task was to define a model of this institution. What are the entities in it? How are they related? What data are gathered and stored? What entities have what powers to CRUD the data? This was not a one-time decision for me. I kept revising my design all week long. I aimed for some reasonable combination of simplicity and realism, and that was elusive. In addition, I needed to create a database reflecting the model and write the programs that would control the interaction of other programs with the database.

The project was far from “complete” by week’s end. In the new Guild, no longer characterized by weekly deadlines, that was no problem. So I kept working on it over the (long) weekend, and beyond. I hope to let you try it out and give me comments, once it works.

On Friday I hosted a visitor at the Guild, namely one of my brothers, who began programming computers 55 years ago and is still making his living doing so, currently in the domain of pharmaco-vigilance. He gave an informal talk to a dozen Learners and fielded questions about how software development has changed over time, the skills that make programmers competitive, and other topics. We Learners are the main impresarios of visiting speakers at the Guild. Getting a time slot in the conference room is not always easy, but group meetings take place in various sofa alcoves, too.

Speaking of alcoves, the Guild offers various physical environments for Learners to choose among. There are low and high 2-person tables for sitting and standing, couches, and even mattress alcoves for horizontal work and nap-taking. There’s a stability ball in use, and I’ve recently been trying out an elliptical exercise machine while standing and sitting at desks.

Week 16 at an Unbootcamp

Wednesday, September 6th, 2017

Who’s who on your web site

During my 16th week (ending 25 August) as a student (officially, “Learner”) of web application development at Learners Guild in Oakland, California, I was assigned to work with another Learner on a project with a focus on authentication and authorization.

We were given an insecure website to start with, and our job was to outfit it with a modicum of security. Specifically, we needed to make it possible for visitors to use passwords to authenticate themselves, and for the site administrator to assign each user to a role, with roles having different privileges.

We mostly worked as a pair, agreeing on each line of code. This was probably better than trying to split the work into two parts. There are numerous alternative tools and strategies for website security, and each of us needed the other’s help as we struggled to figure some of them out and make our decisions. By the end of the week, we had a site that made use of “cookies” to keep track of visitors and spare them from logging in repeatedly. The cookies and the users’ passwords were protected from evesdroppers by encryption. Users with the lesser of the two roles could get information from the site, but could not add, change, or delete information.

Whether we learned enough to be dangerous is unclear, but we merely scratched the surface of web security in that exercise. One recent article has warned that security is such a hard problem that most of the treatises on how to do it right are wrong. Learners Guild introduces us to this subject, but does not pretend to turn us into security gurus.