Michele Pratusevich, a pathological dilettante

Favorite Podcasts 2019-2021

2021-10-18T00:00:00+00:00

What is now becoming an annual tradition, here is my list of favorite podcasts from 2019-2021. See my past posts for comparison:

I’ve combined my 2019, 2020, and 2021 lists, since I (like many of us) was driving much much less, and therefore had less time to listen to podcasts. I didn’t particularly like this change of events (I really like podcasts!) but it meant I shifted my podcast focus a little bit.

This list is organized by category and annotated with average podcast length and a “seriousness scale.”

Stories / long form journalism:

This is by far my favorite kind of podcast format, tried and true. I devour this stuff, adding a few new podcasts in the regular mix from last year.

(40 minutes) serious Ear Hustle - This is the most unique podcast I’ve definitely heard. It is produced by an inmate in San Quentin prison in CA (together with Radiotopia) all about live in prison. Most of the episodes are serious, but they are absolutely riveting.
(40 minutes) casual Even The Rich - The various seasons take story arcs through the rich and powerful - what makes them tick, what is their downfall, what are their stories behind the scenes.

How the world works:

Who doesn’t love analysis of social behavior? This list is identical to last year’s - these podcasts are timeless, my absolute favorites.

(40 minutes) casual Freakonomics - From the authors of the popular book Freakonomics, they dive into why certain trends exist in the world from the perspective of economics. Very accessible to any audience, and I always come away learning something.
(20 minutes) casual Planet Money - Another NPR podcast talks about stories related to the economy, spending, or money, but tells it in an easy way that is engaging to listen to.
(30 minutes) serious Code Switch - Gene and Shereen from NPR take on race in America. They discuss various topics related to race, always respectfully, and always from the heart.
(30 minutes) serious Rough Translation - The host talks about foreign stories, told in the context of different cultures. You don’t hear these kinds of stories in American news!

Science and technology:

(20 minutes) casual Hidden Brain - An NPR podcast that talks about a human behavior phenomenon and attempts to explain it from the perspective of sociology, psychology, or neuroscience. The episodes are told in story format, and you come away thinking about how the episode might apply to your own life.
(30 minutes) casual The Pipeline: All Things CD & DevOps - I wanted to get a bit more knowledge into casual topics in CI/CD over the last year or so, and I found this podcast (by the Linux Foundation) engaging and interesting. Topics are varied, and there are often guest speakers with interesting ideas.

Home & Garden:

(10 minutes) casual Epic Gardening - Kevin the host talks excitedly about short topics related to home gardening. The topics are varied, and just short enough to keep up with almost daily!

Enjoy! What podcasts do you like?

Favorite Podcasts 2018-2019

2020-02-09T00:00:00+00:00

What is now becoming an annual tradition, here is my list of favorite podcasts from 2018-2019. See my 2016-2017 post and 2017-2018 post for comparison!

I am still driving to work, but less often now, so there are not too many additions to my classics from last year.

As usual, this list is organized by category and annotated with average podcast length and a “seriousness scale.”

I have listened to many podcasts and have wasted a few hours listening to some pretty bad ones. Here are some of my favorites - I hope you find something you’re looking for!

Stories / long form journalism:

This is by far my favorite kind of podcast format, tried and true. I devour this stuff, adding a few new podcasts in the regular mix from last year.

(40 minutes) serious Radiolab - When you think of long-from journalism and storytelling in audio form you think of Radiolab. In a single episode you will experience all emotions from rock bottom to giddy top, all through a single theme or story the hosts tell in a jam-packed 40 minutes. Not for the faint of heart - the topics they cover are often serious and will make you think.
(40 minutes) serious Ear Hustle - This is the most unique podcast I’ve definitely heard. It is produced by an inmate in San Quentin prison in CA (together with Radiotopia) all about live in prison. Most of the episodes are serious, but they are absolutely riveting.
(40 minutes) serious We Crashed: The Rise and Fall of WeWork - After WeWork went up in a firey ball of investor losses, Wondery made a podcast to explore exactly why. I love long-form journalism and storytelling, so this fits my style perfectly.
(40 minutes) serious Gangster Capitalism - An in-depth story about the college admission’s scandal from 2018 and the mastermind behind it, it is a serious story about rich families and college admissions. I personally was not satisfied with the ending, but the story was a great one to listen to.

How the world works:

Who doesn’t love analysis of social behavior? This list is identical to last year’s - these podcasts are timeless, my absolute favorites.

(40 minutes) casual Freakonomics - From the authors of the popular book Freakonomics, they dive into why certain trends exist in the world from the perspective of economics. Very accessible to any audience, and I always come away learning something.
(20 minutes) casual Planet Money - Another NPR podcast talks about stories related to the economy, spending, or money, but tells it in an easy way that is engaging to listen to.
(30 minutes) serious Code Switch - Gene and Shereen from NPR take on race in America. They discuss various topics related to race, always respectfully, and always from the heart.
(30 minutes) serious Rough Translation - The host talks about foreign stories, told in the context of different cultures. You don’t hear these kinds of stories in American news!

Science and technology:

(20 minutes) casual Hidden Brain - An NPR podcast that talks about a human behavior phenomenon and attempts to explain it from the perspective of sociology, psychology, or neuroscience. The episodes are told in story format, and you come away thinking about how the episode might apply to your own life.
(40 minutes) serious Reply All - This podcast claims to be about the internet. Really, it’s about interesting stories that are facilitated by the internet, discussing weird technological glitches, crowdsourcing miracles, memes, and much much more. The hosts are very entertaining, but I give this a serious rating because the topics discussed are often deep.

Food:

This is a new category added for 2018-2019. I’ve been getting more into cooking, food, and baking, and my podcast preferences reflect that.

(40 minutes) casual Savor - The two hosts love food, and talk about the history of food, where it comes from, and what is interesting about it. It combines trivia, history, and food - 3 of my favorite things. The two hosts also have a great rapport, and their banter makes things interesting!
(25 minutes) casual Inside Trader Joe’s - This is a branded podcast from Trader Joe’s talking about how they run their business. Good thing it’s centered around food! Trader Joe’s has a unique business model and a unique approach to food, so it combines business and food from the inside. Unlike other branded podcasts, this is NOT an advertisement for Trader Joe’s.

Enjoy! What podcasts do you like?

Lasercutter Memes

2019-04-18T00:00:00+00:00

I recently got trained on the lasercutter at Artisan’s Asylum and wanted to do a project! Thankfully, my friend Emilie had just the thing.

Memes

Memes (i.e. units of culture) have been on the internet for so long that some people are starting to print them out to share. I hear this is getting especially common in nursing homes or retirement communities, but I read that on the internet so I don’t know.

What we did instead was etch a meme instead of print it out! It took a few tries to get all the etched settings right, but it turned out great. This involved importing the PNG into Inkscape, tracing the bitmap, and cleaning it up to make a printable SVG.

The Final Product

Personally, I think it looks gorgeous:

Protecting Yourself Against rm

2018-10-26T00:00:00+00:00

Those who use the command-line on GNU/Linux operating systems know and love rm. But it also comes with so much power! No one wants to accidentally rm -rf the company data. To prevent myself from doing this on our data server, I aliased rm to something more sensible.

First, I created a shell script ~/are_you_sure_rm.sh in my home directory. The file was pretty simple:

#!/bin/bash

echo "You just tried to do rm.
If you really meant to do so, then type /bin/rm followed
by what you want to do. It will be unprotected.
It is recommended you do /bin/rm -i for interactive mode."

Next, I made it executable:

chmod +x ~/are_you_sure_rm.sh

Lastly, I added an alias for rm to the native shell by adding this line to my ~/.bash_aliases file.

# make sure to prompt on every removal of a file
alias rm="~/are_you_sure_rm.sh"

After logging out and back in, my new superpower is activated.

Now every time I try to rm something when SSHed into the company data server, my shell warns me! Amazing!

Why I Left Amazon

2018-09-03T00:00:00+00:00

Friday August 17, 2018 was my last day at Amazon Go as an Applied Research Scientist II. The following Monday August 20th, 2018 was my first day at my new job as Senior Machine Learning Engineer at Root.ai. Deciding to leave Amazon was not an easy decision, and I wanted to share my personal reasons for leaving Amazon, both for myself for the future and for others in similar situations.

There are many reasons to leave a job, but ultimately it boils down to one thing: are you running FROM something or running TO something? For me, the decision to leave Amazon was not because of anything at Amazon, but because of the opportunity I was given a chance to run towards. I was definitely running TOWARDS my new job at Root.

What I did at Amazon

I spent a total of 2.5 years at Amazon. I joined after working for almost a year at an ultimately unsuccessful startup. At the time, I wanted to cut my teeth at research, and a big company like Amazon was going to be a good place to take a risk on doing research; a startup simply didn’t have the luxury of taking a risk on a new engineer eager to do research. I was also looking for mentorship and a professional network - I wanted to see how things could be done well. So the leap of faith between me and Amazon was mutual; I was given the title Applied Research Scientist (after a few months of asking nicely) despite not having a PhD, and in return I was expected to do world-class research.

My primary responsibility was to invent new algorithms, techniques, and processes for understanding the world around us. As an applied research scientist (as opposed to just a plain old research scientist) I was also expected to take these new algorithms and apply them to problems faced by Amazon, which often meant collaborating with engineers to put the algorithms into production code. In practice, you really could only do one of those two things: you were either the researcher who couldn’t write code, or the coder who wasn’t great at research. My strength is adapting to the needs of the situation as they arise, and my strength to flow between doing and researching mode was not given a chance to flourish.

In my time at Amazon, I succeeded at my two primary goals: getting mentorship (check) and learning how research works at a big company (check). In the process, I have made professional connections that I will carry with me for years to come, and on the research side I got an ArXiV paper in the process.

Nagging Feeling

When I first took the job at Amazon, I did not know whether I would be the kind of person who climbs the corporate ladder and makes a corporate career at one place. Most of my peers from MIT did NOT follow this path, and honestly, that made me want to try it even more. My peer role models put startups and “working for yourself” on a pedestal, but I wanted to see for myself why that was the case. At 22 years old after my Master’s, I just didn’t know enough about the world to know what I wanted. So I did what any engineer would do: I experimented. In Amazon’s terms, I took a bias for action and went for it. I took the corporate job to see what it was like, learn what it means to do research in a corporate setting, and get mentorship for the future.

The offer I got from Amazon was very tempting: secret project out of a research group in the Boston area to work in a mixed hardware / software research problem with engineers and leaders at all levels. The pay was good, the benefits were better than the non-existent benefits I had at the startup before, and it hit my top-2 goal wish list. Besides, I had a good gut feeling about my would-be boss. And we all know that that’s often the most important thing. However, there were two big downsides:

I would have to commute 50+ minute by car one way. I didn’t own a car (easily fixable), and that was a LOT of lost time. I was not sure how important this was to me at the time.
I did not know what the project was. I did not find out what we were working on (back then it wasn’t even called Amazon Go) until my first day on the job.

The first issue, the commute, I thought would be outweighed by all the benefits of working at Amazon. For the better part of 2.5 years, I was right about that.

The second issue, the project, I knew I was taking a risk. My previous job (at Ditto Labs) had been in image and video analytics, which I was not passionate about. In contrast, before my MEng I had worked at MEET, where the mission and the core of what we were doing informed everything we were doing. Comparing those two experiences, at MEET I was excited to come to work every day, even when it was hard (there was literally a war towards the end of my stay in Israel). At Ditto, when things got tough, it was hard to find a foundation to fall back on. In hindsight, I should have known this would eventually be an issue.

On my first day at Amazon, I found out we were revolutionizing shopping, and my hopes sank a little bit. I was simply not passionate about optimizing or improving shopping. From day one, this nagged at me. However, it didn’t rear it’s ugly head until I contemplated leaving.

Throughout my time at Amazon, I focused on learning the most I could while adding the most value that I could. I took on projects that I thought were interesting, even proposing my own project that eventually led to the ArXiV paper, despite my lack of passion about physical retail. I still felt like I was adding value to the company and the group every day through my work. My focus was really on learning the most I could about what kind of work excited me, and it didn’t matter what problems I worked on to achieve that goal.

Finding Root

When a recruiter contacted me out of the blue about a robotics opportunity in the farming sector, I was more excited than I should have been. The nagging feeling about not working on something I believed in stood up in full force. I was reminded of my work with MEET years ago, when I felt excited to be coming to work every day not because of the work but because of the mission and the long-term vision. With Root, I was excited by the prospect of being on board with a larger vision of improving the world.

Leaving Amazon was not running away from a “bad opportunity” at Amazon, by no means. It was running towards an opportunity where I could be at my best, to a company with a mission that excited me. At Root, I could be both an engineer and a researcher (I didn’t have to choose or check a box), and I could do it fluidly while creating tangible, move-the-needle value from day one.

Summary

Root and Amazon could not be more different. But then again, I was approaching the two jobs at different points in my life, and I was a different person than I was 2.5 years ago. At Root, I was employee number 5 (if you count the co-founders). In my group at Amazon, I was employee number 13 (but by the time I left, I was the 6-th most senior group member, because of attrition). But overall, what I really was doing was running towards an opportunity that hit better with my career trajectory and my strength.

To summarize my reasons for leaving:

I was running towards an opportunity where I believed in the mission and long-term vision of the company.
In my new role I was fluidly moving between research and engineering, without being pigeon-holed into a single role.
In my new role I am responsible for making company-wide recommendations for computer vision and machine learning. My choices would directly impact the company’s future.
My commute was shortened from 50+ minutes by car to 10 minutes by bike.
If I were to found my own company one day, being closer to the founders / venture capital money was a valuable career move.
I was ready to move from the “learn a lot” phase to the “do a lot” and “make a lot of mistakes” phase of my career.
In Amazonian terms, I was ready to step up my ownership game to the next level.

My reasons for leaving, like many before me, were personal. Your own mileage may vary. If anyone is in a similar predicament and wants to get in touch to discuss career trajectories, please feel free to get in touch.

Blogging with Jupyter for Learning Julia Part 2

2018-08-25T00:00:00+00:00

I’ve previously posted about Blogging with Jupyter in a previous post. For the latest post on LearningJulia I needed one additional feature: LaTeX equation numbering in Jupyter. Here’s how I got that to work.

Getting LaTeX Equation Numbering in Jupyter Notebooks

LaTeX natively supported in Markdown editing in a Jupyter notebook through MathJax. Getting it to work in Jupyter notebooks involves installing the jupyter_contrib_nbextensions package.

These instructions are taken from the official install docs, and they worked for me.

pip install jupyter_contrib_nbextensions
jupyter contrib nbextension install --user
jupyter nbextension enable equation-numbering/main

Then, restarting the jupyter kernel enables the extension. To get the numbered equations to show up in a markdown notebook, just use LaTeX syntax:

\begin{equation}
H u - v = 0
\end{equation}

\begin{equation}
\begin{bmatrix}
h_1 & h_2 & h_3 \\
h_4 & h_5 & h_6 \\
h_7 & h_8 & h_9
\end{bmatrix}\begin{bmatrix}
u_1 \\ u_2 \\ 1
\end{bmatrix}
-
\begin{bmatrix}
v_1 \\ v_2 \\ 1
\end{bmatrix} = 0
\end{equation}

This is the result!

The only downside of this extension is that every time you re-compile a cell with equation numbering, the numbers keep incrementing. The good part is that the extension comes with a way to fix this problem: a little widget at the top of the notebook appears. When you click it, the numbering is restarted:

Pretty cool, right?

Getting LaTeX Equation Numbering in `nbconvert`

Automatically, nbconvert will apply these new extensions. The one thing it won’t do is apply the correct MathJax settings in the style. To do that, all I needed was to add these lines:

<script type="text/x-mathjax-config">
MathJax.Hub.Config({
    TeX: {
        equationNumbers: { autoNumber: "AMS" }
    }
});
</script>

to the exported .html file after running nbconvert. And the result works great!

You can read the full blog post here to learn what all these equations mean.

Conclusion

I hope this helps someone else, or at the very least, future me!

Favorite Podcasts 2017-2018

2018-08-17T00:00:00+00:00

As I move from a driving commute to a biking commute, I anticipate my podcast consumption to decrease over the coming years. As a followup to my previous post of podcasts I listen to from 2016-2017, here is the 2017-2018 list, organized by category and annotated with average podcast length and a “seriousness scale.”

I have listened to many podcasts and have wasted a few hours listening to some pretty bad ones. Here are some of my favorites - I hope you find something you’re looking for!

Stories / long form journalism:

This is by far my favorite kind of podcast format, tried and true. I devour this stuff, adding a few new podcasts in the regular mix from last year.

(40 minutes) serious Radiolab - When you think of long-from journalism and storytelling in audio form you think of Radiolab. In a single episode you will experience all emotions from rock bottom to giddy top, all through a single theme or story the hosts tell in a jam-packed 40 minutes. Not for the faint of heart - the topics they cover are often serious and will make you think.
(40 minutes) serious Death, Sex, & Money - From WNYC studios, the host picks a topic in the realm of human existence (which can be summarized by either death, sex, or money), and though a series of short stories strung together to form a longer story, dives deep into the personal nitty-gritty. Once in a while an episode is light-hearted, but often it is a serious discussion of all sorts of issues related to the human experience.
(40 minutes) serious Covert - Stories of the most dangerous military operations of all time from various different governments. The episodes often come in two parts and will keep you on your toes the entire time!
(40 minutes) serious Ear Hustle - This is the most unique podcast I’ve definitely heard. It is produced by an inmate in San Quentin prison in CA (together with Radiotopia) all about live in prison. Most of the episodes are serious, but they are absolutely riveting.
(40 minutes) serious Mafia - These are long-form stories about historical mafia figures from American history, their stories, and how they got caught.

How the world works:

Who doesn’t love analysis of social behavior? This list is nearly identical to last year’s - these podcasts are timeless.

(40 minutes) casual Freakonomics - From the authors of the popular book Freakonomics, they dive into why certain trends exist in the world from the perspective of economics. Very accessible to any audience, and I always come away learning something.
(20 minutes) casual Planet Money - Another NPR podcast talks about stories related to the economy, spending, or money, but tells it in an easy way that is engaging to listen to.
(40 minutes) serious More Perfect - The creators of Radiolab decided to make a serious podcast that dove into the legal cases that form the precedents for how the US Supreme Court and justice system work. As of this writing there is only one season, but each episode dives into a story about a seminal but little-know Supreme Court justice or court case from American history.
(40 minutes) serious 99% Invisible - Roman Mars takes on the underlying design and architecture of our world. The descriptions are detailed and very interesting!
(30 minutes) serious Code Switch - Gene and Shereen from NPR take on race in America. They discuss various topics related to race, always respectfully, and always from the heart.
(30 minutes) serious Rough Translation - The host talks about foreign stories, told in the context of different cultures. You don’t hear these kinds of stories in American news!
(20 minutes) casual Why We Eat What We Eat - Short anecdotes about food and eating habits. Unfortunately it doesn’t seem like they are producing any new episodes.

Trivia:

Unfortunately in this category, I have not found any good podcasts! My perennial favorite, Good Job Brain!, has stopped producing new episodes, and it turns out that No Such Thing As A Fish perfectly puts me to sleep!

If you have good trivia podcast recommendations, please send them my way.

Science and technology:

The only big change from last year was that the Talking Machines podcast got boring, so I stopped listening!

(20 minutes) casual Hidden Brain - An NPR podcast that talks about a human behavior phenomenon and attempts to explain it from the perspective of sociology, psychology, or neuroscience. The episodes are told in story format, and you come away thinking about how the episode might apply to your own life.
(40 minutes) serious Reply All - This podcast claims to be about the internet. Really, it’s about interesting stories that are facilitated by the internet, discussing weird technological glitches, crowdsourcing miracles, memes, and much much more. The hosts are very entertaining, but I give this a serious rating because the topics discussed are often deep.

Entrepreneurship:

In a change from last year, I have given up listening to this category of podcast. I decided I don’t want to buy into the internet marketing / click-bait world, and am content working in startups (where I get enough entrepreneurship).

Gardening and Homesteading:

This is a new category added for 2017-2018. As I’ve gotten more interested in growing my own food / local agriculture, I’ve been listening to more and more of these kinds of podcasts!

(40 minutes) casual Living Homegrown with Theresa Loe - Theresa Loe talks about canning, gardening, organic vegetables, etc. in an easy-to-approach away. She often does interviews with experts, who are equally approachable and explain things easily.
(40 minutes) casual The Modern Homesteading Podcast - The podcast host talks about homesteading essentials, and always brings in personal anecdotes from his own homestead. Because they are personal stories, the lessons learned are real, solid advice.

Enjoy! What podcasts do you like?

Deep Learning Approximation

2018-06-15T00:00:00+00:00

During my time at Amazon I worked on a deep learning project called Deep Learning Approximation that I got approval to publish my work on ArXiv.

Deep Learning Approximation speeds up the runtime of neural networks, which is especially relevant for pay-per-compute or limited-compute embedded environments. It decouples the task of speeding up neural networks from the task of making them more accurate. It enables tuning off-the-shelf networks for runtime, to complement fine-tuning for accuracy.

Abstract

Neural networks offer high-accuracy solutions to a range of problems, but are costly to run in production systems because of computational and memory requirements during a forward pass. Given a trained network, we propose a techique called Deep Learning Approximation to build a faster network in a tiny fraction of the time required for training by only manipulating the network structure and coefficients without requiring re-training or access to the training data. Speedup is achieved by by applying a sequential series of independent optimizations that reduce the floating-point operations (FLOPs) required to perform a forward pass. First, lossless optimizations are applied, followed by lossy approximations using singular value decomposition (SVD) and low-rank matrix decomposition. The optimal approximation is chosen by weighing the relative accuracy loss and FLOP reduction according to a single parameter specified by the user. On PASCAL VOC 2007 with the YOLO network, we show an end-to-end 2x speedup in a network forward pass with a 5% drop in mAP that can be re-gained by finetuning.

Details

Read the full paper for all the juicy details!

Blogging with Jupyter for Learning Julia

2017-03-18T00:00:00+00:00

For the Learning Julia blog, I use Jupyter notebooks as my primary blogging tool. The website is generated with Jekyll and hosted with Github pages. with a single command-line jupyter command and some custom configuration, I generate an HTML file I can embed into a Jekyll post.

My workflow

The workflow of a new post on Learning Julia is as follows:

In a Jupyter notebook, write some Julia code
When I get to the point where I learned something, go back through the notebook and add markdown annotations and text
Convert the notebook into an HTML file
Create a new post, write the introduction, embed the HTML notebook output, and write any final thoughts or concepts
Publish!

I’ll walk you through all my steps I use and show you any custom code.

Steps 1 and 2: Jupyter Notebooks

Launch a Jupyter notebook with the Julia kernel using jupyter notebook. Code away!

Step 3: Convert to HTML

I use nbconvert to convert a Jupyter notebook into an HTML file. I extended the basic HTML output template to do the following:

Any images in the Jupyter notebook output are saved as separate images rather than base64
The image paths need to point to a URL for the Jekyll site.
Multiple outputs are collapsed into a single output cell. For example, in a line with multiple print statements.

nbconvert comes with a set of built-in preprocessors that already do some of these tasks. For example, the ExtractOutputPreprocessor saves the images locally, and the coalesce_streams processor squeezes multiple outputs into a single output cell.

The easiest way to set the configuration for nbconvert is through a Python script. You can see the one I use here:

I set the ExecutePreprocessor as well - since I am setting the preprocessors manually I still want to make sure the entire notebook is re-executed, to preserve the input / output indices.

Notice how the HTML output is written into the _includes/notebooks folder in the Jekyll project. The images are then saved into the assets/imgs/{notebook_name} folder. The ExtractOutputPreprocessor by default saves images as relative paths, but we want to change them to url paths. I do this by the jekyllurl() function in the template. This outputs a Liquid filter that is accessible in the nbconvert template I used. It is an extension of the basic.tpl template, but slightly modified.

You can see the filter outputs for example in line 133.

The second filter, svg_filter, removes the DOCTYPE lines in in-line SVGs to avoid rendering errors that look like this:

You can see it in action on line 113 in my nbconvert template.

To run nbconvert with this configuration, do:

	jupyter nbconvert --config nbconvert_config.py PATH_TO_NOTEBOOK.ipynb

I am currently using nbconvert version 5.1.1.

Step 4: Create a new post

After the conversion is done, it is saved into the _includes/notebooks/ folder. I create a new post (with the standard Jekyll header, etc.) and include the notebook named 04-imfilter.html with:

{% include notebook/04-imfilter.html %}

If I know Mathjax is needed in the .html, I make sure to add

{% include mathjax.html %}

to the header. You can see mathjax.html here - it is just a few script tags that include MathJax from its CDN.

I do any extra post writing here, with some final thoughts.

Step 5: Publish

When all is said and done, I push the .html files, image files, and .markdown post, and a new post is born!

References

To figure out the configurations used in nbconvert, I used the following references:

If you want to check out my entire Jekyll configuration, feel free to poke around the Learning Julia repository on Github.

Hope this helps!

Favorite Podcasts 2016-2017

2017-02-15T00:00:00+00:00

I have a 45-minute commute to work (each way) every day, so I’ve been listening to lots of podcasts. Here is a roundup of my favorite podcasts from 2016-2017, organized by category and annotated with average podcast length and a “seriousness scale.”

I have listened to many podcasts and have wasted a few hours listening to some pretty bad ones. Here are some of my favorites - I hope you find something you’re looking for!

Stories / long form journalism:

(40 minutes) serious Radiolab - When you think of long-from journalism and storytelling in audio form you think of Radiolab. In a single episode you will experience all emotions from rock bottom to giddy top, all through a single theme or story the hosts tell in a jam-packed 40 minutes. Not for the faint of heart - the topics they cover are often serious and will make you think.
(40 minutes) serious Death, Sex, & Money - From WNYC studios, the host picks a topic in the realm of human existence (which can be summarized by either death, sex, or money), and though a series of short stories strung together to form a longer story, dives deep into the personal nitty-gritty. Once in a while an episode is light-hearted, but often it is a serious discussion of all sorts of issues related to the human experience.
(40 minutes) serious Serial Season Two - The entire podcast season is devoted to telling a single story. In Season 2 the hosts talk about the story of Bowe Berghdal, a US Army private who was captured in Afghanistan and held by the Taliban for 5 years before his release. Needless to say, this series is very serious. (They also have a Season 1, but I don’t like listening to murder mysteries).

How the world works:

(30 minutes) silly DTR - Tinder and Gimlet Creative come together to give you 40 minutes of pure hilarity through stories and case studies of people in the online dating world. The topics mostly cover how dating has changed in the face of technology.
(40 minutes) casual Freakonomics - From the authors of the popular book Freakonomics, they dive into why certain trends exist in the world from the perspective of economics. Very accessible to any audience, and I always come away learning something.
(20 minutes) casual Planet Money - Another NPR podcast talks about stories related to the economy, spending, or money, but tells it in an easy way that is engaging to listen to.
(40 minutes) serious More Perfect - The creators of Radiolab decided to make a serious podcast that dove into the legal cases that form the precedents for how the US Supreme Court and justice system work. As of this writing there is only one season, but each episode dives into a story about a seminal but little-know Supreme Court justice or court case from American history.

Trivia:

(40 minutes) silly Good Job Brain! - A weekly (less recently, since they’ve been writing a book that is also awesome) quiz show / trivia podcast hosted by 4 tech workers from SF. Each episode is themed around a topic, and there is usually a joke about poop somewhere. Very funny!
(40 minutes) silly No Such Thing As A Fish - A (nearly) weekly British podcast centered around hilarious news stories of the week, filled with quips and laughs.
(40 minutes) silly Tell Me Something I Don’t Know - A live show hosted in New York City, where famous people and “regular audience members” compete for having the most interesting fact. Hosted by Steven Dubner, one of the hosts / authors of Freakonomics.

Science and technology:

(20 minutes) casual Hidden Brain - An NPR podcast that talks about a human behavior phenomenon and attempts to explain it from the perspective of sociology, psychology, or neuroscience. The episodes are told in story format, and you come away thinking about how the episode might apply to your own life.
(40 minutes) serious Reply All - This podcast claims to be about the internet. Really, it’s about interesting stories that are facilitated by the internet, discussing weird technological glitches, crowdsourcing miracles, memes, and much much more. The hosts are very entertaining, but I give this a serious rating because the topics discussed are often deep.
(40 minutes) serious Talking Machines - One of the few podcasts out there discussing machine learning, it is hosted by Ryan Adams, a professor at Harvard. In each episode he discusses a topic from machine learning, and has a guest speaker with him to debate and discuss. If you don’t know anything about machine learning, this one is going to be pretty boring.

Entrepreneurship:

(15 minutes) casual The Distance - A quick short podcast where each episode highlights a small family business that has been around for a long time (usually over 20 years or multiple generations). The host tells the story of the business, including interviewing the owners, giving background on the business, and highlighting successes / failures.
(40 minutes) _casual The Financial Independence Podcast - The Mad Fientist hosts a personal finance blogger as a guest to the podcast to talk about their story in personal finance or reaching financial independence. These guys are not professionals, so it is just a conversation between two average people about their financial plans and goals. I can understand if this is not your cup of tea ;)
(40 minutes) serious The Side Hustle Show - Hosted by Nick, a dynamic and bouncy host who has worked on side hustles for years, The Side Hustle Show features a successful entrepreneur in each episode who has a unique story. The conversation involves discussing how others can learn from other people who have been successful in building a business.

Enjoy! What podcasts do you like?

Installing Zim Wiki on OSX

2015-09-08T00:00:00+00:00

Running programs meant for Linux are hard to run on OSX, especially if they use graphics. This is how I got Zim wiki running on OSX.

Installing Zim as a stand-alone app

After using a Linux computer for 5 years, my work environment changed and I am now using OSX full-time. One addition to my personal productivity suite has been Zim wiki, a personal wiki system made of a bunch of text files and a Python wrapper that I sync between my various machines / partitions using Dropbox. The downside of switching operating systems, I had to get Zim wiki running on OSX.

I took much of my inspiration from the Gnome-wiki page on building GTK for OSX and someone’s earlier blog post for how to package Zim as an app on OSX

My setup:

OSX Yosemite 10.10.3
Zim 0.63
Anaconda Python
Homebrew for package management
XCode 6.2

Here are my series of steps (for OSX Yosemite 10.10.3 and Zim 0.63):

Download the Zim source files from the zim downloads page
Make sure you have XCode, svn, git, curl, and OpenSSL installed. My package manager is Homebrew and I installed it with those, but people use different things. From here, the instructions are basically taken from the guide for setting up GTK for OSX
Download gtk-osx-build-setup.sh in your home directory and run it
```
 sh gtk-osx-build-setup.sh
```
In general, I prefer not to mess with environment variables, especially the PATH and LD_LIBRARY_PATH, since I don’t want to mess up my work environment, and don’t want to have to keep track of changing them when I run Zim. So, my solution does not involve changing any of those variables.
This will install jhbuild, but it is installed in ~/.local/bin/jhbuild. So make an alias for the jhbuild command by adding this to your .bashrc or .bash_profile or .zshrc:
```
 alias jhbuild="~/.local/bin/jhbuild"
```
Run jhbuild bootstrap at the command line
Run jhbuild meta-gtk-osx-bootstrap
Run jhbuild build meta-gtk-osx-core
Run jhbuild build meta-gtk-osx-themes
Run jhbuild build meta-gtk-osx-python
Run jhbuild build pygtk.
If all of the jhbuild commands run without a problem, you should be good to go to set up a stand-alone app. Of course, there are many ways for them to go wrong, but if you want help with those feel free to leave a comment or send me an email and I’ll try to help. From here the instructions come from a blog post about how to create a stand-alone Zim app. First, download Platypus. It is a program that can be used to bundle apps on OSX.
Run Platypus and change the parameters as follows:
- App Name: Zim
- Script Type: Bash
- Script Path: click “New” below the path, then replace echo 'Hello, World' with ../Resources/zim-0.63/zim.py
- Output: none
- Identifier: default
- Author: default
- Version: 1.0
- Uncheck all 4 options (including “remain running after initial execution”)
- Click the + sign for “Files to be bundled” and add the source folder for the Zim source.
- If you want the icon for Zim, then you can drag the zim.png file from the zim-0.63/data/ directory into where the icon is

Click Create to create your app, and save it anywhere (the Desktop is a nice place.)

Drag your new icon into the Dock, and you can click it to launch Zim!

I haven’t yet figured out how to get the tray icon working - I suspect I am missing a GTK plugin to build with jhbuild, so if you figure it out, I am excited to know!

I had two main errors (with jhbuild) that I was able to fix, and there are many more that can happen. I will describe my two errors here, and if you have others, feel free to post in the comments / email me and I’ll update this with more.

Error 1: `libxml2`, or in general missing packages.

During some parts of the jhbuild process I kept running into errors where I was missing packages when they clearly were there. This is most likely because jhbuild is not building or linking the packages with the correct version of Python or GTK. To solve this, when an error comes up, I selected 4 from the terminal menu (i.e. open a jhbuild shell), then cd into the Python-2.7.8 directory, and do:

make
make install 

Then exit the shell with exit, and continue the build process. (Reference from this forum post).

Error 2: `libgtk-quartz-2.0.0.dylib`

After I finished all the jhbuild compiling without errors, I ran into an error after packaging, where I would open Zim, but every “wrong”” movement such as random mouse clicks, backspaces too vigorously, or clicking some buttons would crash Zim horribly with the error that libgtk-quartz-2.0.0.dylib plugin failure.

What fixed this for me was changing the default Python expected by Zim to Anaconda Python. The path for my Anaconda Python is in /Users/mprat/anaconda/bin/python, while all the .py files in the Zim source were expecting to use Python from /usr/bin/python, as set by Linux. So I opened the Zim source files in Sublime and changed all the #!/usr/bin/python to #!/Users/mprat/anaconda/bin/python, and re-packaged the app with Platypus. After that, no libgtk-quartz-2.0.0.dylib problems.

I hope this helps anyone else struggling to install Zim on their OSX machines!

Word Frequency in the King James Bible

2015-02-05T00:00:00+00:00

Somehow in undergrad I never got around to learning about the MapReduce algorithm. To fix this, I learned about it from the first lecture of MIT’s 6.824: Distributed Systems Engineering, and will attempt to explain MapReduce here, then implement it in Python on a real live example.

In short, MapReduce is an algorithm for parallelizing computation, based on a two-step process of “mapping” and “reducing.” If you are interested in reading the full Google Research publication about MapReduce, it is online here, and is a fairly accessible paper.

In the map step, some function is “mapped” into a list of elements, and the output is a list of (key, value) pairs, where each (key, value) pair is the key (or the elements in the list, before the function was applied to it) and the value, which is f(key), or the value returned after the function is mapped to that element.

At the end of the map phase, the output can be thought effectively of two lists: one list of all the original keys, and one list of the values mapped to new values according to some function.

Then in the reduce phase, this list of values is aggregated (or reduced) into one element that is the solution to whatever algorithm is desired.

The reason MapReduce is so powerful and parallelizable is that the map and reduce functions can be done in parallel to multiple lists (in fact, the mapping of function to elements of a list is inherently parallelizable, since the same function is applied to all elements of a list independently).

An example

It helps to think of an example. Let’s say we want to take the King James Bible and count the occurrence of each word (this allows us to find the most common word, etc.). This can be done in a parallel way with MapReduce, as follows:

The map phase consists of taking each line of the text file as a list of space-separated words and mapping it to a list of word-value pairs (word, 1). For example, the sentence
```
  "I cried unto thee"
```
becomes
```
  ("I", 1), ("cried", 1), ("unto", 1), ("thee", 1)
```

Here, the map function is taking a list of words and outputting 1 every time it sees a word. This means that each time a word is seen, the 1 is like a counter.

The reduce phase just takes the list (or lists) of (word, 1) values given above and sums the numbers for each word. This means that in the end, each word will be a (word, int) value, where int is the number of times that word was seen in the map phase.

In the end, correctly implementing MapReduce on the King James Bible will yield the following results as the top 5 words that appear:

('the', 63937)
('and', 51699)
('of', 34624)
('to', 13569)
('that', 12913)

Actually implementing a parallelized version of MapReduce is challenging, since the communication between the threads that do the computation and the threads that do the dispatching gets rather hairy. For 6.824, the assignment is all implemented in Go and is in general much faster than Python, but it would be in poor taste to post the solutions to the homework on line. Instead, one can write a single-threaded version of MapReduce for the same task in Python, as shown here.

For efficiency’s sake, instead of using tuples to represent values, my Python implementation uses dictionaries. Additionally, when the map step happens, there is part of the reduce step that happens at the same time. Namely, when words are constructed, they are automatically added to a dictionary that keeps track of their frequency in that line, but only because the dictionary syntax used there is cleaner than using nested if statements to check whether a key exists in the dictionary already.

A Fictional Middle East

2014-02-13T00:00:00+00:00

I have never written a piece of fiction before. My first attempt, written in February 2014 over the course of a week, was prompted by a “call for fiction” submission to Mashallah News. The prompt was this (taken directly from the Mashallah News website):

Imagine alternate fates for what is, at present, a complicated Middle East. While the various crises sweeping the region might oppress our sense of what is possible and confine our hopes to a handful of initiatives, our imaginations are beyond the scope of contemporary limitations. By inviting writers to use the tools of fiction to contemplate the farfetched and seemingly impossible, we hope to spark a very real debate about what kinds of future Middle Easts are conceivable.

My attempt to answer this question is below, written 6 months after moving to the Middle East. Originally, my story did not have a title. I am still struggling with the appropriate title for this story, since I have a hard time summarizing my main point in four words. I hope you will enjoy it - feedback is more than welcome.

the future godless levant

“There is no such thing as religion anymore!” I say, ending my lecture. The eager students applaud and file out of the room as a few students stay behind. “So when you said Maronite Christians, you were talking about the Shiite Muslims, right?” one girl asks. “No, they were all Jews anyway!” says another, rather flippantly. I try to hold back my laughter as I explain that the definitions of separate religions and sects from the 21st century were different than they had been in the first century BC.

My students are all talented. But as headmistress, the students I advise are the most obstinate - the ones no other educator can handle. The ones who had been beaten as children for not staying quiet during nap time. The ones who had built a radio receiver from their parent’s old vacuum parts to listen to for satellite signals from outer space. The ones who have radical ideas about the isolation of the Middle East from the rest of the world. Or about religion. Or about the next privacy-invading technology. Or the military. The ones who will end up both destroying our civilization as we know it and the ones that will lead it to new heights. But all of them respect me because my brother is the mayor of our village. They know that they can discuss anything with me - I am the most patient and the most inviting. And no matter what it is, I will find out anyway.

I go back to my office to start my daily grading of papers and find a student from the morning class waiting for me.

“Can I confess something?”

“No need to confess - here we speak our minds.”

She looks me squarely in the eyes. “I think I believe in God.”

I look out my window and see the students sitting around the olive tree, eating lunch. I like to think I am part of that tree - rooted in tradition, but more like the olive who will either fall within the protection of the tree, or be carefully picked and taken for other purposes. Students have come to me with this before, so I am not concerned.

“It is no crime to believe in God, but you know religion is against the law.”

She looks at me like she is hiding something. I ask her, gently, “Are there others? Have you been meeting in private?”

She tells me the whole story - the readings, the meetings, the prayers. She and her friends have not decided what God they believe in, just that they believe in a God. Organized religion is against the law, punishable by imprisonment and heavy fines. But I know the way to reach the mind is through the heart. No amount of coercion, fines, torture, imprisonment, will make a difference of opinion. The change must come from within. She planted the seed in her own brain, and she must be the one to stifle it’s growth.

“A god is different from religion. A god is flexible, a god listens, a god helps. Religion is cumbersome, does not bend, and often gets in the way of how we really feel. It dictates how we act, how we feel, what we do, and does not tolerate differences of opinion. My true faith lies with people.” I told her my own story.

Before this village grew up out of the dirt, I lived in a different time and place. We were all children of farmers - simple and poor and bound to the land. We thanked our God for our crops, our parents, our lives, our futures. Our religion and our traditions were intertwined - they told us what to eat, how to dress, what we could do. We were dependent, we were stuck. I was blessed to be one of my family. We were rooted in our traditions, confident in our means. But then the wars came. People from a distant village, equally rooted in their beliefs came and told us our roots were infected and false. My brother and I fled, disowning all that we had known for so long. Our branch had fallen. I stopped eating, I stopped sleeping, I stopped praying. To me, our religion was dead. Our arguments had caused nothing but bloodshed, simply over what we could and could not do, or where we could and could not go.

We started our new lives on a small simple farm here, where our village stands, outlawing religion within the city walls. The olives that bore fruit in groves outside the new village were our new religion. We had no prayer meetings, we had no place of worship. People slowly came to the village, seeking refuge from their own droughts. We worked the land, made our village services, made our schools. The people who were moving to our village were the same age as those who had destroyed my former home. But the people who came were even stronger. They had hated, they had loved, and they had fallen from the comfort of their roots. Many who came had been so dependent on their religion, they did not know how to live without it. We held weekly discussions about what we believed, who we really loved. I came to realize that faith in an individual means more than faith in a being I have never seen. I believed that the widowed mother of three would find shelter from the horrors and pursue her dream of making clothes. She did. I believed that the young man who ran from his father’s zeal would build his new house with his bare hands and find a spouse to share it with him. He did. The child who dreamed in swathes of color became a painter. The elderly woman took her books out of hiding and started a library. Over and over, the strength of people who fled and came here were shown to me. I pray not to a god who listens to everyone, not to a god who judges me. I pray to a god who believes in the will of the individual. But I don’t pray to the God that told me that people were a certain way, that they had to act a certain way.

I look back to her, realizing I had been talking without looking at her, eyes fixated at the olive tree. “To me, my god is people. It is everywhere, in each and every person. But religion reminds me of the injustice I have seen.”

She looks at me, eyes glistening and glazed, looking off into the distance. “I am not ashamed to believe in god, but I am scared to grow on my own.”

“God is like the olive tree - sacred to each one of us, but free in form to grow. Religion is like the wire that holds the tree to grow a certain way. We all deserve our chances, we all have faith in our own way. But we are free.”

I leave her in my office; she needs time to collect her thoughts. I believe she will make the right choice. I don’t have faith in God anymore - no one does - but I have faith in her.

MEET Fellowship

2013-09-22T00:00:00+00:00

In one of the most adventurous and spontaneous decisions of my life thus far, I decided to spend a year living and working in Jerusalem for [MEET](http://meet.mit.edu), teaching computer science for change. (For a laymen's description of MEET, check out [my other post](/projects/meet/2013/07/10/meet-mission-program.html).) #### My role at MEET, 2013-2014 From August 2013 to August 2014, I am a full-time staff member (the second ever MEET Fellow) at MEET based in Jerusalem. MEET is an NGO that aims to empower Israeli and Palestinian youth to bring about positive change in their communities and solve complex problems by teaching them computer science and business skills over three years in an after-school high school program. My responsibilities include (but are not limited to)... - {: .detail-text} teaching all yearlong computer science classes (Y1 and Y2, both Jerusalem and Nazareth) and providing feedback, advice, and mentoring to all (~140) students - {: .detail-text} mentoring individual and group projects - {: .detail-text} creating and designing all said projects - {: .detail-text} providing feedback and mentoring to two students studying overseas {: .detail-list} - {: .detail-text} developing the new computer science curriculum for the Y2 yearlong and Y3 summer (collaborating with the business curriculum team leads) - {: .detail-text} creating content, connecting experts, thinking big {: .detail-list} - {: .detail-text} improving the Y1 yearlong curriculum from 2012-2013 - {: .detail-text} serving as "Head of Curriculum" and think about high-level issues related to the 3-year computer science sequence - {: .detail-text} writing up transition materials for the next yearlong and summer instructors {: .detail-list} - {: .detail-text} serving as "Head of Instructors" as a liaison between the Middle East staff and the MIT instructors that are recruited to teach the summer program - {: .detail-text} thinking about MIT instructor needs - {: .detail-text} thinking about CS curricular needss {: .detail-lixt} - {: .detail-text} helping with summer instructor recruitment and spring / pre-summer preparation - {: .detail-text} managing and coordinating MEET alumni TAs for the yearlong and the summer {: .detail-list} The year will be an exciting mix of intensity, teaching, management, and on-the-fly thinking. Of course, all done in conjunction with Talya, the program manager. #### Goals Goals: - {: .detail-text} Become a better computer science instructor, both for explaining fundamental concepts and as a project mentor - {: .detail-text} Learn basic conversational Hebrew and Arabic (as a consequence of living in Jerusalem) - {: .detail-text} Improve my middle-management skills - {: .detail-text} Learn a new computer-science-related technology I have never worked with before - {: .detail-text} Publish my lecture notes / lesson plans / labs in a coherent way somewhere on the internet - {: .detail-text} Figure out the best way to provide feedback to so many students at a time adn in an effective way - {: .detail-text} Think about what is _really_ important to teach from CS to empower young students to change the world {: .detail-list} I am excited to see the students grow as they continue their computer science studies, and I am excited to help them produce successful individual and group projects throughout the year and the summer. In all, I took this job knowing that it will be both challenging and rewarding. My education thus far has brought me to a point where I am ready to take on challenges and share my knowledge with the world, empowering both myself and others.

MEET summer 2013 on mostly academics

2013-07-25T00:00:00+00:00

In Fall 2013 I applied to be a summer instructor for MEET, an NGO who’s mission is to empower Israeli and Palestinian youth to create social, political, and economic change within the Middle East, both by giving them a network for interaction but also business and technical skills. By some strange happenstance, I was accepted to be an instructor (to teach Y2s web development, something I knew nothing about), and I agreed. Through a whirlwind of preparation, culture shock, and educational mayhem, I think I helped bring MEET one small step closer to it’s mission.

Between July 8, 2013 and July 21, 2013, I (as a member of a 5-person team), taught web programming (MVC patterns, Django, HTML, CSS, Javascript) to 60 Israeli and Palestinian high school students at the Hebrew University campus in Jerusalem for around 8 hours a day, 6 days a week.

the task and the team

Our team of 5 instructors - me, Aline, Kyle, Lorenzo, and Nikhil, could not have been more diverse in our experience with computer science and teaching, but we were tasked with teaching the group of Y2 students (a group of 40) how to make a dynamic website. We were not given a syllabus or any context, but were told that by the end of the summer the students had to know HTML, CSS, Javascript, Django, and how to put all of those together to make a dynamic website.

Lorenzo was the veteran: he had been at MEET two previous summers, and was given the role of team lead. In his former life he graduated from MIT with a degree in math and was now working for a financial company in Mexico City.

Aline was the other vet: she had been at MEET once before, had graduated MIT with a degree in neuroscience (but had started out as a CS person), worked as a professional chef, and now worked as a technical recruiter in San Francisco.

Nikhil was the second half of our international cohort: he graduated from MIT with a degree in EECS and was now pursuing a master’s in India while simultaneously working for GE.

Kyle was my year at MIT, also EECS, and star of the track team, set up to work in Chicago for a financial company after the summer.

Our task was incredible: we had no material from previous years, so we had to come up with a curriculum, come up with projects, develop the lessons, and deliver them to the students. All in the span of 13 academic days. BAM.

the summer preparations

The spring preparation I was told was going go take about 10 hours in the spring, on top of a few in-person training sessions.

The in-person training sessions were incredibly interesting: the history of the Middle East / the conflict, a geography lesson about the Middle East, a seminar on teaching, a talk about other initiatives doing peace work similar to MEET, a session where a Gazan Palestinian and an Israeli Jew were brought in to talk to us about their own personal narratives, and a session about MEET in general. It was an opportunity to meet other instructors not on my team and get a bit of insight into the organization and the problem it was trying to solve.

Because the 5 of us were in different timezones all over the world, we did not plan much other than the basics of who was responsible for what topics. Most of us (myself included) had never even learned Django ourselves, and we were expected to teach it to the students.

We had discussions about whether we needed to do an intro lesson on topics like “what is a server” and “what is a database” - the basics many CS students take now for granted. How would we have student work? How would project work be saved? How would the projects look like? What experience did the students already have? How well did they ACTUALLY know python?

These were all questions I in retrospect should have asked more often and more forcefully. I now understand that I came to the summer not wholly prepared for what we were going to teach and not understanding the context of the students we were teaching. I was told that “the students were really smart” and “the students work really hard”, which I took to mean that they had mastered basic python and knew some stuff from CS outside of what they were taught. Oh boy is that a wrong assumption to make in teaching.

I also realized that while I knew the students were learning both CS and business, I didn’t know what they were learning in the business curriculum. I didn’t know for how long. I really didn’t know much…

On the plane flight from JFK to Tel Aviv (which by the way, took me nearly 18 hours including layover time), I spend the majority of it working through the Django tutorials and playing with my own Django app. I figured, if I can work through the Django tutorials in a sleep-deprived plane flight, how hard could it be to teach this to some high schoolers who knew python?

I landed in Tel Aviv and was academically prepared to teach the material. The lessons were not super prepped, but I figured, how hard could that be?

the students and the instructors

One thing to understand is the deliberate naming that is “instructor”. MEET does not hire “teachers”, they hire “instructors” and “mentors”. These people are meant to be role models for the students, to be guidance and advice, rather than teachers. MEET is not school, and we don’t want to treat the students as such.

The role of the instructor is not only to provide high-quality education but also to provide a role model for following MEET’s 6 values:

Lead by example
Think big
Act with integrity
Treat everyone with respect and equality
Embrace teamwork
Strive for excellence

So we are not teachers - we are positive role models. This is a subtle point of social engineering that has stuck and made a lasting positive impact. By calling the MIT cohort “instructors”, we are emphasizing the discinction between formal educator and informal role model. As one of the MIT instructors, I felt like I was closer to the latter than the former, all because of that one word choice.

the summer

In the week before the student classes began, the instructors and the staff all bonded with a barbecue at Mustafa’s house (MEET Student Relations Manager, living in Beit Zafafa), a trip to the Negev, dinners, lunches, office MEETings, and class prep time. We worked frantically to prepare our lectures and yet have time to explore Jerusalem, this historic, amazing city we all wanted to be in.

We started teaching, and quickly realized the level of the students: the short of it is that they were not as strong as we were told. In fact, most of our assumptions were just not correct. The thing I am proud of was that we started off the summer with a lecture on clients and servers, what that means, and where a website fits into that.

But when we started to teach Django and Javascript - arguably harder concepts than HTML and CSS - we ran into problems. We discovered that students didn’t have a good idea about what classes where, what URLs were, or really what we were trying to do in the first place. Aline, Kyle, and I worked and re-worked the lessons to finally find a better fit for the students as we were approaching crunch time for the projects. We were lucky to have two groups of students to teach. The unfortunate part was that one group of students got the shorter end of the stick while the “second” group got the benefit of our re-works.

I now understand that this work and rework process is natural for an instructor - to work, rework, test, retest, present, re-present, and guide the students in any and all ways possible. The unfortunate side effect of that was that we were regularly pulling 11+ hour days (between in-class time, socializing with the students at dinner, re-designing the lessons, testing the labs, testing the software on the university and then MEET computers, and running occasional tutoring sessions) and then socializing with staff and instructors and exploring the city / surroundings of Jerusalem in our “free” time. It was a love-hate relationship as you can understand.

the projects

The way we designed the curriculum for the summer was with the goal in mind that the students had to have, in groups, something presented at the end of the summer that demonstrated all that they had learned over the summer. So we alloted 7 full days of project work (that was about 20 hours for each group), to create a website that we (the instructors) had designed for them.

We each had to build the project prototype to prove to both ourselves and the rest of the Middle East staff that we were in fact capable of building such a website, and to prove that it was possible.

We had 5 projects overall, and each student team took a project and ran with it. Some groups went far, some groups not that far, but all ended up with projects that they presented at the end of the summer program to the rest of MEET. Oh, did I mention the code for the projects is on Github. The projects are not actually live anywhere (we did not buy server space or have time to teach how to deploy an actual website), but the students nonetheless had enough time to barely build a functioning local copy of a few projects with Django.

the end

Even though the summer experience was not easy, I can say that the prep work over the spring semester and the countless hours, reworks, and redesigns of the lessons during the summer were worth it: the students were proud of their projects by the end of the summer, the instructors as a group were closer, and all came out of the summer feeling a bit closer to achieving the MEET mission.

See more photos from MEET on .

MEET project descriptions from Summer 2013

2013-07-22T00:00:00+00:00

MEET students in summer 2013 worked on 10 different projects. The code is all on Github, and the (rough) descriptions are below.

MeetConnection

A social network to bring together MEET students / staff / instructors to ask questions and search for other users. Idea proposed by Nikhil.

MeetMe

A social network to find users in your area with similar interests and get connected to them. Idea proposed by Nikhil.

Create and share surveys that can be taken online. Idea proposed by Aline.

BookLists

A book recommendation, tracking, and reviews website. Idea proposed by Kyle.

Taste

A music-ranking and organizing website that you can share with your friends. Idea proposed by Kyle.

ToBeContinued

A collaborative story-telling website turned into a turn-based game. Idea proposed by Michele.

StorieShare

A collaborative story-telling website. Idea proposed by Michele.

SurvMe

Create and share surveys that can be taken and shared and visualized online. Idea proposed by Aline.

ShookSookBits

Marketplace organizer with maps, shops, and products of the Old City of Jerusalem. Idea proposed by Lorenzo.

ShookSookBytes

Marketplace organizer with maps, shops, and products of the Old City of Jerusalem.Idea proposed by Lorenzo.

MEET the program

2013-07-10T00:00:00+00:00

As every MIT undergrad does, I was looking for something interesting to do with my summer. I knew I was going to be graduating in June and was looking for a unique summer experience. I had already decided early in Fall 2012 (my fall semester senior year) that I would take a gap year between the end of my undergrad and the start of my MEng (Master’s in Engineering) at MIT. But I wanted to kick off my year with the right summer experience - MEET was the answer.

MEET in general

I had heard about MEET, but all that I knew about it was that it stood for “Middle East Education through Technology” and that they taught computer science to Israeli and Palestinian high school students.

Knowing basically nothing about the program and knowing no one who had done it before (later it turned out I did, but when decision time came I didn’t know that), I felt drawn to what MEET was trying to do. I was drawn to it’s ideals, goals, mission, and vision.

Look at the mission for yourself: “Our mission is to educate and empower tomorrow’s most promising Palestinian and Israeli leaders to take action towards creating positive economic, political, and social impact in the Middle East.” (taken straight from their website). By investing many resources into a small group of students, MEET was aiming to foster a network of future Israeli and Palestinian leaders, doers, facilitators, entrepreneurs. I agreed with the philosophy. Young people are the ones who will make change. Education is key. Technology is a vector for problem solving skills, modernization, critical thinking, teamwork. I specifically liked the idea of a longer program - I didn’t think a one-off camp or academic program would come close to achieving the mission. MEET was not a one-off program (students in MEET were in the program for three years and then even later through an alumni program), so it sounded more plausible.

For students in MEET, their commitment was high: they committed at the minimum one month every summer, and one 3-hour weekly meeting for the two intervening years. They came to MEET with a strong academic record, a good working knowledge of English (all classes are taught in English), and a high score in a group dynamics test. During the summer after their freshman year in high school, they became “Y1s”. By the time they were Y3s, they would be ready to take on the world as entrepreneurs, makers, doers, and facilitators of change.

Don’t get me wrong, the idea of making change in the Middle East through one small program is a crazy idea. But no one makes big change without a few big ideas. Even though the outcomes from MEET’s interventions could not be measurable for years to come, my gut feeling told me it was a worthwhile investment of my time and energy.

I wanted to be a part of MEET - to work with the students and the staff to come one step closer to the ultimate vision. I applied, interviewed, and was accepted as a summer instructor for summer 2013.

At the time, here is what the student CS curriculum looked like:

Year 1:

Summer: Introduction to programming (python)
Yearlong: Skill building, personal projects, HTML/CSS introduction

Year 2:

Summer: Web programming (MVC design pattern, HTML/CSS, Javascript, Django)
Yearlong: Skill practice, integration with business, group project ideation and workplan

Year 3:

Summer: Group project completion

And I wanted to play my part.

me and MEET

To be honest, I did not know much about the conflict in the Middle East (let alone specifically Jerusalem) before I began preparing for MEET. It was an issue that unfortunately did not mean anything to me in my daily life in the United States, and it’s and one that the media does not feel the need to seamlessly cover. I knew it was a conflict and I knew I didn’t know about it. While I was going to be in Jerusalem I was determined to find out more.

I was asked many questions from friends at home and abroad about why I chose to do MEET. From the American camp I heard: Are you Jewish? Is that why you are personally invested in the conflict? Are you interested in international development work? Humanitarian aid? NGOs? Aren’t you giving up a lot of time and money for something you won’t do for a living? Are you crazy? It’s dangerous there.

And from the Middle East I heard: What is your religion? Will you make aliyah (both the good and the bad connotations)? What made you give up your summer to come to Jerusalem instead? Why do you think computer science is a tool for change?

After thinking about these questions and many more of my own, I came up with a list of goals I wanted to achieve over the summer at MEET, and to reflect on later:

Understand the historical context for the Israeli-Palestinian conflict
Discuss with Israeli and Palestinian adults the meaning of the conflict to them
Form an opinion about the conflict
Assess my opinions for whether MEET’s mission will help solve the conflict
Finalize my relationship with religion

MEET is an amazing program. Shalom, Salaam.

MIT Graduation Cap

2013-06-06T00:00:00+00:00

MIT has many interesting traditions. But my personal favorite is the tradition of MIT’s graduation hats. I had a lot of fun with this tradition, especially given the weather.

The term “walking at graduation” means a lot to someone who spent 4 years as an undergraduate at MIT. No matter what you studied or what extracurriculars you had, the 4 years you spent at MIT were hard. The last official thing you do with the Institvte is receiving your diploma at graduation, where the graduate wants to go out in style.

Now, the PhDs already go out in style. See their graduation regalia, courtesy of CapGown.com:

But the Bachelor’s regalia is all black and made of some kind of cheap plastic. To go out in style, what many undergraduates do is decorate their graduation caps with various items that are unique to them.

My graduation cap

I graduated with my Bachelor of Science in Electrical Engineering and Computer Science on June 6, 2013. The forecast for that day was 90% chance of rain. At least it was supposed to be 75 degrees F or so. A few years go, I had spent $5 on Amazon to buy an umbrella hat, just for fun. But the night before graduation, it seemed like I had made an amazing decision.

Because you see, I could just affix my umbrella hat to my graduation cap to cover my cap from the rain. The cap wasn’t very structural - it’s some black plastic covering over a cardboard cap.

However, I wasn’t sure it this would be (1) enough, or (2) quite indicative of me. So I decided to combine this with an idea that had started growing on me over the course of the past semester. I spent so much time in the White Mountains in New Hampshire with the [MIT Outing Club)(http://mitoc.mit.edu) that it felt almost natural to put a map of the White Mountains on my graduation cap. Together with a MITOC patch.

Of course, combine this with the umbrella hat and you have quite an exit.

As you can see, not everyone has their caps decorated. It makes you feel that much more special. What happened to me was that the Dean of Student Life asked me to take my umbrella hat off my cap to not obstruct the view. I readily complied, not wanting to jeopardize actually walking at graduation. Hence the lack of umbrella hat in my graduation photo with mom and dad.

All in all, I am quite happy with my unique graduation cap. Not as good as the graduated cylinder to measure the rainfall during the ceremony, but definitely very indicative of me.

EECSCon Poster

2013-04-04T00:00:00+00:00

EECSCon is happening this coming Saturday! I made a poster describing my SuperUROP work on mobile rephotography. Check out my poster here! If you don’t want to look at the PDF, parts of the poster are reproduced below as images.

EECSCon itself was an interesting experience. It was the first time I had to make a poster about academic “research” work. Putting together all of my thoughts without going into the technical details was quite a challenge, but luckily I was working on a graphics-and-computer-vision project, so I had lots of images I could show.

Education Designathon and iCampus Prize

2013-03-15T00:00:00+00:00

After successfully working on Terminus (with Shawn!) at the Education Designathon held at MIT in spring 2013, I decided that the Terminus project from 11.127 so long ago would be a great entry for the MIT iCampus Prize Competition in the spring of 2013.

the education designathon

I have always loved education - as a system, as a problem, as a project. However, I’ve had a hard time thinking of ways I can use my computer science training to help with education (sure, MOOCs, but I haven’t yet decided whether those are beneficial for education or not). In either case, when I got an email from Jessica Artilles advertising the designathon, I was super excited.

(Photo credit to Jessica Artilles.)

Here is Professor Woodie Flowers, professor of mechanical engineering at MIT and founder of FIRST robotics, giving the opening talk at the Education Designathon.

A “designathon” instead of a “hackathon” that promised to bring together education experts and technologists alike was going to be exciting.

At the designathon of course I started working on a problem but soon realized that it was already solved. So to my luck, I found Shawn (yes, original Terminus group member Shawn!) at the designathon too and we decided we wanted to continue with Terminus.

We approached the problem this time from an element of fun: we wanted to use the 24-hours-or-so that we had at the hackathon to learn a new technology. So we decided to tackle writing Terminus for the web. We had a heck of a time finding the old Terminus files (I had put them on Github but they were not complete), so we eventually found our storyboarding document and started to redesign the code from scratch. (I will talk about the technical details later.)

(Photo credit to Jessica Artilles.)

We’re hard at work, coding, eating, enjoying our challenge for ourselves.

At the end of the day-and-a-half that we spent redesigning, coding, learning, and tweaking, we were to go with a version of Terminus that was almost identical to our Java version except written in Javascript. We presented for 2 minutes and demo’ed the project, to great success at the designathon.

(Here’s a rather embarassing photo of me and Shawn talking about Terminus at the end of the hackathon. Photo credit to Jessica Artilles.)

For our Terminus web-hack, we ended up getting the “Best Scalable Assignment” prize at the Designathon, and were encouraged by OEIT (MIT’s Office of Education and Information Technology) to apply for the iCampus Prize.

iCampus: the competition

Whenever you re-appropriate a project for a competition or a cause (rather than just playing at a hackathon), it is criticl to again understand the audience and specifications. If not to create a winning entry, the information about audience will give your project a message, tagline, and story. In a sentence, the iCampus prize is a competition to use technology to enhance living and learning at MIT.

Shawn and I both decided to continue work on Terminus at least for the iCampus prize. The first-round submission was due a week after the designathon, so we had to get to work!

the Terminus story

The reasoning goes like this: MIT’s computing system (called Debathena) is built on top of Ubuntu Linux. The majority of undergraduates, when they first get to campus, have no idea how to use the computers that the university is providing. Sure, there is some graphical interfaces, but part of the beauty of Debathena is that there are a number of terminal commands developed specifically for MIT - for printing, searching for users, creating mailing lists, accessing student group files and folders, and many more.

The barrier to learning these terminal commands for MIT undergraduates is manyfold:

We don’t have the time to make mistakes
We use our own personal computers for almost everything
There is no MIT-specific tutorial

Terminus aims to solve all these problems at MIT (for freshman, undergraduates, and graduate students alike). We bring gamification into the picture. Through the exploratory environment provided by Terminus, we empower MIT students to become more familiar with the terminal, both for MIT-specific commands and for general use.

the re-design: technical details

Now that we knew our audience, we had to get designing. We narrowed down our desired feature list to a few key points that dictated a few major design choices:

Accessible anywhere (within internet range acceptible)
No complex hosting
No login needed
Both general and MIT-specific commands

To address each of these choices, we came up with the following solutions:

Web app!
No backend database - all front-end, all-Javascript / jQuery
No saving game state
Slightly modified game logic from the original Java version

We decided that our implementation was going to be a simple web game built all in Javascript. We found this Javascript plugin that would do some of our work - we had to add the game logic. For now, because we were using only-front-end-Javascript for the game play, we decided to host it out of my public locker space on MIT servers. We later decided to move it to it’s own hosting (also on MIT servers).

The re-write was also an opportunity for us to clean up the code. Towards the end of our Java run, we had become sloppy and finished the game with a lot of hacks. The original system design was not upheld as we scrambled towards a project deadline. But this time, we wanted to adhere to our code system design. We came up with an easy design so we could add rooms and tasks with relative ease.

the re-design: gameplay

In our re-implementation, we had to add to our basic gameplay from the Java version of Terminus. We had to really think through our analogy between a file system and a world, bridging the connections between locations with appropriate “terminal commands” or game actions. We took the time to formalize our game map, ending up with this:

The level system is long, providing for a more interesting game experience. The levels were grouped in this manner to teach types of basic skills together, with the intention of later on providing a feature to skip through levels. Our product for the iCampus prize did not involve any feature for skipping levels, but it did eventually teach you to create symbolic links to other levels from your home directory.

(Incidentally, in the game, your “Home” directory has a similar purpose to a UNIX “home” directory.)

One major re-design from the previous version was the addition of an MIT-specific environment where MIT-specific terminal commands are taught. You can get here from home, and it is a cute simulated environment that both teaches MIT-Debathena terminal commands and mirrors features of MIT.

One major design decision was to still include graphics on the page, very much like the original Java version. For the game play, we decided that graphics spice up the text-only nature of the game.

In short

Terminus provides a solution to a common problem at MIT: the computing environment is Ubuntu Linux, and there are many custom commands on the MIT Debathena computing system that incoming students are not familiar with. By exploring the safe (yet challening) environment of Terminus, they can become more familiar with both the command-line environment and the MIT computing environment at their own pace.

The First Version of Terminus in Java

2011-05-10T00:00:00+00:00

A first attempt was made in Java. It was pretty decent for a final project for a non-coding class. And it had sweet graphics.

Before you code: design!

The name of your game can make or break your success. Fortunately, Terminus sounds both sufficiently cool and sufficiently related to the word “terminal” that our job in that respect was done. The medium was also a no-brainer: the ideal metaphor is no metaphor at all. For us, because we were teaching terminal commands, it made the most sense for Terminus to be a computer game.

Before starting full-force on the development of the game, factors like the audience, basic mechanics, plot lines, and outstanding features need to be fleshed out to avoid unpleasantness later on.

Know the problem

We identified a few main barriers to learning terminal commands that we tried to overcome with game design and aesthetic choices:

The terminal is ugly
Documentation is convoluted, hard to find, and sparse
The terminal is unforgiveable - if you mess up there is no “CTRL-Z”
The immediate benefit of learning terminal commands is not obvious

The choices in mechanics and aesthetics attempt to battle (and in some cases mockingly mimic) these barriers.

Know the Audience

Our target audience was high school and early college students. These were people who have use for knowing terminal commands, or are likely to be deciding whether they “get” or “don’t get” computers. We wanted to capture and engage the population that would benefit from learning the terminal - either to advance their chosen academic track or to move them towards a technical education.

On one hand, this audience was an easy one, since we knew them well: we were in the same age group. On the other hand, this audience is a fickle one, hard to please and easily distracted. And yet another problem was that we did not exactly fall within our target audience, since most of us were already familiar with using the terminal. We anticipated problems later on for testing, but went ahead with the design process.

Game design: mechanics and play

A text-based adventure could only be successful if the gameplay, plot, and activities are engaging enough for the user. Our first big challenge was to create a storyline around the various terminal commands that was engaging enough for our target audience.

We settled on a basic gameplay that drew analogies between terminal concepts and fantastical experiences:

computer	abstraction
file system	a series of rooms
terminal commands	spells
the cursor	your position

And instead of commands like “go north”, we used parallels from the computing world to explain the new “spells”:

command	abstraction
cd	“change direction”
ls	“look at your surroundings”
grep	a cute sidekick elf

A huge benefit of the game being themed around magic is that any discrepancies with reality are merely brushed into the voodoo pile. The abstraction of a “spell” alludes to an underlying respect for the systems that you deal with when interacting with the terminal - it sets up the learner to expect to not understand everything at face value.

The game starts immediately with role play: you are a wizard in training, learning the spells of the great masters. You are told you are on a quest to find the sudo password, needing to enlist the help of grep your elf friend. As you interact with the environment, move through the world, and reach the end of the first level, you are given a series of tasks that force practice of basic commands like cd, ls, less, and mv. We identified these four commands has the most important to teach initially, based on merely our own experience. At first our design of the world, challenges, and tasks included practice of an ambitious set of commands, but time constraints forced us to pick a few to focus on. When moving forward, more thought and data gathering needs to be placed on which commands to introduce in order.

The environment itself was designed to be completely safe - you cannot execute arbitrary commands, and there is no possibility in harming the game itself with any mistakes. Unlike a real terminal, Terminus will forgive the user for their mistakes.

Game design: aesthetic

Lastly, we decided that the game would benefit from pictures that added to the allure of the game. Retro-pixel-art graphics would add to the gamification, bringing in silly pictures to reward the user when they typed correct commands.

The aesthetic was clean and simple: terminal on the left, rewarding picture on the right.

Java is the chosen one

I was nearing the end of my sophomore year at MIT when the Terminus project started. At that point, I was not yet a declared computer science major. I had taken 6.01, MIT’s introductory computer science class taught in very basic python, but the language I was most familiar with was Java. I had taken it in high school just 2-3 years before, and was taking 6.005, MIT’s software development class taught in Java, that semester.

11.127 was not a computer science class (by all MIT standards it was “a humanities class”) and therefore deserved the best ratio of excellence to effort. Out of our group of five, it was decided that Shawn and I were going to be the main coders. Because I was less experienced, we chose Java (my then-comfort language) as our language of choice - it would be easiest to code with the least amount of effort.

Absolutely no thought was given to the distribution of the game: we were going for pure ease of finishing. That’s how our first version of Terminus ended up as a Java program.

Back in the day before Github became cool, our code repository was hosted on MIT servers as a password-protected SVN repository. I have since uploaded the (decompiled Java) code to Github, but have lost all SVN commits and tags because of coding inexperience.

Graphics

Emma was excited about trying graphic design, so she took on the role of lead designer, making all the retro-90s-pixel-graphics for the first Java version of Terminus.

Lessons learned

The main takeaway from this design process was that no aspect of the design can be overlooked. We brainstormed and designed the gameplay and aesthetic, but neglected to think about the use case of a deployed version of the game: as a Java app, there is a high barrier to using the game in the first place. We should have approached building this game as a web application from the start. The technical challenges of building the application in Java (and with a time crunch of a final project deadline) were the challenges of novice coders building a system - version control, namespace variables, adequate commenting, and code system design were all issues we ran into that could have been improved for the next time.

Moving forward, don’t make Java apps if you want to have your products delivered, and make sure to use git rather than SVN.

In conclusion, the first version of Terminus as a Java application made a beautiful final project for 11.127/CMS.590.

Playing Zork on Linux

2011-04-28T00:00:00+00:00

The inspiration behind Terminus, Zork, is a fantastic game. Here’s a guide for how to set it up to play on your Linux machine (tested on Ubuntu >= 12.04).

Download

First, you need to download the game itself. Here is the link from Infocom, the company that was created by the original programmers of Zork. The Mac binaries of Zork I, Zork II, and Zork III are all available.

Software packages

You need to install the following packages:

sudo apt-get install frotz uudeview

frotz will be used for running the game, and uudeview is for uncompressing the files.

Go go go!

Download the .hqx file of your choosing from the Zork download page.
Move the .hqx file from the download location to a location of your choosing using the mv command.
Uncompress the .hqx file using the uudeview command with the -i flag (to disable interactivity).
```
uudeview -i zorki.hqx   	
```
Use the frotz command to play.
```
frotz ZORKI  	
```
PROFIT!

Enjoy the fun that is Zork!

Gamification and a Linux Learning Game

2011-04-15T00:00:00+00:00

What started as a final project for a class ended up as an effective Linux-learning game.

The beginning: a class

This semester (Spring 2011) I took one of the most enjoyable classes I have ever taken at MIT: 11.127/CMS.590, or Educational Games, taught by Professor Eric Klopfer from the Urban Studies and Planning department. (Since then, the class has been renamed Computer Games and Simulations for Education and Exploration.) The main goal of the class was to discuss and utilize gamification techniques to create games that were both educational and fun. At the end of the semester, our project groups were to use the gamification principles we studied to create effective learning games.

Gamification

The idea behind gamification is simple. “Gamification” is the act of turning something into a game. When applied to education and learning, it is even simpler. You make something into a game, and learners find it more fun. Because learners find it more fun, they learn more. Although education and gaming experts disagree about exactly what constitutes gamification, a few sample characteristics are:

Competition (either with yourself or against others)
Narrative (plot, characters)
Exploration (giving the user interesting choice)
Rewards (points, virtual currency, stars)

(partially edited and bastardized from the Wikipedia article)

Services like Foursquare thrive on the idea of gamification: you get points by checking in to a location and earning rewards. But less obvious examples are also elements of gamification. For example, Github’s repository “stars”: and Yelp’s compliment icons: These icons and rewards give the user freedom to explore the possibilities of the environment, creating a persona for themselves in whichever way they choose, possibly competing against others for particular achievements.

One easy way to gamify something boring is to relate it to something more fun. Recycling bottles outside the supermarket gives rewards: you get money back! Safety trainings at work become increasingly similar to dramas about losing fingers, complete with suspenseful music. What is more fun - listening to someone talk about safety or watching a movie?

In the recycling example, the intent is not to educate, but rather to recycle as much material as possible. The relationship between money and materials is made obvious and the metaphor is clear: materials == money. You recycle more, you get more money (and the benefit to you is a mtaphor for the benefit of recycling on society). In the safety video example, there is a real educational goal. However, the relationship between the product and the gamification is completely off: safety is serious, but the gamified movie is not. Dramatic movies are purely for entertainment, so the gamification of the safety video exactly opposes the inherent message. Taking these two differences to light, we take anecdotal evidence for the success of the two gamified activities: in a high school classroom, you hear students talking about collecting recycled bottles to earn spare change, but while watching the safety video you hear sneers and laughs around the room.

From this we learn a lesson: the closer the metaphor is to the desired lesson learned, the more effective the metaphor.

The task

For the last group assignment for 11.127 (to create any kind of game in any medium with significant educational value), my group and I decided to apply exactly this last principle - closely relating the metaphor to the lesson - quite literally.

The context

The Linux command-line terminal is a daunting black box. First looking at it, it looks like a void of nothingness waiting to eat you alive.

But if you’ve ever used a terminal, you know that it’s like exploring an unknown abyss, mapping a new land, discovering something new. For those who have played the 1977 interactive fiction text-based adventure, Zork, this is nothing new. Zork, the quintessential text-based adventure game written at MIT from 1977-1979, is arguably the most well-known text-based adventure game, originally written by Tim Anderson, Marc Blank, Bruce Daniels, and Dave Lebling from the MIT Dynamic Modeling Group.

For a more detailed game-oriented history of Zork, check out this Gamasutra article.

But Zork was only played by computer nerds of the 1970s (and beyond). To play it required at least a familiarity of a terminal (back then it was a DOS box, much scarier than today’s modern Linux terminal). (Incidentally, if you want to play it and use Linux, here’s how.)

By today’s standards, Zork is not a “modern game,” but back then, it used the most advanced user-input techniques of the time: the keyboard and the DOS prompt. Shockingly (or perhaps not), the text-based adventure game model mimics what the programmers of that era knew inside and out - terminal commands.

The main idea; the main goal

Given the similarity between a user-terminal interaction and a user-text-based-adventure-game interaction, the Terminus team decided to tackle the problem of teaching users how to use the terminal through a gamified text-based adventure game.

The main goal: to make the command-line terminal a less scary place. To use the techniques of gamification to teach terminal commands to users.

The original team

The original team was formed after discussion about the game idea during the 11.127 class sessions: Shawn Conrad ‘12/MEng ‘13, Michaela LaVan ‘12, Michele Pratusevich ‘13, Emma Tolley ‘11, and David Zhou ‘12 were the original team members. Most of the artwork credit goes to Emma Tolley, with later artwork being added by Shawn Conrad. Original storyboarding by Michaela LaVan and David Zhou.

Michele Pratusevich, a pathological dilettante

Favorite Podcasts 2019-2021

Favorite Podcasts 2018-2019

Lasercutter Memes

Memes

The Final Product

Protecting Yourself Against rm

Why I Left Amazon

What I did at Amazon

Nagging Feeling

Finding Root

Summary

Blogging with Jupyter for Learning Julia Part 2

Getting LaTeX Equation Numbering in Jupyter Notebooks

Getting LaTeX Equation Numbering in nbconvert

Conclusion

Favorite Podcasts 2017-2018

Deep Learning Approximation

Abstract

Details

Blogging with Jupyter for Learning Julia

My workflow

Steps 1 and 2: Jupyter Notebooks

Step 3: Convert to HTML

Step 4: Create a new post

Step 5: Publish

References

Favorite Podcasts 2016-2017

Installing Zim Wiki on OSX

Installing Zim as a stand-alone app

Error 1: libxml2, or in general missing packages.

Error 2: libgtk-quartz-2.0.0.dylib

Word Frequency in the King James Bible

An example

A Fictional Middle East

the future godless levant

MEET Fellowship

MEET summer 2013 on mostly academics

the task and the team

the summer preparations

the students and the instructors

the summer

the projects

the end

MEET project descriptions from Summer 2013

MEET the program

MEET in general

me and MEET

MIT Graduation Cap

My graduation cap

EECSCon Poster

Education Designathon and iCampus Prize

the education designathon

iCampus: the competition

the Terminus story

the re-design: technical details

the re-design: gameplay

In short

The First Version of Terminus in Java

Before you code: design!

Know the problem

Know the Audience

Game design: mechanics and play

Game design: aesthetic

Java is the chosen one

Graphics

Lessons learned

Playing Zork on Linux

Download

Software packages

Go go go!

Gamification and a Linux Learning Game

The beginning: a class

Gamification

The task

The context

The main idea; the main goal

The original team

Getting LaTeX Equation Numbering in `nbconvert`

Error 1: `libxml2`, or in general missing packages.

Error 2: `libgtk-quartz-2.0.0.dylib`