Two Ruby patterns around map and reduce

When you're going to choose a method to work to transform a group of n things in Ruby, there are two broad patterns you can choose: work with a map function or work with a reduce / inject function.

This pattern choice was recently explained to me as part of my Ruby education at Launch School. I hadn't fully grokked that the choice around how you transform a bundle of things (an Array, perhaps) really can be summarised by those two options.

You use a map method when you want to transfer your array into another array of (transformed) things. (For example, you wanted to transform an array of lowercase names into an array of uppercase names).

example_array = ['alex', 'john', 'terry', 'gill']
transformed_array = example_array.map(&:upcase) # => ["ALEX", "JOHN", "TERRY", "GILL"]

You use a reduce method when you want to transform n number of things (inside your array) into a single thing. (For example, you wanted to sum up the values of an array).

example_array = [1, 3, 5, 7, 9]
transformed_array = example_array.reduce(:+) # => 25

How the Internet Works

The internet. It just works. Understanding exactly how is a bit more complicated than many pieces of engineering. The more you examine the different aspects and parts that make it up, the more you see complexity concealed under the surface.

Visiting this website, for instance: it feels like a trivial thing to do, but there are many different parts making that happen, from the parts that actually transport the bits of data across the physical infrastructure, to the pieces that serve it all to you on a secure connection (ensuring that what I've written hasn't been altered by a third-party).

I've just finished Launch School's LS170 module which takes you a decent way down in the weeds to explain exactly how all of these pieces fit together to make up 'the internet'. So today I thought I'd retransmit some of that as a way of cementing it in my own mind.

At a very abstract level, the internet can be thought of as a network of networks. A network itself is a set of two or more computers which are able to communicate between each other. This could be the computers attached to a home network, or the computers that connect through a central server to a particular Internet Service Provider or ISP.

The internet makes use of a series of 'protocols', shared rules and understandings which have been developed or accreted over time. These protocols allow a computer on the other side of the planet to communicate in a mutually comprehensible manner. (If these shared sets of rules didn't exist, communicating with strangers or sending messages from one server to another would be a lot more difficult).

So once we have this top-down understanding of the internet as a bunch of networks that interact with each other, what, then, is the process by which a web browser in the United Kingdom communicates with a web server in China? Or in other words, if I want to access a website hosted on a Chinese webserver, how does that series of communication steps work to make that happen?

At this point, it's useful to make use of another abstraction: communication across the internet happens across a series of layers. There are several different models for these various layers. Two of the more common models — the OSI model and the TCP/IP model — are represented below:

At the top level — "Application" — you have your website or whatever the user comes into contact with that is being served up to your web browser, let's say. All the layers below that are progressively more and more specialised, which is another way of saying that they become progressively less comprehensible if you were to eavesdrop on the data as it were passing over the wire or through the fibre optic cable.

Let's move through the big pieces of how information is communicated, then, starting at the bottom. (I'll mostly follow the TCP/IP model since it's a bit less granular and allows me to split things up in a way that make sense). This chart will help keep all the pieces in your mind:

Note that each layer has something known as a 'protocol data unit' or PDU. A PDU is usually made up of a combination of a header, payload or chunk of data and an optional footer or trailer. The header and footer contain metadata which allows for the appropriate transmission / decoding etc of the data payload.

The PDU of one layer is used by the layer below or above it to make up its own separate PDU. See the following diagram as an illustration:

Physical Layer

Before we get into the realm of protocols, it's worth remembering and reminding ourselves that there is a physical layer on which all the subsequent layers rely. There are some constraints relating to the speed or latency with which data can be transmitted over a network which relate to fixed laws of physics. The most notable of those constraints is the fact of the speed of light.

Link Layer — Ethernet

Ethernet is the protocol that enables communication between devices on a single network. (These devices are also known as 'nodes'). The link layer is the interface between the physical network (i.e. the cables and routers) and the more logical layers above it.

The protocols for this layer are mostly concerned with identifying devices on the network, and moving the data among those devices. On this layer, devices are identified by something called a MAC (Media Access Control) address, which is a permanent address burned into every device at the time of manufacturing.

The PDU of the Ethernet layer is known as a 'frame'. Each frame contains a header (made up of a source address and a destination address), a payload of data, and a footer.

Internet Layer — The Internet Protocol (IPv4 or IPv6)

Moving up a layer, part of the Ethernet frame is what becomes the PDU for the internet or network layer, i.e. a packet.

This internet layer uses something known as the internet protocol which facilitates communication between hosts (i.e. different computers) on different networks. The two main versions of this protocol are known as IPv4 and IPv6. They handle routing of data via IP addressing, and the encapsulation of data into packets.

IPv4 was the de facto standard for addresses on the internet until relatively recently. There are around 4.3 billion possible addresses using this protocol, but we are close to having used up all those addresses now. IPv6 was created for this reason and it allows (through the use of 128-bit addresses) for a massive 340 undecillion (billion billion billion billion) different addresses.

Adoption of IPv6 is increasing, but still slow.

There is a complex system of how data makes its way from one end node on the network, through several other networks, and then on to the destination node. When the data is first transmitted, a full plan of how to reach that destination is not formulated before starting the journey. Rather, the journey is constructed ad hoc as it progresses.

Transport Layer — TCP/UDP

There are a number of different problems that the transport layer exists to solve. Primarily, we want to make sure our data is passed reliably and speedily from one node to another through the network.

TCP and UDP are two protocols which are good at different kinds of communication. If the reliability of data transmission is important to us and we need to make sure that every piece of information is transmitted, then TCP (Transmission Control Protocol) is a good choice. If we don't care about every single piece of information — in the case of streaming a video call, perhaps, or watching a film on Netflix — but rather about the speed and the ability to continuously keep that data stream going, then UDP (User Datagram Protocol) is a better choice.

There are differences between the protocols beyond simply their functionality. We can distinguish between so-called 'connection-oriented' and 'connectionless' protocols. For connection-oriented protocols, a dedicated connection is created for each process or strand of communication. The receiving node or computer listens with its undivided attention. With a connectionless protocol, a single port listens to all incoming communication and has do disambiguate between all the incoming conversations.

TCP is a connection-oriented protocol. It first sends a three-way handshake to establish the connection, then sends the data, and sends a four-way handshake to end the connection. The overhead of having to make these handshakes at the beginning and at the end, it's a fairly costly process in terms of performance, but in many parts of internet communication we really do need all the pieces of information. Just think about an email, for example: it wouldn't be acceptable to receive only 70% of the words, would it?

UDP is a connectionless protocol. It is in some ways a simpler protocol compared to TCP, and this simplicity gives it speed and flexibility; you don't need to make a handshake to start transmitting data. On the negative side, though, it doesn't guarantee message delivery, or provide any kind of congestion avoidance or flow control to stop your receiver from being overwhelmed by the data that's being transmitted.

Application Layer — HTTP

HTTP is the primary communication protocol used on the internet. At the application layer, HTTP provides communication of information to applications. This protocol focuses on the structure of the data rather than just how to deliver it. HTTP has its own syntax rules, where you enclose elements in tags using the < data-preserve-html-node="true" and > symbols.

Communication using HTTP takes the form of response and request pairs. A client will make a 'request' and it'll receive (barring some communication barrier) a 'response'. HTTP is known as a 'stateless' protocol in that each request and response is completely independent of the previous one. Web applications have many tricks up their sleeve to make it seem like the web is stateful, but actually the underlying infrastructure is stateless.

When you make an HTTP request, you must supply a path (e.g. the location of the thing or resource you want to request / access) and a request method. Two of the most common request methods are GET and POST, for requesting and amending things from/on the server respectively. You can also send optional request 'headers' which are bits of meta-data which allow for more complicated requests.

The server is obliged to send a HTTP status code in reply. This code tells you whether the request was completed as expected, or if there were any errors along the way. You'll likely have come across a so-called '404' page. This is referring to the 404 status code indicating that a resource or page wasn't found on the server. If the request was successful, then the response may have a payload or body of data (perhaps a chunk of HTML website text, or an image) alongside some other response headers.

Note that all this information is sent as unencrypted plain text. When you're browsing a vanilla http:// website, all the data sent back and forth is just plain text such that anyone (or any government) can read it. This wasn't such a big issue in the early days of the internet, perhaps, but quite soon it became more of a problem, especially when it came to buying things online, or communicating securely. This is where TLS comes in.

TLS or Transport Layer Security is sometimes also known as SSL. It provides a way to exchange messages securely over an unsecured channel. We can conceptually think of it as occupying the space between the TCP and HTTP protocols (at the session layer of the OSI framework above). TLS offers:

• encryption (encoding a message so only authorised people can decode it)
• authentication (verifying the identity of a message sender)
• integrity (checking whether a message has been interfered with)

Not all three are necessarily needed or used at any one time. We're currently on version 1.3 of TLS.

---

Whew! That was a lot. There are some really good videos which make the topic slightly less dry. Each of these separate sections are extremely complex, but having a broad overview is useful to be able to disambiguate what's going on when you use the internet.

Mastery-based Learning with Launch School

It’s a new week, so we have a new podcast episode for you. Matt and I spoke with Chris Lee of Launch School about his approach to online education. We discuss the different tradeoffs and considerations that come into play when a curriculum is being put together.

To my mind, mastery-based learning — where you don’t advance to the next stage until you’ve really mastered the topic at hand — really shines for things where you have some kind of longer-term goal. Just because it’s a good approach doesn’t mean it’s easy, though. In Chris’ words:

We started this to try to figure out education. It was not a money making endeavor. So to us, teaching became the engineering problem to solve. I was not a proponent of Mastery Based Learning before Launch School. Mastery Based Learning or Competency Based Learning is not unique to Launch School, it’s a well known pedagogy in academic papers. But it’s really hard to implement.

Think about a physical classroom. Mastery Based Learning means that a student gets to occupy a seat in that classroom for an indefinite amount of time. That’s a really hard promise to make when our schools are tasked to usher through students. It’s not about training students and making sure they understand every topic, but getting people through.

You can download and listen to the episode over on the main Sources & Methods website here.

Sources and Methods Does Technology

Episode one of Sources and Methods’s new season is out today. In this interview, Matt and I spoke with the two creators of an online programme to teach the abacus.

I’ve been studying the abacus over the past few months using the RightLobeMath course and can attest to how thoroughly they build up the skill progressions. Using the web app doesn’t always feel completely polished as an experience, but it’s clear that a lot of thought has gone into the pedagogy. I’m extremely glad that it even exists at all as a service!

The rest of the season has all been recorded and edited and will be released at regular intervals. We got to talk to some amazing guests, some of whom are personal heroes / inspirations of mine from the world of technology. For now, though, you can find the first episode here.

Using Ruby's .digits method

I discovered the .digits method in Ruby the other day. As a quick illustration, it extracts the digits of a method into an array, reverse sorted.

12345.digits #=> [5, 4, 3, 2, 1]

You can optionally specify what base you’d like it to use to calculate the digits using, i.e. the same calculation as above but in base 100 would give you the following:

12345.digits(100) #=> [45, 23, 1]

Reading around a little bit, it seems that if you’re trying to get hold of the digits of a number, simply doing a .digits.reverse is perhaps an ok solution if the number is small, but at a certain point it starts to get slow. This is because .digits isn’t just ‘splitting’ the number.

For that reason, perhaps using .to_s.chars might be a better alternative. You can then use a .map function to convert the characters into integers:

12345.to_s.chars.map { |digit| digit.to_i }

I’m not entirely sure what .digits is actually used / useful for, given the speed issues.

Solid Study Habits for Coders

I’ve been working to diversify my skills over the past three years, in particular to grow as a software developer / computer programmer. To that end, I started working my way through the Launch School syllabus a few months back. I’m at an inflection point in the course right now so I thought it worth reflecting on what study habits have served me well as well as which ones I still haven’t quite managed to adopt.

Before I started, I exhaustively read through their forum comments and in-house blog posts to see how I might best approach my study time. They recommend you spend 20+ hours per week working on their course materials. With such a large investment of my time, I wanted to make sure I was getting the best return.

Core principles / Mental Models

• ‘Get Good at the Fundamentals’

This is a bit of a mantra at Launch School and I find it greatly appealing as a principle to drive how I study. It’s also useful as a heuristic to decide whether to dive deep on something, to read an article, to attend a meetup and so on. (See more here.)

• ‘Process, not goals’

I’m not sure I saw this explicitly enunciated somewhere, but given the fact that it can take around two years to work your way through the syllabus it seemed useful to keep in mind. I already have adopted this thanks to Beeminder and a really excellent piece by Scott Adams from 2013. With a somewhat long-term goal, arbitrary goal-focused time deadlines (‘finish the 202 course by May’) are less useful than something where you specify the amount of time you’d like to regularly invest into the study process.

• ‘Finishing is not the goal, mastery is.’

There’s a little bit of fetishising the idea of ‘mastery’ at Launch School, but this principle reminds me not to be in so much of a rush while working through the course. As Chris Lee mentioned in the forums, “if you’re in a rush, my question is: “where are you going?””

• (Find ways to) enjoy what is hard

This one I find quite difficult, lazy and averse to struggling with difficult things as I am. The whole skill/career of coding and wrestling with these abstract concepts in your head is one where you’re constantly upgrading your baseline of difficulty. This is rewarding in that there are always challenging problems to chew down on. This is also frustrating, though, because there’s always somewhere harder / out of reach to work towards. A number of students and TAs on the forums mentioned that having a mindset where you actively seek out those moments as opportunities for growth was a game-changer for them. (Note: strong intersections with Dweck’s growth mindset here).

Mindset

• Abandon artificial timelines

Don’t work to get through a course in x or y number of months ‘just because’. Rather, only advance if you’ve actually mastered the things in that course. This is a freeing perspective to take if you can find a way to adopt it. Society / culture encourages always keeping an eye on the clock, so this is a hard one (for me at least).

• Comparisons are odious

It doesn’t help to compare timelines. Everyone is coming at things with a different background and set of experience behind them. It also doesn’t help to compare competency / progress through the course for the same reason. It adds very little to my ability to grasp a particular topic to know where I lie on the bell curve. The only slight exception to this is knowing that the full core curriculum will take somewhere between 6-24 months to complete; this way if I am still studying it 20 years from now I can maybe recalibrate.

• Lean in to hard problems

I covered this earlier. If I have it as a sort of rubric which reminds me to lean into the difficulty whenever I encounter such a patch, then that’s useful.

• Master the current problem in front of you, right at this moment, without anxiety

Books are written one word at a time. Similarly with logic problems, or broken code or whatever, taking a calm look at something that looks knotted and gnarly is the way to approach it. There’s no need for anxious sudden movements, or huge massive changes. Work your way through things one step at a time.

• Be clear about the ‘why’

For something that isn’t completed quickly (i.e. within a few days), it pays to remember why you’re doing it. This helps with motivation, it helps reorient you to what kinds of choices you have to make, and it (often) helps remind you of some best practices around working towards that mastery.

• (Be specific)

This is sort of a sub-point relating to specifying the reason why you’re doing something. Try to specifically connect with some kind of emotion, visualise the outcome in some kind of image etc; this will help get the most of your reasons why in terms of it translating into motivation and clarity of purpose.

Practice

• Study ‘to depth’

Make sure to study the exercises or problems to their full depth rather than just completing them for the sake of moving on. A useful image to have in your mind is that of squeezing an orange. You don’t want to abandon the orange (i.e. the opportunity to study a particular problem) until you’ve squeezed every last drop out of it. There’s a point at which you’ve spent too much time, of course, but for many / most people you’re likely erring on the side of ‘making progress’ vs getting lost going too deep.

• Do code exercises

There’s lots of options for this. You probably don’t want to start out doing this when you’re still figuring out what a variable is, but fairly soon it pays to get into the habit of doing an exercise or three each day. Think of it almost like your daily workout. You’re building your muscle memory for solving problems, as well as cementing various syntactic and idiomatic phrasings. Of course, Launch School has you doing a mountain of exercises as well, so don’t worry too much about supplementing from outside the course, at least not initially.

• Reinforce concepts / theories using active recall

This is learning meta-methods 101, but always worth reminding oneself to actively test yourself. Don’t just read through notes, but keep a list of higher-level concepts or method names and then take 30 minutes or an hour once a week to type out an example or two using each of those concepts and methods. (More on this later).

• Deliberate practice

This builds on the previous concept of active recall. For me, this often takes the following shape: I’ll complete an exercise or a challenge. Perhaps I’ve solved the problem fine using my own code / approach, but when I finish and look at the ‘official’ solution it differs from mine in some (big or small) way. I’ll take a look, make sure I understand the principles around which it’s organised, then I’ll shut that page / window and try to replicate that approach myself. Sometimes, if a problem was hard enough to solve, I’ll even leave it a few days and just try to work the problem from scratch in any possible way that I can think of. I have enough of a goldfish brain that sometimes this will feel like I’ve never solved the problem in the past.

• Compare solution tradeoffs

Alongside just trying to code it from scratch yourself, it sometimes helps to compare the various approaches (perhaps adding in solutions given by other students) and seeing which might be optimum. Asking ‘why’ at this point is often a useful place to stretch towards, even though the answer to that ‘why’ is often a few modules ahead of where you are. I keep a log of these bigger picture ‘why’ questions.

• Build things

Perhaps slightly controversial amongst those taking Launch School. They don’t encourage a ‘hack and slash’ mentality but rather direct towards a more methodical and deliberate approach. That said, once you’re at a certain point, it can be useful, motivating and just practically beneficial in terms of the reps it gives you, to build something that has meaning for you or for others. At the moment I’m just working on somewhat more pure Ruby code in the terminal / via the command line, but later on I imagine this will become more relevant. (To that end, perhaps keep a list of project ideas).

Taking Notes / ‘Studying’

This is the one that people seem to have the most thoughts about on the Launch School forums. That’s possibly explained by the fact that people will know what works for them — or at least will have some patterns that they feel have worked for them in the past, in somewhat analogous situations.

• Type out all code examples manually

This one is easy to forget. When you’re following along with a video or textbook, make sure to type out the examples, however easy or seemingly comprehensible they seem. Typing not only engages your muscles, giving you an additional hook for memory, but it forces you to slow down and gives an opportunity to question what each character of a code snippet is doing.

• Take notes with pen and paper first time round

This is especially true for things that I’m not fully comfortable with. For something where I have thousands of hours of experience under my belt — the modern political history of Afghanistan, let’s say — I have more of a structure in my head and so can get away with typing notes. For the rest, like all these new things I’m learning about Ruby, pen and paper is pretty unbeatable. There’s a bunch of good science confirming that that’s the case, and it aligns with my experiential sense as well.

Some people in the forums noted how one of their preparatory tasks prior to an assessment was to type up their handwritten notes into a more formal digital reference of the course materials. I’m in two minds as to whether I think that’s going to be useful, mainly because the online documentation exists to serve that purpose. But I’m at the point where I have to decide about that so watch this space…

• Anki for things you need to remember

If I think a particular method / fact / morsel of knowledge is something I’m going to want to actively recall from memory in the future, I’ll add it to Anki. I try to follow the principles outlined in Piotr Wozniak’s essential piece entitled “Twenty rules of formulating knowledge”. (Seriously if you use Anki and you haven’t read it, stop right now and go read it).

I use a mix of cloze-deletion cards and custom templates for coding.

This card is a simple cloze deletion card. I wanted to make sure I was learning the options for file permissions as part of the command line portion of the prep course.

This card tests my ability to produce an example where I’m using the .reduce method. I try to include a bunch of these production cards since they mimic the kinds of situations / circumstances where I’d need to recall this piece of information in real life.

[Even though comparisons are odious (see above), in case it’s of interest to others, I’m just through RB101 and about to begin RB109 and I have 536 cards that I generated during the course of my studies.]

• Ask questions

Ask lots of questions. The advice given by Launch School instructors is to focus on the why questions when asking others. (The how questions are usually a matter of looking something up). I found this was broadly true. I have a reserved set of pages at the end of my notebook where I write down these questions that seem a bit outside my comfort zone.

Some of these get answered in the course of the programme. For example, I see that one of my questions was about why symbols are often preferable to non-symbols when used as hash keys. This was answered (sort of / enough to give me a sense of the answer) a few lessons later. Others are bigger issues for which there probably is no final answer. For example: “doesn’t dynamic typing force us to spend a lot of time validating input? isn’t static typing safer?”

Asking ‘why’ something behaves they way it does allows you to better develop your mental models and can be an effective way to grasp what’s going on.

• Feynman technique

I use a slight variant of this much-lauded technique. It consists of something approximate to the following steps:

1. Write the title of a topic that you want to study / test yourself on
2. Write or map out an explanation of that subject intelligible / appropriate to a non-specialist. Do this from memory.
3. Identify any gaps in your explanation / understanding.
4. Relearn / restudy / interrogate to fill in the gaps.

Part of one of my Feynman reviews that I do on Saturday afternoons

You can use narrative / diagrams to condense and clarify your explanation. For my Launch School studies, I do this once a week on Saturdays. I keep a list of new methods that I’m learning about during the week. Particularly towards the end of RB101 these started to mount up. Then on the weekend, I’d take the list of methods and test myself by writing out (by hand, with pen and paper) code that illustrated how to use each method. If needed, I’d write or say out loud an explanation relating to that method. This is a humbling exercise; you realise that you don’t know the things that you thought you knew.

• Write blog posts to explain anything that feels unclear

My last blog post is an illustration of this. I was having trouble getting what the .zip method could be used for and how it transformed things to which it was applied. So I wrote up some notes to myself in the form of a blog post.

I sometimes worry that too many of these posts — written purely for me to understand something — are alienating for those who subscribe to the blog via something intrusive like the email newsletter. I considered putting my ‘writing for the purposes of understanding’ posts in a separate location. In the end, though, I’m probably overthinking it. Like it or lump it!

• Make mental models of how things work

A lot is made of this, both at Launch School and in the wider world of study techniques. I’m not sure I have too many examples of where I’ve formally had to think through something using a mental model of how it works. I imagine this will start to be more applicable in later courses. Or perhaps it’s just that I already have some mental models for how the code behaves owing to my previous studies in coding. At any rate, I’m keen to get the most out of this but so far haven’t found it to apply too much.

• Make a cheat sheet at the end of a topic

I haven’t done this yet, though I can see how it’d be useful. For my current course and assessment, I think it’s probably hard to do — i.e. condensing the Ruby language to a single sheet of paper. But I’m reserving the right to do this at a later stage.

• Spend time reading the code of others

I tried to do this a little bit while going through the exercises. My hesitation was initially that the code hadn’t been reviewed or formally assessed and I didn’t want to absorb bad patterns from others who — like me — were likely at the beginning of their journey and who couldn’t be expected to know if they were writing something that should be emulated or not.

In the end, I think it’s still useful to read the code of others. It’ll usually be somewhat clear or not whether an answer is overly complicated. And answering why you think that is in itself a revealing process.

Review

The Launch School syllabus takes a year or two to get through. You start off with Ruby, but later on you’re working on Javascript or whatever. The concepts and the methods and the details could easily start to get forgotten if you’re not regularly reviewing and practicing things you studied in the past.

• Anki as the cornerstone for spaced repetition

As evidenced by the large number of cards in my Anki deck, Anki occupies a central place in my strategy to outsource the need to worry about reviews and recall over the long-term. If there’s something I want to be able to recall a year from now and it’s not something I’m using literally every day or two, then it’s going to end up in Anki.

An important note, though: learn the material FIRST, before adding it to Anki. I’ve learned this the hard way in the past; if you don’t learn it before adding to Anki, you’ll find Anki becomes slow and filled with a sense of drudgery. It’s also inefficient to group those two very separate tasks into a single moment at the point where you’re reviewing a card.

The great thing about Anki is that as a particular fact passes from your short term memory to your long-term memory, the need for reviews becomes less frequent, so you’ll see it less often. Trust the spaced repetition algorithm. It knows what it’s doing.

• Explain a concept out loud

This overlaps with the Feynman technique (see above). You can do this on your own, or to a friend / captive audience. Doing this with people who are much older or younger than you can be instructive as to whether you actually understand a particular topic.

I sometimes build this in as part of my Anki studies. I’ll have a card where the front says “What is [concept x or whatever]? Try explaining it out loud.” Then I’ll either find someone to do this with or I’ll just do it myself. Then on the back of the card it’ll either have a small list of key sub-concepts to make sure I got it right or it’ll say “Go look at your notes to confirm that you covered everything important”. This way I’m getting prompts to review old material, but they’re reoccurring at regular enough intervals that I don’t have to worry about having to do this too often.

• Keep Ruby / other fundamentals sharp

People in the forums mentioned that when they moved on to Javascript or other parts of the course, they found their Ruby skills starting to atrophy. Many said they wished they’d been more formal about reviewing old materials and keeping those skills fresh.

I think this is best solved by doing regular code challenge exercises as provided by sites like those listed above. I’ll use Beeminder to keep me honest and doing at least one or two every few days.

• Review old materials

People suggested that roughly 20% of your weekly study time should be devoted to reviewing old materials. I wonder if that’s a little high, but for me that might translate to keeping a solid hour or two on Saturdays for review of those old materials. And by review I mainly mean active recall using some of the techniques mentioned above, and then reading through notes to confirm whether I still knew something or not.

Getting Stuck

This is where I struggle the most with coding — the mental game of failure. But having a process to deal with those moments — because they will come — addresses a good chunk of the issue when it comes to getting stuck. The following are possible options for working through it, as suggested by fellow students / instructors:

• Read the error messages thoroughly
• First try it with pseudocode
• Solve problems on your own before looking at solutions or asking others for help. (If you can’t solve it, and depending on the size of the problem, still don’t look at the solution until a day or two has passed).
• Use the rubber ducky method of talking through a problem. (This can be translated to writing as well, where just the act of writing up where you’re stuck can often be enough to get you unstuck)
• Don’t cheat yourself of the opportunity to learn if the problem is difficult. Work through it and take your time.
• Use the PEDAC system / process

Community

Everyone studying at Launch School is doing so remotely. We’re all scattered around the world, but doing thing with others can be really helpful with motivation. I don’t always find it the most time-efficient way of studying, but working with others in a structured manner seems to be strongly recommended by posters in the forums. For me I think this will take two forms: attending the group study sessions appropriate to my particular level, and interacting with discussions on the forums and Slack channel.

I might supplement this with ad hoc study groups depending on my need for that during assessment preparation. At any rate, there seems to be a good deal of opportunity for that kind of thing among fellow students.

Habits / Meta-Structure

A lot of this comes under the rough category of ‘life fundamentals’. Most shouldn’t need too much explanation.

• Stop using / viewing social media or meaningless input — for me that’s Twitter and YouTube. I have turned this off completely outside specific windows.
• No email — I also have email turned off everywhere except outside certain windows. On my phone, I’ve set it up that I don’t have access to IMAP mail via apps or the standard ‘Mail’ app, but I am able to send mails through SMTP email.
• Be careful with caffeine / tea — I don’t drink coffee, but some varieties of tea cause me to get a little too edgy and scatter-brained. So this is just a reminder to be conscious of that and always err on the side of caution. Also, periodically taking 1-3 weeks completely without caffeine (as with salt) allows me to reset my baseline, needing less to cause the stimulating effect it has.
• Keep the house / room clean
• Go for a walk every day
• Exercise — do it.
• Sleep — this is maybe the most important item in this entire post for me.

Scheduling Study / Core Routine

• Study Every Day

I try to study a minimum of two hours every day on average, moving up to a stretch goal of three or four if I am able. This allows me to make meaningful progress in my studies. Ideally, I try to have at least one day / week which is a 3-4 hour uninterrupted slot. But probably four hours is my maximum when it comes to focused, productive work.

• Pick a sustainable pace

I could probably do a few days of full-on / flat-out work, but eventually I’d burn out. The trick here is to do enough that you can always work the next day. This means not working from a place of exuberance or excitement. Learning and coding doesn’t have to be high-octane. That doesn’t mean it can’t be enjoyable or satisfying, needless to say.

This means starting with reasonable weekly hours and slowly increasing them rather than jumping straight into an intense pace of 5 hours a day, let’s say.

For me, this initially looked like starting with 15 hours per week and I’m currently at around 18. Reaching somewhere around 25-30 would be my ideal, but I have to listen to how my mind and body responds, and have to balance other work to support (read: pay for) this course of study.

• Create a routine / habit around Launch School study

For me, this means having my studies as the first thing I do in the day. I want to give it the time when I’m at my best during the day, so that means first thing in my morning. I potter around for 30-60 minutes after getting up, and then I immediately start work on my studies.

• Block things

I covered this above a little, but basically for me it means using tools like Freedom and Focus apps to keep me honest and not distracted. I’m fairly good about using these tools, but not always and it’s easy to notice the difference.

• Take breaks

I usually segment my studies with inbuilt short breaks. These can be anywhere from 5-10 minutes and I try to get up, stretch or do some kind of physical exercise / movement. For Macs, the Move! app is a great utility. I like to take somewhere between one and two breaks per hour on average.

• Think about posture early on

This is something which I haven’t thought too much about, but people on the Launch School slack channel and elsewhere have suggested it’s important. If you’re going to spend hours behind some sort of laptop, getting posture and ergonomics right seems like a good thing to aim for. I’ve had good experiences with the Ninja Standing Desk (sadly not being produced any more, it seems!) though I don’t currently have it with me. This is something to return to in a few months.

• Take a day off

I take one day off each week which is for non-tech things, or family or friends. This is usually Saturdays for me but not always. I turn off phones and laptops and don’t let myself use them for the whole twenty-four hour period. I sometimes lose this habit when I have too many things going on and am overcommitted — witness that I’m currently writing this blogpost on my supposedly sacred Saturday ‘day off’ — but in any given year I’ll stick to it perhaps 80% of the time. The more I work on Launch School the more I’m reminded that it’s a good thing to disconnect from digital input and reconnect with the world around me.

• A routine for the end of the day

Currently the two key parts to this involve writing down what’s coming up tomorrow and where to start with them. It also includes making my environment conducive to just starting work the next day — i.e. cleaning my desk.

Using Ruby's .zip method to combine arrays

In Ruby, zip is a way to combine elements from two different arrays, albeit in a way that is slightly difficult to understand at first glance.

The documentation is a bit opaque, at least to my eyes, and the examples given take a bit of time to get your head around.

Let’s say you had an array of fruits that you wanted to distribute to your friends. You’re organised, so you have a list of your friends as well.

fruits = ["mango", "orange", "pomegranate"]
friends = ["Rob", "Mary", "Holly"]

Using multiple methods and loops, it’d be fairly trivial to conjure up something to combine these two into a new array, but luckily for us .zip exists to save the day.

friends.zip(fruits)

will return:

[["Rob", "mango"], ["Mary", "orange"], ["Holly", "pomegranate"]]

This way everyone will know what fruit they’re getting.

Note that if one of the two arrays is longer / shorter than the other, the missing space(s) will be filled with nil values.

RaspberryLPIC: A New Series & Setup Steps

I mentioned in my last post that I hoped to move on to the LPIC-1 exam in the coming weeks. I’m going through a bit of flux in terms of my stable laptop setup at the moment and I wanted a bit of stability as I work my way through the course. The idea suggested itself to me: what if I work through the syllabus using a Raspberry Pi?

I have a few Raspberry Pi 3 and Zeros lying around the house, so I’ve chosen the latest model I have — a model B version 1.2. I can SSH into the device over wifi regardless of whatever laptop I’m using at the time.

I’m choosing to use a Raspberry Pi for a few reasons:

• I want something that feels (and is) ‘disposable’ — if I make some mistake in my settings, I can install everything from scratch fairly trivially
• I didn’t want to do it on a virtual machine because sometimes this can behave idiosyncratically and I wanted something as close to an ‘authentic’ Linux experience as possible.
• I didn’t want to use a server from a cloud hosting provider since a dedicated server running online is probably overkill for what I need. You can get cheaper if you’re just using part of a server (via some virtualised service etc) but that seemed likely to provide non-standard output.
• I wanted to plug and play bits of hardware as part of my studies. That’s obviously not possible on a cloud server, and can provide non-standard responses when done through a virtual machine.
• I didn’t just want to install Linux on a spare laptop since I don’t have one of those lying around where I currently am. If I break anything, moreover, the installation / reformatting process and so on takes much longer than just flashing a SD card for a Raspberry Pi.

The hardware is pretty decent on the model I’m using, at least for the purposes of the LPIC-1 exam. This seems like an ideal use case.

Once again, I’m following through using the Linux Academy’s video lectures. As far as I understand things, the LPIC-1 exam requires more than just passing familiarity with a few commands. For that reason, I’m using a few supplementary books. Once I’ve gone through both books and videos I’ll be testing myself with practice exams.

Yesterday I spent a few hours trying to get my base setup installed on the Raspberry Pi. I started with an ambitious plan to install the version of Arch developed for use on a Raspberry Pi 3 (i.e. this version of an ARM chip) but it ended up being somewhat non-trivial. I ended up breaking Pacman (the Arch package installer) and unable to install any new software or update the system.

I realised that Arch probably wasn’t the ideal setup for this experiment in any case. The default Raspbian distro, based on Debian Wheezy, seemed a better option. Flashing that onto my SD card and getting a headless copy up and running was easy.

I might take a short detour before diving into the LPIC course proper by working my way through the Linux From Scratch series. I figure I’ll learn some useful things in that process of building my own custom kernel / distribution that I can then build on through the LPIC-1 syllabus. But I haven’t fully decided on that path yet.

In Afghanistan, watching someone learn to code for the first time

I recently had the opportunity to observe how a total newcomer to coding / computer programming starts their learning journey. She was embarking on this journey in Kabul, which brings some special considerations that I thought I’d outline here.

First off, coding in Afghanistan? I actually happen to think it’s not the worst thing someone could do with their time. Power outages and internet costs, while better than they were in previous years, still make the prospect of spending hundreds of hours learning skills a precarious proposition. (Outside Kabul, just to give some context, even big cities like Kandahar are starved of electricity. When I was down there recently we had a couple of hours per day at best.) But all that to one side, there’s a need for skilled professionals in the computer science / engineering world and there seems to be a decent amount of room for remote work. (Note that there’s some debate about the extent of the shortage but I don’t think it’s getting ahead of myself to suggest that proficiency in computer science will be a valuable skill in the years to come.)

If you are going through university in Afghanistan you’re teaching yourself anyway, to some extent. The quality of the tuition — even in some of the private universities — isn’t great and the job market doesn’t reward degree certificates; it rewards competency, something which you aren’t necessarily going to get from a degree / certificate. To use some of the free resources available online would seem like a smart option. Worst case, you make yourself a little more employable because you took some initiative and have skills to contribute to a new employer. Another scenario is that you have some skills you can market around the world, all from the convenience of your home.

All of this requires English. It’s an unfortunate fact that there really is no way round learning English if you want to teach yourself computer science skills. There are ways round it, especially at the beginning, but if you’re going to progress you’ll really have to have a decent level of competency at understanding technical documents / tutorials and the like. I wish it was otherwise, but that isn’t changing any time soon.

I wanted to recommend my friend learn via some resource that was at least partly in her native language, Dari / Persian. After all the fanfare of recent years about how young people are learning how to code around the world in a variety of languages, I was a bit disappointed at the options available. For Dari, there were basically no options. One site, code.org, had some initial courses that had been translated into Persian, but it was the Iranian version / dialect and this caused some problems in comprehending the instructions later on. Worse still, the courses were only half-translated. Videos in between units were in fast idiomatic English, with scenes and situations that seemed representative of some alien universe. Yes, it’s nice that Bill Gates was there to explain how variables work, but first let’s slow down and explain what a variable is, preferably without flashy graphics that don’t actually explain the topic.

There were various assumptions made about students’ experience and skills in mathematics. Early units in the code.org syllabus expect you to understand basic geometry and some algebra. I guess you have to start somewhere, but I wish there were ways of teaching this starting from an earlier baseline of understanding.

I had initially thought that a good way to get my friend thinking about some of the bigger issues would be to have her use a Raspberry Pi and handle some basic Linux administration but that ended up being too many new things at one time. Some of the much-vaunted tropes about learning to code really don’t make much sense.

One other practical problem turned out to be that code.org is a data-hog. My friend ended up having to spend a non-trivial amount of money recharging her 4G phone (from which to tether her laptop) because code.org used fancy javascript animations and who knows what else. I feel like this is a serious symptom of a blind spot in Silicon Valley’s efforts at some kind of cultural imperialism. They can’t imagine themselves into the shoes of a nascent coder, so they produce these bloated websites that mean that while someone can maybe code for an hour or two using fancy javascript animations, maybe they won’t be able to afford the hundreds of hours that it takes to become competent.

I feel like better skills to teach at this level are more fundamental: how do you figure out the answer to a problem? how do you solve problems in general? This is actually the real skill that you want someone to master, not whether they can get a turtle to draw a circle in 4 colours, and this skill is not taught at all in these courses. (A corollary: how do you find good / worthwhile problems? or how do you figure out what things are worth working on? None of this is taught at all).

The kind of education provided by sites like code.org gets it backward. In this way of seeing the world, you can get busy ‘learning to code’ but it won’t necessarily fit into your life and you can’t really make real progress without other external guidance and support. The dream of universal education for a young person in somewhere like Afghanistan, delivered by these kinds of programmes, seems more smoke and mirrors than a real ladder towards education and real skills.

Using Regex with Python to Find Strings

The next step in my data processing project is to find strings matching certain patterns in the PDF data. Today I worked my way through the relevant chapter (#7) of Al Sweigart's excellent / useful Automate the Boring Stuff with Python.

I've left some sample code above as a reminder (mainly for myself) of the basic pattern / syntax that you can use. I saw a slightly more concise pattern for running the search in Data Wrangling with Python; I may experiment with that in the future. That has you running something like:

search_result = re.search(word, fulltext)

I guess one of them will have a speed advantage, especially when multiplied over hundreds of thousands of pieces of text.

The next step with this project will be to connect this regex function with the splitting file. That way when I split the file, I can rename the file at the same time with a string that I've extracted using a regex search.

If you've reached this far and you don't know what I'm talking about, there's an interesting article by Cory Doctorow where he argues that regular expressions should probably be taught as a foundational skill to children:

Knowing regexp can mean the difference between solving a problem in three steps and solving it in 3,000 steps. When you're a nerd, you forget that the problems you solve with a couple keystrokes can take other people days of tedious, error-prone work to slog through.

Python Virtual Environments, Testing Environments and Markdown Strikethrough

I spent part of this afternoon fixing things in my PDF splitter code.

• I learnt about virtual environments and the various choices available in Python. This was the most useful overview. I ended up choosing pipenv which is also outlined here. It installs a Pipfile in your directory which is an equivalent to the old requirements.txt that was previously used. This means that whenever you use pip to install a new package, it’ll remember and update the file accordingly.
• For testing, I ended up holding off for the moment. It wasn’t immediately apparent which of the various testing suites I should be using and the examples given in places like this used strange syntax. I’ll have to tackle this later, but for now I’m putting it on hold.
• I learnt that you can make some text strikethrough (EXAMPLE) in Markdown by enclosing the text in two tildes (~~).
• I read about application layouts / structures and made some initial decisions about what files to include in my project. Some of this is overkill for where I am currently, but soon enough this project will expand and I’ll need a standard structure format.

Tomorrow I want to start working on my regex search-and-rename function. I’ll start by figuring out the right regex string to use for my search, then I’ll figure out how to add in re.search into my script.

Real-World Go with Referenced Functions

Writing small test scenarios and packages in the Go Playground, or in a single main.go file is all good and well, but in the real world things are more complex. (Or so I heard).

Today I wanted to get a brief sense of how that all works. I had some sense of how to make this all work when working through the GreaterCommons course, but it proved harder when the training wheels were taken away.

This is what I emerged with at the end of my experiments. It is a main.go file that references extended.go. This ended up being dependent on knowing a bunch of setup quirks and techniques that aren’t particularly well signposted for beginners. I ended up finding a tremendously helpful document on the main Go site entitled “How to Write Go Code”. They don’t signpost it much, especially when compared to ‘Effective Go’ or the general specification.

I worked my way through the official examples. Luckily they were simple enough that I could follow all of the logic. Everything was incrementally constructed, slowly becoming more complex. I learnt the following:

• it’s best to setup your workspace in $GOPATH/src/github.com/YOURUSERNAMEGOESHERE
• every time I initialise a GitHub repository on my computer (rather than creating it at GitHub.com and then simply cloning it down to my computer) I have to relearn all the little commands relevant to making that work when pushing up to Github. (It’s sufficiently fiddly and reminiscent of using PGP. Lots of small moving parts and room for error. Big space for improving that user experience…).
• if you use the path listed above as your workspace, you can reference your other folders fairly easily. See my code for examples of that.
• The packages you’re referencing (i.e. not in the central main.go file) can be called anything you’d like, as can the file names. If you want to make the functions in those packages globally visible, however, make sure the functions start with a capital letter. (In my example, I have extended.Extended).

I am already demonstrating some sloppy habits with my documentation, tests, benchmarks and examples, I realise. For these kinds of toy demonstration examples it is less mission-critical, but there feels like a vague principle at stake.

My next Go exploration project will probably be the final version of an Exercism exercise I’ve been working on for a while.

Table Tests in Go

Today I wanted to stretch my use of test scenarios with Go. The example I described a couple of days ago basically had me running individual tests for specific values. What I wanted was a way to test a bunch of different values for the same function. Enter: table tests.

You can see the code I ended up with partly in the image above but also on Github here. It took a while to get there.

I started with some notes I’d taken during Todd McLeod’s excellent GreaterCommons Go course. Those notes were enough to get a framework up and running. I understood the principle: you create a struct to store all the different values, loop over them all to check whether the test fails in any particular scenario.

When I ran go fmt at the end to format my code, it gave me an error as it refused to build:

View fullsize

I could see that it wanted two ints and I was giving it a slice of ints. Basically this turned into a hunt for fixing my loop and which values I was spitting out at various iterations of the loop.

I ended up isolating the part of the code that was causing the problems, putting it up on the Go Playground so as to isolate exactly what was going wrong. Once I’d figured out exactly how to handle the loop, I could then bring that logic back into my main_test.go file.

Now I know how implement table tests in Go. My next exploration will be around functions that aren’t located in the same file. So far I’ve been mainly using the same main.go file for all the code I’ve written, but a step up in the complexity will be to interact with different files.