Naitian's Blog

Cultural collapse

2024-08-16T00:00:00Z

There has been a bit of talk about model collapse, spurred by this Nature paper that was published a few weeks ago. The paper demonstrates some theoretic and empirical results about how training new models from data generated by previous iterations of the model can result in degenerate models.

There's been a fair amount of criticism of this paper, mainly centering on the fact that the conditions tested in the paper don't really reflect the way synthetic data is used to train models in the real world.

I'm not particularly worried about the potential of model collapse. There's lots of active research on how we can make use of synthetic data, and post-filtering seems like a tractable and valid way of avoiding some degenerate cases. What I've been thinking about more is a sociotechnical problem: the influx of AI-generated content may not be harmful for training future models, but I worry that the reification of content generated by models that only have the shallowest conception of meaning can result in an ecosystem in which cultural artifacts are slowly leached of any depth. Model collapse doesn't bother me as much as the potential of cultural collapseMaybe this term is a little hyperbolic, but counterpoint: maybe not? does.

Layers of meaning

Culture is a fuzzy object. I approach culture as socially negotiated meanings of signs. Since I work on language (broadly defined), let's first consider how this definition plays out in language as a cultural artifact. At the most basic level, we consider words (signs) to have referential meanings. The word "dog" evokes some conception in your mind of the four-legged mammal that wags its tail and barks.

But there are other kinds of meaning as well: there is the social meaning about regional identity embedded when someone, for instance, says "pop" instead of "soda".https://www.popvssoda.com There is meaning in interaction: it is meaningful to respond to a question with silence, even though no words were ever uttered. And speech is not only referential, but performative. Uttering "I do" can marry a couple; saying "I bet you it will rain tomorrow" initiates the wager (if the interlocutor accepts).These examples are from J. Searle, How to do things with Words. There is even meaning embedded in the way we dressPenelope Eckert, Variation and the Indexical Field and the make-up we apply.Norma Mendoza-Denton, Muy Macha Within all of these semiotic fields, there is structure and meaning.

If there are multiple aspects of meaning, what kind of meaning do language models learn? They are built on the idea of distributional semantics: words take on meaning by how they relate to other words. Food is the set of things that you "eat". Eating is what you do to "foods". This relational system of meaning is internally useful for the model, and generally maps on relatively well to how we interpret language, but the meaning making for us happens when we read the tokens that the model outputs. It's at that point that we decide that "dog" means the same thing to the LLM as it does to you and I.

This is pretty effective in practice, and I find distributional semantics to be a pretty compelling approach to understanding meaning. But it's worth considering also what aspects of meaning aren't learned in this scheme. Introductions of distributional semantics often quote computational linguist John FirthFirth, A Synoposis of Linguistic Theory as saying "You shall know a word by the company it keeps." But in that section, he explains that collocationalA word's appearance in relation to other words. meaning is but one aspect of meaning, and that collocation should not be mistaken for context, which is sociocultural. Meaning takes place across words, but also all kinds of other signs. Modern systems are learning aspects of meaning that are largely removed from socialcultural context!

What's concerning is that, for the most part, companies developing AI products are okay with this. At minimum, there is a lack of critical engagement with how language can construct power dynamics and social structure: to build systems that serve a particular language variety means neglecting the diversity of other ones. And this is not just hypothetical. Studies have shown, for example, that speech recognition technology works much worse for Black English speakers than white ones.Koenecke et al., Racial disparities in automated speech recognition

What is perhaps more insidious, I think, is when people build these systems to engage with culture. Like this startup whose ad was floating around the internet a little bit ago:

What bothers me isn't even the product necessarily; there are instances where simplifying text might be useful! But I object to the problematization of "difficult language", and especially to the implication that your reading potential is measured by the number of book summaries you can ingest. What aspects of meaning are we losing when we focus solely on the plot? Language is meaningful, and we need to be intentional about which aspects of meaning we keep and which we discard.

This temptation to boil everything down to the essence reflects a total misunderstanding of the point of the exercise in creating and consuming culture. In trying to distill the plot, we may have lost it altogether.

The nature of the enterprise

So what are we trying to do here? Recently, there was an ad for Google Gemini that caught some viewers off guard. A father asks Gemini to write a fan letter on behalf of his daughter.

To many people, myself included, this seems to miss the point of writing a fan letter entirely. But why? Pegah Moradi, a PhD student at the Cornell I-School, wrote an excellent piece about the autopen, the machine that can replicate signatures.Moradi and Levy, "A Fountain Pen Come to Life": The Anxieties of the Autopen In the essay, she covers three cases in which use of the autopen elides social values that we attach to the act of creating a signature: authenticity, accountability, and care.

That is to say, the shape of the signature doesn't contain the meaning, but rather what the signature signifies. And this signified meaning comes because we have historically agreed on the cultural significance of a signed name. To mechanically create or recreate the signature outside of that context reduces its meaning. To generate a letter removes the labor of care that gives the letter meaning in the first place. The "grammar" of the fan-mail ritual requires the work that goes into constructing the letter; to remove that work results in a semantically vacuous interaction.

Google's assertion that generating this letter is equivalent (or preferable, even) to the act of writing one is an erasure of the richness of cultural meaning that gives the ritual of fan-mail its significance. It reifies the idea that culture is reduced to the tokens which comprise the artifact; culture becomes a decontextualized facsimile of itself. This is what I mean by cultural collapse.

In my opinion, the point of writing, of art, of creating and consuming culture, is to create meaning, not to transmit it. I write these words not with the hope that you will think my thoughts, but that they will play a role in inspiring your own.

I don't mean to suggest that culture and computation are mutually exclusive. My own research is all about computationally studying these other aspects of meaning -- for example, what are the different meanings contained in condolence-givingZhou and Jurgens, Condolence and Empathy in Online Communities or embedded in the meme templates that we choose to use on Reddit?Zhou, Jurgens and Bamman, Social Meme-ing In fact, this kind of work has really been enabled by the great progress in NLP and computer vision. But culture as it exists around is incredibly rich with layers and layers of meaning, and we need to think critically about which meanings we are computing on, and which we are ignoring.

Shaky writing

2024-06-04T00:00:00Z

It's been a minute.

I recently received a kind email from a reader who asked me how things are going. This was a pleasant reminder that others actually read my writing, and a less pleasant reminder that it has been a while since I've posted on this blog.

This hiatus hasn't been due to a lack of inspiration; in fact, there's been a lot on my mind recently about grad school, my research, and what it means to "study culture" empirically. I have wanted to write about all of these things. So what gives?

I think, since starting my PhD, my relationship to writing has changed a bit. In the past, I assigned very little stakes to the writing that I put out (in fact, this wasn't really something that I thought about.) But now I feel much more ownership of my words and ideas and, with that ownership, a greater pressure to only share the good ones.

Perhaps I am placing too much value on this blog, but I would like to use this platform to discuss ideas that I find meaningful. To an extent, I think this does warrant a deeper, more critical level of engagement with what I am writing.

On the other hand, when I've started drafting posts, I've found myself paralyzed by indecision or talking myself into knots. I am compelled to endlessly explicate, constantly contextualize; I find myself exhausted, paragraphs deep, and no closer to making my point. I need to make my peace with the fact that discourse is ambiguous, messy, and interpretive. I can't expect to fit an entire discourse into a single turn, so I need to just put my thoughts out there and start talking.

I've recently begun reading The Archaeology of Knowledge. At the end of the introduction, Foucault talks about writing with uncertainty:

What, do you imagine that I would take so much trouble and so much pleasure in writing, do you think that I would keep so persistently to my task, if I were not preparing – with a rather shaky hand – a labyrinth into which I can venture, in which I can move my discourse, opening up underground passages, forcing it to go far from itself, finding overhangs that reduce and deform its itinerary, in which I can lose myself and appear at last to eyes that I will never have to meet again.

And so too shall I proceed, hands shaky, into the labyrinth.

Reflections 2022

2023-01-02T00:00:00Z

New Year, New Me.

I look forward to writing these every year, because time just flies by and I don't have much chance to take a step back and let life sink in. I am particularly savoring the opportunity this year because it has been an eventful one.

This Year in Numbers

250 Github contributions (back on the decline, but that's ok)

700 miles ran (including 1.5 marathons!)

324 New York Times daily crosswords completed

1 musical attended (Jagged Little Pill at the Golden Gate Theatre)

1 cap and gown 🎓

Highlights

This was the first January in 16 years that I did not have any classes. A short-lived respite; my classes start again next Tuesday. I ran 79 miles and got my first PhD program acceptances. Also found out about Wordle (what a moment that was.)

February, though short, was also eventful. I ran 79 miles, got my first Covid booster, and traveled to Madison, WI. It is a neat city with pretty buildings, a cool art museum, and a lake that you can walk on! Towards the end of the month, I flew out to LA with some friends, which leads us into...

March was the month of travel for me. I ran 106 miles, including my first half marathon, and flew for probably a few thousand more. It started out with the LA trip; we went to Joshua Tree (who knew the desert could be so pretty), Pomona (who knew a college campus could be so pretty), and the Academy Museum of Motion Pictures (who knew Studio Ghibli films could be so pretty(A lot of people, actually)). March was also the month of grad school visits, so a week after getting back from Los Angeles, I flew out to Switzerland for the EPFL visit days (and for Switzerland). It was a really great experience, and the entire country is so picturesque. After Lausanne, I visited Jungfraujoch and Zurich. The day after returning from Zurich, I drove to Ithaca with my parents to visit Cornell. It was gorges, and snowy, even by my Michigan standards. Two days later, I flew out to Berkeley, CA, which had neither gorges nor snow, but did have some beautiful sunsets.

By comparison, April was a bit more relaxed. I walked for graduation and ran 148 miles.

May was the same way, largely spent in Ann Arbor and at home, just taking a break and running (for 157 miles). I did, however, spend about a week immersing myself in Hayao Miyazaki's directorial oeuvre: I watched, in the following order, The Wind Rises, Lupin III, Nausicaä, Laputa, Totoro, Porco Rosso, Princess Mononoke, Spirited Away, Howl's Moving Castle, and Ponyo. I had watched Kiki's Delivery Service a few months earlier, in LA.

In June, I went backpacking for the first time, hiking around 20 miles in two days. In the future, I will bring more camp activities and spend less time walking. It was also the month of the Banff Marathon, which I had been training for the whole month. My parents and I flew up to Banff (absolutely stunning), where we visited Lake Louise, picked up my packet, and prayed for the rain to go away. The race was a totally unique experience; I saw several rams along the route, and it was just breathtaking the whole way throughWhich, granted, is not idea for aerobic activities.. After the race, I limped all the way to Seattle, where I visited some friends.

I officially moved out of my room in Ann Arbor in July.

In August, I moved to California and started school. There's a lot to say about that, but I will leave it at that for now.

September and October flew by. I got my California ID, my parents came to visit, and I submitted another GRF application (second times the charm??)

I saw Jagged Little Pill with Isabelle in November. We also went on a hike in Marin (that lasted a bit longer than expected...). I celebrated my 23rd birthday (oh my god) and went on strike. For Thanksgiving, I flew to Seattle to visit some friends and we took a weekend trip to Portland (also a great city, with a massive bookstore.) Michigan won The Game. I took the Amtrak back from Seattle (unfortunately, most of the trip was in the dark) and continued strike action.

And finally, in December, I came home for the first time since I left for California. I watched the World Cup finals with my dad, who is a massive futbol fan. Now I am sitting on the couch, into the last week of break, wondering where all the time went.

Reflections

I've had a harder time writing this post than in previous years. Last year, I wrote

"I'm temporarily stuck looking ahead into a bright cloud of complete uncertainty."

In many ways, much of that uncertainty is gone. This time last year, I didn't know where I would be living in a year. Now, I know where I will be for the next five or six.

But, like a new pair of shoes, I have stepped into a new life in which I'm not yet comfortable. There is the nagging rigidity of preformed expectations: the program milestones I need to achieve, the ideas I had about what grad school would be like, and what I thought my twenties would entail. At the same time, it feels alien: moving to a new place, adopting a new habits. Right now it feels like an awkward fit, not yet broken in.

I have a pretty good idea now of what the next few years will be like -- of what I will be doing and where I will be. The Berkeley iSchool has a pretty comprehensive guide on the timeline to do a PhD. But in between those milestones will be thousands of ephemeral moments (and a handful of defining ones) that are entirely unknown to me, and it is those that I look forward to the most. These moments are the wrinkles and creases and scratches of a well-worn shoe that shape it snugly around my feet.

Breaking in a new pair of shoes can be frustrating and sometimes painful. I am not the most patient person. I find myself sometimes yearning for the comfortable, lived-in, familiar past. But I know that this feeling will diminish with time, as I settle into the rhythms of this new part of my life. There's no other way to break in a shoe than to just start walking.

So happy new year. I guess I'll get going now.

How to ask questions at grad visits

2022-12-27T00:00:00Z

Grad school visit days are an opportunity to learn more about your potential advisor and school. You'll need to make some tough decisions in the near future about where to attend, and you're going to want as much data to make this decision as possible.

This past semester, I took a qualitative methods classA fascinating course, because I come from a very quantitative background., where we learned about conducting interviews. Here are a few tips from that course which I wish I'd known when I was talking to professors and grad studentsThese are just tips for getting better information, but don't stress out about following these to the tee (or even following them at all)!.

Interview Strategies

You want to know what your life will be like at school X working with professor Y for the next four to six years. How do you get that data? In this case, you ask others about their experiences, and use that to inform your mental model.

But question-asking is a lossy information transfer. People frequently forget to mention things, make ambiguous statements, or have trouble putting their thoughts into words. It is your task to aid them in this process, so that the information you receive is a faithful interpretation fo their experience.

1. Be prepared

It's best to have a rough plan going in. Come up with a couple of themes that you want to cover and some questions you want ask. When I was talking to current PhD students, I usually asked about their experience working with X advisor, living in Y city, working in Z university. I would also ask them how they decided where to attend This last question usually yielded insightful responses..

Remember, though, that this is just a guide, and the nature of an interview is organic. So, it is best to have these questions and themes at the back of your mind as you have a conversation with whoever you are talking to.

2. Be specific

Sometimes it is tempting to ask broad questions, since it is hard to know what specific questions to ask. This makes sense! After all, you have never done a PhD (and possibly never even gone to grad school), so how would you know what it is you want to find out?

However, broad questions elicit broad answers, and vivid, detailed answers are more useful for you.

So instead of asking a question like

"What don't you like about X University?",

try asking something more specific like

"What are some logistical frustrations about being at X?".

Or even better, ask about specific experiences, like

"Can you tell me about a recent time when you felt frustrated by some logistics at X?"

In general, if you can ask about experiences, those will result in the richest descriptions, since people can draw on their memories instead of trying to generalize.

3. Ask follow-ups

Another way to get richer answers is to follow up on anything you find ambiguous, or that you'd like to learn more about. This may seem obvious, but for me, this is actually quite challenging, because you need to quickly synthesize what they said and respond.

It might be helpful to think of some likely follow-ups when preparing -- this will also serve as practice for coming up with follow-ups. You might also want to note down what follow-up questions you thought of in previous interviews or visits, so that you have them top of mind in the future.

4. Be creative

Though meeting in a coffee-shop or on Zoom might be the easiest, it might not be the most effective setting. If you're visiting on campus, consider maybe doing a "walking interview" through campus or meeting in the office space. This might trigger certain memories, experiences or anecdotes that people may forget to mention otherwise.

5. Take notes

Remember to remember! It can be hard to have a conversation while scribbling down notes, so I recommend jotting down some thoughts after the meeting instead. It will still be fresh enough for you to remember the important points, and this allows you engage more actively in the conversation instead of trying to multitask.

Concluding thoughts

When I was going around doing visits, I had a rough idea of the things I wanted to know about, but the questions I asked often resulted in the same set of general, surface-level answers.

Hopefully, with some of these tips, you can be better prepared to have deeper conversations that result in more informative answers. But don't miss the forest for the trees! The important thing is that you are meeting with people and learning about the campus and surroundings in a way that is comfortable for you.

So if the strategies I've mentioned provide some helpful guidance for you, great! But if they seem awkward or difficult to implement, don't worry about it. Just do what feels good for you.

I think interviews and visits two of my favorite parts of the application process. I had some insightful and inspiring conversations. I hope you enjoy this process as well. Good luck and have fun!

The 600 Mile Marathon

2022-06-23T00:00:00Z

Starting at the finish line

I ran the Banff Marathon on Sunday, June 19th. I finished in 4 hours and 11 minutes, but the race was the culmination of a training effort that took months. It was the most difficult thing I have ever done.

Starting at the start (or why I did this to myself)

I graduated a semester early, so I was searching for something to fill up my extra time. Having just submitted my grad school applications in December, I decided to run a marathon, an ambitious undertaking that is frequently compared to a certain other one that I recently committed toWhy do I want to do a PhD?.

A natural-born athlete, I am not. I was on the track team in high school, but as a pole vaulter so I could minimize the amount of running to about 60 feet at a time. I tried and failed to pick up distance running as a hobby multiple times in the past. Being a runner was something I had always aspired to, but never actually achieved.

I wanted to run because it seemed like a cheapIt turns out running shoes are not cheap., healthyIt turns out it's pretty common to get injured running. activity that I could do anywhere. But more importantly, I wanted to run to prove to myself that I could. I figured the push to a marathon finish would yield some amount of self-discipline and other useful lessons I could take with me as I started my PhD in the fall.

The journey, not the destination

Having explicitly decided to run a marathon as a character-building exercise, here are the character-building lessons I learned in the process (in no particular order):

There will always be bad miles. It's impossible to run a lot and feel good about every mile. The bad runs -- the ones that were slow or painful or just felt harder than they should've -- are inevitable. Just accept it and look forward to the next run.
Take time off to recover. I was guilty of not doing this enough in my training block, which resulted in the knee injury I'm hobbling around with now. It's tempting to stick to the schedule, especially when there's a set deadline, but that can lead to worse injuries and worse performance in the future.
Be consistent, but be flexible. I traveled a lot in March and April visiting grad schools. My schedule was all over the place, and I frequently had flights on days I was supposed to run. This meant I had to shift my training around to accommodate. That can be difficult because I was leaning heavily on a set training plan to make up for my lack of experience, but it also meant I got to go on some very scenic runs in Switzerland and Ithaca and Berkeley (with lots of hill running).
Run your own race. I'm a competitive person, and I feel the strong temptation to pass people, but I had to learn to run at my own pace. Getting a running watch helped me to keep my own time, but I also learned to accept that everyone is training at different levels. I set a time goal I'd personally be happy with and focused on that instead of comparing myself to others.
Lean on your support network. Having (and finding) a community also helped me a lot. My friends helped me so much with encouragement and general enthusiasm for my plan, and the broader running community is so supportive and willing to share knowledge with runners at all levels.
"Just keep running." When push came to shove and I was feeling all sorts of pain at mile 24 of the race, I knew I had to just push myself to run to the finish. For the last 2k of the race, I kept repeating to myself the mantra of "just keep running". Focusing on putting one step in front of the other, I tried to ignore the pain. Eventually, I rounded the corner and the finish line came into view.

Finishing past the finish line

Crossing the finish line, I felt such an overwhelming sense of relief that I burst into tears. The race didn't just span the 26.2 miles I had run that day, but the 600+ miles I had run in the months leading up to it.

Within an hour of finishing, though, I already found myself thinking about the next race I wanted to run. So here's biggest lesson I learned in this whole experience, and one that I didn't understand until the very end: there is always going to be the next race.

I have a habit of getting into obsessive sprints: two days to code a website, six months to run a marathon, a year to finish a paper. Even when I was training for an endurance race, I approached it with a fixation on a single, short-term goal: finish the Banff Marathon in June.

That approach has aligned closely with my world so far, which was one delineated by quarters and semesters and final exams. But looking into the future, the terminal points are becoming less clear, and short obsessive bursts of energy either won't be enough or will cause me pain in the long runHeh. Get it?.

Facing this reality is scary, and I'm sure internalizing and adjusting to it will be hard -- maybe the most difficult thing I have ever done. But I've learned a lot about running long runs and doing difficult things in the past few months; I feel confident now that I'll learn plenty more in the years to come.

Why do I want to do a PhD?

2022-06-15T00:00:00Z

In a couple of months, I'll be starting my PhD at UC Berkeley School of Information. The whole grad school application process was a wild ride, and something I'd like to write more about in the future, but for now, I'd like to write a bit about my motivations for deciding to do a PhD in the first place.

Hedges (and acknowledging the audience (that's you!))

If you're considering applying to grad schools, please don't take this post as anything other than my own thoughts as I navigated this decision. If you relate to them, that's great! Maybe you should do a PhD. Maybe neither of us should (whoops).

If you are someone who has done a PhD in the past (or are in the middle of one right now), I'm not sure why you're reading this, but if it reminds you of your own motivations, that's great! If it doesn't... Different strokes for different folks, I guess.

If you are me from the future, hi! I hope things are going well, and if they're not and you're really doubting me for signing you up for this, here is why I (you (we)) decided to do it in the first place.

Anyway, I decided to do a PhD because...

...I'd like to satisfy my curiosity.

I became interested in doing research in undergrad because I read a paper I really liked. It was the first time I enjoyed reading a research paper, and that made me realize that there's scientific research happening that I'm actually interested in.

I would like to read more of those types of papers. I would like to read more papers full of other people's interesting ideas, but there are also papers I would like to read that test my personal hypotheses about the world. Because I don't have the resources to fund my own research lab and tell people to write those papers, it seems the next easiest thing to do is to tell myself to write those papers. So that then I can read them.

...I want to get better at research.

The flaw in the above plan is that I'm not very good at writing papers right now, so I need to get some practice operationalizing research ideas, writing code, synthesizing literature, (and writing papers). If only there were some kind of educational institution in which I could practice conducting research.

...the alternatives weren't as appealing.

I've also done software engineering and data journalism internships.

I wasn't that thrilled with my SWE experience: the work was sometimes interesting, but I missed having a sense of ownership over what I was doing. In my research experience, I owned my work, and I liked that feeling. The flip side is that there's less of a mental safety net -- failures feel more personal. There's a constant pressure to be productive because if you're not working on your project, it's not like someone else in the org will be. But to experience higher highs, it makes sense you have to also take the lower lows, and it was a great feeling to see my name on a published paper.

I'll write more about data journalism in the future probably -- I worked on the data graphics at NBC News Digital for a semester. It was a generally fantastic experience, but I felt two frustrations: 1) you have to work on the news, which isn't always necessarily what you're interested in and 2) it's a bigger ask to use some more advanced methodologies because it'll both take more time and be harder to explain to readers.

...why not?

Finally, it's just something I'd like to do. Why do we climb mountains or run marathons or set out to do anything at all? There are moments where you'll feel great, for sure, but also plenty of pretty terrible moments. But I think any meaningful experience has good parts and bad parts. On balance, having done a PhD will probably make me a more improved person, so it seems like there's not much reason not to do one if I, for whatever arbitrary reason, just want to.

If life is just a collection of experiences, then this is an experience I'd like to collect.

PS

I did the nested parentheticals a couple of times in this post. I think I like it. I hope it didn't bother you too much.

So you want to build a high tech college newsroom

2022-02-16T00:00:00Z

College newsrooms have traditionally been the launchpad for many successful journalism careers. They provide a lower-stakes environment for aspiring journalists to hone their skills, gain an understanding of the industry and make connections.

In recent years, major national newsrooms like the New York Times and The Washington Post have ramped up their tech efforts to revitalize their digital products, and there are many initiatives to help smaller newsrooms keep up with this technological revolution within the industry as well. But despite the growing importance of newsroom engineers, data journalists and graphics developers, many college newsrooms don't offer a space for students with these career aspirations.

A traditional computer science background is also insufficient for the aspiring newsroom technologistNote: there is a huge variance in the types of roles encompassed by "newsroom tech": anything from using data science in service of reporting to building newsroom tools to developing web apps and graphics.. While more traditional software engineering positions exist within the newsroom, many roles (like graphics or data reporting) have different workflows with different timelines and expectations compared to the typical software engineering job. In my experience, the hiring process also differs from traditional software engineering companies. There seems to be a greater emphasis on explaining your prior work, as opposed to the LeetCode-heavy recruiting process in big tech companies. Finally, newsroom hiring efforts are dwarfed by Big Tech, to the point where many students are likely unaware of newsroom engineering as a viable career path at all.

Over the past three years, as a student at the University of Michigan (a university without a j-school!), I've been working alongside other extraordinarily talented students to turn The Michigan Daily into a high tech newsroom: one which prepares students for the code-heavy newsrooms of the future.

Step 1: Sell the vision

In the best case, your college newsroom is the Columbia Spectator. In the worst case, your college newsroom views technology as a perversion of the sacrosanct art of journalism. More likely than not, though, your newsroom is totally unaware of the exciting possibility of newsroom tech (or they have dismissed it as beyond the capabilities of a college paper). In any case, you need to make a strong pitch.

A college newsroom has two missions: 1) deliver quality journalism and 2) develop aspiring journalists. Here are some brief talking points that address both:

Data analysis and statistics skills are important to uncover interesting stories (journalism), provide a new angle (journalism) or even just critically evaluate the truthfulness of certain claims (pedagogy).
The digital medium opens up many storytelling possibilities that increase engagement (journalism) while also allowing students to rapidly experiment with new technologies (pedagogy).
In fact, all this is so true that major national newsrooms have begun doing this years ago!

At The Daily, we were fortunate to already have a web team when I first joined. However, it was poorly integrated and had little buy-in from the rest of the newsroom. This means projects would frequently fail to see the light of day. This underscores the importance of (first) getting the rest of the newsroom excited about your web team and (second) building out the processes and workflows to get projects out the door.

Step 2: Set up a structure

It turns out, college newsrooms work because they've had decadesif not centuries! to figure out how to operate. This includes processes like how to pitch a story, how to train new hires, how to collaborate between sections, etc. You likely have four years at most to build out these processes for what might be a brand new "web team", so you better get cracking!

The first step is to figure out how tech fits into your newsroom. At The Daily, we have a "web team", which falls into the org chart as another section alongside News and Sports and others. You may want to separate out further, since people working on newsroom tools don't produce content. Or you may want to integrate more tightly, since your graphics developers or data journalists need to work with other sections to get stories out the door. Or both. Newsroom tech is a big umbrella, with different timelines and expectations for different types of work.

You also need to determine what roles you want to fill. Since there is so much variety in the type of software you can write in a newsroom, you might want to focus on developing a subset of skills at the onset. At The Daily, we put a lot of effort initially into developing our data graphics subteam. This increased our presence in the newsroom, produced some tangible outputs and gave us the leeway to expand into other areas (like mobile app development and web projects).

Your web team doesn't exist in a vacuum, and you need to figure out how to integrate with the newsroom; what responsibilities will you take on? How will this affect the work that other sections do? For example, you might want to have a chat with the design section about how your graphics developers will fit into the current workflow and what changes might be necessary. How will you produce stories? Will your data team be working with reporters from other sections or pitching their own stories (or both)?

After you make these decisions, you need to communicate it all to the rest of the newsroom. Make sure other sections are aware of the work you're capable of doing, the work you'd like to take on and how that aligns with the work they do.

Step 3: Develop your team

While most college students have at least some amount of writing experience by the time they end up in the newsroom, that's much less likely to be the case when it comes to software engineering. The floor to entry is much higher, since there's a lot of prerequisite knowledge to start producing content. The big challenge is to provide the minimal amount of training for students to start contributing to projects, while assuming minimal prior experience.

Again, the pedagogical value comes mainly from experiential learning. That means your training shouldn't resemble or replace coursework (after all, everyone is already in college to take courses). Offer support and expertise to give students their greatest chance of success (publishing anything is better than nothing), but also provide the room to experiment and fail.

This is something we are in the process of constantly refining at The Daily. The biggest priority for senior leadership is developing a culture for newer members to learn and flourish.

Step 4: Enculturation

Just as your web team doesn't exist in a vacuum, neither does your newsroom. Try to expose your team (and yourself) to the surrounding community of college and professional newsrooms. In my experience, the "news nerd" community of newsroom technologists has been incredibly open and generous with knowledge.

Learn about the processes and workflows other organizations use, as well as the tools and technologies they employ. See what stories other organizations are producing, and how they are executing their vision. This all feeds into inspiration for your newsroom's next big project.

Impress upon your team the possibility of working in the newsroom. Make them aware of various newsroom internships for the summer or during the school year. Encourage them to apply! This gives great insight into how professional newsrooms operate and helps build valuable connections as you advance your career.

The most important thing you can do to guarantee the success of your high tech newsroom is to ingrain an inclusive, productive culture. Get your old members to teach your new members, and get your new members to come back year after year.

Step 5: Profit!

There you go. You did it. Your college newsroom now has an amazing team of software engineers and data journalists and graphics developers and UI/UX designers working on a half dozen different projects for the newsroom. Remember: it didn't start like this. It started with just a handful of people (or maybe even just you) who were excited about the idea of working where tech and journalism intersect.

And it doesn't end like this either: The Michigan Daily web team is still growing and evolving to better serve the newsroom and better serve our students. I can only hope that I helped The Daily take those first steps -- and I hope you might be inspired to take them, too.

Acknowledgements

Thanks to my former co-managing online editor, Parth Dhyani, as well as current MOEs Eric Lau and Dora Guo, who all provided valuable feedback and support (in writing this piece, in The Michigan Daily, and in general.)

P.S.

If you are interested in, or have been in the process of, setting up a more tech-forward organization in the college newsroom, please reach out to me! I'd love to chat with you. You can find me @NaitianZhou on Twitter, or email me at naitian@umich.edu.

If you do tech + news professionally, I'd also love to hear your thoughts. And if you're hiring, I know some very qualified students who would make fantastic interns or employees :)

Reflections 2021

2022-01-05T00:00:00Z

Time flies

Usually I post one of these on New Year's Eve. Unfortunately, I was busy this year watching Michigan playPlay might be too strong a term for what happened on the field that night... Alabama in the Orange Bowl, so here we are, a few days later.

This Year in Numbers

585 Github contributions (a new high score!)

33 more college credits

1 Bachelor's degree (!!)

11 PhD applications

...and a lot of things on my mind.

Highlights

In January, I began my penultimate semester of college (although I didn't know it at the time). I also began my term as one of the managing online editors at The Michigan Daily (more on this later). I also got super into the NYT spelling bee, and I implemented Naive Bayes for homework for the third and fourth time.

In February, The Daily published a couple of projects and stories that I had a hand in: the Statement Love Edition, which I helped coordinate, and a data-driven piece on Covid cases. This would mark the beginning of a lot more rich online content from The Daily. I also got Sunday donuts from Loomi Cafe for the first time. This became a weekly tradition that was unfortunately short-lived, as Loomi closed this December.

March flew by with a lot of Daily work: a bunch more data stories from The Daily, including a multi-part piece on feeder schools that would go on to win an award and get a ton of readers. We also published a special project, reflecting on one year of online classes. Finally, we launched a brand new website, opening up a lot more flexibility in the projects we'd be able to tackle in the future.

In April, I got vaccinated.

In May, it felt like the world once again existed outside the confines of my own room, and I was eager to take advantage. In roughly chronological order, I: helped my family move back to Troy, Michigan (after having moved from Troy just a couple years ago), learned to skateboard, read Pachinko and Abolish Silicon Valley, attended my friend's graduation at UVA and climbed Old Rag in Shenandoah. I also (virtually) began my summer internship at the University of Washington.

I departed for Seattle in June, opting to take the Amtrak Empire Builder from Chicago. This was a two-and-a-half day trip, and I loved every minute of it (give or take). You can read some of my thoughts about it here. Aside from the train trip, I explored lots of Seattle (especially U District), went on a few runs, climbed a couple of mountains, and endured a really killer heat wave.

July contained more Seattle adventures, including more hiking, some kayaking, a trip to Portland, and I got my Seattle Public Library card.

I wrapped up my time in Seattle in August. My parents came to see Mt. Rainier and Olympic National Park with me before we flew back home to Michigan. I also began my last ever semester as an undergrad at the University of Michigan.

In September, I house-sat a cat and it was the best week of my life.

October was a Michigan fall, and I did all of the classic Michigan fall things™. This included a trip to a cider mill with the Blablablab, making my own cider (also with the Blablablab), a couple of backyard bonfires, and (of course) a Michigan football game. I also submitted my NSF GRF application.

I turned 22 in November. Oh yeah, and Michigan beat OSU for the first time in close to a decade. That was a good day.

That brings us to December. If some of these months seem sparse in detail, it's because this past year really flew by -- especially this past month. There were a lot of good-byes, a lot of lasts, and not a lot of time to process all of it...

Reflections

Which I suppose leads us to this section. Some time to process everything that happened this past year and, really, these past three and a half years of college.

It's hard to know where to begin, so maybe I'll contextualize by starting with my last graduation. When I graduated from high school, I felt a sense of completion and a really strong optimism for the future. This is what I wrote in my 2018 reflection:

I can only hope that the next five years will be as fulfilling and interesting and fun as the past five. I hope that, just as I found a home in Virginia, I'll find a home in Michigan, and wherever life might take me next.

What I hadn't anticipated was the tumult. The best way to describe the past couple of years would be careening down the interstate with the windows down, and a stray newspaper just flew into my face. Thrilling, sure, but also terrifying.

I'm ending my years at Michigan a semester early (I achieved this through a convoluted series of events, which is fit for a whole other post...) It feels like I've slammed on the brakes, flown out of the vehicle, and extended this analogy past its breaking point. What I'm trying to say is, I don't feel the same sense of closure that I felt four years ago after high school.

I'm sure this is in no small part due to the crazy circumstances of the past couple of years. Aside from a global pandemic that resulted in my coursework being online for half of the time I was at Michigan, my family has also moved four times in three years, meaning somehow I've accumulated five or six different Michigan zip codes. When I said I hoped to find a home in Michigan, I should have clarified: I'd be content with just one, and not six.

But premature departures, pandemics and Zhou family migration patterns are trivial in the bigger picture of my experience at (in, and around) Michigan. They may have made this ending come sooner or seem quicker in its approach, but I doubt I'd be any more prepared with any amount of lead time. I have put a lot of myself into the people and organizations and life in Ann Arbor, and it's hard to imagine waving goodbye to all of that.

I'm proud to have helped build up two stellar student organizations from close to nothing: the Michigan Data Science Team and the web team at The Michigan Daily. They are in excellent hands now, but it's still hard to say goodbye. But even greater than that, I'm proud to have built so many lasting relationships with people here -- people I can laugh with, confide in, rant to, seek support from. Those are the hardest goodbyes.

Fulfilling, interesting and fun? Definitely.

That brings us to now: I've applied to PhD programs which I'm waiting to hear back from, which means I'm temporarily stuck looking ahead into a bright cloud of complete uncertainty.

Usually, at the end of these reflections, I like to take a look forward into the next year. This time, though, I don't think that's feasible. I don't know where I will physically be this time next year, much less what I'll be doing or what I'll have to look forward to. Just... something interesting, probably.

So I'll bide my time for now, sitting with my feet dangling off a precipice overlooking the entire rest of my life. I think I'll spend the next couple of months savoring the end of the beginning.

Reflections 2020

2020-12-31T08:00:00Z

An R.E.M. song

It's the end of the world as we know it

And I feel fine.

This Year in Numbers

415 Github contributions (making a comeback!)

31 more college credits (I think? I'm starting to lose track...)

12 weeks reading papers this summer at USC ISI.

12 more weeks making plots and crunching numbers at NBC News.

1 musical attended (Hadestown, on Broadway!!)

1 first-author paper published (in Proceedings of EMNLP 2020)

27 bylines from 2 news organizations.

2 new library cards (Boston and New York City Public Libraries)

Highlights

This will be difficult because it feels like time didn't really exist before March, but I'll try anyway.

In January, the Michigan Union held its grand opening before shutting back down due to Covid just three months later. We kicked off a new semester of Michigan Data Science Team with a new set of workshops targeted for beginners. I read The Signal and the Noise by Nate Silver. Finally, after talking to my roommate Parth, I decided to join the data team at the Michigan Daily.

February was short but still plenty eventful. I started working on my first analysis for the Daily, read Fortune Cookie Chronicles by Jennifer 8. Lee, and went axe throwing with MDST. On the last (leap) day, I landed in Boston to visit my friend Nina at Harvard.

This leads into March, where I wrapped up my spring break with what in hindsight was probably an ill-advised tour down the east coast. I wrapped up Boston by getting a library card from Boston Public Library (absolutely beautiful), visitng the Isabella Stewart Gardner museum, getting Chinese food and desserts from Chinatown, and seeing the ducks in Boston commons. After a harrowing sprint to South Station, I made it to New York, where I had more Chinese food, attended a comedy show at my hostel, and visited the New York Times building, the Highline, the Chinese American History Museum, the New York Public Library (also very pretty), Hadestown on Broadway, the MoMA, and then sprinted to Penn Station to catch an Amtrak to DC. From DC, I continued to Pittsburgh, catching up with friends at CMU and Pitt, before driving back up to Ann Arbor. All this took place over the first week of March, after which everything descended into chaos: we had primaries coverage for the Daily, immediately after which Michigan shut down for Covid. March ends with making a premature departure from campus.

After a very eventful March, April was boring by comparison, marked mostly by online classes and exams as the semester wrapped up.

May was mostly enjoying my summer vacation before school began and finalizing my paper for EMNLP. I also resolved to sew myself a backpack as a summer project only to discover all the sewing machines were out of stock! I started my research internship at USC after Labor day. Finally, I watched as SpaceX launched the first astronauts into space from the US in close to a decade. An early interest in rockets and space really propelled me onto a STEM track, and this was a reminder of what had inspired me so many years before.

In June, I finally managed to buy a sewing machine (but no materials yet). I was introduced to crossword puzzles and proceeded to ~~waste~~ spend a few hours every day on crosswords...

July is when my backpacking plans went into full force as I finally received my supplies. Plenty of mistakes were made, and I had to disassemble and repair the sewing machine more than once.

I finally, in a mad dash over three days, finished my backpack in August. This was just in time to move back onto campus, where I would proceed to take all my classes from my room and leave the backpack sitting dejectedly in a corner. I also made some fantastic productivity purchases: a nice chair from Ikea and a standing desk (amazing).

In September, I started at NBC News and covered the first presidential debate my second week of work. It was an exhilarating experience for someone totally new to the news scene as we worked to debug our vis literally up until the minute the debate began. I received notice that my paper was accepted to EMNLP. I also deep-fried food for the first time and it was a resounding success. Finally, I bought a crossword subscription, much to the detriment of my productivity.

October was dominated by covering Presidential debates (the ones that weren't cancelled, at least), prepping for EMNLP, crosswords and other word games, and enjoying the last of the good Ann Arbor weather.

In line with March and September, November was quite eventful. Election week coverage, deep frying more food, attending and presenting at my first conference, and celebrating my 21st birthday (by not going to any of the bars)! Somehow, a lot of these things also happened in the same week...

Finally, December saw the end of the semester and my internship at NBC. It also saw the renewal of my crossword and Netflix subscriptions, both of which I was not comfortable maintaining during the semester.

Reflections

This is the end of a very eventful year. It's one that I can safely say I did not see coming, filled with disappointments and hardships. But it has also had some really amazing moments. With the switch to a new normal in terms of media of communication, I've been able to reconnect with many friends I've lost touch with over the years. I've also had so many fantastic opportunities professionally, and I've met some really fantastic people at both USC and NBC.

And in the midst of personal, national, and international chaos, I've grown to appreciate so many of the things I used to take for granted: seeing my friends and loved ones in person; being able to travel to China to visit my grandparents; seeing the bottom halves of strangers faces. I've also learned to take care of myself in trying times: to create a space I want to live in; to find joy in my routines (think you crosswords); to reach out to my friends for company and support.

Every year sees ups and downs, setbacks and growth. This year was no different in that regard, and I'm confident that 2021, whatever it has in store, will also bring both plenty of disappointments and plenty of joy. In many ways, my limits were tested this year -- in some cases, I grew and stretched those limits. In others, I saw the cracks and learned when I should ease back. The trials of this past year have taught me a lot about myself.

I'm looking forward to a year filled with new joys and new disappoints. I'm looking forward to a year where I can see and hug my family and friends. I'm looking forward to the year I start my senior year of college, where I meet new people and experience new things. But mostly, I'm looking forward to a year that will hopefully chill the fuck out.

Good night, 2020. Good morning, 2021.

Understanding D3

2020-05-27T07:00:00Z

This is a first draft. I will likely revise (multiple times) in the future for clarity. But hopefully, even in its current state, you might find this useful.

The strange case of D3

Dr. Jekyll: D3 is famous for being an incredibly versatile visualization library.

Mr. Hyde: D3 is infamous for having a steep learning curve and being difficult to understand past copy and pasting examples.

I have experienced the dark side of D3, but recently, I feel as if I have had minor breakthrough, so hopefully I can in turn provide you with some sort of lightbulb moment.

But just as a disclaimer: in no way do I profess to be an expert (or anywhere close). I've still a lot to learn. I just think something clicked for me.

The big idea (and why it's so hard)

Having gained some understanding, I now know this is the mantra you must repeat to yourself.

D3 gives you functions to work with data bound to elements.

Does that sound kind of familiar? It probably should. Here's the first sentence on the D3 website.

D3.js is a JavaScript library for manipulating documents based on data

and later on...

D3 allows you to bind arbitrary data to a Document Object Model (DOM), and then apply data-driven transformations to the document

That leads me to believe D3 is difficult to learn because it relies on a very simple and powerful concept -- too simple to warrant understanding when just starting out and too powerful to appreciate without building and seeing lots of examples.

Let's start with just a line

We will begin with the three basic parts to working with D3. We will have an element in the DOM (element). We will have some data, with which we'll draw a line (data). And we'll use D3 to put those things together (functions).

D3 has a lot of conventions. These are useful to learn as a stepping stone to learning the concepts, so I will try to use a few of them here.

This is what the result looks like.

Figure: Just a Line Plot

Set up

Let's start with the easiest part to set up: the DOM. This is all the HTML I have:

<figure class="example">
<h2 class="figure__title">Figure: Just a Line Plot</h2>
<svg>
</svg>
</figure>

We have a simple dataset (5 points to form a line).

const X = [1, 2, 3, 4, 5];
const Y = [3, 5, 1, 6, 9];

Again, nothing special.

The Code

This is the interesting part, but don't be intimidated. In fact, this chart is made with only 16 lines of actual code.

First, let's define some variables we want to keep track of:

let width = 600;
let height = 300;
// this is the margin convention
let margin = {top: 5, right: 0, bottom: 30, left: 30};

Remember our mantra: data, function, elements. Again, let's start with elements.

Elements

// Create elements
// select SVG
let svg = d3.select("figure.example > svg")
    .attr("width", width)
    .attr("height", height)

// create chart
let chart = svg.append("g")
    .attr("transform", `translate(${margin.left}, ${margin.top})`);
let chart__line = chart.append("path")
    .attr("fill", "none")
    .attr("stroke", "black");
let chart__xaxis = chart.append("g")
    .attr("class", "g__xaxis")
    .attr("transform", `translate(0, ${height - margin.top - margin.bottom})`);
let chart__yaxis = chart.append("g")
    .attr("class", "g__yaxis")

I won't go too far into the details here, but the basic idea is we create all of our chart elements under a single "chart" group. This has to do with the convention of defining a size for the SVG, defining margins, and adjusting the size of your "canvas" accordingly.

I want to stress that this sets up our chart, but we've yet to actually draw anything. We have added the elements, but we haven't set up any functions or bound any data. So let's do some of that now.

Functions

// Create functions
let xScale = d3.scaleLinear()
                .domain(d3.extent(data.map(d => d[0])))
                .range([0, width - margin.left - margin.right]);
let yScale = d3.scaleLinear()
                .domain(d3.extent(data.map(d => d[1])))
                .range([height - margin.top - margin.bottom, 0]);
let line = d3.line().x(d => xScale(d[0])).y(d => yScale(d[1]));
let xAxis = d3.axisBottom().scale(xScale);
let yAxis = d3.axisLeft().scale(yScale);

Here, we set up our scales, axes, as well as the line generator. This doesn't draw anything either, because we've yet to put the functions and elements together. Luckily for us, that step is pretty easy.

Data

// Bind data and call functions
chart__line.datum(data)
    .attr("d", line);

chart__xaxis.call(xAxis);
chart__yaxis.call(yAxis);

I want to focus on two things here. First, notice how we now bind our data to the chart__line element. We use datum because we are drawing one line, so we're binding this one piece of data (singular: datum). Now, when we set the d attribute, we can pass in a function that takes the datum (our array of coordinates) as input and returns the line path as output.

Second, notice how we're drawing the axes. We set up the xAxis and yAxis functions earlier, and the .call is essentially passing our selection as input to the function. It's equivalent to xAxis(chart__xaxis), for example, so don't let the syntax scare you.

Using .call is convenient for chaining functions, and this pattern is recommended for creating reusable charts. The idea is you can have a selection of svgs with bound data, call your chart on that selection, and draw charts using the bound data for each element in your selection.

Why this way?

It's possible to create D3 graphics without following this pattern. I'd bet most people (myself included) did not start creating graphics with this pattern. So why take the extra effort to learn and implement these ideas?

There are a couple of reasons which go hand-in-hand.

This is the way D3 was designed to be used.I will qualify this statement by saying that, since I didn't design D3, technically I don't know if this is true. That said, having read a lot of Mike Bostock's (and others') writing on best practices for D3, this seems to be the "right way"
Because of this, when you implement things this way, things are more likely to "just work".
Also because of this, debugging becomes easier because you're not trying to resolve any conflicts between your mental model and the model D3 adopts.

I'll provide an example of how you might be tempted to do things, and how those end up causing headaches later on. The tl;dr is that problems arise when you don't separating elements, data, and functions effectively.

In the past, I used to do this a lot:

// draw axes
g.append("path").datum(data).attr("d", line)
g.append("g").call(xAxis)
g.append("g").call(yAxis)

Why is this bad? We don't save our selections, and you can think of this as treating the path element as bound to this specific datum.

What does that mean? If we want to change our data, we will update data and run that code again, but since we don't keep a pointer to the path element, we end up just appending another path. Instead of redrawing the line, we draw a new line. Additionally, if we wanted our graphic to be responsive (that is, resize when the browser window resizes), we need to update and redraw our axes. That means we should also keep pointer to the axes elements.

Moral of the story? Set up your elements once, then use D3 functions to bind data and draw many times. Since you're not creating a new element every update, D3 can keep track of the current bound data and update accordingly. This also lets you use D3 transitions more easily.

Modeling Moments so Dear

2020-05-25T07:00:00Z

In the time that you've started reading this, there's a chance that you've experienced, as Jonathan Larson put it, a moment so dearassuming you experienced one immediately before this page load -- this provides a lower bound.

How do you measure a year?

RENT is a Tony Award and Pulitzer Prize winning musical describing the bohemian lifestyle of a group of young artists in Lower Manhattan. It remains one of the longest running shows on Broadway.

Even if you haven't heard of the musical, you've probably heard one of its most famous numbers: Seasons of Love, which has become a popular hit in its own right. Here is the iconic first verse:

Five hundred twenty-five thousand six hundred minutes \ Five hundred twenty-five thousand moments so dear \ Five hundred twenty-five thousand six hundred minutes \ How do you measure, measure a year?

I'm less interested in how to measure a year, and more interested in getting my fair share of moments so dear.

Send in the Clowns Stats

We know from the lyrics that there are 525,000 moments so dear in one year. There are 525,600 minutes. That means there is, on average, one moment so dear (MsD) approximately every 1.001 minutes.

It makes sense to model the distribution of our MsDs (MssD?) as exponential. Exponential distributions are frequently used to model "waiting time" problems, because they have a couple of properties, which are reflected in our scenario.

The random variable (in our case, the amount of time until a moment so dear, since the last moment so dear) is always positive. This makes sense, since we shouldn't ever say something like "the next moment so dear is -3 minutes from the previous moment so dear"
The distribution is memoryless. That means it doesn't matter if we have been waiting for 3 minutes or 3 hours, the probability of a moment so dear occurring in the next minute will always be the same. As the cast sings in Finale B, there is "no day but today".

With those conditions, I claim our moments so dear can be modeled as:

where is the mean, and is the random variable for minutes until the next MsD.

At this point, you may be asking yourself, what are the implications?

The implications, my friend, are many.

Calculating Probabilities

First, this means we can make claims about, say, the probability of experiencing a moment so dear.

In this figure, the black line represents the probability density function of our random variable . The red line, which is more interesting for us, represents the cumulative density function. This value is the same as the blue area under the curve. You can interpret it as y is the probability that we experience a moment so dear in the first x minutes.

So if we want to know the probability of experiencing a moment so dear in the five minutes following our previous MsD, we can plug in minutes and solve for y = .

So there's a 99% chance that a moment so dear will occur within 5 minutes of the previous one.

Confidence Intervals

We might also be curious how confident we are in this model. After all, who's to say there are always 525,000 moments so dear in a year? We should naturally expect there to be some variance -- we might get some more dear moments in one year, in a week, indeed in a minute, than the next!

Assuming we're right to use the exponential distribution, how good is our guess of the parameters (in this case, the average waiting time)? Since we're looking at means, we can use the Central Limit Theorem to give a rough confidence interval. We know, for large , the mean follows the normal distributionparameterized by the mean and the variance (notably, variance and not standard deviation)

We can use this mean and standard deviation to calculate a 95% confidence interval: we can state with 95% confidence that the true mean of our exponential distribution lies in the interval .

Life Lessons

If you are like me, you may have been surprised by just how frequently these moments so dear arise. After all, since you've loaded this page, there's a chance that you've experienced a moment so dear.

I certainly didn't think that was the case, but maybe there's a lesson to be learned here. Maybe I do experience a moment that I should hold dear every minute or so. Maybe we should cherish more of the little things and embrace the delight that comes with our normal everyday life.

After all, the numbers never lie, right?

Reflections 2019

2019-12-31T08:00:00Z

Here we go again.

My my, how can I resist you?

It's another year, and that means another end-of-year wrap-up.

this year in numbers

215 Github contributions (oof)

36 more college credits

10 weeks crunching numbers and making graphs this summer at Capital One.

4 musicals attended (watched?) (Miss Saigon, The Band's Visit, Dear Evan Hansen, and West Side Story!)

3(?) countries visited (Canada, China, Australia, and a layover in New Zealand).

Over 3.4 thousand Facebook reactions on my post in Subtle Asian Dating analyzing the language use of SAD posts.

And 1 shout-out from Randall Munroe (of xkcd fame) for my book cover sentence generator.

Highlights

If last year was a year of drastic change, this year was one of settling into the flow of things.

In January, I saw Miss Saigon at the Kennedy Center (starring Emily Bautista as Kim). This was the first of three musicals I had the opportunity to see at the Kennedy Center this year. Our seats were amazing, and the Kennedy Center is really beautiful at night (and all the rest of the time too). I also did a lot of math.

February was a lot more math homework (it kind of took over my life), but with one eventful uh... event. As I mentioned above, I wrote up a fun joke paper analyzing language use of the subtle asian dating Facebook group, and it was met with lots of positive feedback (and I'm now evaluating whether I have too much time on my hands).

We had our spring break in March, and that apparently still means college visits even a year into college. First I went to UVA for HooHacks and to catch up with some friends from high school (the whole thing was kind of a TJ reunion). Then I met up with my U-M squad to drive up to Toronto, where we had Japanese-Mexican fusion tacos, exorbitant amounts of bubble tea, enjoyed Canadian Netflix, and ate dumplings with my friend at U of Toronto.

In April, Blueprint published its 8th issue featuring my good friend Xindi's art on the cover! Also played in the spring band concert, attended my first Michigan MT performance (Sweeney Todd), and finished up freshman year of college with Coco bubble tea and instant hotpot.

May was a month at my new home in Michigan. It was also my new home because I got naturalized! Other noteworthy events included my car getting towed (it's a long story) and attending the Dog Bowl in Frankenmuth, MI!

June marked the beginning of my second summer at Capital One. I worked on a hackathon project which detected when you scrolled past a cat picture and suggested a donation to your local pet charity based on how many cat pictures you've seen. Also hiked the Billy Goat trail and met up with some friends from high school.

In July, I celebrated my first fourth of July as an American, and watched the DC fireworks from my apartment in Pentagon City. The day after, I went to the archives to see Constitution and Declaration of Independence in person for the first time. Also went to the Lawn at the National Building Museum, celebrated the 50th anniversary of the moon landing, and got a DC library card. Last but not least, I saw The Band's Visit at the Kennedy Center, and that might have been the highlight of this year. We had amazing tickets in the center of the orchestra section, and the entire musical was just so beautifully well crafted. Highly recommend.

August was equally busy. It started with a visit to the White House (cool, but honestly underwhelming) and farewells to my team and friends at Capital One. Then Dear Evan Hansen at the Kennedy Center (set design was amazing), seeing the sunrise in DC, and celebrating David's 20th birthday before departing on my travels.

August Travels: First on the itinerary was Santa Monica where I spent my 12 hour layover at LAX. After seeing The Farewell, eating Street Noods, and watching a west coast sunset, I took off for Chengdu. In China, I visited family, friends, and ate lots of food (the existence of AYCE personal hotpot makes me believe in a higher power). I only spent a couple of days in Chengdu before heading off to Melbourne, Australia where I met up with my friend Jacob. We spent over a week in Australia, where we experienced Melbourne's White Night, the Twelve Apostles, friendly birds, and delicious food. We also snuck into an Australian Costco, hiked the Blue Mountains (where we met an international student from Thailand / Virginia!), explored Sydney, ate emu / kangaroo pizza, and watched West Side Story at the Sydney Opera House! Pad that out with platypi, Nepalese dumplings, and some more hiking, and we're at September.

September was the start of sophomore year and my first year living in our house off campus. Also the first MDST meeting in my new role as VP of Projects (in other news, lots and lots of meetings and planning for the MIDAS Data Challenge).

In October, we kicked off the MIDAS Data Challenge and had hotpot at Xindi's.

In November, we wrapped up the Data Challenge, I turned 20 (!!), and I played Dem Debate Bingo. I also tried quince for the first time.

December was wrapping up the fall semester and wrapping up this semester's MDST project. Then I traveled around California with my family, saw lights in Georgetown with friends, and went to go see the Space Shuttle Discovery at the Udvar-Hazy Center.

Reflections

Now that we're heading into 2020, I guess it might be a good idea to look at not just the past year, but the past decade. A lot has happened in these 10 years.

In 2010, my family had just bought our first house. We bought another car. We received our green cards. After so many years of uncertainty, worrying about visas, living in apartments, it felt like things were finally settling down. Little did I know, the next decade -- the next half of my life -- would see me moving farther, living in more apartments, and growing much much more than I could have ever imagined (seriously, who could've guessed I'd be over six feet tall).

I lived in our house for all of 3 years before moving to an apartment totally foreign city a few hundred miles away. Since 2010, I've lived in more than six different zip codes, I've gotten drivers licenses in two states, and I have like 5 different library cards. I moved from a middle school where my biology teacher was hesitant to teach evolution to one of the best high schools in the nation. I've learned so much about life, about myself, about love, and about linear algebra (in no particular order). And I know I have so much more to learn and experience in the next decade, and hopefully many more after that.

Maybe one important lesson I've learned, as I step back and look at these past 10 years from a thousand-mile-high vantage point, is that you should never settle. My dad took a huge risk when he decided to enter residency. My mom took a huge risk when she decided to move the two of us to Virginia. We had a house, two cars, and neighbors with a dog. We had a free pass to stay in the country. According to everything I've read, that sounds a lot like the American Dream™. But sometimes we yearn for something more, and that requires taking risks and jumping in without knowing exactly where we'll land. It requires courage, courage I'm glad my parents had, and courage I hope to inherit as I take my first steps into adulthood and the pursuit of my own goals and ambitions in 2020.

Matisse is a Team Player

2019-07-26T07:00:00Z

Henri Matisse works well with others in the courtyard of the Kabbalist, and in the morning, Leonardo's shadow got to give the people what they want.

Two very influential artists, to be sure, but what was Matisse doing collaborating with Kabbalists, and what exactly did the people want from Leonardo's shadow?

Some Context

In mid-June, Randall Munroe, the genius behind xkcd and the author of quite a few books, announced he was going on a book tour to promote his latest book: How To: Absurd Scientific Advice for Common Real-World Problems

As part of the announcement, he introduced an interesting challenge:

Write the best story using nothing but book covers.

The winner of the challenge would be rewarded by a visit from Munroe as part of the tour. Even though Ann Arbor was already in the itinerary, I couldn't help but think about this challenge... and how I could use some of my linguistics knowledge to my advantage.

The Project

I decided I would try to hack this challenge by acquiring a dataset of book titles, and having a computer generate these stories for me.

I found a list of over 200,000 books listed on Amazon, and a couple of Jupyter notebooks and Python packages later, we were off to the races.

Grammar School: Constituency

The key concept behind this project was something I learned in my introduction to linguistics class last fall: constituency trees. The basic idea is that each sentence can be represented as a combination of words and phrases (constituents).

For example, a sentence is, in its base form, a noun phrase and a verb phrase:

S -> NP VP

And a noun phrase might be a noun, with optional adjectives and determiners, and maybe a prepositional phrase.

NP -> [DET] [ADJ] N [PP]

And a prepositional phrase, in turn, might be a preposition followed by a noun phrase.

PP -> [P] [NP]

And in this way, we can construct a very expressive and productive grammar for the English language. Productivity here means that, with even a limited vocabulary, we can form many distinct sentences and thoughts.

So the main idea was we would label each book title as a noun phrase, verb phrase, adjective phrase, etc. Then, we could use this grammar to compose sentences.

The Nitty Gritty

Although there were over 200,000 books in the dataset, I couldn't use all of them. In fact, out of 32 categories, I used only 10. Books with categories such as cookbooks, calendars, etc were excluded because those titles were generally not very useful.

The categories I ended up using were:

Biographies & Memoirs
Children's Books
Engineering & Transportation
History
Humor & Entertainment
Literature & Fiction
Mystery, Thriller & Suspense
Science Fiction & Fantasy
Self-Help
Teen & Young Adult

I also did some preprocessing on the titles before parsing the constituents.

cleaned_titles = books.title.str.lower()  # Lowercase
cleaned_titles = cleaned_titles.str.replace(r"\(.+\)", "")  # Remove everything in parentheses
cleaned_titles = cleaned_titles.str.replace(r"\[.+\]", "")  # Remove everything in brackets
cleaned_titles = cleaned_titles.str.replace(r"(volume|vol\.) (\d+|\w+)", "")  # Remove volume numbers
cleaned_titles = cleaned_titles.str.replace(r"issue (\d+|\w+)", "")  # Remove issue numbers
cleaned_titles = cleaned_titles.str.strip('-, ')  # Remove dashes
cleaned_titles = cleaned_titles.apply(lambda x: x.split(':')[0])  # Only keep first part of title (no subtitles)

The last part -- getting rid of subtitles -- sometimes helped and sometimes did not.

Parsing

I used benepar, which is a state of the art constituency parser that fits nicely into NLTK. I found that it provided decent results. One issue that I ran into was handling more granular details such as subject verb plurality alignment. In those cases, I wanted to know what the noun was in the noun phrase, etc.

For this, I used a different grammar model: dependency grammar. In dependency grammars, instead constituents, each word is dependent on exactly one other word in the sentence. This image from Wikipedia is pretty good at showing the difference between the two.

I use the root of each dependency tree as the "active noun" or "active verb" in the phrase, and their parts of speech include markers for plurality, properness, verb tense, etc.

Creating Sentences

Afterwards, it was just a process of returning a random sample for each constituent. I wanted the sentence generation to be completely automated, but I ended up adopting a more hybrid process where I would query for noun phrases, for example, until I found one I thought was interesting, then move on to a verb phrase.

Gallery

Here are a couple more sentences I put together with the help of computers. Stay tuned for an online interactive version in coming days that will let you construct your own book cover stories.

Radioactive horses and ponies thank you for being a good friend, but not the hippopotamus.

19 varieties of gazelle found apple, apples everywhere!

The Russian Kremlin desperately seeking exclusivity around the world with Justin Bieber.

Merry Belated Christmas

2019-07-07T07:00:00Z

Christmas in July

It's Independence Day when I'm writing this, which seems like a good time to write about my winter holiday cards from last year. In a previous blog post, I wrote about a small project I made with my naitian.holiday domain name. However, that wasn't the original purpose for the domain. The first use for the domain was digital holiday cards for some of my friends.

Planning

AKA all the things I wanted to do but didn't.

There were a couple of clear requirements that were non-negotiable:

There had to be at least some form of authentication (so not everyone can see everyone else's card)
Emails would be sent out notifying people of their cards.
Cards need to be personalized with:
- Greeting
- Name (duh)
- Message

Later, I also decided a couple more requirements, both for fun and for education:

Everything would be compiled and hosted statically on S3.
In the theme of using AWS for everything, I'd also send email notifications with Amazon's Simple Email Service (SES) and handle domain name / certificates with Route53.
Each person would only see pretty URLs (e.g. naitian.holiday/nate)
Cards would include these draggable Polaroid-style pictures from my Google Photos.

Implementation

AKA what I ended up doing

Infrastructure

I will be totally honest with you and say I don't actually remember all the details to the infrastructure on AWS, but it wasn't super complex. The gist is:

All the static files are hosted with S3's static website hosting.
I used Cloudfront as the CDN for the S3 files.
I have a hosted zone for naitian.holiday in Route53 which points to the Cloudfront endpoint (which in turn points to the S3 bucket).
Photos were hosted on Google Photos

Design

Aesthetically, I decided to go for a festive red with a subtle gradient. I chose a classy serif typeface and drew this freaking amazing ~~Christmas~~ non-denominational holiday tree.

Build Process

Each card was defined as a yaml file. I wrote a Python script to read these yaml files and used markdown to render them into HTML files. At the same time, I generated the SES email template data for bulk sending the notification emails.

I also had a Makefile which would run the rendering script, compile the SCSS into CSS, minify CSS and JS, and push everything to S3. There were also Make steps which would send a test email and send out the actual emails.

Authentication

One of the most interesting parts of this whole exercise was figuring out a good authentication method. I definitely did not want to make anyone sign in or create any accounts (partly also because I wanted this to be a totally static site).

I ended up compromising with a "good-enough" authentication plan, which I had to alter a little bit to also keep the pretty URLs. Here's how it ended up working:

When a card is rendered, it is actually placed in a directory named after its SHA256 hash.
This hash is used as an auth token in the link.
Not only is an HTML file generated with the card's content, another HTML page is generated with Javascript for authentication and a hidden input field containing a SHA256 hash of the token.
When a user navigates to the site (e.g. naitian.holidy/nate), they are actually navigating to the page with only the auth code.
- On the client side, the token (if it's present) is hashed and compared to the correct token.
- If incorrect, the user is rejected.
If correct, there is an XHR request that fetches the actual HTML and displays it.

This means the user would have a hard time even realizing that any authentication had occurred in the first place.

To recap, for each card, the path structure looked like this:

naitian.holiday/<SHA256>/index.html   <- this is the HTML for the card
naitian.holiday/nate/index.html       <- this is the HTML for authentication

Of course, I also added a robots.txt which disallowed any crawling. This makes it pretty difficult to find the (very much public) SHA256 paths of any of the cards.

So, while not airtight, this worked well enough to prevent people from just typing in names of other people to see their cards.

I also stored the tokens in local storage, so after the first visit, the token isn't actually required.

Nifty.

Email Notifications

Emails were surprisingly straightforward to set up. I used the Simple Email Service from Amazon. Initially, I planned to do a lot more CSS for the HTML emails, but ultimately decided against it for two reasons: it would have been more work to implement and try to test, and I felt like it would feel more personal if it was more "raw".

I had a make rule which would send just test emails to myself and a different rule to send out the emails for real.

April Showers

2019-04-20T07:00:00Z

It's supposed to rain all of today, and I'm stuck inside, so I figured now might be a good time to post this "poem" (flash fiction? flash flood?) that I wrote a while ago.

I don't usually post my poetry, because I write these mostly for myself, but here's a glimpse, I guess.

Of course, this one isn't actually about the rain -- but I do feel way more comfortable writing about the weather than anything else this may be about, so here you go. I'll stop stalling now.

Torrential

A day in late summer.

You awaken one morning and it's in the air. The smell of anticipation. An overwhelming sensation of tension.

It's in the air. Not rain, but the hint of rain. Not a storm, but the shadow of a storm. You step outside and feel it on your skin.

And you brace yourself for the inevitable, the torrential.

The downpour.

As if God himself had flipped a switch and opened the gates. An instantaneous, miraculous change. A refreshing change. And a flood of everything you didn't know you wanted.

You stand there, getting drenched, revelling in the power of the staccato beats, getting your fill, until you're dripping in it. The water rubs away any past dirt still clinging to your skin.

A small voice way in the back is shouting at you, about ruining your clothes, about catching a cold. But in the moment, that voice gives way to the excitement, the thrill, the flashes of lightning, the crashes of thunder

You're afraid to move -- afraid that one wrong move would make it all stop. Weather is finicky in that way, you say. So you stand there, paralyzed, wondering how long until this, too, comes to an end.

flip

And the rain stops. The clouds part, the sun reveals itself, and fresh, cool rain makes way for suffocating humidity.

For the storm is gone, as quickly as it came, but a lingering taste remains of what used to be.

The wet, sticky air clings to your skin, not letting go. Unable to let go. Refusing to let go.

The dampness hangs there, static and unyielding, and you stand just as still as before. You ask out loud, "Where do I go now?"

But the only response is the sound of water droplets dripping off your shirt.

Subtle Asian Meta

2019-02-08T08:00:00Z

Shameless plug: If you, one of the 5 people who visit this blog every month, work in computational linguistics or related research, please contact me at naitian at umich.edu. I would love to pick your brain and maybe even work with you. Thank you and enjoy the rest of the show.

Subtle Asian Data

I recently published a joke paper I wrote over the course of about three months (with the help of David). While entirely a joke, it also contained entirely real analysis of subtle asian dating user demographics and language.

Here's the abstract:

Recent subtle asian Facebook groups have gained incredible popularity among young adult Asian diaspora. We focus on one of these groups – subtle asian dating – and conduct a content analysis on its posts to examine what it can tell us about the members of Asian youth subculture, and how their identity and culture affect their view of and approach to dating and relationships.

You can find the entire paper here. I highly recommend it -- what it lacks in insight, it makes up for in just how ridiculous it is.

The Critical Reaction

The obvious resulting course of action was to post my paper on subtle asian dating. The post took off in popularity, gaining over 3.4 thousand reactions and close to a thousand comments over the next three days.

The comments were pretty interesting to read at first, and for maybe the first half of the first day, I was keeping up pretty closely as they rolled in.

That's when I made the following astute observation to my friend:

So I think the breakdown in comments right now is:

50% about how it was typeset in latex

20% why did you do this

10% umich represent!

10% I'm ashamed to go to the same school as this guy

And 10% miscellaneous

To which she responded:

HAHA

Misc tagging

always

Naturally, after the commenting had died down, I had to check myself. How far off was I with my predictions? (Hint: very)

Just how many comments were misc tagging? (Hint: not that many)

Exactly how many people were impressed with my LaTeX skills? (Hint: my skills are not very impressive)

Subtle Asian Meta

So I went ahead and scraped all the comments from the post.

Data Collection

For the curious, I did all the data collection in Chrome Dev Tools.

Terrible code, but it worked I guess.

Analysis

I tossed the generated JSON object into Jupyter Notebook to see what I could get. The following numbers are just for top level comments (this means replies are excluded):

There were 618 comments. Almost 95% of users tagged someone else in their comment, so "misc tagging" was pretty accurate. However, I was more interested in who commented only to tag someone else. That is, the body of their comment consisted only of a tag.

In that case, the number drops to less than 25%. But wait, there's more.

How many people were impressed with my LaTeX? Surely less than 50%. And Shirley would be correct. In fact, only 6.5% (N=40) mentioned LaTeX in their comments.

And how many people thought it was cool that I went to their school? Well, I looked through the posts and filtered by any of the following keywords:

['school', 'michigan', 'hoo', 'blue', 'umich', 'mich', 'uva', 'virginia']

which encompasses both U-M and UVa. A couple of false positives? Probably. False negatives? Also probably. But this gives us a general sense. Even fewer comments matched the criteria for this filter: 5.8% (N=36).

Finally, I took a cursory glance at who was incredulous, by filtering by the following keywords:

['wtf', 'why', 'time', 'tf', 'believe']

And it turns out that only includes 5% of posts.

In conclusion, I was totally wrong, but my version of reality was way funnier, so who really won this fight?

So there you go. subtle asian metadata

First Semester Reflections

2019-01-08T08:00:00Z

Eve of Destruction

And by destruction, of course, I mean winter semester. School starts up again tomorrow, so I figured today I'd share some reflections on my first semester of college (or as our friends across the pond say, uni).

And since I'm lazy, I'll do it in list form.

A List of Things That Happened

and how I felt about them, etc etc.

The football team is pretty good at, you know, football.
We do not speak of the OSU game.
Homework actually counts for something
Homework is apparently useful for reinforcing lecture material.
Math is definitely easier when learning it for the second time.
I have way more time than I know what to do with.
I should work on more projects.
I should do research.
CAEN is definitely run better than tjCSL
Working at CAEN is nowhere near as fun as working at tjCSL.
Late nights are okay on weekends, never on weekdays.
I definitely sleep way more than I used to.
It's a bad idea to get trapped in downpour at 3am.
Looking forward to chemistry, the saturation point also means, after a certain extent, it's physically impossible to get more wet.
Projects and homework take a lot of time.
Michigan Data Science Team is pretty cool.
I miss playing in band (am playing in band W19).
There are lots of opportunities for free food.
Trello is really useful for making sense of my life.
Who am I kidding, it's impossible to make sense of my life.
I appreciate histograms.
CAEN SSH does not allow Kerberos ticket auth and that makes me mad.

If You Start Playing...

2019-01-06T08:00:00Z

naitian.holiday

I discovered early December 2018 that there existed .christmas and .holiday TLDs. Naturally, I had to purchase one, so I sprung for the non-denominational (and, more importantly, cheaper) naitian.holiday domain.

The next question, of course, was what I should do with it. I ended up using it for two projects, so I definitely got my money's worth. One of the projects was if you start playing.

if you start playing...

If you start playing YouTube Rewind 2018 at 11:53 and 2 seconds on New Year's Eve, Will Smith will say "uhhhh that's hot" at exactly midnight.
— Fab NZ (@fab_nz) December 31, 2018

Inspired by this meme format, I decided to make a New Year's countdown that would automatically start playing these videos at the correct time.

Here are the specs for the project:

specs

client side: it really doesn't need a backend, and I wanted to host on S3, serve through CloudFront, etc.
customizable: I want to be able to share links to custom videos / timestamps.
dark theme: for the nighttime countdown, of course.

tech

Building out the application was actually pretty straightforward, thanks to the Youtube iframe API.

To make it customizable and all on the client side, I used window.location to get URL parameters.

let url = new URL(window.location.href);
if (url.searchParams.get('custom')) {
   const id = url.searchParams.get('id');
   const timestamp = url.searchParams.get('timestamp');
   vid = {
       id,
       timestamp
   }
} else {
    // Get from list of presets
}

You can check it out at naitian.holiday/iysp/?preset=umich.

The Github Repo.

Reflections 2018

2018-12-31T08:00:00Z

What

Wow time flies. I'll try to keep this short and sweet, but we have a lot of stuff to cover.

This Year in Numbers

491 Github contributions (less than last year -- sad...)

17 credits of college courses taken

8 weeks spent surviving Java Spring during my summer internship at Capital One

Over 1.4 thousand likes and reacts to my post on UMich Memes for Wolverteens -- my crowning achievement.

0% -- the battery capacity of my laptop that died

8% -- the battery level of my new laptop as I'm typing this post.

Things That Have Happened At Some Point in 2018

In January, I published an Alexa skill with my friend, went to a couple of track meets, and released the Ion bus app. I also went to HoyaHacks at Georgetown, where I made Scout with David, and had a couple of delicious cupcakes.

In February, I ate (and was subsequently disappointed by) a kiwano melon. I also stole the show as Banker Number Three in the TJHSST production of Mary Poppins. To top it all off, tjCSL achieved an consecutive 7 days of uptime on all services, which was unfortunately very exciting for me.

In March, production started ramping up for Threshold Litmag, went on a class trip to Washington, DC, where I got my Library of Congress library card. We also moved out of our apartment.

In April, I deployed Ion Signage 3 and went to Bitcamp, where my team used machine learning :wow: and a Myo armband to determine whether you were holding a can. Also did some more pole vaulting, and went to Chicago, where I experienced deep dish pizza for the first time.

In May, I wore a skirt. I also played at Chantilly Jazz Fest with the jazz band, constructed a gondola out of cardboard, executed a flawless (read: heavily flawed) prom asking, and ran tech support for tjSTAR (also presented my senior research project at tjSTAR). May turned out to be pretty eventful.

In June, I went to prom, then graduated and took lots of pictures and said lots of goodbyes. Then I went to orientation, at which I met my very first college friends. Then I came back to Virginia, moved into George Mason University, then began working at Capital One! I also went to the National BBQ Festival, in which the free samples and free stuff make up for the price of admissions. The week after, I saw the National Symphony Orchestra perform.

In July, I went to the "A Capitol Fourth", except it was the dress rehearsal, so it was mostly sound checks and John Stamos forgetting his lines (sick burn). Also checked out the National Building Museum and funhaus, then ordered food at a Chinese restaurant for the first time, completing my transition into Asian Adulthood. Ooh! I also witnessed the aftermath of a microtornado, so that was cool, I guess.

In August, my team at C1 moved into the newly constructed headquarters, featuring a hot chocolate machine on every other floor and pricey yet delicious cafeteria food. Then I flew to Detroit, then San Francisco (where I was stuck for almost 14 hours due to flight delays), then to Chengdu. I caught up with family, friends, and an abundance of Uniqlo stores. I also flew a (simulated) airplane and managed not to crash, so that's pretty exciting, too.

On September 1st, I moved into the University of Michigan. I took a picture in the Big House and then got rained on. In September, I also went to my first Michigan football game, took a selfie with a helicopter, traversed the interconnected buildings of North Campus, and saw the Philadelphia Orchestra.

October involved a squishy moon in the UMMA, MHacks (!), HackHarvard (!!!), and some really beautiful sunsets in Ann Arbor.

November included one (1) fake mustache, many Welcome Wednesday Bagels, first snow, seeing Candide live (hilarious and wonderful), trying to climb into the walls of Rackham Graduate Building, and heading back to Virginia for Thanksgiving.

December was a last push to finish out the semester. I built a gingerbread house, discovered this really cool bookstore in downtown Ann Arbor, turned on the Christmas lights in the CAEN cave (where I work), and practiced a lot (relatively). I also had a Zingerman's sandwich for the first time, which means I'm basically an Ann Arbor native now. After school ended, I flew back to China, where I went to Guangzhou (saw a tomb and a huge library), Chengdu (saw my grandparents, ate hot pot), Zhuhai (went to the beach, saw a huge clam-shaped thing and a whale shark). I should clarify, the clam-shaped thing is a building (the opera house), and the whale shark was in an aquarium. I did not see those things as I was walking along the beach.

And so that brings us to now. This was a pretty cursory look at the past year, and I guess there wasn't much reflecting going on -- mostly just remembering what the hell I did for another 525,600 minutes.

Reflections

This past year was pretty busy, and there were a lot of firsts. I lived on my own for the first time. I wore a graduation gown for the first time (hopefully not the last). But there were also a lot of lasts -- a lot of farewells bade (bidden? biddeth?).

This year was the start of a new era for me, one with greater independence, with more responsibilities, with new people to meet and new things to discover. But the start of a new era means the end of an old one, and as I think about not just this past year, but the past 5 that I've spent in the state of Virginia, I realize just how lucky I was to have the privilege of living there, of meeting the great people that I did.

I've lived in a lot of places in my life -- the five years I've spent in Virginia is maybe the longest amount of time I've spent in one place; it's certainly the span of time with the most significant changes and growth.

I'm not sure where I'm going with this. I guess, as I ring in the New Year (in about 50 minutes), I can only hope that the next five years will be as fulfilling and interesting and fun as the past five. I hope that, just as I found a home in Virginia, I'll find a home in Michigan, and wherever life might take me next.

And you know what?

I'm almost certain it will be.

Happy 2019!

Procrastination and Showering

2018-12-18T08:00:00Z

Procrastination

I have a final in just over two hours. In fact, it's the last final of my first semester. The final final, so to speak.

And like the model student I am, I'm not studying right now. Instead, I'm writing an entry for a blog that probably only I read.

But whatever. Here's a quick tip I've picked up.

Showering

Yes, that is indeed something one should do at college. But there's more. I've discovered, the time spent under the shower head is a great time to do math homework!

On multiple occasions, I've figured out a problem or a proof while being pummeled by particles of water. I think it has something to do with the white noise of water and not having any distractions.

Here are a couple of ways to set yourself up for success in seeking your shower-solution:

You should definitely attempt the problem before showering. You should know the problem inside and out before you try to throw suds at the solution.
Don't shower immediately after attempting the problem. I like to sleep on it, so try it the night before, then shower in the morning.
A good way to know if you will find success in the shower is if you feel like you're incredibly close to the answer, but you're missing one key insight, or your mental processes are clouded by the fact that you've been working on it for so long.

One pitfall of this technique, of course, is the inexplicable lack of accessible showers in the exam setting. But you win some and you lose some, I guess.

Best of luck to you in your hot-shower homework endeavours. I need to go cram for a final now.

Let it Snow

2018-12-13T08:00:00Z

Just drag this link to the bookmark bar, click it, and you, too, can be greeted by the non-denominational red deer-pulled guy:

❄️Let it Snow❄️

Ion has a winter theme that gets activated every December, with snowfall and a Non-denominational Red Deer-Pulled Guy.

I found myself missing this, since Michigan's "Intranet", Wolverine Access (which is actually just Oracle SIS, but I digress) doesn't have this nifty feature.

So I decided to port the snow theme over to a bookmarklet, so I can access get snow at any time!

Thanks Derek Morris (TJ '11) and Zachary Yaro (TJ '12) for the actual code.

Pro Tip: if you click it multiple times, you'll get multiple non-denominational holidays!

Pro Tip 2: if you click it enough times, your computer will overheat to keep you warm during those cold winter nights.

The Consequence Eradicator™

2018-12-12T08:00:00Z

MHacks 11 (and the customary apologies)

I have been kind of terrible about keeping up this blog. Sorry about that. That said, a lot has happened since the last blog post almost a full year ago. For one thing, I am a college kid now!

I also had a great time as a tech intern for Capital One over the summer (something I'm definitely going to be writing about very soon).

But let's get back to this story.

MHacks 11 was held at the University of Michigan from October 12 - 14. I convinced my friend, David, to fly up to Ann Arbor all the way from Charlottesville for the event.

What follows is the story of how David (UVA '19), Renee (also U-M '22), and I did our parts in contributing to the eerie convergence between the Simpsons and reality.

Conrad: the Consequence Eradicator

You don't need to watch the whole video (though I highly encourage it). Basically, Lisa and a team of programmers write an artificial intelligence (Conrad) to predict the outcomes of social media posts.

Thusly inspired, we made a Chrome extension which predicts the reactions a post on Facebook would get.

Step 1: Data Collection

Fortunately for us, @minimaxir on Github had a relatively large dataset of public posts from large Facebook pages, and their reactions. The dataset is linked here. I only found out later that he also did our exact same project, but whatever.

Anyway, that was data collection.

Step 2: Data Preprocessing

We chose only to look at posts with text content (so we ignored shared links, photos, videos, etc.) We also only considered posts less than 1000 characters long, and which had more than 11 non-like reacts.

Step 3: Modelling

We spent most of Saturday doing preprocessing, and then eventually realized we still had to actually build a model. We started off by trying a random forest regression with bag of words. Results were not great.

After tweaking the hyperparameters around a bit, it became clear results weren't improving.

That's when we took the leap to using gensim and doc2vec to generate sentence embeddings. This meant that, instead of just using word frequency, we used a much more complex model to encode posts which took into account word order.

This yielded much better results, especially after I also normalized the target output.

Step 4: Building the Extension

At this point, it was the morning of demos, and while we had a halfway decent model, the chrome extension was non-existent.

So came the mad scramble, in which I was literally writing code as we walked to the IM building. I wrote a small Flask API backend, which the Chrome extension was supposed to call.

Initially, I didn't want to deal with the Chrome messaging protocol, so I tried to make the call directly from the content script (which ran as Javascript code on the client with no extra permissions).

We ran into a roadblock, where cross origin requests were forbidden. I tried to overcome this by editing my /etc/hosts file to redirect some ancillary Facebook domain to localhost. This almost worked, except Facebook also expected https-only requests, so I was stuck with having to do the correct thing of using Chrome's messaging protocol.

By this point, I'm writing the code while we are standing at our demo table.

It turned out to actually be super easy to use the messaging protocol, but that didn't stop me from screwing up 11 times before I finally got everything working.

This was me when I finally got the Chrome extension to work.

Wrap-Up

Unfortunately, I have no screenshots of the actual app working, but if you want to run the janky code for yourself, it's all open source on Github.

I learned a lot through this hackathon. It was the first hackathon project that I did with a heavy data science workflow.

This hackathon was a blast, and David and Renee were awesome teammates.

Reflections 2017

2017-12-31T08:00:00Z

Hello again

It's been a while. I've been pretty busy doing senior year things like college applications and senior research (cough not really). But anyway, I figured now would be a good time to reflect on this past year - what I did, what I didn't do, and what I should be doing next year.

This Year in Numbers

563 Github Contributions

1 Palantir Social Impact Prize

4 weeks spent surviving PHP and MySQL during my internship, during which:

I added 18 hotels
processed 64 images
and modified 10055 lines of code!

6 college applications submitted (and 1 acceptance received!!!)

In Ion, I made 168 commits, with 4230 additions and 6669 deletions.

I cleared 10 feet in pole vault, very narrowly qualifying myself for states!

3 AP exams taken

Revisiting Last Year

I made a post on January 1st that listed some goals for the year. Let's see how well I did.

This Website

There’s still lots of work to be done, particularly in the little “terminal” easter egg on the home page, but I’m very happy with the site.

I definitely worked on the website quite a bit this year. I fixed some big bugs with the terminal, and added some useful tools to improve my workflow. It's definitely a lot of fun to work on.

This Blog

I definitely plan on posting more, and hopefully at least once every week

Oops. I kinda dropped the ball on this one... That said, I did post more often than before, and I attribute that entirely to a smoother creation flow.

This Life

That said, I’ll take to heart Dory’s advice of “Just keep swimming”, and keep you guys updated.

Update: I kept swimming, and finished junior pretty darn strong. It was hard, but totally worth it.

Looking forward

Here are my resolutions for this year:

Go to college
Clear 11'
Double the number of blog posts
Get 100 stars on Github.

purple.com: a brief eulogy

2017-11-29T08:00:00Z

On November 2, 2017, I lost a close companion. purple.com is no longer the bold-yet-understated purple eyesore that I had grown to know and love.

It has been replaced by purple, a mattress company that I keep getting ads for on Facebook.

In a token of remembrance, here is the story of my life with purple.com.

I first came across purple.com in the summer of 2015. I had finished my first year of high school, blissfully unaware that school could get much much worse, and I had been to my first hackathon, HackTJ, where I built something incredibly broken, but with which I was satisfied nonetheless. I was hooked on hackathons.

I only mention this because I encountered purple.com at my second hackathon ever. The internet was, as it usually does when a couple hundred people try to access it at once, slow and unreliable. I sat with a couple of my friends, annoyed and impatient. One of them, who was more acquaintance than friend at the time, let out a cry.

Guys, I have internet!

I looked at her screen. It was filled with a disgusting shade of purple.

What the fuck is that.

"It's purple.com," she informed us. "It's the fastest loading webpage in the world."

That was a bold claim - one that I'm pretty sure is not true - but I took her word for it, and ever since, purple.com has been a constant in my life.

purple.com has been around since August of 1994. That's over five years before I was born. When I learned about purple.com, it could legally drink alcohol. It's not just a website. It's an institution - one that has been replaced by a mattress company.

As I navigated my way through high school, purple.com has always been there for me.

At every hackathon, when the internet inevitably goes awry, the blinding purple is the bearer of good news: You can google things now.

Every time I was frantically trying to connect to school WiFi so I could print that paper due next period, that luscious #DD00FF was there to reassure me: Everything is okay. Your paper is horribly written, but at least you can print it out.

And all of the late nights spent ~~working~~ procrastinating, when I've exhausted Facebook and Reddit and Youtube, and even my email, my muscle memory would turn to purple.com, and the really quite horrid purple would issue its stern admonishment: Get back to work.

But several weeks ago, that all changed.

I was having network connectivity problems. Unfazed, I opened my browser and navigated to my home away from home. And I watched the loading indicator spin.

That's okay, the network is still broken.

Then Google loaded.

Then Facebook, then Blackboard, then fcps.edu.

And purple.com just sat spinning.

I refused to lose faith.

It's an old site, probably the server had to be replaced or something. It'll be back up soon.

I held on to hope against hope that, the next day, everything would be back to normal.

I wanted to believe, but, alas, all good things must come to an end.

Web archive of purple.com

Thanks purple.com for all the memories. I guess now I'll just have to go to notpurple.com.

About this Site - The Terminal

2017-05-26T07:00:00Z

I'm Back!

I've been planning on continuing my "About this Site" series for a while now (like over 2 months), but I guess I've been distracted with other things (as a high schooler does). Regardless, partly due to the prompting of a friend, here is the third installment.

Inspiration

I believe I have waxed poetic about the command line before. I most definitely will in the future if I have not already. I was, therefore, kind of infatuated with the idea of a website that has a little command line built into it. This was implemented in my original website, where I even added scan lines and a subtle flicker to really drive home the retro feel.

My old website

For this refresh, though, I wanted to make something cleaner. More importantly, I wanted to make something that required very little maintenance.

Problems

First, let's go through some of the problems with the previous Javascript terminal. For one thing, there were errors that were straight up ignored (to be fair, this error didn't break any functionality).

Look at all those errors

Also, just about everything, from the commands to the available files, was hardcoded. This meant if I were to add a new section to my site, I would have to manually update that code. What a drag. It ended up with code that looked like this:

if (parsed.cmd === 'open') {
var target = '#' + parsed.arg;
$.smoothScroll({
scrollTarget: target
});
} else if (parsed.cmd === 'ls') {
out = 'about&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;projects&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;contact';
} else {
out = 'That command is not yet supported. Try ls or open.';
}

Ewwwww.

Specs

So for this new and improved terminal, I wanted several features:

Better design (this meant a visible, blinking cursor)
Procedurally generated files (this proved to be the most challenging)
Extensible command system (I used ES6 classes for this)

Let's Get Down to Business

We're not going to defeat the Huns, but we are going to make our new and improved terminal.

Better Design

Okay, so this one is kind of vague. I mocked up the design, which was heavily inspired by my actual terminal.

The most difficult part was probably hiding the cursor and replacing it with a block cursor. I still don't have a perfect implementation - in case you didn't realize, you can't actually move the cursor around on the line. It just stays at the end of the line.

The thing about the cursor (or caret, if you'd like) is that it is always the same color as your text. There's no way to style it individually. The trick here is to make the text transparent. Then, just add a text-shadow with your text color and no offset. This keeps everything the same except for the caret, which is now transparent!

#input {
    color: transparent;
    text-shadow: 0 0 0 #0EFF1F;
}

Wow!! Nice.

Another big problem was making scrolling work nicely. This was more difficult than you would initially expect, because the input is a contentEditable div, while the rest of the text is a separate div. A couple of overflow rules did the job nicely, though.

Procedural Generation

This is the cool part! My biggest gripe with the old implementation was how much was hardcoded. I wanted to be able to more or less browse the entire site with the terminal, so hardcoding everything was not a viable option.

This means I needed an API or something to query for all of the different parts of the site. Fortunately, I have Jekyll!

Here's the amazing thing about Jekyll: it can generate any document. This includes not just Markdown or HTML files. The trick is to use Jekyll to generate a JSON file with information about the website.

mind = blown

Here are the entire contents of terminal.json, which is the relevant JSON file:

---
---
{% capture nl %}
{% endcapture %}
{% assign files = site.documents %}
{% for page in site.html_pages %}
{% assign files = files | push: page %}
{% endfor %}
{
    {% for page in files %}
    "{{ page.url }}": {
        "content": "{{ page.content | replace: '"', "'" | normalize_whitespace}}"
    }{% unless forloop.last %},{% endunless %}
    {% endfor %}
}

That's all there is to it. This generates a JSON object of all of the pages in the website, with the url as the key and including the content as the sole property of each page.

You end up with a JSON file looking like this.

Now, this is still not wonderful, because all we have now is a bunch of file paths. This doesn't encode information about what is and is not in the current directory.

So I added a pwd variable. I now realize pwd stands for "print working directory", so it doesn't really make sense to name a variable that, but in my mind, it just means "our current working directory", and ocwd just doesn't have the same ring to it. I use this to keep track of where in the tree I am at the moment

I then search down the list of files to see which paths are direct children of the pwd.

Everything else is pretty straightforward: I just inject the content of the selected path.

This is what gets me the procedurally generated functionality of the terminal. That's not all I wanted though; I wanted it to be even more dynamic. I wanted the terminal to be extensible, so that I would be able to add new commands really easily.

Well then. Let's get started.

Extensibility

I decided on using ES6 classes to organize the JavaScript into a self-contained unit.I've experimented with this before to some success.

The actual implementation was very strightforward. I basically have a map of possible commands mapped to the functions that they call. All of the commands have access to the instance variables. Easy, clean stuff.

Wrap-up

So I guess that sums up the tech componenet of the terminal easter egg. Even though it was just an easter egg, it was probably one of the things I spent the most time on, just to get everything working okay.

Improvements

There are still some improvements to be made; some (obviously) less trivial than others.

I want tab completion.
I want to be able to register new commands outside of the actual class
Lists extend horizontally, not vertically.

Overall, I'm really happy with how it turned out, though, and I think this is a great foundation to keep building on.

Do My Friends Care About Me?

2017-04-15T07:00:00Z

A Brief Analysis of my Facebook Friends

This was a (not so) quick look at how I stacked up against my Facebook friends in a totally arbitrary measure.

I looked at the ratio of likes and reacts (henceforth to be referred to as a singular entity: "realikes") to a user's profile picture to that user's friend count. That is, what percentage of a user's friends realiked his or her profile picture?

Gathering Data

I'll post a more detailed write-up of the technical aspects of scraping the Facebook profiles, as well as an iPython Notebook with the code.

The most challenging (and time consuming) part was gathering the data. I ran into several dead ends before finally scraping the data from Facebook using Selenium. I'll go through all of the failed methods and my succeessful method here.

I had already collected a list of Facebook profile URLs just using Chrome Dev Tools on the client side.

My first idea was to use the Facebook Graph API. However, that quickly proved to be impossible, mainly because this StackOverflow answer said so.

So on to the second solution! I figured I could use the python requests and beautifulsoup libraries to crawl Facebook, and just pass in my Facebook cookies for auth. While the authentication totally worked (exciting!), I discovered that Facebook does basically all of the rendering client side, so the HTML that I received was just a bunch of links to async scripts.

Ultimately, I resorted to Selenium to scraping first the links to profile pictures, and later, the actual realike counts.

Examining the Data

After a little bit of cleaning up in Excel, I was ready to take a deeper look at the data.

# Import our beloved libraries

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt

# Read in the data

data = pd.read_csv('./data.csv')

# View the first 5 entries

data[:5]

	# Likes on Pic	# Friends
0	77.0	321.0
1	137.0	527.0
2	176.0	563.0
3	54.0	898.0
4	103.0	283.0

# This includes "bad" rows, which don't have values for either or both of the columns
len(data)

# Drop the bad stuff
data = data.dropna()

len(data)

plt.plot(data['# Friends'], data['# Likes on Pic'], 'bo')
plt.title('Realikes to Friend Count')
plt.ylabel('Realikes')
plt.xlabel('# Friends')

<matplotlib.text.Text at 0x115283f28>

There seems to be a general upwards trend, with users with more friends receiving a greater amount of likes from friends. This makes sense, since their pictures go out to a larger audience. I am more interested in the ratio between the realike count and friend count.

Looking at the Realike Ratios

# Insert new column of the ratios.
data['Ratio'] = data['# Likes on Pic'] / data['# Friends']

# First look at the ratios! Just a brief summary.
data['Ratio'].describe()

count    278.000000
mean       0.158833
std        0.093243
min        0.000000
25%        0.083202
50%        0.159469
75%        0.220952
max        0.492114
Name: Ratio, dtype: float64

Ok, so this summary provides some interesting information.

Just from clicking around Facebook earlier, I had thought that the average ratio would be somewhere between 20% and 30%, but it ended up being much lower, at 15.9%.

Also interesting to note is that no one had over half of their friends like their profile picture, although the max of 49.2% came pretty close.

# Sort data by friend count
data = data.sort_values(by='# Friends')

%matplotlib inline

plt.plot(data['# Friends'], data.Ratio, 'bo')
plt.xlabel('# Friends')
plt.ylabel('Ratio')
plt.title('# Friends vs Realike Ratio')

<matplotlib.text.Text at 0x113fc76a0>

One of the biggest things I was hoping to see was a correlation between friend size and ratio. However, that did not really manifest itself. As you can see, the points are relatively evenly distributed.

# Top 5 realike ratios.
data.sort_values(by='Ratio', ascending=False)[:5]

	# Likes on Pic	# Friends	Ratio
8	156.0	317.0	0.492114
11	155.0	376.0	0.412234
158	280.0	742.0	0.377358
4	103.0	283.0	0.363958
12	406.0	1118.0	0.363148

# Bottom 5 realike ratios.
data.sort_values(by='Ratio', ascending=True)[:5]

	# Likes on Pic	# Friends	Ratio
92	0.0	125.0	0.000000
40	0.0	117.0	0.000000
299	1.0	370.0	0.002703
57	2.0	539.0	0.003711
89	6.0	826.0	0.007264

Viewing the lowest 5 realike ratios reveals that those with the lowest friend counts do not have the lowest realike ratios.

Does Friend Count Matter?

I then took a look at the distributions for users with more than 1000 friends compared to users with fewer than 1000 friends.

It's important to note that there are significantly more users with fewer than 1000 friends in my data set.

gt1000 = data.loc[data['# Friends'] >= 1000]
lt1000 = data.loc[data['# Friends'] < 1000]

len(gt1000)

gt1000['Ratio'].describe()

count    44.000000
mean      0.173164
std       0.084129
min       0.008739
25%       0.116832
50%       0.180046
75%       0.219244
max       0.363148
Name: Ratio, dtype: float64

lt1000['Ratio'].describe()

count    234.000000
mean       0.156139
std        0.094783
min        0.000000
25%        0.072971
50%        0.155958
75%        0.220952
max        0.492114
Name: Ratio, dtype: float64

The mean ratio for those with > 1000 friends is a little bit larger than those without, as is the median.

%matplotlib inline

plt.figure(figsize=(12, 4))

plt.subplot(121)
plt.plot(lt1000['# Friends'], lt1000['Ratio'], 'ro')
plt.plot(gt1000['# Friends'] - 1000, gt1000['Ratio'], 'bo')

plt.xlabel('# Friends')
plt.ylabel('Realike Ratio')

<matplotlib.text.Text at 0x1140b42e8>

This plot might be a little bit confusing. The red dots represents users with fewer than 1000 friends. The blue dots represents users with 1000 or more friends, but the dots are scaled so as to align with the red dots (by subtracting 1000 from the friend count).

What does this reveal? Not much. There are more red dots in the upper right corner than blue dots, but the points are spread evenly enough where this is insignificant.

Looking at Friend Counts

As an aside, I took a look at the distribution of friend counts.

data['# Friends'].describe()

count     278.000000
mean      656.589928
std       395.612176
min        22.000000
25%       371.750000
50%       564.500000
75%       841.750000
max      2403.000000
Name: # Friends, dtype: float64

Conclusion? My friends, on average, have twice as many friends as I do. Sad.

plt.figure(figsize=(16, 8))

plt.subplot(121)
plt.boxplot(data['# Friends'])
plt.ylabel('# Friends')

plt.subplot(122)
plt.hist(data['# Friends'], bins=20)
plt.ylabel('Freq.')
plt.xlabel('# Friends')
plt.title('How Many Friends My Friends Have')

<matplotlib.text.Text at 0x114f552b0>

Distribution of my friends' friend counts

As shown by the box plot and, perhaps more obviously, by the histogram, the distribution of friend counts is skewed right, accounting for the large difference between mean friend count and median friend count. Either way, I look to be pretty anti-social.

Conclusions?

I can't really draw any statistically significant conclusions from these data. That said, there were some trends that were insightful or interesting to some extent.

Quality over Quantity

It's apparent that having a higher friend count does not necessarily result in a higher realike ratio. For 4 of the top 5 ranked realike users, the friend count was below the third quartile. In fact, the user with the highest friend count (2403 friends) had one of the lowest ratios (.8%)

That said, by examining the bottom 5, almost all were below the median friend count. This seems to imply that having too few friends is also not ideal.

Given these very broad generalizations, one can make the logical ssumption that there is a "Goldilocks zone" of friend count that yields that highest ratio. However, the data is probably much to scattered to be able to actually generate a useful model.

An Individualized Analysis

This data set was composed of only my friends. This meant the data set was tailored uniquely to my choice of friends, which are mostly high schoolers in the NOVA area.

Next Steps

There are quite a few paths in which I can proceed with this little experiment, if I want to. For one thing, it would be great to acquire more data, and, now that I think of it, generally profile pictures and friend counts are public, so I could expand the data set to beyond my friends.

Looking at the contents of the profile picture would also be interesting. For example, in pictures that were especially popular, were there multiple people? What is the gender / age / etc of the subject? However, this will be a much more nontrivial task.

The Blue Lagoon

2017-04-13T07:00:00Z

The Blue Lagoon

"The Blue Lagoon is a 1980 American romance and adventure film directed by Randal Kleiser"

This phrase is stuck in my head. Not because I'm a huge fan of poorly rated movies, but because it's a test phrase that Google likes to use to show off its speech synthesis algorithms. Speech synthesis has kinda been stuck in my head too.

Tacotron Yum

Recently, researchers at Google published a paper describing a text-to-speech generation model called “Tacotron”. It uses deep learning to learn how to generate audio based on input text. Besides catching my attention due to the delicious sounding title, the paper intrigued me because of the problems that arise when trying to synthesize speech from text. Current speech synthesis models in production rely primarily on concatenation of pre-recorded words, with some smoothing to make the words flow together more. The problem with this method is that the length of words and intonation are not taken fully into consideration, causing the synthesized audio to sound robotic and unnatural.

Synthesizing speech is a non-trivial problem, mainly because there is a lot of interpolation involved. Raw text does not provide a lot of clues for the tone, inflection, and expressiveness. The inflection in asking a question, such as "It's your birthay today?", is significantly different from that in a statement such as "It's your birthday today!" In addition, individual voices, obviously, differ by a lot, based on gender, nationality, etc. It's hard to teach a computer to generalize the important parts.

Tacotron takes a different approach from the current concatenative methods: it uses an “end-to-end” approach, wherein it learns from text/speech pairs to determine how to directly generate the raw spectrogram given an input text. This allows for it to include features such as a natural rhythm of speech, incorporate stress and intonation. The strength of a deep learning model is that it can naturally incorporate features that may otherwise go overlooked. Since it learns from recordings, for example, and uses that to generate speech, the generated audio also includes mouth-sounds and breathing that make the speech sound more human.

Speech synthesis is an incredibly relevant application of computer science, which is why I found the topic so interesting. Text to speech could be used to automatically generate audiobooks, create dialogue procedurally, and provide accurate verbal translations. Personal assistant applications that use a conversational interface would require natural speech synthesis for a more immersive user experience.

Additional Reading

You can read the Tacotron paper here (arxiv 1703.10135).

You can read about another one of Google's speech synthesis projects, WaveNet, here (website) or here (paper; arxiv 1609.03499).

About this Site - Design

2017-03-05T08:00:00Z

Getting Started

After getting an idea of what I wanted to accomplish with the site (which I detailed in the previous post), I was ready to begin designing.

Sketching
Mockups
- Home
- About
- Art
- Blog
- Projects
Post Mortem

Sketching

I normally start out with sketching some ideas. Conveniently, I was going to Seattle for winter break, so the hours on the flight sans internet was well-used.

I find sketching to be useful for figuring out layout and the flow of content. I was now ready to start making some mockups.

Mockups

I use Affinity Designer for all of my computer graphics work. I used to use Adobe Illustrator before I switched computers, and the overall workflow is very similar, which meant a pretty low learning curve for the transition.

Home

I started with the home page. I tried to keep it simple, and allow it to act as a hub to all of the other pages.

The index of the site

I also wanted to keep the terminal, and ultimately decided on adding a little flip tab to reveal the "inside" of the site.

The hidden terminal.

About

One of the first conditions for the About page was that I had to include a picture of myself. However, images always raise the risk of disrupting the stylistic consistency (especially when the photo isn't that good). I eventually decided to add an overlay of the theme color.

Both the desktop and mobile layouts

Art

A huge reason for the redesign of the site was because I wanted a place for me to show off the things that I draw and design. This is where the design things got interesting.

For the home page of the Art section, I wanted to keep it as a simple mosaic layout, without any text. In fact, in the original design, I had envisioned tiled and interlocking blocks. The goal was to have a wall of art, and clicking on one would lead you to a page explaining the piece in greater detail.

Mockup for home page of art

This detail page was more interesting to work with. I wanted to cast attention primarily upon the work, so I chose a dark background. The piece is displayed prominently as the first item, but underneath is the same layout as a blog post.

Detail page for a specific page. Note the unappealing background color.

This is probably the least polished part of the site. Some concerns I have about the details page is how the colors might clash. The current color is far from neutral.

Blog

I wanted to keep the blog as a separate entity from the rest of the site. This informed some of my decisions, such as having the navigation at the root of the blog be a "go to website" button, instead of the nav bar as shown on the rest of the site.

Table of Contents for the blog. Probably page that changed the least from design to development

The blog is mainly text-based, so I stuck to a black and white color scheme, like ink on paper. I'm satisfied with the very minimalist aesthetic.

I struggled more with the page of an article. I had a couple of choices to make.

Typeface:
- I planned on initially using two typefaces: Open Sans for headers, and a serif typeface for body text. However, it looked kind of busy, so I ultimately decided against it. I may revisit the idea in the future, though, because I kind of like the look.
Cover photo:
- I was unsure of how I would handle cover images. Initially, I planned on making the cover images fit into the width of the article, but I ended up preferring the expansive feeling of having the image stretch across the entire width of the screen.

Mockup of a blog post

Projects

I probably struggled with the Projects page the most. I tried 5 or 6 different card designs before settling on one that I liked. I played around with working project-specific colors into each card, but I figured that would be too busy.

So many variations of the card.

I added a subtle drop shadow just to keep things interesting.

Post Mortem

Overall, I'm very satisfied with the design of this site. Nonetheless, there are still a couple of things that I may change in the future.

Art Detail Page
- As I previously alluded to, I'm not entirely satisfied with the design of this page. I have two main concerns.
- I'm not happy with the color choice. It looks kind of muddy, and doesn't really allow the pieces to stand out that much.
- The presentation of additional images is flawed, especially since some images don't contrast as well against the background, and they're currently very small without a way to zoom in on them.
Project Cards
- I'm still not entirely sold on the design of the project cards. I think the presentation is a bit too plain.
Blog Post
- Font color is something I'm still working on with the blog. The color of links is harsh, and stands out too much. The pure black text on a pure white background also seems jarring. However, I like how sharp it feels with that much contrast.
- The Table of Contents needs to be dealt with to make it more interesting, or at least more visually appealing.

About this Site - Intro

2017-02-14T08:00:00Z

Edited 3/6/17 to add in new links and change title.

Introduction

I spent the better part of my winter break revamping my personal website (of which this blog is a component). You can view the old site here: naitian.github.io.

If you want to skip to another part of this walkthrough, I have links to all of the available parts listed for you here:

Design

Setting Goals

I think it's important to consider what the goals, desires, and requirements are for every project.

While I was generally satisfied with the old website, there were some issues that I felt needed addressing.

The overabundance of colors pulled from flatuicolors.com was busy, and seemed like it wasn't well thought out.
The terminal in the background never worked very well, and ultimately didn't do everything I wanted it to. I wanted a dynamic "terminal" through which you could basically browse the entire website.
I had gotten tired of the one-page layout, after also using for the Dev Club Website, so I wanted to challenge myself with a new type of layout.
I wanted to start up the blog again, and the original Jekyll blog was kind of a pain to work with. I wanted to minimize the friction involved with publishing new posts, which would in turn encourage me to write more.

Okay, so those were the things that I took issue with. However, there were some aspects of the site that I wanted to keep.

I liked the terminal; it's fun and nerdy. So I wanted to keep it, but maybe make it a bit more subtle.
I liked having distinct colors for the different sections.

Fizz Buzz

2017-01-26T08:00:00Z

Fizz Buzz? How trivial.

Recently, I needed to submit a fizz-buzz program as part of my application for a summer internship (hi Dagger Analytics!). I've decided to take advantage of that to talk about why sometimes, the most elegant code isn't the best code.

Cutting to the chase

Here is my Fizz-Buzz code:

// Javascript solution

for(let i = 1; i < 101; i++) {
   let string = '';
   if (i % 3 === 0) {
      string += 'fizz';
   }
   if (i % 5 === 0) {
      string += 'buzz';
   }
   if (string === '') {
      string = parseInt(i);
   }
   console.log(string)
}

Click to Toggle Output

Post-mortem (the good part)

Ok, so now that you have viewed this solution, you may have some questions. I can hear them right now.

Naitian, why would you use Javascript? Why are you using 13 lines to write something this simple? Etc, etc.

Well to address the elephant in the room, I used Javascript because it was the most convenient thing for me to write in. But to satisfy you, here's a solution in Python.

for i in range(1, 101):
    string = ''
    if i % 3 == 0:
        string += 'fizz'
    if i % 5 == 0:
        string += 'buzz'
    if string == '':
        string = str(i)
    print(string)

As you can see, it's the exact same thing. Alright, cool. So why didn't I do something totally rad, like this list comprehension!?

for line in [str(i) if (i % 3 != 0 and i % 5 != 0) else 'fizz' if (i % 3 == 0) else 'buzz' if (i % 5 == 0) else 'fizzbuzz' for i in range(1, 101)]:
    print(line)

See, it's only 2 lines and does the exact same thing! It also showcases my l33t h4x0r skills! Well, yeah, but you tell me what's going on in that mess.

When writing code, especially when it's a one-off sort of thing, it's often easy to get stuck trying to get a more "elegant" solution. But I think it's good to keep in mind that the technically superior solution is not necessarily the best solution. Sure, the list comprehension is arguably faster, but you shouldn't sacrifice that for readability, especially at such small scales.

That's not to say you shouldn't try to write good, performant code, but instead you should focus on writing maintainable, bug-free code, which ends up being a much more valuable skill in the real world.

Getting Cozy with Jekyll

2017-01-14T08:00:00Z

The Problem

I've been having lots of fun with this blog, and Jekyll makes it easy to write posts. I love the simplicity involved in creating a post and publishing it. However, there were some irritations involved when starting to write a post: I had to write the front matter manually every single time. As it turns out, I was basically copying and pasting the front matter and changing values every time. There must be a better way!

There isn't an easy fix for this. Since the front matter is specific to every post, there's nothing I can specify in the Jekyll configuration. So the question was: what do?

The Solution

After a little bit of research into preexisting solutions, I decided it would be easiest to just write my own little script. I have a special set up, where, in addition to just blog posts, I also have art and project posts that I want to semi-automate the generation of also.

I ended up writing a Python script that basically walks me through the front matter requirements for each post. The interface looks a little bit like this:

blog > title: Getting Cozy with Jekykll
blog > author(Naitian Zhou):
blog > cover(required): TODO
blog > desc(A blog post): A quick guide to easliy generating new Jekyll psts with Python and Mustache
Would you like to add a tag? (y/N)y
blog > tag > name: Python

This generates a file _drafts/getting-cozy-with-jekyll.md with the following content:

---
title: Getting Cozy with Jekyll
author: Naitian Zhou
cover: /assets/TODO
description: A quick guide to easily generating new Jekyll posts with Python and Mustache
tags:
    - Python
---

A couple of interesting notes: I implemented very basic default values, which allowed me to leave the Author: field blank, and included the ability to add lists to the front matter.

In fact, I even made it so that I could specify more JSON schemas for posts and the script would automatically be able to handle those as well. Here's the relevant directory structure:

 - //other Jekyll files
 - _templates/
   - schemas.json
   - art.mustache
   - blog.mustache
   - project.mustache
 - _utils/
   - help.py

I used the mustache templating language for easy templating. The art.mustache file looks like this:

---
title: {{title}}
src: {{img}}
{{#other}}
others:
{{/other}}
{{#other}}
   - {{file}}
{{/other}}
description: {{desc}}
---

This method gives me a lot of flexibility to flesh out the templates in the future. I could even add content into the body text, in addition to the front matter.

I used Python and the pystache library to take the input and render out the correct files.

To take input, I wrote a recursive function that looks at the schema specified by the schemas.json file.

Here is the entirety of the schemas file:

{
    "blog": {
        "title": "required",
        "author": "Naitian Zhou",
        "cover": "required",
        "desc": "A blog post",
        "tag": [
            {"name": ""}
        ]
    },
    "art": {
        "title": "required",
        "img": "required",
        "desc": "An art piece",
        "other": [
            {"file": ""}
        ]
    },
    "project": {
        "title": "",
        "thumb": "",
        "desc": "A project page",
        "tech": [
            {"name": ""}
        ]
    }    
}

The function looks like this:

def prompt(title, obj):
    """Prompt for input

    :obj: Empty Object
    :returns: Filled-in object

    """
    for key in obj:
        if type(obj[key]) is list:
            if input('Would you like to add a {}? (y/N)'.format(key)) == 'y':
                while True:
                    obj[key].append(prompt('{} > {}'.format(title, key), copy.deepcopy(obj[key][0])))
                    if input('Finished? (y/N)') == 'y':
                        break
            obj[key] = obj[key][1:] if len(obj[key]) >= 2 else None
        else:
            message = '{} > {}: '.format(title, key) if obj[key] == '' else '{} > {}({}): '.format(title, key, obj[key])
            val = input(message)
            if val != '':
                obj[key] = val
    return obj

It prompts you for the requisite values (and keeps the default if you don't enter anything), and recursively goes into lists if lists are present. It will then return an OrderedDict that we can feed into pystache.render().

Now whenever I want to write a new blog post, I can just call

$ _utils/help.py new blog

and it will hold my hand as we navigate through the front matter options.

You can find all of the files on the Github for my blog.

More specifically, here are the Python script and the template directory

Oops! and Why I Use Vim

2017-01-09T08:00:00Z

A Quick Apology

So a little over a week ago, I wrote my first post of the year, detailing a couple of my goals, one of which was to hopefully release a blog post every week. Oops... That lasted for a total of one week...

Anyway.

An Unhealthy Obsession

A couple of months ago, I switched to using Vim full-time to do all of my text editing (coding and writing Markdown... I still use MS Word for rich text editing).

When I say I can't go back to Sublime Text anymore, it's not because I'm in love with everything about Vim. It's not even that (despite what some people may say) Vim has shown me the flaws of all of the other graphical text editors in the world. In fact, I sometimes find myself missing all of the thoughtful, plug-and-play aspects of Sublime Text, like how easy theming it is, or how seamless the autocompletion is, or how package manager (with Package Control) "just works".

The real reason I can't go back to Sublime anymore is because, whenever I want to save a file, I end up typing "

" before I realize I needed to press Command-S. Oops.

So you may be wondering to yourself, Why would Naitian ever have wanted to use Vim then?

Good question.

An Unlikely Romance (OoooOOOOoooo)

The original motive was not to become a l33t hax0r that lives in the terminal. Oops. My experience with the command line has been one of slow, begrudging acceptance. I like to imagine it as a buddy film where the initial mutual disdain slowly blooms into a wonderful friendship.

Movie analogies aside, the true reason I chose to use Vim was because I could use Vim with tmux, which meant I had full control over how my text editor and terminal emulator meshed together. It was like a tiling window manager except I didn't need to install a tiling wm. Is that a weird, convoluted excuse to use vim? Yes, but that be the truth.

Well, after I played around with the vimrc for a little bit, I was hooked on how configurable vim was (I'm a sucker for config files), and the rest is history.

The Happy Ending

So now I use Vim every day to do everything from writing this sentence to making my website to doing my AI labs.

Expect a post on how I use Vim coming up soon (hopefully next week when I don't forget to post...)

Also! You know what would make the ending even happier? If you used that handy dandy RSS link in that footer down there to subscribe to this blog and read all of these mildly amusing posts!

New Year, New Blog, and New Bugs

2017-01-01T08:00:00Z

Organizing My Thoughts

I'm writing this blog post on New Year's Day, bracing myself for the violent reentry into my hectic school life in less than 2 days. I think this is a good opportunity for me to take a step back and organize my thoughts while I still have the time (and patience), so here goes.

This Website

I've spent the majority of my winter break working on this website. It's built with blood, sweat, and tears, except instead of blood I used Jekyll, and instead of sweat and tears I used Sass and HTML.

This was also my first time working with Sass, so definitely expect something about that experience soon. In fact, I didn't expect to be using Sass, until my hand was basically forced when I wanted to use any type of asset pipeline for minimizing and optimizing my assets.

There's still lots of work to be done, particularly in the little "terminal" easter egg on the home page, but I'm very happy with the site.

This Blog

After finishing the first version of the blog sometime in May of ~~this year~~ last year, I uploaded my first post (about Chrome Dev Tools), and then promptly ignored it for the rest of the year. I definitely plan on posting more, and hopefully at least once every week, with either tidbits of my personal life or technical advice.

This Life (Mine, Not Yours)

I expect that, once I enter the halls of Thomas Jefferson High School for Science and Technology, I will once again be faced with the challenges of balancing schoolwork with everything else that I want to do, including Dev Club, this blog, band, and so much more. So how do I plan on staying afloat? If only I knew. That said, I'll take to heart Dory's advice of "Just keep swimming", and keep you guys updated.

Speaking of Being Updated...

Subscribe to this blog using the RSS feed!

Anyway, Happy New Year's, and I hope you're as excited as I am (despite my moaning and groaning) to start this year off strong.

Chrome Developer Tools

2016-05-30T07:00:00Z

Chrome Dev Tools

A good grasp of how to use Chrome (or equivalent) Dev Tools are one of the most fundamental skills a web developer must have. From monitoring network calls to debugging Javascript to testing out CSS style changes, Dev Tools provides a useful repertoire of functions to help you develop, test, and optimize a web page.

Why Chrome?

There is not a particular reason why I chose Chrome Dev Tools over other browsers, other than that I use Chrome and Chrome Dev Tools more than other browsers. Chrome Dev Tools does offer a lot of useful features, some of which may apply to cutting-edge web development standards, that may not be present on other browsers.

Opening Chrome Dev Tools

Windows: F12 or Ctrl+Shift+I Linux: Ctrl+Shift+I Mac: Cmd+Opt+I

CDT and the DOM

DOM stands for Document Object Model. It's a convention for representing and manipulating objects in HTML, XML, and XHTML documents (characterized by the angle brackets).

What can I do?

Inspect any element
View and change CSS rules
View the element's box model

Inspecting Elements

There are several ways to select and inspect a particular element. One can:

Click on the element selection tool, then click on an element to jump to that position in the document.

Click on a specific element in the Dev Tools Elements view.

What Can I Do With These Elements?

Now that you have selected an element, you can right-click on the element to see some of the actions you can do:

Especially notable is the ability to toggle states such as active, hover, etc.

Styling

One of the most useful aspects of Dev Tools is the ability to change styles easily.

With an element selected, you can easily view its styles.

The "Styles" tab contains all of the CSS rules that govern the selected element.

We can see that the selected element has an id of "overlay", and a class of "shell", and that there are CSS rules defined for those selectors. The overridden styles are struck through. You can also toggle element state in this tab.

If you have animations or transitions with a timing function defined, you can also use the cubic bezier editor to help you with your animations.

Box Model

The Computed Box Model provides the final computed values of margin, padding, width, height, etc. This is particularly useful when creating responsive layouts, or when there's an awkward gap in your layout that you can't find the source of. You can access this view by clicking on the computed tab.

Network

Another very useful aspect of Dev Tools is the Network tab. This allows you to view all requests made from this webpage. This includes requests for images, files, fonts, scripts, etc.

It also helps you determine if there is a major bottleneck to page load times. In this image, try to find at least one request of each of the following types:

HTML Document
Font
Stylesheet
Javascript File
Image

Example Case Study

Cubemania is a Rubik's Cube timing website that allows users to save their times. I use it a lot. Let's analyze some of the requests it makes, specifically when a user logs in.

Now let's open up Chrome Dev Tools and switch over to the Network Tab.

Make sure that the red "record" button in the top left is active.

Now I'll click log in and see what requests are made.

We're hit by a barrage of requests. Let's look at the most interesting ones...

There's a POST request at the very top. Usually these are for form submissions. Let's click it open and take a more detailed look.

This a lot of information! We can deduce some things about how Cubemania works on the server side! For example, we now know that this POST request is making a call to the http://www.cubemania.org/session endpoint, and that our session is stored in a _Cubemania_session cookie. We can also see all of our request headers, which we might be able to use to recreate this request manually. If we scroll further down, we see the really interesting bit: the form data.

Now, I blacked out my password, of course, but as you can see, we know exactly what fields are passed into the POST request! Now, you might notice that there is also an authenticity_token field. This is generated on the server side to try to make sure that you cannot spoof these requests. A bit of light Googling reveals that this is common in Ruby on Rails web apps. However, if we access the contents of the HTML first, we will be able to find the token and pass it into the POST request.

Resources Tab

The resources tab contains information on the majority of client-side storage options. This includes local storage and cookies.

Local Storage

If we click open the local storage section, we can find that Cubemania stores all of my times in the local storage.

Cookies

We can also view the cookies that Cubemania has stored. In here we do indeed see the _Cubemania_session cookie we saw mentioned previously.

Exercises

Go on the Cubemania website and answer these questions:

Click on the 'Users' tab. What type of CSS selector is used to apply the yellow background on hover effect?
Search for "naitian" in the search box. Monitor the network traffic. What is/are the query string parameter(s) of the search query? What is/are the value(s) of the parameter? Is this request a GET request or POST request? Why does that make sense?

Visit this wonderful lawn care website: http://kamronsoldozy.github.io

Look in the Console. What are some errors? Are any of these errors related to each other?
Based on these errors, what part of the home page is broken? What is it supposed to do?
How can we fix this?

Bonus) Solve a Rubik's cube in under 30 seconds.

Exercise Answers

1a.) #content a

1b.) Parameter: q, Value: naitian, GET request, There is no need for a POST request, since this value does not need to be kept confidential.

2a.) There are three errors. The failure to load jquery.min.js is directly tied to the Uncaught ReferenceError: $ not defined.

2b.) By viewing the details of the ReferenceError, we see that we need jQuery in image_slide.js, which is supposed to provide an image slider.

2c.) If we load in jQuery, the image slider should no longer be broken, and will alternate between the 2 images.