I often put code for personal projects online. In part this is to share what I've done with the world so others can see how cool it is and maybe reuse part of it. It also makes it easier for me to find it in the future if I want to work on it further or see what I've done.
The downside is that sometimes if I'm just hacking something together, the code's a mess, and I worry that perspective employers may see this as representative of my work. If I was going to work on it or support it long term, I'd spend time to make sure the code was neat, but, for example, if I'm trying to get a robot to play instruments in 3 days, code organization has to take a back seat.
I guess the solution is to be clear about the state of the code and the reason for it when describing the project online or in the comments. Good developers should know that code doesn't always start off beautiful and if they value their time they should also know that it's not always worth it making it beautiful. As long as they know that I know it's a mess, I can't imagine they'll hold that against me.
Monday, February 13, 2012
Monday, January 9, 2012
Parasites
My friend Ben Wallick did a parody of Coldplay's Paradise called Parasites. I'm not sure I agree with the premise of the song, but it's funny and very well done.
http://soundcloud.com/ben-wallick/parasites-paradise-parody-ben
http://soundcloud.com/ben-wallick/parasites-paradise-parody-ben
Thursday, November 24, 2011
Thanks
I'm thankful that I get to do what I love every day, and get paid well to do it.
Then I can go buy whatever food I want whenever I want it without having to grow it months in advance with lots of hard work.
Life is good!
Then I can go buy whatever food I want whenever I want it without having to grow it months in advance with lots of hard work.
Life is good!
Tuesday, October 25, 2011
PR2 Poop Scoop
Success! We scooped poop and people talked about it!
I made some notes about problems we had during the hackathon and possible solutions:
Problem 1: Making changes to code requires recompiling and rerunning a node or event shutting down and re-running a lunch file.
Solution A: Load params dynamically (param server, dynamic reconfigure, flat file, etc) so we can change them at run time.
Solution B: Set launch file to respawn nodes if they die.
Solution C: Build a tool which monitors source files and rebuilds node executables as needed. I must also kill old instances of nodes when rebuilding them. I've written a prototype of this.
Problem 2: Had to edit nodes to test pieces of functionality.
Solution: Make sub-behaviors runnable via command line and/or ROS calls.
Problem 3: Battery running low at bad time.
Solution: Feed power cable from above so we can do some testing while it's plugged in.
Problem 4: When something didn't work, it took too much time to track down where the problem was.
Solution: All code should have very rebose ROS_INFO or loginfo calls.
Problem 5: Devs killing each other's nodes.
Solution A: Work in gazebo when possible.
Solution B: Maybe schedule time for each dev to test code on the robot.
I made some notes about problems we had during the hackathon and possible solutions:
Problem 1: Making changes to code requires recompiling and rerunning a node or event shutting down and re-running a lunch file.
Solution A: Load params dynamically (param server, dynamic reconfigure, flat file, etc) so we can change them at run time.
Solution B: Set launch file to respawn nodes if they die.
Solution C: Build a tool which monitors source files and rebuilds node executables as needed. I must also kill old instances of nodes when rebuilding them. I've written a prototype of this.
Problem 2: Had to edit nodes to test pieces of functionality.
Solution: Make sub-behaviors runnable via command line and/or ROS calls.
Problem 3: Battery running low at bad time.
Solution: Feed power cable from above so we can do some testing while it's plugged in.
Problem 4: When something didn't work, it took too much time to track down where the problem was.
Solution: All code should have very rebose ROS_INFO or loginfo calls.
Problem 5: Devs killing each other's nodes.
Solution A: Work in gazebo when possible.
Solution B: Maybe schedule time for each dev to test code on the robot.
Tuesday, September 6, 2011
Jeff Atwood just blogged about how logging in to sites could be done much easier. Three cheers for someone thinking about a solution for this insane situation!
At the end he lists 2 catches, one of which is that you need to trust some server online to be a secure place to store your passwords. I don't see why that should be though. If, as he says, you'd log in to your browser, why can't the browser encrypt the stored passwords and then store them to a not-so-secure place online?
Maybe he's concerned that an attacker could get them, wait a few years for a security problem to be found in the encryption, and then crack them. That scenario is somewhat mitigated by the fact that if a security problem is found, you could walk through the list of accounts and change the passwords for any important ones.
Maybe with the right meta tags or whatever, the change password process could be done automatically by the browser. If that was the case, the browser could change all your passwords periodically without there even being a discovered security weakness in the encryption. That would make all the security people happy who think changing passwords regularly is good. And in fact it would be good since it provides the advantages of changing passwords (limited exposure if a password is stolen) without the disadvantages (user inconvenience of having to learn a new password).
At the end he lists 2 catches, one of which is that you need to trust some server online to be a secure place to store your passwords. I don't see why that should be though. If, as he says, you'd log in to your browser, why can't the browser encrypt the stored passwords and then store them to a not-so-secure place online?
Maybe he's concerned that an attacker could get them, wait a few years for a security problem to be found in the encryption, and then crack them. That scenario is somewhat mitigated by the fact that if a security problem is found, you could walk through the list of accounts and change the passwords for any important ones.
Maybe with the right meta tags or whatever, the change password process could be done automatically by the browser. If that was the case, the browser could change all your passwords periodically without there even being a discovered security weakness in the encryption. That would make all the security people happy who think changing passwords regularly is good. And in fact it would be good since it provides the advantages of changing passwords (limited exposure if a password is stolen) without the disadvantages (user inconvenience of having to learn a new password).
Wednesday, July 13, 2011
Tuesday, July 12, 2011
Subscribe to:
Comments (Atom)