Weekly Update (August 6, 2017)

Hello again.

I regret to inform that I haven’t posted anything useful in the last week. I’ll try to make this change.

Part of the reason is that I was occupied playing the wonderful, beautiful Pyre. Supergiant has produced two (now three) of my favorite games of all time, so I couldn’t help but finish Pyre as fast as possible.

I got to see Earth, Wind and Fire, with three of the original members performing. That was pretty great!

On the code side, I put up a Jekyll site to house all the demos I’ve been collecting. It’s a nice place to put them together and showcase. You’ll find it hosted on Github pages.

In order to populate the site, I made a fabric simulation and a fluid simulation. This is the first time I’ve managed to get a fabric simulation to work! In the past, when I’ve tried to make spring systems, I’ve gotten really odd results.


I finally discovered that the reason for this was because I had no friction. In theory, this should only cause spring motions to oscillate, but I think rounding error compounded over many frames probably caused the system to go out of control. All I had to do was add a velocity-based damping factor to the differential equation and it worked out.

(I also accidentally discovered a cool effect, and kept it for later use. It’s based on a bug, so here’s a gif in case it gets fixed in the future.)

A tear in spacetime!

The fluid simulation uses cellular automata. I got the algorithm from a Reddit post. I really like the algorithm because it’s extremely elegant. I’ll probably find a way to repurpose it for a later project.

My favorite project this week is probably this parallax demo. It’s a jQuery plugin that generates a parallax-powered mountain scene into an arbitrary element. I’ve put it in the background of some of the page on my website. (If you’re reading this in the future, that link may have changed, and that effect may no longer be live.) I’ll probably work on making the plugin public.

I started working on a project to bring pure math education to the masses, but it’s still in its infantile stages. Expect another update on this soon.

On the lab side, I got the front-end for the collaboration we’re working on to a workable enough point that we’re ready to demo it. We’re meeting with the other group on Thursday to explain how our system can interface with theirs.

That’s all for me.

Weekly Update (July 30, 2017)

This past week has been pretty tiring. I coded a lot, as usual.

I started contributing to freeCodeCamp.

I released the Pico theme used on my homepage. It’s called Attache.

Little Planet Procedural got quite popular! Someone found it and posted it to Hackernews. I had a few people reach out to me expressing their interest in my work. Nice!

I was pretty active on Github this week. Github shows something like 60 contributions. I wrote a little script which can schedule publishing so that you can optimize viewership. Use it instead of apps like Later for Reddit to save money. Although, if you’re a competent dev you can probably figure out how to write it yourself, anyway. It’s not hard.

As usual, I’m continuing to work at my lab. I’m meeting with my program advisor next week to check in.

Didn’t do much work on my game this week, but it will continue to progress slowly but surely. Be sure to watch out for an official announcement + development blog later down the road.

That’s all for me.

RIP Flash

On July 25, 2017, Adobe officially announced the eventual discontinuation of support for Flash. In the software world, this is referred to as an EoL or ‘End-of-Life.’

Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.

It’s interesting to go back in time and look at web development and design paradigms. At first, with limited technologies available, websites were just static pieces of unstyled text. As the technology to make things flashier began to emerge, enthusiastic developers endeavored to inject as much shiny technology into every webpage as possible, resulting in such creations as this.

animated gif
Oh my…

It used to be considered a web design paradigm to create giant background images and resize them, so much so that people wrote articles specifically on the practice, while nowadays, nearly a decade later, this is generally considered poor practice. While 10 years may not seem like that much time, the internet itself has only been around since about 1990 – making 10 years about a third of its whole lifespan! A lot has changed since then.

One major change has been the gradual flattening and minimization of design paradigms. Many company logos have flattened to become cleaner. Some would argue that a lot of this is due to Apple’s design philosophies. Either way, minimalism is here to stay.

The ubiquity of minimalism is underscored by the desire for interactivity in modern design. Minimalism and interactivity may seem like two opposing concepts – after all, isn’t interactivity adding more, while minimalism is about having less? In reality, minimalism promotes interactivity by allowing the same input from the user to have a more drastic visual effect. A mouse click leading to a color change doesn’t translate into nearly as much visual impact when there’s other fluff on the screen as opposed to a blank canvas. What we see is an overall increase in responsiveness as the web continues to mature. In many ways, user experience is all about responsiveness. This is essentially the core topic of the bible of UX design, Steve Krug’s “Don’t Make Me Think.

Adobe aimed to address this desire for responsiveness through Flash. For a while, Flash was the only real option for graphical interactivity around. It frontloaded a lot of the computational power necessary for interactivity to the flash interpreter, allowing for faster site loading times. In more modern times, full-Flash websites are generally discouraged – but that didn’t stop them from becoming very popular. Just a few years ago, at least 80% of Chrome users would visit a site with flash each day. Now, the number is just 17%.

A big reason for this is probably Youtube’s switch from Flash to HTML5 video. One of the big things motivating Flash’s use for so long was its near-monopoly as a technology for video-playing. However, the past few years have seem tremendous leaps in web spec, including native HTML5 video support, the release of ES6 and the introduction of WebAssembly. This combination of factors led Adobe to decide that Flash was no longer needed.

What does this mean?

Well, from the front-end, not that much. The typical user probably alternates between a few social media sites, work sites, and a handful of news outlets. Pretty much all of these big companies converted to HTML5 video a long time ago.

Really, the most interesting effect of this change is the removal of legacy support. Adobe is working closely with major web companies like Google to ensure as much Flash content is migrated as possible, but the lack of proper support means that some decade-old websites are probably going to be unviewable in a few years.

This is particularly interesting because the web has a fetish for legacy support, so much so that people constantly write articles about it. Whether it’s making websites work with old browsers or making browsers work with old websites, dealing with multiple conflicting standards has been a cornerstone of web development since time immemorial. A web developer aims to deliver the best possible experience to every user, regardless of platform.

This brings up two conflicting viewpoints on the Flash subject. Opponents of the change will argue that important archival websites will be rendered unviewable for future generations, an issue never before faced in the short history of the web. Supporters of the change will cite the increased security and stricter guidelines of modern technologies as promoting a cleaner, more streamlined web.

There isn’t really a right answer here. Personally, I’m all in favor of this change. Anyone who’s tried to write industrial code to support IE8 has experienced the nightmare of writing legacy code. In my opinion, Microsoft should have discarded IE long ago and forced old customers to update. (They finally did so last year.) Unfortunately, technical illiteracy makes such updates difficult, since the everyday layman will adopt the philosophy of “if it ain’t broke, don’t fix it.”

I think that we should just make technical literacy a more prominent part of education. Perhaps this is a bit of a selfish answer, since I’m just trying to save myself development hassle, but in the long run streamlining development tightens security. The more complex a project gets, the more likely it is that holes will appear. We really don’t need to open up more outlets for attacks than we need to.

Modern specs have already shown to be more secure than Flash, and this difference will only be amplified if we try to duct tape legacy support onto Flash in the future. We’ve already seen some pretty horrible things happen due to lazy updating and legacy software. The WannaCry attack costed hundreds of millions of dollars in damages due to poorly maintained software. Perhaps the most infamous example is the Java 6 bug, which directly contributed to the decline of Java, formerly one of the most universal languages. Now, it doesn’t even have official Chrome support due to its history of security issues.

Closing Thoughts

By 2020, we will have witnessed a landmark step in the development of the web. This is the first time1 such a major technology has been phased out from the entire web, across all browsers. While the overall security of users will likely overall increase, entire businesses and sites that run on Flash are going to be in for a tough time. Kongregate is built nearly entirely on Flash games. They will likely need to find a wrapper to play legacy .swf files, which may open up vulnerabilities.

Whatever happens, this will likely be a learning point for the future. As the web specs continue to evolve at a breakneck pace, even more technologies will get phased out. In particular, there are certain conflicts (e.g. function hoisting) in the ES6 and ES5 specs that may render entire websites unviewable.

Goodbye Flash. You will be dearly missed, and will forever exist as childhood Kongregate games in my heart.

1 Edit 06/28/17: Someone correctly pointed out to me that other technologies, such as the blink tag and applets, have been deprecated. My statement is thus not strictly true. However, Flash will still be one of the most widespread, if not the most widespread, technology to be deprecated – the blink tag was more of a novelty, and applets fell apart browser-first. (Chrome removed support long before Sun gave it up.)

Weekly Update (July 23, 2017)

I continued to work with my lab. I’ve begun trying to construct a systemization of data tasks. This would potentially lay the groundwork for the future of another project.

I did a bunch of SEO on my websites and updated my Github. I’m looking more and more legit by the day!

google search result
This is on the first page!

I was contacted by a reader of my blog, which is a really nice feeling for me, since it indicates that the random jumble I’m writing here is potentially influencing someone else, even if just a little bit.

I’ve finished transcribing In Just a Moment’s Time from Skullgirls. Keep watching for a cover! I’ll also probably upload the transcription to Musescore at some point.

I ran into an issue on my current game. I wrote about this here, as well. However, I’m going to keep pushing forward to make this work!

This week, I’m hoping finish that cover, and otherwise just continue to work on projects. I’m working on porting some of my design docs over to a CMS the same way I’ve done for docs.alanluo.com.

Engines and Limitations

So, I’m currently making a game. I’ve been using Unity as my engine of choice due to its documentation. The Unity Docs are very well-written and totally comprehensive. Unity also has a rather large corpus of official instructive videos. I rarely find myself needing to look beyond the official Unity resources when treading into unknown territory.

For my current game, I’ve spent a long time designing the holistic product. I’ve always believed in integrated design when it comes to making things. I have the entire game down in my head, from level design to aesthetic to music to even the title. It’s all there, and it all fits together. Now I just need to make it work.

However, I’ve run into a bit of a situation. The way Unity is made, I cannot make my aesthetic work.

Essentially, I’m trying to make a real-time paint splatter effect similar to the one used in Ink. (You can find a Codepen prototype here. Credits to Zack Bell’s original post.) This essentially requires drawing a level-sized texture in realtime, masking the texture with the visible portions of the level, and updating the texture every time a splatter is made. In theory, this should be very fast. Drawing pixels is already what happens on the bottom layer of the graphics pipeline. By skipping the rendering step and going straight to the draw step, this should be very fast. Right?

Unfortunately, Unity’s architecture prevents this. Most of the operations exposed to the Unity developer, including graphics drawing, occur on the CPU. In order to update a texture, you have to call Texture2D.Apply(). The Docs page indicates that this function doesn’t actually ‘apply’ pixel changes in the literal sense, rather, it uploads the CPU version of the texture to the GPU for rendering.

While not an expensive operation, this means that even the simple task of rendering a texture every frame becomes throttled by bandwidth, and it becomes nearly impossible to actually accomplish the aesthetic that I am aiming for on a large scale.

Considering that this project is currently in its infantile stages, this should not be a problem. However, I have December deadline to meet.

Moving forward, I have a couple of solutions.

I could rework my design of my current game to change the aesthetic. This would force me to give up a little bit of my creative vision, but would allow me to stay comfortable within an engine that I am familiar with.

I could shelf this current game entirely. In order to meet the deadline, I could make a different game in my current engine, and save my current idea for a later time. However, I run the risk of making a game that’s not very well thought-out.

I could stick with my current idea, and rewrite the entire thing in a different engine. Since we’re still in early stages, this wouldn’t take that long. However, I would also have to learn that engine quickly enough to make the deadline.

All of these solutions are pretty terrible, if you ask me. I’m going to have to mull this over and discuss this with other people before moving forward. In the meantime, there are a few discussion points.

First of all, how valuable is holistic design? One one hand, there is a lot of value to cohesion and polish in a final product, but on the other hand, this can cause development to lag when reaching for an MVP. What’s more important – upholding artistic integrity, or finishing?

Second of all, should you learn one engine really well, or know a lot of engines pretty well? In theory, I could still fix my problem in Unity with direct low-level OpenGL calls, but this would require a much more in-depth engine knowledge, which might be easier or harder than learning Game Maker. On the other hand, since Unity and Game Maker are very different engines, perhaps I should just learn them both, anyway. This applies to many other things – Jekyll vs Pico, React vs Meteor, etc. (Okay, those things aren’t directly comparable, but whatever.)

I’m going to have to work at this a little bit. Expect a return to this topic in the future.

Establishing a Personal Brand

Alright, full disclosure: I am not a professional in this field. In fact, quite frankly, I’m not even sure if I’ve got a damn clue what I’m talking about. But I just spent a few days agonizing over this so I’m gonna give my own insights.

First of all: why bother? Why go through all the effort of personal branding when you can make good money being a nobody on the internet?

To some extent, it really depends what your goals are. If you want to become a researcher, your online identity probably won’t matter – all the people who care about you will already know your name.

For me, there are all sorts of weird projects that I would like to make into real projects. Having a cohesive online identity would make me much more credible as a maker. In addition, if I happen to build up a following, I have already have a pre-established market to sell things to.

For instance, I’m currently working on making a game. I could try to go through the whole Greenlight process as a no-name developer and drown with the other thousands of indies. This is obviously not a particularly favorable situation.

My current plan is to gradually establish my online identity as a game designer, granting credibility to people who’d like to check my background. In the process, I’ll try to build up a following just large enough to successfully run a large Kickstarter. That’s the first goal – we can move on from there.

As another example, you should know from this blog that I code a whole damn lot. One person I respect a whole lot is Daniel Shiffman. He does all sorts of cool stuff, check him out! He has a very well-established personal brand as a guy who connects creativity and code (a purpose you may recognize from my own site). When I first stumbled upon the Nature of Code book, I looked more into his background and started following his Youtube channel, and eventually his website and blog. When he runs his next project, I’ll be one of the first customers to hop on that purchase!

Social media and the internet allows you to crowdsource the entire public relations and marketing nightmare. By building a following, you get free market research. By producing content, you create an image for yourself. Even though these acts may not be profitable by themselves, they can fuel future entrepreneurship.

Let’s keep this in mind when we start building our brand. We’re not trying to make money. We’re trying to establish an online presence for ourselves.

There’s a really easy to benchmark this. Pick a name. It can be your real name. Got it? Now pick an adjective or noun describing you. In my example, I might pick ‘Alan Luo, Developer.”

If you Google that phrase, you want one of your online presences (Twitter, Youtube, personal website, etc.) to come up on the first page. “Jenna Marbles Youtuber.” “John Green Vlogger.” “Randall Munroe Comics.”

Once we’ve reached that milestone, we want to drop the label and just put the name. So, my eventual goal is to make it so that this site pops up when you Google “Alan Luo.”

Not only should the link exist, if I click that link, I should see something that makes me view this person as a credible expert of their field. Regardless of whether or not I’ve published any real software yet, I want my website to show people that I’m serious about coding and that I might publish something in the future.

At the time of writing, I’m somewhere in between step two and three. Googling “Alan Luo” lands me somewhere between the end of the first and start of the second page, and when you click my website, you see a mostly completed portfolio site that’s lacking a little bit in fleshed-out content.

Alright, keeping these goals in mind, I’d like to highlight some of the struggles and solutions I ran into during this process.

Multiple accounts. This was one heck of a nightmare! I have like a dozen accounts across a handful of properties, just on Google alone, then handfuls of accounts on a number of smaller websites, and so on… The first thing I did was centralize each facet of my identity onto a single email and moniker. (I have three primary online identities right now, two of which I will not yet disclose for various reasons.) For instance, “Alan Luo, the developer” is ‘alan-luo’ on Github and Reddit, ‘alanluo’ on Codepen, and has the email “me@alanluo.com.” However, I have entirely separate sets of usernames and emails for my other identities. The key thing to highlight is that each within each identity, I always use the same Moniker.

For managing multiple accounts, I recommend linking as many things as possible to Google. First of all, Google has historically strong email security. Second of all, they already have a feature for managing multiple accounts. If you use Reddit, I also recommend using RES, as well.

Multiple Identities Why bother separating into multiple identities? Why not bunch all of it into one? The point here is that you don’t want something intended for one audience to interfere with another audience. If I make hardcore coding videos on my Youtube channel, I don’t want to start releasing music videos, or I’ll estrange followers. Separating yourself into multiple identities allows you full control over what the world views you to be.

One thing to note here is that you must separate your personal and professional selves. If you’re a League of Legends streamer, the last thing you want is the discovery that you’re a moderator of a DOTA 2 forum.

SEO and Content Propagation

Once you’ve sorted out all your accounts via the first two steps, the last step is to actually build the identity. Build an identity most relevant to what you’re doing. If you’re an artist, make a Deviantart account and build up a solid portfolio. If you’re a coder, you should have a Github and Codepen account, a personal website, a portfolio and CV, and a devblog. A personal website demonstrates that you have basic web development skills, which are pretty much ubiquitously needed. Github and Codepen allow you to build up your corpus of shareable code. The devblog is just a really popular thing among developers, and is not necessary, but it an important rite of passage. (See my first post.) Your portfolio and CV don’t have to be public or indexed on any search engines – just make sure they’re sufficiently available for employers.

The reason I bunch SEO into this section is that if your content is well-made enough, SEO will sort itself out. Any social media outlet that is well-propagated will have a high search engine rating. Linking these outlets to your own site will quickly boost the rating of that site, as well. These are often referred to as ‘Web 2.0s’ in SEO. (Although, if you Google that term, you’ll see all sorts of shady techniques for creating spam accounts to boost your index rating. Please don’t do this.)

Another advantage of separating your identities is that SEO becomes much cleaner. I know that I can make this website show up if you look up “Alan Luo coder.” However, if I want it to show up for both “Alan Luo coder” and “Alan Luo game designer,” I have a whole different bag of worms. I’ve chosen to associate the “Alan Luo” persona with my developer self, as that is what I am currently more focused on. If this changes in the future, I’ll be sure to update my identity accordingly.


Well, I hope this has been useful to someone. Personal branding is honestly a huge pain in the butt and I will probably have to tackle this again sometime in the future. If you’re reading this years in the future, first of all: Hello, technomancing cyberninja from the future! And hopefully you can take something useful from this.

Weekly Update (July 16, 2017)

As has been the case for most of this summer, I spent most of my time working with my lab. I’m not sure at what liberty I am to disclose what we’re working on, but I’ll say that I worked on debugging an experiment we ran on Amazon Mechanical Turk. Essentially, we were running into an issue where the asynchronicity of Node resulted in one file being edited by two instances at once, resulting in corrupted data.

I also got my knowledge base up and running at [docs.alanluo.com](http://docs.alanluo.com]. Those are literally my personal notes synced to a remote Git repository on my hosting service. In an effort to promote global education, I plan to make those notes public for anyone to benefit from. I also turned the site into a theme for Pico CMS called Clutter. (Technically, some of this is from more than a week ago, but whatever.)

There are a handful of internships I am looking at. Unfortunately, most only take college students. This, however, has not stopped me from preparing applications anyway. I updated my CV, and asked some adults I knew for references.

On the music front, I have begun transcribing In Just a Moment’s Time from Skullgirls. Expect a cover coming out soon.

Oh! And, of course, I set up this blog! I doubt anyone has read the posts up to this point, but I hope to expand my personal brand and online presence. I have more plans for this going forward – stay tuned!

On that note, I spent quite a bit of time planning and rearranging my online identity. When you have more than one interest and you’re looking to make all those interests digital, it’s hard to keep accounts, emails, and identities in check. I’ve decided to break my online identity down into three people. I’m not entirely willing to disclose the other two just yet. They’re all a part of my aforementioned plans. Just wait.

This week, I’m hoping to start taking better notes, prepare for water polo season, and continue my research job. And hopefully I’ll start maintaining this blog multi-weekly. As in, more than one post a week.

Becoming a Better Coder

There are all sorts of pedagogies and philosophies for improving yourself. It doesn’t matter what field. It’s a common for classical musicians to start entire schools based around their personal pedagogies. In light of this, I’d like to present my personal method for becoming a better coder. This is the routine that I follow.

Whether you’re a new developer or an experienced one, I encourage you to read this. Even if you’re the best coder in the world, I’d like to know your thoughts on if my philosophy is useful / boring / unnecessary / etc. And hey, you might gain a new perspective.


I believe that the best programmers are ones who have domain expertise but are flexible. Often, I’m asked, “What languages do you know?” I can’t help but think that this is a pointless question. Programming evolves on a day-to-day basis, and different languages suit different problems. If you only know one language and cannot adapt to fit a new situation, you’ll be a one-trick pony.

That being said, there is a lot of merit in knowing one engine inside and out. The hardest problems cannot be solved by Googling, and will require a deep knowledge of not only how a system works but why.

My personal pedagogy is designed with these two concepts in mind. I’m training myself to be the best I can be in the field of my choice, but with a diverse enough toolkit to tackle any problem.

I believe that we should practice coding the same way one practices music. Even the greatest pianists do technical exercises every day. Similarly, I believe that no matter how good or accomplished you are, there are fundamentals you need to train every day.

I break down programming into four main components.

Programming Theory

This refers to developing an aptitude for the act of coding itself. This means learning languages, libraries, APIs, and so on. No matter how good you are at a language, there is always more to learn. If you’ve been comfortably using Javascript in webpages, push yourself to make apps and learn closures. If you’ve never seen ES6, learn that. If you know everything about ES6, read a style guide. If you’ve read every style guide, learn a library. There’s always something to do.

This section also includes learning a new language. I feel like learning the advanced aspects of a language you’re familiar with is similar to learning a language you’ve never seen before. I encourage exploring known languages further and learning new ones. I think it’s important to always be doing both. Essentially, this section refers to the engineering part of programming. If I’m given any problem and I’m told to use any platform, can I understand all the tools available, identify the best one, and use it to construct a solution?

I find that a good rule of thumb is one concept a day. For Javascript, you might do closures one day, then prototypes the next. Make sure you really spend the time to understand the concept fully.

Computer Science

This refers to, essentially, data structures and algorithms. These are things you can learn with a pencil and paper (but not implement). This is the abstract side of programming, while programming theory is the concrete side.

The implementation is just as important as the understanding. Every language has its quirks that necessitate a certain algorithm being implemented in a certain way – whether it’s with using pointers, stateful functions, etc. I try to regularly learn and implement new algorithms.

I try to learn and implement an algorithm a week. I try to not use the same language too many times, so that I can become fluent in multiple languages.


Demos are essentially small projects. They are usually used to demonstrate understanding of a particular topic, often showcasing a neat usage of one algorithm. The point of demos is to keep you creative. I feel like just being a good engineer is boring. The ability to generate ideas, connect concepts, and create applications is inherently tied to creativity and imagination. However, contrary to popular belief, these skills are very much learnable.

For reference, ‘demo’ refers to something of about this size.

I try to do one to two demos a week. I often end up making demos for the algorithms I’ve just learned. Also, another advantage of consistently doing demos is that it quickly builds up a portfolio to send to potential employers.


Projects are the bulk of coding and are the most important part. They’re what coding is spiritually about. Projects are the things you make. This includes both your work / job and personal projects. I lump them all into this category – they’re long-term pursuits with no clear end and often involve many languages and algorithms at once. They’re things that you’d be happy to publish and/or monetize.

Spending lots of time on theory is no use if you can’t put it into a project. No matter your skill level, even if you’re a total beginner, you should always be working on a project. I don’t care if you’ve read the whole Java spec start to finish, if you’ve never made a project, your skills are worthless.

One issue that I’ve personally observed often is the lack of focus on project work in the AP Computer Science curriculum. Schools treat coding like any other class, when in reality it is more of a skill than a subject. Sure, computer science is often very much like math – but AP CS in high school barely teaches any computer science at all. In general, high school CS education is broken. Hell, the AP test is taken with a pencil and paper! What results is a slew of high-scoring CS students who can barely code.

You should spend as much time as possible working on a project. If it’s a project you care about, it’ll keep you up at night.


How you schedule your work day is entirely up to you. These are just guidelines, but I’d recommend spending an absolute maximum of one-third of your time on non-project stuff. Even if you’re in a rush to finish, spending time away from your project can actually accelerate the development process.

You can read about relevant algorithms or learn the engines you’re using more in-depth. Often, this will actually save you time in the long run, especially if you learn a key paradigm or model. For instance, writing an app with or without MVC philosophy is an entirely different experience. Just don’t forget to make time for demos.

When I’m not in school, I probably spend about 10 hours a day coding. Out of those 10 hours, 8 will be project work.


Well, that’s all for me. This is what I tell people who ask me for help, and this is what I stand by. Feel free to contact me with your thoughts – I’d love to hear what your learning strategies are, whether you agree with me or not.

The Internet of People

July 12, 2017. Today is global Net Neutrality Day. Amidst our turmoiled political climate, America has united to uphold the principles of free speech we hold so dear. You can participate in this battle here.

The internet is not made of things.

We have inclinations to view the internet like any other object, like something we can just pick up, use, and put down. And certainly, there is an element of truth to this perspective. The internet has computers, cables, and screens. The words you’re reading are sitting on a box somewhere on Dreamhost’s servers, being transmitted at light speed through intercontinental cables. Cables, screens, and servers – those are all ‘things.’

But the internet is not ‘things.’ It should be obvious that the internet transcends the traditional boundaries of ‘thing’ that we ascribe to other everyday objects. It doesn’t transport material goods. We’ve created a system where we use imaginary digital currency to pay for imaginary digital goods. None of it exists. Netflix shows are not ‘things.’ My digital money is not a ‘thing.’

In reality, the internet is this abstract, amorphous structure that just, well, exists. It’s nowhere and everywhere. You can’t shut it down. It’s a bastion of free speech. It’s started uprisings, united distant friends, and told stories. It’s the most powerful platform of expression that humanity has ever created. The internet is an abstraction of humanity, a digital embodiment of ourselves.

Because the internet isn’t about things, it’s about people. It’s about expression. It’s an information superhighway. It’s humanity’s greatest invention. It’s a symbol of unity. It’s a pinnacle of technology. It’s the greatest expressive platform that we have ever created.

And the FCC is trying to turn it into a thing.

When I play with toys, I play with a ‘thing.’ But when I play a video game, I’m playing a product that never existed physically. Many games are created, published, and sold all in cyberspace. They’re just ideas. Some of the ideas on the internet are stronger than others. The internet has memes to passions to personas and everything in between, and these ideas collectively form the most visceral and direct manifestations of individuality we have ever seen.

With the rise of Youtube and Tumblr stars, we’ve seen this fundamental expression be turned into business. It’s the content creator agreement. I make cool stuff, you look at it. Both of us benefit. The people in the middle lay down the roads for us and don’t mess with the shit we’re trying to send through.

Essentially, ISPs (the monopolistic ones, like Comcast) have been constantly trying to mess with these roads. They own the roads, and they thus claim the right to be able to throttle and control bandwidth. This is a terrible thing, but they call it ‘innovation.’ ISPs have tried to do this again and again, only to be faced with legislation and pushback. But somehow, something always happens, and a loophole is always found. The latest loophole would allow ISPs to overturn the safeties that were been put in place for consumers in 2015.

We fought them back then, so we can fight them now. Participate in this battle here. Want to know more? Vi Hart has a fantastic video summing up the history of this whole thing.

If you’re a developer, you know that the internet has evolved to nourish thousands of cultural microcosms that span political borders. You’ve seen what the internet has brought to the world.

Fight to defend it. Fight for free speech.

On Coding Style

It’s hard to write good code. It’s easy to find yourself putting in temporary fix after temporary fix, duct taping all the holes in your website until the function nesting has more layers than a Hungarian sponge cake.

There’s an adage that goes:

Code is read more often than it is written.

This should be your one and only golden rule when writing code.

You’ll often see coding style guides in the wild. Don’t follow these. At least, not strictly. They’re a good guideline, but blindly adhering to them demonstrates a lack of critical thinking rather than an appreciation for the origin of and necessity for a style guide in the first place. Style is supposed to make your code more readable.

Most of those style guides come from companies with hundreds of employees writing thousands of lines of code. It makes much more sense for them to strictly standardize their code – it makes Git diffs cleaner, and makes it easier when reading code to switch from component to component. But if you’re writing code for yourself on your personal website, write code that YOU want to read.

For instance, take this example from the Airbnb Javascript style guide:

// bad
function foo() {
  // ...

// good
const foo = function bar() {
  // ...

This standard makes a lot of sense. The first example can cause readability issues by hoisting.

However, the second example is verbose and annoying. If i’m writing a 100-line demo on Codepen, there’s no point in bothering with that verbose syntax – and, in fact, it can make my code less readable if I need to start nesting functions. If I’m writing a small code block, I’ll just use the ‘bad’ traditional syntax and make sure to put the declaration of my function before the first time I use it.

Note that I’m not disparaging on style guides. In fact, I encourage every developer to read the style guide of every language they learn once they reach a mature enough level to understand it. Just don’t take the style guide as religion; understand it and synthesize it into your own.

Keep this in mind when you write code. Write code that is fast to read, not code that is fast to write. Unless you’re working with a large team, stick to your own standards. Just don’t be unreasonable about it.