Posted by Jacob Cohen on 04 November 2009 at 12:02 PM | Permalink | Comments (0) | TrackBack (0)
|
A Spoonerism, named after Rev. Spooner, is a phrase in which syllables of certain words have been swapped, often so that they form new words. A popularly used example is "Mardon me, padam, but this pie is occupewed, may I sew you to another sheet?"
Here are some new ones I've come up with I thought of*:
Posted by Jacob Cohen on 22 September 2009 at 09:37 PM | Permalink | Comments (2) | TrackBack (0)
|
Ever wonder how characters from video games and other 3d animations are made to move around, and how their movements are getting more and more realistic with each new generation of movies and games?
One of the key components to making this happen is something called rigging, also known as skeletal animation. This is where a technical artist sets up a 3d model of a character or other object so that it can move and be moved. The animator makes the model jump and dance and swordfight and run, but this is possible because of the setup done by the technical artist.
Here is a demo reel made by my brother Dave, a technical artist and character rigger. The beginning clips show some examples of the various types of work he has done, while the second portion of the reel goes through some characters he has created for a new game as he explains the rigging available on each 3d model. See the explanation below for what some of the terms he is using mean.
Source: Dave Cohen's Rigging Showreel
And now a brief explanation of what some of these terms mean. And how this is done.
Suppose you want to animate a human character for a game. This character needs to be able to walk along, to jump, and to have facial expressions.
Some of the movements provided for the animator are set up to support something known as Forward Kinematics, or FK for short. This describes the computations necessary to make sure that, for example, when you move the upper leg of the 3d model forward, the knee, lower leg, and foot move along with it. The position of a particular piece of the model is calculated based on the angles of the joints and the length of the "bones" that connect it to the rest of the model.
FK is also typically used to tilt and turn the head, open and close the jaw, open and close eyelids, etc. With FK, you manipulate joints and the system figures out how the model moves accordingly.
Another technique used for rigging is called Inverse Kinematics, or IK for short. This describes the computations necessary to set a portion of the model to a particular position and figure out the angles and positions of the joints accordingly. For example, if you want to make your 3d person walk, you can just move the foot forward to take a step, and IK figures out how the leg joints need to move to make that happen. Additionally, the foot can then remain on the ground while the body moves above it, and IK will figure out how the joints move to make this happen.
Prior to Inverse Kinematics, the animator had to manipulate each joint to put the foot in the proper place using Forward Kinematics to make the 3d person take a step. Worse, they then had to counteranimate the foot to get it to stay on the ground while the rest of the body moved forward. This sometimes resulted in walking characters looking like they were sliding, or made the walking look jittery and unrealistic.
For facial animations, the rigger sets up scripts that do math that calculates how the various components of the face should move or deform to make the mouth move for speech, raise the eyebrows, scrunch the forehead, puff out the cheeks, and whatever other tools the animator will need to make the character speak, show surprise, fear, anger, and other emotions, and do other things like smile and frown.
Posted by Jacob Cohen on 08 September 2009 at 09:00 PM | Permalink | Comments (2) | TrackBack (0)
|
Ever wanted to get better at speaking and writing in another language? You're not alone.
A former coworker of mine, Natalie Gordon, left Amazon to go travel, and in the course of her travels in Spanish-speaking Latin America and South America, recognized the potential to create an online tool for people who speak English and want to learn Spanish, and people who speak Spanish and want to learn English.
She created a web site called Lenguajero (www.lenguajero.com), and it connects Spanish and English speaking visitors with each other so they can improve their language skills. It provides themes for discussion, such as favorite food, current events, the movies, and even learning to swear.
Their most recent addition is a feature called "Write in Spanish - Escribir en Inglés". This provides a topic for discussion and encourages visitors to leave a comment in the language they are learning, or to leave feedback on another visitor's comment if you are a native speaker. Today's topic is Favorite Food, and some members are already describing ecuadorian food, pizza, sushi, and cebiche.
If you've ever wanted to improve your Spanish skills by interacting with native speakers directly, or if you speak Spanish natively and want to improve your English, this is an incredible tool that can connect you with other people who are also trying to learn. Try it out! I just wrote about sushi.
Posted by Jacob Cohen on 05 September 2009 at 10:39 PM | Permalink | Comments (0) | TrackBack (0)
|
Some time ago, XKCD compiled a list of phrases that yielded no search results in Google.
Shortly thereafter, all of those phrases could be found in Google search, and almost all of them were talking about the list from XKCD.
This seemed an interesting concept. I'd like to contribute my own to the mix. Here are some phrases that seem like they could plausibly have Google search results, but don't:
And here are some phrases that seem like they should have no search results, but do:
Posted by Jacob Cohen on 19 August 2009 at 07:48 PM | Permalink | Comments (6) | TrackBack (0)
|
I have moved the rafb.net/paste source code from its old location (which, alas, broke when I moved my blog to Typepad's servers) to a new open source project at Google Code.
Behold: rafb-nopaste project at Google Code.
I have also managed to use Typepad's file manager to fix the existing rafb.net/paste and rafb.net/paste/source URLs that have been picked up by search engines and Wikipedia, etc.
Posted by Jacob Cohen on 12 August 2009 at 10:22 PM | Permalink | Comments (1) | TrackBack (0)
|
Oops. I've recently switched blog software, from a self-hosted Wordpress-based blog, to Typepad, which runs on Typepad's servers.
As part of this switch, I moved the rafb.net domain to point to Typepad's servers to be able to continue to use rafb.net as my blog address.
However, I didn't account for the fact that this would, of course, make people unable to get to rafb.net/paste to see the message that I've discontinued it, or where to get the source code.
I'm going to work on getting that restored as soon as I can. I am thinking it would make the most sense to just create a Google Code project and upload the source there.
Posted by Jacob Cohen on 12 August 2009 at 11:37 AM | Permalink | Comments (1) | TrackBack (0)
|
As I was on my way to lunch today, it occurred to me that most escalators I see are lit from underneath. I began to wonder why they would do this, and the only reason that leapt to mind was that it helps show the gaps between the treads at the top and bottom of the escalator.
This seems like a waste of energy. Why don't they just paint a line on the gap between treads? This would serve the same purpose without using any energy. This got me thinking of other ways we could save energy on escalators.
Posted by Jacob Cohen on 11 August 2009 at 12:54 PM | Permalink | Comments (0) | TrackBack (0)
|
Previous: see part 2 here
In my first post on this topic, I gave some general pieces of advice that should not have come as a surprise to anyone. Know how to do the stuff you are being interviewed for.
In this post, I will cover a particular aspect of interviewing that you may find in the technical interviews of many software companies: coding on a whiteboard.
I will not go into the specifics of why companies ask candidates to do this, or provide a comprehensive list of the companies that do this, but the fact remains that you may be asked to do this, and should therefore be prepared.
My advice for coding on a whiteboard can be broken down into the following topics:
This means you have several disadvantages compared to when you are writing code at a computer. You need to keep a few things in mind in order to be able to put your thoughts onto the whiteboard efficiently.
Plan ahead - a whiteboard is a finite amount of space. Every time you have to go back and add variable declarations, or add another line of code to the end of a for loop you've already finished, is going to cause mess and delay if you have to erase and rewrite the nearby code or scrunch your writing to fit it in. If you put the closing curly brace at the end of the method before you've added its body, you should have a really good idea of how much space you need to write that method.
Know your language - you are going to be writing code without the aid of auto-completion, inline type checking, and other tools that an IDE provides. Nonetheless, you should know how to write syntactically correct code in at least one major programming language without relying on an IDE to fix mistakes as you go. You should know that Java's int primitive type does not have methods, or that C++'s pointer syntax uses a ->, not a .
This may be your only code sample
This may be the only code the interviewers are going to use to judge whether or not you meet their technical bar. As such, you should pay attention to what you are doing and how this will be viewed as a reflection of your coding ability.
Use reasonable coding style - I am not talking about whether you place your curly braces on the same line as an if-statement, or on the next line. I am talking about choosing variable names and using them consistently. Use abstraction where appropriate. Create methods. Use comments. Your code should be as easy to read from a whiteboard as it would be from a computer screen.
Check your work - As you write the code, be on the lookout for ways your code might break. When you are finished, take a look through it to make sure you don't have any glaring errors. Did you remember to return a value from functions that are supposed to return a value? Did you pass parameters where they needed to be passed? Running some sample input through your function might reveal any weaknesses you missed when writing it.
Practice - If you are preparing for technical interviews, practice writing code. It doesn't have to be on a whiteboard, a sheet of paper is fine. The point is to shore up any places where you would ordinarily rely on your programming environment (IDE, etc) to solve basic programming problems.
Posted by Jacob Cohen on 09 August 2009 at 12:43 AM | Permalink | Comments (1) | TrackBack (0)
|
So far, Typepad is working out pretty well. I was pleased with how easy it was to migrate my blog content over from Wordpress.
That's not to say I haven't encountered my fair share of annoyances so far. These have been as minor as losing some of the images I had uploaded by hand to my old server (and thus were not part of the Wordpress export), to major issues such as a change in the format of my permalinks.
However, for almost all the hiccups I have encountered, a solution was only a Google search away. Overall, the software is just as full-featured as Wordpress was, and now I do not have to keep updating every time a new security patch comes out.
Posted by Jacob Cohen on 08 August 2009 at 07:25 PM | Permalink | Comments (0) | TrackBack (0)
|