Wednesday, April 30, 2014

As Usual

April 26

April 29

Saturday, April 26, 2014

Apology Etiquette In San Francisco

Friday, April 25, 2014

Build an Anime Robot in WebGL Using Three.js

Tachikomas are robotic spider tanks (which can also double as vehicles) from the anime TV series Ghost In The Shell: Stand Alone Complex. Despite some fairly relentless fan service, it's a great show. It features terrific cyberpunk, where the Tachikomas are not just props or weapons, but also characters.

I built a pair of Tachikomas in the commercial 3D graphics software Cinema 4D:

This software is awesome, but it costs around $3,600. (Fortunately, I'm taking a class on it, and my school set up a free student license for everybody in the class.)

After I built the Tachikomas above in Cinema 4D, I then made a simplified Tachikoma using Three.js, the popular and excellent JavaScript library for WebGL:

While I was building the robot, I used a wireframe view to make it easier to see what I was doing:

Obviously, this is less fully-developed than the version I did in Cinema 4D. And better animators than me have done far more amazing work with WebGL and Three.js.

But this Three.js Tachikoma is 100% JavaScript-created, running in a web browser. And it's easy code (with an important caveat). Using Three.js allows you to bypass a lot of the verbose weirdness of raw WebGL. If you do JavaScript work with Node.js, or you work on a site with a relatively dense and complicated DOM, understanding this code might even be a cakewalk for you.

I didn't use any of the more obscure features of WebGL, like custom GLSL shaders, and I didn't use any expensive or incomprehensible 3D animation software. It's something any JavaScript developer can do. The software to create these images doesn't cost $3,600; it's free and open source, and you interact with it by writing code.

Here I am typing JavaScript commands into the console to move the Tachikoma around during the process of building it:

But here's the caveat: although the code is easy, there's a whole paradigm you need to understand before you can write code like this. If you work with JavaScript, you're probably a web developer, with a lot of domain knowledge about Web browsers. You may even be an expert in which Web browsers mess up which parts of their own implementations (which is thankfully becoming less valuable knowledge than it used to be). But working with 3D graphics requires that you understand a completely different and unrelated set of domain knowledge.

The same basic mental model powers Cinema 4D, Maya, Blender, and Three.js (and very probably the proprietary systems at Dreamworks and Pixar as well). It's a paradigm with quirks that could really baffle you if you've never been exposed to it before. And it's probably obvious that you can't claim to be anywhere near the cutting edge of JavaScript development unless you understand this paradigm. So if you want to create innovative interactive experiences on the Web, or build HTML5 games, you should learn how to do 3D with Three.js.

And I can teach you.

I made a product where I explain the 3D graphics paradigm. I included a bunch of code in a git repo and I made it easy to follow along. I demo building a TIE Fighter, in real time, and I show you the process of building this Tachikoma in Three.js.

This is a product which includes several videos. In one, I give a presentation which explains the 3D paradigm and setting up the Tachikoma code. In the next video, I show the entire process of building the Tachikoma, very quickly. In the next, I take you through the whole thing slowly and clearly, line by line.

Building the Tachikoma took 18 git commits; I recorded separate, individual videos for 14 out of the 18. Then I edited them all together into one seamless video. Not only that, you can match the stages of the video to the git repo, because I put the git hashes onscreen:

This means you can check out specific commits and follow along as I write the code.

I also highlight random useful third-party libraries, tips, and gotchas:

The line-by-line video is about an hour and fifteen minutes long. But, because I know that a lot of programmers like to move quickly through videos, I've also included a "speed painting" version, set to an original drum-and-bass track which I created. The "speed painting" video condenses the entire hour-plus process of building the Tachikoma down to less than six minutes.

The first video, the presentation video, is about 20 minutes long, and there's another 15-minute video at the end. For fun, I finish the product by showing you how to create some simple animations in Three.js, so you can play around with what you've learned. For instance, I show you how to create these animations:

And this one:

(There's also a fourth bonus animation as well.)

And of course I include the code in the repo. It's another 4 commits, grand total 22.

Again, just to be clear, this is all JavaScript. I'm using animated gifs and YouTube to show it to you, but I made it all in JS (and the Chrome browser). And after you learn how, you'll be able to do the same thing.

At least, this is my hope; I can't actually guarantee that. But I can guarantee that if you buy my presentation, you'll be 100% satisfied. If you're not, you can have a full refund.

Since I fully intend to stand by that guarantee, I better be upfront with you about the product's limitations: the audio isn't perfect in the full-length Tachikoma build video, because I had some microphone noise when I was recording it. The file itself is a huge download. The whole product's extremely slanted towards Chrome and OS X users; I didn't test any of this code on other operating systems, and I'm pretty sure some of it only works on Chrome. (I wasn't worried about that because Firefox and Safari will almost certainly catch up, although Internet Explorer never does.)

Lastly, if you don't like bad language, the good news is I tried not to swear anywhere in this product, but the bad news is I failed. The silly bouncing tachikomas animation contains swearing on 8 lines of code. But I only swear once in the actual presentation videos, and it's while reading one of those lines of code, so hey, personal best. Anyway, other than that, I'm pretty happy with this product, and I think you will be too.

So there's a detailed code base, containing a Three.js version of an anime robot, plus four bonus animations (technically the fourth bonus animation is more of an import/export format demo). There's a video which shows you how the bonus animations work. There's a video which shows you how 3D in general works. And there are two videos which show you how to build the Tachikoma -- one fast and one slow. For now, you get all of that for just $41.

By the way, I made a little music video with dancing Tachikomas. I don't show you how to do this in JavaScript, this is 100% Cinema 4D, but you might find it entertaining anyway.

Finally, this is a brand new product, and I haven't shown it to anybody yet, so here's a bunch of praise for my other products:

Go ahead and buy this thing! I'm happy with it, I think you will be too, and if you're not, 100% refund.

Friday, April 11, 2014

Tachikomas Twerking

I made this in Cinema 4D.

The soundtrack's Night Is On My Mind.

Tuesday, April 8, 2014

The Internet Will Never Be Secure, Ever

Because it's written in C.

To quote yaakov34 on Hacker News:

There was a discussion here a few years ago about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this...

My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code...

This vulnerability is the result of yet another missing bound check. It wasn't discovered by Valgrind or some such tool, since it is not normally triggered - it needs to be triggered maliciously or by a testing protocol which is smart enough to look for it (a very difficult thing to do, as I explained on the original thread).

The fact is that no programmer is good enough to write code which is free from such vulnerabilities. Programmers are, after all, trained and skilled in following the logic of their program. But in languages without bounds checks, that logic can fall away as the computer starts reading or executing raw memory, which is no longer connected to specific variables or lines of code in your program. All non-bounds-checked languages expose multiple levels of the computer to the program...

We can't end all bugs in software, but we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.

To clarify, if you're not familiar with C, you might not realize that it basically makes all of its memory available to any code at any time. It's kind of a counter-intuitive design choice.

So the comment is saying the problem with Internet security is that the entire Internet, and the entirety of every Unix-style operating system, is based on the foundation of a programming language which allows you to read arbitrary data out of memory.

This is indeed a very big problem. If you want security, you probably don't want an entire online economy built on C.

The only thing I don't like about the comment is that the last few sentences:

we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.

Can we, really? How? Who the fuck is going to pay for that?

Here's what we would have to do first: rewrite every Unix-style operating system from the ground up in a new language. And that's the easy part. Afterwards, we would have to make this new operating system, or group of operating systems, so easy to use and install that everybody who already has stuff installed and running out there in the big wide Web would find it cost-effective to start over with a new operating system. We would then have to repeat the process for every programming language written in C.

What are the fucking odds? We live in a world where COBOL and Fortran became hot languages in 1999 because of the Y2K bug.

It's theoretically possible that a really, really savvy government could fund such a project, but that's not the world we live in. This is the government we actually have:

Unixes are old, and deep, and complicated. It is much easier to understand Unix (and friends) through the lens of an archaeological dig than it is to build a mental model of it as a coherent, well-designed piece of engineering. It has layers and layers and layers of systems which all interact successfully, without being designed to be aware of each other in any sense at all. The whole reason Unix works is because it has this very simple "everything is a file" paradigm, which enables lots and lots of small, highly specific programs at the system level to interact with much larger and more complex software at the application level, using very simple and manageable interfaces.

When it comes to security, though, because everything's built on C, it's less like "everything is a file" and more like "everything is a fail." It is utterly inevitable that more problems like Heartbleed will occur. Our entire online economy is built on an inherently unsafe foundation.

Long story short, the only way to get a secure Internet is to completely rebuild every part of it from scratch. That's just not how technological advances occur. People build on the stuff that is already there. The team behind Go probably want to do this kind of total Internet rebuild, and replace HTTP with SPDY while they're at it, but not even Google has enough Imperial stormtroopers to pull off that kind of coup.