Author: mattchung

  • Squeezing the most out of your study sessions (midterm and final exam preparation)

    Squeezing the most out of your study sessions (midterm and final exam preparation)

    Why publish my studying techniques?

    This semester, I manage to pull off an A not only for the midterm and final exams, but for the class as a whole. My intention of revealing my grade is not to boast (that’s poor taste), but to give some credibility to the techniques and strategies below, techniques and strategies (rooted in pedagogy) for someone who is working full time, someone who is is growing as a (freshly minted) father and husband, someone who pursues a wide array of other interests outside of graduate school. That being said, receiving the highest letter grade is not my goal in the program (although I admit it once was). My goal is to learn as much as I can, absorb as much computer science, connect the dots between all the other classes, bridge the gap between theory and practice, and apply the knowledge to my job as a software engineer.

    Exam logistics

    Assumptions

    This blog post assumes that you can openly collaborate with other students. During my term (Fall 2020), us students shared our answers using a two pronged approach: studying with one another over Zoom (see my post on War Rooms) and comparing answers in a shared Google Document. Crowd source at its finest.

    Time Bound

    You have up to 3 days to take exams. And before the exam window opens, the study guides (i.e. all the previous exams bundled up in a .zip file) are published. That’s about a week for you to prepare. And once the exam window opens, the professor and teacher assistants publish the actual exam. That’s right: they provide all the questions (even then, the exam is no walk in the park). In other words, you walk into the exam with no surprises, knowing exactly what questions to expect.

    Spaced repetition

    To make the most use out of my time bounded study sessions, I apply three techniques rooted in research: forgetting curve, spacing effect, and testing effect (check out a paper I wrote titled “An argument for a spaced repetition standard”).

    Put simply, instead of one massive, multi-hour study session, I break down the study sessions into a fistful of sessions, around five to ten, and spread the sessions across multiple days (i.e. “spaced repetition”), each session lasting anywhere between 10-20 minutes. During each study session, I test myself (i.e. “testing effect”) and try to answer questions just as I’m about to forget them (i.e. “forgetting curve”). With this approach, I optimize memory retention for both short and long term. This technique aligns with what Bacon stated back in 1620:

    “If you read a piece of text through twenty times, you will not learn it by heart so easily as if you read it ten times while attempting to recite from time to time and consulting the text when your memory fails”.

    Studying previous exams

    Here’s how I study previous exams.

    First, I create a blank page in Google Docs. Then, I select one of the previous exams (only one because of time constraints) and copy all of its questions into this blank document. Next, I attempt to answer each question on my own: no peeking at the solution guide! This is how I test myself.

    My google doc sheet

    After answering each question, I compare my guess — sometimes it is way off — with the answer printed in the answer sheet. If my answer is incorrect, I then copy the correct answer, word by word, below my original answer. The act of copying helps reinforces the right answer and positioning the two answers — mine and the correct one — next to each other helps me see the holes in my logic.

    I apply this circular technique — copy question, answer question, compare the two, copy correct answer — for each question listed in the exam. Bear in mind that I apply this circular technique only once. Repetition will come in later when I study the actual final exam.

    Studying final exam

    Studying for the final exam approach closely resembles my circular technique (describe previously). The main difference is this: instead of only making a single pass through the questions, I make two passes. The first pass is the same (described above) circular technique of copying each questions and taking a stab at them. In the second pass, I review my answers against the collaborated google docs, where all the other students dump their answers.

    Collaborated Google Doc study guide

    Once my answer guide — not the collaborated Google Docs — is filled out with (hopefully) the right answers, I then the contents into my space repetition software: Anki. After copying, I simply rote memorize, drilling each questions into my head until I stop answering incorrectly, which normally takes about an hour in total, spread across 2 days.
    Finally, after the spaced repetition sessions using Anki, with the contents of the exam sitting fresh in my working memory, I take the exam and simply brain dump my answers.

    Using Anki to study for exam

    References

    https://blog.mattchung.me/2020/09/27/my-anki-settings-for-cramming-for-an-exam/

     

  • Neil Strauss’s 3 pass writing technique

    Neil Strauss’s 3 pass writing technique

    Three passes

    World class writers sit down and pour out beautiful prose in a single sitting, right? That’s the image I image I held in mind for many years and this belief is not only far from the truth but this belief crippled me as a writer. I would sit down to type and proceed to write at glacial speed, spending more time watching the cursor blink. But over many many years of reading about writers and reading about the craft of writing, I learned the truth: that the best of writers make multiple passes at their writing.

    Recently, Neil Strauss shared his creative writing process in his weekly newsletter and he suggests breaking down the writing into three discrete passes. Each pass serves a different purpose. They differ in modes of thinking and vary in speed of execution.

    • Second pass – edit and keep your reader/audience in mind
    • Third pass – scrutinize your work

    Get it all out … as quickly as possible

    One of the most common mistakes is trying to write everything perfectly. As if each word was being etched in stone, or going straight to print.

    During this first pass, you aim for banging out the writing — as fast as possible. Your goal is NOT perfection. Your goal is to brain dump and clear your working memory. You want to generate a mountain of writing that you can, in the subsequent phases, chisel and shape and smooth out. And don’t fear: you never show this writing to anyone (unless you want to, of course). This first draft is for your eyes, and your eyes only.

    Think about your reader

    This is where you start sculpting the clay of your book. You see the book not through your ego, which wanted to write the book, but through an ideal reader’s eyes.

    Now that a heap of writing sits in front of you, what next? You shift your mode of thinking. In the previous pass, you were writing for yourself. But now, center your attention towards your audience. Try and view the writing from their perspective. Consider the clutter. Consider where you are losing their attention. Consider the reader and be prepared to toss out entire sentences — or even sections.

    Welcome the haters

    Note that hater-proofing isn’t just anticipating their arguments and defusing them ahead of time, but also checking to make sure your facts, research, and even spellings are correct. And your arguments are correct and unassailable.

    Once you’ve consider your reader, you now put yourself in the position of your hater, your worst enemy. This is the time for you to really scrutinize your work, to find any chinks in your armor. This is the phase in which you get to play devil’s advocate. Basically, imagine stepping into the ring and boxing with a logical opponent, someone trying to poke holes in your writing, someone trying to expose you as a fraud. Anticipate the punches and tackle them head on.

    Summary

    Ultimately, the three phases creates some structure and within that structure lives creative freedom. And again, each phase serves a different purpose. At the beginning, you want to be your biggest cheerleader, rooting for yourself. Then, towards the end, you transition into your toughest critic.

  • Giant Scale Services – Summary and notes

    Giant Scale Services – Summary and notes

    Introduction

    We’ll address some questions like “how to program big data systems” and how to “store and disseminate content on the web in scalable manners”

    Quiz: Giant Scale Services

    Basically almost every service is backed by “Giant Scale” services

    Tablet Introduction

    This lesson covers three issues: system issues in giant scale services, programming models for applications working on big data and content distribution networks

    Generic Service Model of Giant Scale Services

    Generic Service Model of Giant Scale Services – Source: Udacity Advanced OS Course

    Key Words: partial failures, state

    A load manager sits between clients and the back end services and is responsible for hiding partial failures by observing state of the servers

    Clusters as workhorses

    Clusters as workhorses – Source: Udacity Advanced OS Course

    Key Words: SMP, backplane, computational clusters

    Treat each node in the cluster as the same, connecting the nodes via a high performance backplane. This strategy offers advantages, allowing easy horizontal scaling, making it easy for a systems administrator manage the load and system

    Load Management Choices

    Load Management Choices – Source: Udacity Advanced OS Course

    Key Words: OSI, application layer

    The higher the layer in which you construct the load manager, the more functionality you can have

    Load management at the network level

    Load Management at the network level – Source: Udacity Advanced OS Course

    Key Words: DNS, semantics, partition

    We can use DNS to load balancer traffic, but this approach does not hide server failures well. By moving up the stack, and performing balancing at the transport layer, we can balance traffic based off of service

    DQ Principle

    DQ Principle – Source: Udacity Advanced OS Course

    Key Words: DF (full data set), corpus of data, harvest (D), yield

    We’re getting a bit more formal here. Basically, there are two ratios: Q (yield) and D (harvest). Q’s formula is Qc (completed requests)/ Q0 (offered load). Ideally want this ratio to be 1, which means all client requests were serviced. For D (harvest), formula is Dv (available data) / DF (full data). Again, want this ratio to be 1 meaning all data available to service client request

    DQ Principle (continued)

     

    Key Words: IOPS, metrics, uptime, assumptions, MTTR, MTBF, corpus of data, DQ

    DQ principle very powerful, helps architect the system. We can increase harvest (data), but keep the yield the same. Increase the yield, but keeping D constant. Also, we can track several metrics including uptime, which is a ration between MTBF (mean time between failures) and MTTR (mean time to repair). Ideally, this ratio is 1 (but probably improbable). Finally, these knobs that a systems administrator can tweak assumes that the system is network bound, not IO bound

    Replication vs Partitioning

    Replication vs Partioning – Source: Udacity Advanced OS Course

    Key Words: replication, corpus of data, fidelity, strategy, saturation policy

    DQ is independent of replication or partioning. And beyond a certain point, replication is preferred (from user’s perspective). During replication, harvest data is unaffected but yield decreases. Meaning, some users fail for some amount of time

    Graceful Degradation

    Graceful Degradation – Source: Udacity Advanced OS Course

    Key Words: harvest, fidelity, saturation, DQ, cost based admission control, value based admission control, reduce data freshness

    DQ provides an explicit strategy for handling saturation. The technique allows the systems administrator to tweak the fidelity, or the yield. Do we want to continue servicing all customers, with degraded performance … or do we want to, once DQ limit is reached, service existing clients with 100% fidelity

    Online Evolution and Growth

    Online evolution and growth – Source: Udacity Advanced OS Course

    Key Words: diurmal server property

    Two approaches for deploying software on large scale systems: fast and rolling. With fast deployment, services are upgraded off peak, all nodes down at once. Then there’s a rolling upgrade, in which the duration is longer than a fast deployment, but keeps the service available

    Online evolution and growth (continued)

    Online evolution and growth – Source: Udacity Advanced OS Course

    Key Words: DQ, big flip, rolling, fast

    With a big flip, half the nodes are down, the total DQ down by half for U units of time

    Conclusion

    DQ is a tool for system designers to optimize for yield or for harvest. Also helps designer deal with load saturation, failed, or upgrades are planned

  • Free E-book: Advanced operating systems (AOS) refresher course – summary and study guide

    Free E-book: Advanced operating systems (AOS) refresher course – summary and study guide

    Click here to download “Advanced OS refresher course – summary and study guide”

    I compiled my various blog posts from the advanced operating systems refresher course and bundled them together into a nicely packed e-book. So, if you are about to enroll in Georgia Tech’s advanced operating system course (AOS) and want to step through the refresher material (without sitting through and watching the entire lecture series) or just get a sense of whether you can skip the refresher course all together, then definitely check out the e-book above.

  • Failure: I want more of it.

    Failure: I want more of it.

    Students in the Georgia Tech program collaborate with one another — and collaborate with professors and teacher assistants — through a platform called Piazza. But at the end of the semester, this forum shuts off to read only mode, meaning we all lose connection with one another.

    Because of this, I recently created an e-mail list called computing-systems@omscs-social.com for other Georgia Tech Students who are interested in staying in touch. The motivation behind the mailing list is to share job opportunities, connect with other working professionals, and perhaps most important: provide peer support for one another. This felt like a natural next step since the study sessions (called “war rooms”) that I hosted were pretty successful.

    Piazza post. 70 views. 1 sign up

    But after posting a link on Piazza and sharing the idea, only 1 out of 70 people signed up. Total failure, right?

    Sort of.

    The lack of people signing up for the mailing list reaffirms two of my believes. First, the entire notion of “build it and they will come” is not true. Especially as software developers, we know that we can build the most shiny, most magical, most performant piece of software … and nobody can care.

    The second belief is that failures are a good thing. According to the late Randy Pausch, these setbacks are what we likes to call brick walls:

    The brick walls are there for a reason. The brick walls are not there to keep us out. The brick walls are there to give us a chance to show how badly we want something. Because the brick walls are there to stop the people who don’t want it badly enough. They’re there to stop the other people.

    – Randy Pausch

    In order to grow, you need to fail — a lot — because there’s no linear path to success.

    You can see this pattern of trial and error with Josh Pigard’s most recent venture that he recently sold for $4 million: big success, right? Yes, definitely.

    But notice all his other failed projects listed on his personal website.

    Josh Pigard – projects that were shut down

    On some level, the above are considered failures since the projects ultimately shut down. But that’s not how I see it. I’d like to think that Josh learned a lot of things from those failures, which fed and led him to building and selling his company.

    From this example alone, I think I can take away a lot of lessons learned. In particular, like my wife,  I am a perfectionist. I want — sometimes need — things to be perfect. But that’s surface level, only what maybe the outside can see. There’s a shadow side.

    Really, like many others, I have imposter syndrome. I’m constantly worried that I’m going to get exposed as some sham. My response to imposter syndrome? Striving to be right all the time. And I believe that taken too far, trying to be right all the time can stunt growth because to grow — personally and professionally — I need to constantly be experimenting, tinkering, trying out things that might just fail.

    To wrap things up: will I shut down and abandon the mailing list? Maybe. Maybe not.

     

  • Enterprise Java Beans – notes and summary

    Enterprise Java Beans – notes and summary

    Introduction

    Key Words: EJB, enterprise java beans

    Discuss how we can structure system software for large scale distributed sytem service

    Inter Enterprise View

    Inter Enterprise View: The motivation of using enterprise java beans

    Key Words: monolithic, supply chain model, amalgam, survivability, complexity

    From a user perspective, we view a system (like Ebay or Google) as a blackbox. But in reality, much more complex than that and within the system, there may be multiple enterprise working together and this can be difficult when trying to handle failures, complexity, and so on

    An Example

    Key Words: scheduling, parallel systems, synchronization, communication, atomicity, concurrency, object technology, reuse

    Using a system like Expedia, we face same issues in parallel systems like synchronization and concurrency and scheduling and atomicity and so on

    N-tier applications

    N tier applications

    Key Words: concurrency, parallelism, embarrassingly parallel applications

    Want to reduce network communication (latency), security (for users) by not compromising business logic, and increase concurrency

    Structuring N Tier Applications

    Structuring N tier applications

    Key Words: JEE, protection domain, bean

    We can split the protection domain uses containers, at the client or at the presentation layer, business layer or database layer. Each container contains N beans, bundle of java objects

    Design alternative (Coarsegrain session beans)

    Coarse grain approach. Although this approach protects business logic from outside network, fails to expose concurrency at the EJB container.

    Key Words: monolithic, concurrency

    Each session bean is very granular, the session bean encapsulating most of the logic. The upshot of this approach is that the container offers little service and the logic is not exposed outside the corporate network. The downside is that we do not exploit concurrency. There’s a missed opportunity where the EJB container and pull in data for multiple sessions

    Design Alternative

    Key Words: trade offs, persistent, bean managed persistence, container managed persistence, data access object

    With data access object design, we confront the short comings of the coarse grain session bean, by exploiting concurrency for data access, limiting I/O and network latency when accessing the database. The trade off? Business logic is exposed to the web container

    Design alternative (session bean with entity bean)

    Design alternative: session bean with entity bean. Hybrid approach of coarse grain and data access object.

    Key Words: session facade, design pattern, remote interface, RMI

    We now embed a session facade, that provides concurrency AND does not exposed business logic. To that end, we use RMI (remote interface) to communicate between the containers and/or between the session facade and entity bean

  • 30 different ways to write paragraphs – series introduction

    30 different ways to write paragraphs – series introduction

    This blog post is the first in the series on the different ways to write powerful paragraphs, inspired by Victor Pellgrino’s book “A writer’s guide to powerful paragraphs”.

    According to Victor Pelligrino, a paragraph is a unit of thought that expresses a single idea, communicated through related sentences. And although there are many ways to create powerful paragraphs, you must — first and foremost — identify your topic: “A topic sentence is the most important sentence in a paragraph. Sometimes referred to as a focus sentence, the topic sentence helps organize the paragraph by summarizing the information in the paragraph

    Put another way, the topic sentence is generally what your “paragraph is about.” That’s it.

    After identifying the main topic, your main goal is to fully develop that topic. You’ll want to anticipate your reader’s questions and answer them. And if, along the way, you discover your paragraph fails to satisfy those questions, then perhaps you need to better understand your subject: Take a step back from the actual writing and pivot.  Do some research.

    But most importantly, throughout the writing process, constantly keep the reader at the center of your mind. Ask yourself, “Who am I writing for … what do they know…. what do they NOT know”. Think about what assumptions you are making about your reader; more often than not, we assume too much of our reader and lose them along the way. We fail to fill in the missing gaps and we fail to logically link our thoughts, failing to use transitional phrases (or sentences).

    In summary, you’ll want to identify your topic, provide descriptions, arguments and examples (maybe one, perhaps two, sometimes even three).

  • Recovery management in Quicksilver  – Notes and Summary

    Recovery management in Quicksilver – Notes and Summary

    The original paper “Recovery management in quicksilver” introduces a transaction manager that’s responsible for managing servers and coordinates transactions. The below notes discusses how this operating system handles failures and how it makes recovery management a first class citizen.

    Cleaning up state orphan processes

    Cleaning up stale orphan processes

    Key Words: Ophaned, breadcrumbs, stateless

    In client/server systems, state gets created that may be orphaned, due to a process crash or some unexpected failure. Regardless, state (e.g. persistent data structures, network resources) need to be cleaned up

    Introduction

    Key Words: first class citizen, afterthought, quicksilver

    Quicksilver asks if we can make recovery a first class citizen since its so critical to the system

    Quiz Introduction

    Key Words: robust, performance

    Users want their cake and eat it too: they want both performance and robustness from failures. But is that possible?

    Quicksilver

    Key Words: orphaned, memory leaks

    IBM identified problems and researched this topic in the early 1980s

    Distributed System Structure

    Distributed System Structure

    Key Words: microkernel, performance, IPC, RPC

    A structure of multiple tiers allows extensibility while maintaining high performance

    Quicksilver System Architecture

    Quicksilver: system architecture

    Key Words: transaction manager

    Quicksilver is the first network operating system to propose transactions for recovery management. To that end, there’s a “Transaction Manager” available as a system service (implemented as a server process)

    IPC Fundamental to System Services

    IPC fundamental to system services

    Key Words: upcall, unix socket, service_q data structure, rpc, asynchronous, synchronous, semantics

    IPC is fundamental to building system services. And there are two ways to communicate with the service: synchronously (via an upcall) and asynchronously. Either, the center of this IPC communication is the service_q, which allows multiple servers to perform the body of work and allows multiple clients to enqueue their request

    Building Distributed IPC and X Actions

    Bundling Distributed IPC and Transactions

    Key Words: transaction, state, transaction link, transaction tree, IPC, atomicity, multi-site atomicity

    During a transaction, there is state that should be recoverable in the event of a failure. To this end, we build transactions (provided by the OS), the secret sauce for recovery management

    Transaction Management

    Transaction management
    Transaction management

    Key Words: transaction, shadow graph structure, tree, failure, transaction manager

    When a client requests a file, the client’s transaction manager becomes the owner (and root) of the transaction tree. Each of the other nodes are participants. However, since client is suspeptible to failing, ownership can be transferred to other participants, allowing the other participants to clean up the state in the event of a failure

    Distributed Transaction

    Key Words: IPC, failure, checkpoint records, checkpoint, termination

    Many types of failures are possible: connection failure, client failure, subordinate transaction manager failure. To handle these failures, transaction managers must periodically store the state of the node into a checkpoint record, which can be used for potential recovery

    Commit Initiated by Coordinator

    Commit initiated by Coordinator

    Key Words: Coordinator, two phase commit protocol

    Coordinator can send different types of messages down the tree (i.e. vote request, abort request, end commit/abort). These messages help clean up the state of the distributed system. For more complicated systems, like a file system, may need to implement a two phased commit protocol

    Upshot of Bundling IPC and Recovery

    Upshot of bundling IPC and Recovery

    Key Words: IPC, in memory logs, window of vulnerability, trade offs

    No extra communication needed for recovery: just ride on top of IPC. In other words, we have the breadcrumbs and the transaction manager data, which can be recovered

    Implementation Notes

    Key Words: transaction manager, log force, persistent state, synchronous IO

    Need to careful about choosing mechanism available in OS since log force impacts performance heavily, since that requires synchronous IO

    Conclusion

    Key Words: Storage class memories

    Ideas in quicksilver are still present in contemporary systems today. The concepts made their way into LRVM (lightweight recoverable virtual machine) and in 2000, found resurgence in Texas operating system

  • Software craftsmanship: convey intent in your error codes

    Software craftsmanship: convey intent in your error codes

    ENOTSUP stands for “Error – not supported” and it is one of the many error codes defined in the error header file.

    I recently learned about this specific error code when reviewing a pull request that my colleague had submitted. His code review contained an outline — a skeleton — of how we envisioned laying out a new control plane process that would allow upcoming dataplane processes to integrate with.

    And he kept this initial revision very concise, only defining the signature of the functions and simply returning the error code ENOTSUP.

    The advice of returning relevant error codes applies not only to the C programming language, but applies to other languages too, like Python. But instead of error codes, you should instead raise specific Exceptions.

    Who cares

    So what’s so special about a one liner that returns this specific error code?

    Well, he could’ve instead added a comment and simply returned negative one (i.e. -1). That approach would’ve done the job just fine. But what I like about him returning a specific error code is that doing so conveys intent. It breathes meaning into the code. With that one liner, the reader (me and other developers on the team) immediately get a sense that that code will be replaced and filled in in future revisions.

    Example

    Say you are building a map reduce framework and in your design, you are going to spawn a thread for each of phases (e.g. map, reduce). And let’s also say you are working on this project with a partner, who is responsible for implementing the map part of the system. Leaving them a breadcrumb would be helpful:

    int worker_thread_do_map(uint32_t thread_id)
    {
    /* implement feature here and return valid error code */
        return -ENOTSUP;
    }
    
    int worker_thread_do_reduce(uint32_t thread_id)
    {
        return -ENOTSUP;
    }

    The take away

    The take away here is that we, as developers, should try and convey meaning and intent for the reader, the human sitting behind the computer. Cause we’re not just writing for our compiler and computer. We’re writing for our fellow craftsman.

  • 20s for education, 30s for experience, 40s for career.

    20s for education, 30s for experience, 40s for career.

    In my mid twenties, I was blessed to receive some of the best career, and quite frankly, life advice. During that period of my life, I was working as a director of technology, leading a small group of engineers. But I was getting ready to throw in the towel. I lacked both the experience and confidence needed. So I reached out to my friend Brian, asking him if he knew anyone who could help me with “executive coaching”. Thankfully, Brian connected me with a C level executive: let’s call him Phil (that’s actually his name).

    Prod, provoke, encourage

    When I met Phil at the Jerry’s Deli located in the valley, one of the first things he flat out told me was that executive coaching is bullshit. Despite that belief, he essentially coached me and gave me some sage advice that now I get to pass on.

    Seth Godin once stated that “About six times in my life, I have met somebody, who, in the moment, prodded me, provoked me, encouraged me, and something came out on the other side”.

    Phil is one of those 6 people in my life.

    The best career and life advice

    The sage advice is simple and sounds similar to Nic Haralambous’s advice “Plan in decades. Think in years. Work in months. Live in days”. But Phil’s advice offers a different perspective, another angle:

    20s for education. 30s for experience. 40s for career

    This advice stuck with me and helps me (re) calibrate my goals and values. Of course, life takes its own twists and turns. But as the Dwight Eisenhower said “Plans are worthless, but planning is everything”

    What does that look like in practice?

    20s for education is NOT synonymous with school. It really means soaking up as much as possible. This learning might take place in school but not exclusively. Because learning can happen anywhere and everywhere.

    Fail and fail a lot.

    For us tech folks, this might be learning a new programming language, dissecting the ins and outs of your compiler, picking up marketing or public speaking skills.

    The list goes on and on.

    30s for experience. This is where the rubber meets the road. Where theory and practice intersect. This may mean you want to switch roles (like how I switched from being a systems engineer to a software developer) or switch companies so that you can apply all that hard earned knowledge that you acquired in your twenties.

    Finally, 30s will feed into your 40s, where you get to establish your career. Maybe working for a small company, where you get to wear a bunch of hats. Maybe for a large corporation, where you hone in or specialize in a particular niche. Or maybe as an entrepreneur, building your own product or service.

    Now what?

    I’m actually revisiting these words of wisdom. Right now. For the last six months or so, I’ve been overly focused on an upcoming promotion from a mid to senior level engineer at Amazon. Instead of chasing this new title — cause that’s all it really is — I’d rather redirect my focus and make mistakes, stretch myself and find opportunities that put me in a uncomfortable (but growth inducing) experiences.