Author Archives: kevin

About kevin

I write the posts

links for 2011-03-02

Posted on
  • ROTTEN TOMATOES: Five Favorite Films with Stephen Merchant
    You know, I actually have to say that I think modern technology is really [stymieing] screenwriters nowadays. I mean, mobile phones, the internet, wifi, all those things, they don't work for a screenwriter. How many times did you ever see an episode of 24 where Jack Bauer has to lose his phone, or break his phone, or there's no signal? Because it's just such a godsend; it's like a teleporter, you know? It's too useful, a mobile phone.
  • Apple
    Check out the menu bar effect when you increase/decrease the text size. Really cool
  • Anatomy of long sales letter
    Long sales letters work - piss off designers who want fewer letters. Key is to write really good copy

Liked what you read? I am available for hire.

links for 2011-03-01

Posted on
  • Hacker News | Linus Torvalds: Pearls before swine
    I've done stuff that normal people would consider ubercool - doing illegal raves, run one of the hottest bars in Ibiza, throwing parties for the jetset. When seen from the outside it looks amazing - you get to talk to models, you get free booze, get in for free at all the clubs and have sex with models. The thing that nobody tells you is that it's hard work. Most of the actors that go to the oscars aren't there to get drunk or laid, for them it's a chance to talk shop with their colleauges. When James Cameron is talking to Natalie Portman he isn't chatting her up, he's trying to get her to star in his new movie. A friend of mine just came back from a tour with a known rock-band. They worked hard from nine in the morning until after midnight six days a week. The last day of the week they just wanted to get home to their families. No screwing around with models, no getting drunk and no clubbing. Just hard work. The rockstar life is mostly something the media makes up.

Liked what you read? I am available for hire.

Upcoming talks

Posted on

I will be on a panel Wednesday night, March 2, about “Breaking into the Silicon Valley Job Market” with 3 other seniors. The panel will be at 7pm in Bauer Founders Room at CMC.

I will also be speaking Thursday night, March 3, at the CMC Athenaeum about “Why Everything You Learned In Finance Class is Bullshit.” The dinner is sold out, but you can attend the talk, which begins at 6:45. I’ll post slides and notes as the date gets closer.

Liked what you read? I am available for hire.

links for 2011-02-27

Posted on

Liked what you read? I am available for hire.

Usability in common objects

Posted on
One thing you pick up when you start having to design things on your own is a keen sense for details - all of the tiny parts of an object that make it pretty, and easy to use. A good test for this is to pick up your iPhone, open it to any screen and try to observe all of the gradients, drop shadows, bevels, fonts, and rounded corners that make up the pixels on the 640 by 480 screen. If you tried to design something with the exact same shapes but without the subtle effects, you would probably wonder why the Apple one looks so much better. And the effects are hard to get right - it's easy to go overboard on effects and end up with something hideous. Take, for instance, a basketball jersey, which is a pretty simple object - it's a shirt, with letters, numbers, and a color. But there are a surprising number of rules about a jersey that make it a more usable object. At a very basic level, everyone on the same team wears the same color jersey, so it's easy to identify which players are on your team. Traditionally, the home team wears white, and the road team wears a dark color. Why? In the old days, the road team might not have a chance to wash their jerseys between games of a road trip, so wearing dark jerseys would help hide the stains. Another feature of jerseys is that a team's dark jersey will usually feature the name of the city or university the team represents, whereas the home, or white, jersey, will feature the team's nickname. This is because the team wears the white jersey inside their own gym (where everyone knows the university or city name), but for the road team, the more relevant piece of information is the city or university name. A third principle revolves around numbering, where each sport has different rules based on how numbers are used. In high school and college basketball, players' numbers can have at most two digits, and each digit has to be between 0 and 5. This is so referees can use their hands to report a player's number when she commits a foul. In soccer, the players on the field traditionally wore numbers 1 through 11, where the number indicated the position of the player on the field, with 1 being the goalkeeper, 2 and 3 for the outside fullbacks, and so on. (Fortunately, rugby still follows this tradition). And of course, the numbers should be as big as possible, so people can read them. So even in a pretty simple object like a jersey, you can see a complex set of rules develop to make things easy for people that use them. If you were asked to design a jersey from scratch, it's unlikely that you would have covered all of these use cases, which is why it's important to prototype, test things on real users, and then iterate.

Liked what you read? I am available for hire.

links for 2011-02-26

Posted on

Liked what you read? I am available for hire.

links for 2011-02-25

Posted on

Liked what you read? I am available for hire.

Everything I know about debugging

Posted on

If you write programs, a large portion of your time is spent testing your code, and finding and removing bugs in your program. Not being able to understand a bug is one of the more frustrating experiences you can have as a programmer. I’ve been on the lookout for ways to reduce the amount of time I spend debugging, but I really haven’t seen any good articles on the theory of debugging. Here’s everything I know about debugging. If you have additions, feel free to leave a comment.

Write better code

The best defense is a good offense – if you write your code in a clear and concise way, and write by making incremental changes which are immediately tested, you are less likely to run into time-sucking bugs later on. Some people recommend test-driven development and code review as ways to cut down on the number of bugs that make their way into programs. Remember, the earlier you can catch bugs, the less expensive they are to fix.

Try simple fixes for 2-3 minutes

Some bugs are simple and can be fixed within minutes. I would recommend spending 2 or 3 minutes trying a few simple fixes before bringing out the big guns. Yes, this is “cargo cult” programming but maybe 50% of the bugs you find have trivial fixes, and it might not be cost-effective to bring out the big guns right at the start.

Set up a reduced test case

Try to set up the simplest possible version of your code that produces the error. In HTML and CSS, this is known as a reduced test case. This often involves deleting large swathes of your code, so I would recommend either copy/pasting to another page, or committing the current version of your code, then making changes, and reverting to the original version once you’ve identified the problem. If you have a unit test suite, this would be a good time to add a new test case to the suite.

Use print statements or a step-through debugger

If setting up a reduced test case is not feasible (multiple dependencies or complex code), use print statements to determine the values of variables before and after all method calls in your program that could be causing the bug. This is tedious, but systematic, and preferred to cargo cult programming, where you make changes at random and hope that they solve your problem. Another approach is to use a step through debugger – stop the program at a point where you know the output is correct, and then step through the program line by line, monitoring the information in the program. In python, the pdb module does this. In Java, the DrJava program is looked down upon for being mostly for students, but I’ve found it extremely useful for viewing the values of variables at points in the program. Most programming languages should have a step-through debugger.

Use assert statements

Alternately, you can use “assert” statements to assert that a variable should have a specific value at a point in your code. This will stop code from executing immediately at the point where a variable has an incorrect value. This has the added benefit of making sure you understand your code.

Concede defeat

If you’re still at a loss, consider ways in which you can “go around” the bug, by rewriting sections of your code in a way you understand, or trying something else entirely to solve your goals. Note: I struggle with this because not knowing the cause of a bug drives me up a wall, but you might have some success with it. Also, stepping away from your computer and thinking about the problem in more abstract terms can help – I’ve had some luck with just taking a shower and thinking through the problem.

Ask the Internet for help

If you’re still at a loss, try copying and pasting your error message into Google, or posting on StackOverflow. Be sure to be explicit about what you expected to see and what actually happened, and post the code of any error messages you might have. You can also try the IRC channel for the programming language, but I’ve had less success with this – there might be someone nice who’s willing to help you out, but more often than not your message will be ignored.

About me
My name is Kevin Burke and I’m a senior at Claremont McKenna College. I started programming in January of 2010. Read more about me, or follow me on Twitter here.

Liked what you read? I am available for hire.