Category: cs50

General Assembly WDI, Week 10

Hungarian folk dancers and Hugo.

Day 45

Monday was “Computer Science Day,” which put me squarely in one of my happy places. One of my favorite things in all of Boston is the Bean machine at the Museum of Science, which illustrates the central limit theorem (specifically, the law of normal distribution, aka a bell curve):

Searching & sorting algorithms (which, along with data structures, were the primary topics of the day) tickle that same space in my brain, and come with even more fun videos. Some of my favorite resources for learning about those algorithms, and by extension Big O notation and time/space complexity:

For the data structures portion of the day, we split into groups and each researched a single structure, then presented to the class. My group had linked lists, which are really fun to draw on the board (but maybe not as much fun as tries). Some good resources for learning about these:

  • The CS50 week 5 notes and the “Data Structures” section of the study guide
  • The Wikipedia articles on the major types we covered (lists (including primitive arrays, stacks, and queues), linked lists, associative arrays, trees, graphs, and tries) are pretty good. Wikipedia also has an extensive list of data structures.

Days 45-47

We kicked off Tuesday morning with a giant brainstorming session. The prompt: what technologies and related issues have we not yet covered? It was a long list, and not nearly exhaustive. The goal was to provide starting points for our next assignment: a 15-minute presentation on a topic of our choosing.

This was fun. And overwhelming. And fun. My brain jumped immediately to things I’ve worked on or heard about at Berkman—digital security, Internet censorship (which one colleague chose for her presentation—I was excited to point her to the OpenNet Initiative and Internet Monitor!), Elasticsearch, Kibana, PGP/GPG. I decided to go a completely different direction for my presentation, though, and chose to talk about setting up a code blog with Hugo.

I’m a little behind (only now writing about Week 10 of 12, even though I finished the program in mid-November), but I’ve been doing my best to blog about the code I’m writing and the concepts I’m learning since starting the Web Development Immersive program. I think it’s one of the best things I’ve done for myself as a developer. I’m not always as clear or concise as I’d like to be, but going back through my notes, attempting to distill concepts, and giving myself a second chance to dig into anything that was confusing or particularly intriguing the first time around has helped me retain information, get feedback from others inside and outside of the program, and test my own understanding.

Why Hugo, specifically? Mostly because I’m getting a bit frustrated by WordPress’s bloat and would like to see if I can make the experience of blogging and browsing a bit faster. Jekyll was my first thought, given the size of the community (huge), its connection to GH Pages (which I’ve used for the last four of my public projects), and its use of Ruby (a language I’d like to get better at), but Hugo won me over for its speed argument alone, given that I’d like to port over this blog, which has over a decade’s worth of content. I haven’t yet gone through the process of exporting all of my content to markdown/comments to Disqus and importing them into a Hugo site, but it’s on my to-do list. In the meantime, I put together a quick presentation/tutorial about how to get started with a very basic portfolio site (above) and managed to spark interest in a couple of classmates, which was exciting.

Day 48

I don’t have enough exclamation points to convey my excitement about CLIENT SIDE ROUTING!!!! One of my frustrations throughout the program has been that all of our single page apps only handle/offer a single URL. Want to share a Go Bag packing list with a friend? Nope. Want to send around your Happening event invitation? Nope. Finally getting my hands on (one of) the (many) tools to solve this problem felt so good.

Some basics, if you’re unfamiliar with client side/front end routing: A lot of people are building “single-page applications” these days, which load data dynamically, behind the scenes, as the user interacts with them. The page is never reloaded in the web browser, which makes the user experience a bit faster/more seamless. Because you’re only working with a single web page, you also only have (by default) a single URL. You can check out my packing list app Go Bag for an example of this—logging in, signing up, creating a packing list, editing items, and viewing different lists all happens at https://rhjones.github.io/go-bag/. This is a bummer: what if you want to share a list with a friend? Or send them directly to the sign up page? Or (wait for it) use the back button in your browser? None of this works “out of the box” with a single page application.

Enter: client-side routing, which solves this problem by mapping different parts of a single page web application (like a single packing list, or the view that lets you create a new list, or the log in form) to different URLs. Suddenly, you can bookmark URLs! Share them! Go back and forth between them using the buttons in your browser! It’s like having your single page application cake and eating it, too.

There are larger front-end frameworks that will handle this for you, but we dipped our toe in the water using Router5. We started with a simple HTML page with three divs and a nav bar with three matching links. Each link was tied to an event handler that, when a user clicked the link, would add/remove a “hidden” class to the appropriate divs to “swap out” the desired content. Along the way, the URL never changed.

Using Router5, we refactored this code to instead define a series of routes that matched the previous links and register a series of URL paths based on the internal anchor links. Clicking on one of these links now uses the navigate method of Router5 to navigate to a specific route (i.e., change the URL and execute code associated with that route). We also defined a middleware function that is executed on each transition between routes. This function takes care of adding/removing the “hidden” classes to display the content associated with each route. Ta-da! Functional, shareable URLs that map to specific pieces of a single page JavaScript application.

The goal here was to demonstrate, very simply, how client side routing works and to familiarize us with the concept of associating specific view states with different routes in preparation for working with Ember, which we covered in Week 11. Ember uses Router.js, not Router5, but the principles hold.

On numbers

One of my favorite lectures at SIPA was Paul Thurman’s last lecture for Quantitative Analysis for International & Public Affairs.

Stats is required for every SIPA student, not just those concentrating in economic development or international finance, and a lot of people hate it in the same way that high school students hate math. Thurman was tasked with the very tough job of convincing us that it was relevant to each and every one of our careers. After a semester of practice sets and STATA and normal distributions and t-tests and midterms, Thurman sat us down, flipped on a projector, and pretty much convinced us all.

We had just finished presenting our final projects, which (he teased) had probably been rush jobs—all nighters pulled in the library frantically running multiple regressions. He asked us to walk through another rushed stats project with him to see if we could figure out what had gone wrong. The slides he put up were partially blacked out to protect the confidentiality of the client, but the essence was that a set of tests to identify possible correlations between temperature and the failure of a certain mechanical part were being horrifically misinterpreted.

Turns out the mechanical part was an O-ring—the O-ring that failed on an unusually cold day in January 1986, causing the Challenger to explode.

While the engineers in charge of determining safety—people whose jobs it was to run the numbers and interpret the math—had correctly identified this as a problem, multiple people at other layers of the project—managers at both NASA and Morton Thiokol, the contracting company responsible for building the O-rings—had decided to go ahead with the launch anyway.

Thurman’s point was that statisticians, engineers, and data geeks aren’t the only ones who need to pay attention to the numbers. Most of us would at some point be in a position where we would need to make decisions based on quantitative analysis, and given our collective interest in development, finance, and economics, many of these decisions could have real, serious impact on people’s lives. He then put a photo of his kids up on the screen and charged us with making sure, essentially, that we didn’t fuck things up for them or future generations.

(It sounds almost unforgivably hokey now, but I wasn’t the only one with goosebumps, and some people actually cried.)

Four years later, I’m taking David Malan’s intro to computer science course, CS50. Monday’s class was partially about imprecision in float variables, and Malan showed a video that took me right back to Thurman’s class:

(In case you’re not up for 9 minutes of Modern Marvels: because “one tenth of a second” can’t be represented precisely in binary, the clock on early versions of the Patriot missile lost precision over time. Because of this error, the missile failed to intercept an incoming Iraqi missile during the Gulf War, leading to the deaths of 28 American soldiers. A short explanation is here.)

To sum up: numbers are really important.