[understanding networks week 2] Traceroute Commute

screenshot-2016-09-18-23-20-17

(See the project here.)

For me, the most fascinating part of learning the traceroute command this week was the idea that each IP address the packets move through is tied to a physical place in the world. It was interesting to see the common network providers in the sites I regularly visit, but I became mostly curious about the locations they were associated with.

I decided to trace three websites of places that I have regularly commuted to in real life, including ITP (Greenwich Village), and my two most recent jobs at The New York Times (Times Square) and Kickstarter (Greenpoint). All three of these places are located in New York City, but running a traceroute shows that the packets bounced around to more far-reaching places in order to get to their respective websites.

I started by running the traceroute command in my command line:

screenshot-2016-09-18-23-24-11

I then used Maxmind to find the associated coordinates and other info based on IP addresses:

screenshot-2016-09-18-23-34-56

I then put all that data in a CSV file, which I changed into JSONs to make the data easy to work with.

From there, I used the Google Maps API to build a little page that would find a streetview location for every IP address passed through during the traceroute for itp.nyu.edu, kickstarter.com and nytimes.com.

The result is a sort of internet “commute” for the places that I have physically commuted to.

screenshot-2016-09-18-23-46-57

Of course these places aren’t exactly “accurate,” but it’s interesting, for example, that the last stops for both nytimes.com and kickstarter.com are in Seattle, probably because Amazon is there.

One note: I think it’s kind of funny how much more time my real world commute takes than this cyber commute, in spite of ostensibly shorter distances.

Anyway, this was a fun exercise in making the internet feel a little more physical.

The project is here, and the code is below.

https://gist.github.com/nicolehe/7e4fad768525690f1bf641d39d428424.js

[rwet week 2] a munged poem about voldemort

Screenshot 2016-02-12 11.47.16

My first attempt at making digital poetry was interesting and felt quite different from the other types of programming work that I’ve done so far. For one thing, my Python code was very simple. I wonder if it was too simple?

I guess it’s because I tried a lot of different things that I ended up deleting in my code. This feels more like traditional writing and editing rather than programming, in which we often show our work by the volume of code that we produce.

The text I used was Sarah Palin’s recent speech endorsing Donald Trump. The source was written in paragraphs, and I tried to figure out how to computationally organize it so that it would be one sentence per line. But I didn’t figure it out so I ended up doing it manually, which I know defeats the purpose of making computers do mundane tasks for you, but hopefully it’s something I’ll learn for the future.

I wasn’t sure exactly what I wanted the result to be, except that it would take this rather long text and make it into something more like a short poem.

My Python code (below) basically replaces “America” and other forms of it to “Hogwarts,” and “Trump” to “Voldemort.” (Silly, I know.) It then finds all the “Voldemorts” in the text, as well as all the first commas in each line, and then slices from after the first comma to the “Voldemort” in the line. The substring slice looked like this:

substring = line[commas+1:voldemorts+10]

This cut it from immediately after the comma to the Voldemort, plus the “Voldemort” itself and whatever punctuation might be following it.

I realized that I could have done commas+2 in order to get rid of the space at the beginning of each line, but I think I prefer the way it looks with the space so I made it commas+1.

The result, run simply through the command line looks like this:

Screenshot 2016-02-12 11.55.13

I decided to try using UNIX’s sort command, so I did this:

python munge.py<palin.txt | sort

This game me the final result, shown at the top of this post.

https://gist.github.com/nicolehe/0147a4dea9dfe9a10264.js

[arcade week 2] Two Buds

Screenshot 2016-02-11 12.45.15

Click here to try Two Buds (only works in Safari or Firefox).

This week I started learning about Unity in 2D, as well as using scripting. I made a game called Two Buds, where you have to control two characters at the same time. The penguin catches the fish and the monkey catches the bananas, and if any object hits the floor, the game ends. The scoring is just by how long you last in the game.

I had problems upon exporting, mostly with the way I had set up the text because the resolution size changed the positioning once it was exported. Also, it seems to kind of slow down and freeze when I play it? Not sure if that’s just me…

Anyway, glad I made a working game – looking forward to making my own sprites soon.

[live web week 2] chatroom to dispel loneliness

Screenshot 2016-02-09 22.17.38

Well this might be the homework assignment that resulted in the strangest experience for me. I did the assignment to spruce up the chat page and run it on a server in the cloud, and tested it with myself in different browsers when I was done (screenshot above).

Then I did something that was probably not advisable, which was tweeting the URL out to the public.

Suddenly, it got interesting:

Screenshot 2016-02-09 22.49.36

I hadn’t even considered what would happen if there were multiple people on the page chatting at once, but as some indeterminate number of people joined, it became this sort of intimate anonymous chat room.

Then, people started doing things that I didn’t even know was possible:

Screenshot 2016-02-09 23.11.07

(It turns out not disabling HTML/Javascript in the input box allows people do to….a lot of things.)

I’m not sure how many people were on the page or even who they were, but it was fascinating and felt really poignant to me. I didn’t expect to have created this strange little portal on this Tuesday evening.

I decided to shut it down before someone did something to ruin the nice experience:

Screenshot 2016-02-09 23.23.46

URL: http://162.243.91.198:8080/

https://gist.github.com/nicolehe/2f3b63da25b250ad850b.js

[live web week 2] Testing out Periscope

Screenshot 2016-02-09 14.07.27

So this week we were supposed to try out some kind of live media product and write our thoughts about it. I decided to use Periscope, something I’ve never done before, and it was a pretty interesting experience.

The way the app works is that it’s connected to your Twitter account, and you broadcast live from your phone. Viewers can watch, comment, and “heart,” and it’s all saved and archived so anyone can watch it after.

I didn’t really know what to expect going in. I was just sitting in my living room and started broadcasting, and people started watching.

2016-02-09 22.22.18

Immediately people started watching, and I felt a kind of pressure to perform, though clearly I had nothing prepared. I just ended up kind of talking about random things: my homework assignments, my cat, the project I did at a hackathon over the weekend. There were 3 people in the chat that I knew, and a bunch more that I didn’t. They asked me to show them what was in my fridge, so I did.

What felt strange was the way we were communicating – it wasn’t exactly one to all or one to one, but something in between. I spoke and people listened, and then they responded via chat. Then I responded to the things I read by speaking out loud. I’m sure my roommate in the other room thought I was talking to myself.

I asked people what they usually liked to see on Periscope and got a few interesting responses:

2016-02-09 13.52.01

I did not have the wherewithal to take many more screenshots in the moment, which is related to another part of the whole experience: trying to learn a new technology while being watched by a bunch of people at the same time is somewhat difficult.

Overall I enjoyed it, and can see the appeal. There were a surprising number of people who watched my stream given that nothing was happening – something like 133 total. Anyway, if you want to watch the awkward and boring archive, you can do so here.

[nothing week 2] Seeing Is Forgetting the Name of the Thing One Sees

03_IRWIN_SECESSION_8928-35-800x424

I was not familiar with Robert Irwin’s work before reading these excerpts of Seeing Is Forgetting the Name of the Thing One Sees (which is a great title, by the way), but I felt very much that I want to after doing so. It’s always challenging to properly translate something in a visual medium to text and properly convey what the piece is actually like, and photographs (especially photocopies of photographs) do an even worse job.

But I think the reason why Irwin’s work came across as so compelling in the description is due to the mysterious nature of what he’s trying to create, which is more than just beautiful objects to look at. I was really intrigued by the “energy” he describes in the experience of his work. The way the pinprick sized dots of opposite colors he applied in “The Dots” would cancel each other out visually and create a strange feeling in the viewer is really fascinating.

The way we often think about the purpose of art is that it makes us feel something, but it’s usually in terms of a specific emotion. In painting, the normal interaction is that we look at the paint on the canvas, which move us to think about something and then possibly have an emotional reaction. What is interesting about Irwin’s work is that he uses different techniques to make us feel. Instead of allowing our minds respond to the work, he seems to approach it almost body-first. Due to the optical and sensory illusions he creates, our bodies have involuntary responses that lead to an emotional response.

I also enjoyed reading about the way his work transitioned over time, and how it wasn’t about trying to explore some specific theme, but just about taking things one step at a time until what he had already made didn’t serve him anymore.

I hope I’ll be able to catch a show sometime soon.

[animation week 2] The Spin (stop motion)

Oh man, this took a looooong time – almost 3 full days of work, but Jamie and I are happy with our stop motion animation.

We spent the first day building the set, the second day shooting, and the third day editing.

It varied a bit from the storyboard, namely in the casting of the main character because we realized there was no easy way to make a banana stand up. We also simplified many of the camera angles we had ambitiously envisioned to begin with.

The hardest part of the process was just how tedious it was. But the nice thing about stop motion is that the result is pretty magical, so it seems worth the effort in retrospect!

Here are some pictures from filming:

IMG_0967 IMG_0970 IMG_0972

[pcomp week 2] Electronics labs, switches, and CHOP TO THE TOP!!!

IMG_0067

This week in pcomp we got our hands dirty with circuits and components.

IMG_0020 IMG_0022

I spent a good amount of time getting to know the multimeter, learning how to measure resistance, voltage and current. One of the hardest parts about it was holding the tiny components, measuring them with the multimeter and trying to take pictures at the same time!

I also started building basic circuits with switches and LEDs.

To do the exercise with the potentiometer, I realized I had to solder wires on to the sensor, so I also learned to solder for the first time. It definitely wasn’t the prettiest solder-job in the world, but it worked.

Applying what we learned in the labs, our assignment was to make a switch. We were encouraged to be creative — “A switch is nothing more than a mechanism to bring two pieces of conductive material together and separate them.”

I decided to make a game.

I wanted to do something that tested people’s ability to use chopsticks. I decided to make something that would have two conductive parts with a wide space in between them. The pieces would be connected when people moved other conductive things together in between them so that the circuit could be completed, at which point a light would turn on.

In order to encourage people to use chopsticks to pick things up rather than push things around, I had to make the space between the two conductive points vertical rather than horizontal on the table. Aluminum foil—cheap and abundant—was my material of choice for conducting electricity. So I made a bunch of balls of aluminum foil of different sizes as the things people had to pick up.

The tubes I used were originally pen holders that I had cut the bottoms out of,  glueing foil at the bottom and the top. I had to test if a bunch of foil balls stacked on top of each other would be conductive enough to connect the bottom to the top, so I first used the multimeter, and then wired up a circuit that made an LED light up.

IMG_0044IMG_0045

In order to make this game a race between two teams, I had two tubes and wired up two switches and LEDs of different colors in parallel on my breadboard. So now there’s a green team and a yellow team.

IMG_0070 IMG_0072

I’m not 100% sure the schematic I drew is accurate, mostly because I’m not sure if the line in the middle is correct. But I think it is?

It started to come together, and I wrote the rules:

Light your color first to win. Turn on your light by filling your tube to the top with the balls. You may only touch the balls with chopsticks.

(2 players: each player holds a pair of chopsticks)

(4 players: divide in 2 teams, each player holds 1 chopstick)

A silly game deserves a silly name, and thus I call it CHOP TO THE TOP!!!

IMG_0054

IMG_0055

And voila. I had Aaron (yellow) and Sam (green) play the game to demo. The LEDs are tiny so they’re a little hard to see, but it works!

 

[icm week 2] The beach

(TL;DR: The final sketch is here!)

Create a sketch that includes (all of these):

  • One element controlled by the mouse.
  • One element that changes over time, independently of the mouse.
  • One element that is different every time you run the sketch.

This week’s exercise builds off of what we learned last week and added more dynamic, interactive and/or moving pieces.

I had an idea to do a sunset scene, where the mouse would control the sun and the rest of the elements would change when the sun went down or up. One of the first things I did (pictured above) was divide the height in two to make horizon. Then I made the ocean by making a large blue arc expand slowly, creating the effect of the tide coming in.

But I wanted the tide to also recede,  so I looked up how to use an “if…or” statement:

[javascript]if (oceanWidth = 800 || oceanWidth = 699) {
tideO = tideO * – 1;
}
oceanWidth = oceanWidth + tideO;[/javascript]

This basically made it so that when the ocean arc reached a certain size, it would get smaller until it reached its minimum size, at which point it’d get bigger again.

I discovered the helpful lerpColor() function, which allowed me to easily make a gradient of colors for the sunset.

Screenshot 2015-09-12 14.33.12

But I also wanted to make the colors change as the mouse (aka sun position) changed. I figured that if I could make alpha—or opacity—a variable, I could make it change according to the y position of the mouse. I ended up making two variables that controlled opacity, one for more intense color changes and one for less.

[javascript] a = mouseY;
b = mouseY/6; [/javascript]

I used these for opacity in my lerpColor() function.

[javascript]from = color(225, 22, 84, a);
to = color(243 – b/2, 255 – b/2, 189 – b/2, a);[/javascript]

I also ended up using these variables in a slightly different way as well — by adding or subtracting values to the rgb codes, I could also make the colors brighter or darker as the mouse moved. So my color variables ended up looking like this:

[javascript]cloudColor = color(218 – b, 240 – b/2, 247 – b/2);
oceanColor = color(36 – b, 123 – b/3, 160 – b/3);
whiteWashColor = color(139 – b, 240 – b/3, 238 – b/3);
sandColor = color(194 – b/2, 178 – b/2, 128 – b/2);
sunColor = color(247 + a, 94 + a, 3 + a);[/javascript]

Screenshot 2015-09-13 20.23.46Screenshot 2015-09-13 20.23.55

The screenshots above show you what it looks like when the sun is up vs when it’s down. I’m happy I was able to make the sky change dramatically, while allowing the trees, sand and ocean change more subtly.

For the element that changes each time you run the sketch, I have two birds moving semi-randomly across the sky. And for fun I added a little crab that comes out only when the sun goes down. I haven’t figured out how to make these random movements less jarring and terrifying, which would probably help make the entire scene a bit more relaxed and chill as a beach should be. Oh well! Maybe it can just be the eternal dusk beach of your nightmares.

Screenshot 2015-09-13 20.39.11

As with last week, I had a ton of fun making this sketch. The screenshot above is just a still, so check out the full thing here.

The code is below.  Continue reading “[icm week 2] The beach”

[pcomp week 2] The design of everyday objects & physical computing’s greatest hits

9793515_orig

This week we read two works by Donald A. Norman: the first chapter of his book, Design of Everyday Things, and  his essay, Emotional Design: Attractive Things Work Better. The first rails against everyday objects that are poorly designed, by which he mostly means difficult to understand and confusing to use. He cites numerous examples, like doors that don’t make it clear whether you should pull or push, the thermostat in his refrigerator, and now-almost-obsolete landline telephones.

Scissors, Norman says, are an example of a well-designed everyday object because their affordances, constraints and mappings allow you to easily form a conceptual model in your mind of how they should be used, even if you’ve never done so before.

His essay is a response to some criticism in his book that makes it seem as though he values usability over all else in design—beauty, in particular. His response clarifies that it’s not what he was trying to say, and that designing with people’s emotions in mind is equally important.

These readings make me wonder about the cultural influences in what makes something considered easy to use, or beautiful. I was recently in Japan, a land well-known for its design and usability of everyday objects. As a non-Japanese speaker, some things were easy for me to understand: a basket under your restaurant chair for putting your purse, for example.

Others were not. Many ramen restaurants have you order via machine rather than telling it to the waitstaff (pictured above). The idea is great, but I unfortunately lacked the cultural knowledge or reading ability to figure parts of it out—like how you have to put your money in first before pushing the buttons for your order, and that you have to hit the change button to get change at all at the end.

You only have to give any modern 3 year-old an iPad to see how much culture determines whether or not something is easy to use, so I wonder what kind of cultural assumptions are in the background for a person to understand how to use something as seemingly straightforward as Norman’s scissors.

The final reading this week was Tom’s blog post, Physical Computing’s Greatest Hits (and misses). It’s intimidating and inspiring at the same time to see all the types of projects that can be made with physical computing. What I like in particular is a sense of playfulness about most of them. We don’t necessarily have to create world peace with our designs—making someone smile can be a good enough reason to make something.