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!
Thursday, November 24, 2011
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
Saturday, May 21, 2011
Some Ideas I Like About Development
I read http://edweissman.com/53640595 and here are some bits I especially liked.
I work in 2 modes: (A) At the computer and (B) Away from the computer.
When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).
Mode B is generally much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it's time to get back to the computer and return to Mode A.
The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn't matter how correct anything is, just as long as it's progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I'm at, and go for the next micro jump.
How do you stay productive?
1. Do not have access to the internet on your work machine. If you don't have 2 computers, get a netbook for < $300 and connect it to the internet. They should be in 2 different workstations, ideally in 2 different rooms. The thinking is that if you have to get up, you'll only do it if it's really necessary. It works pretty well.
2. You should have 2 modes: coding and not coding. For coding, you should be at your desk coding. For not coding you can be anywhere, but "not at your desk". One of my biggest problems is that I often find myself in one mode when I should be in the other. If you're having trouble writing code, then you probably don't know what to write. Grab source code listings, pen, & paper and "get away from your computer". Don't come back until you know exactly what you're going to be working on. Better yet, until you're "dying" to work on it. On the other hand, if your doing analysis and are stuck, stop. Go back to the computer and code something, anything small, just to get going.
3. End every day in analysis mode. Don't go to sleep until you have tomorrow's plan ready. You should wake up knowing exactly what you're going to be working on and excited to do it.
4. Never text or IM when working. Have the cell phone nearby only for emergencies. For email, go to the other computer once an hour (see #1 above).
5. Try 48 minutes on, 12 minutes off. For long coding sessions, this works pretty well for me:
http://successbeginstoday.org/wordpress/2006/09/the-power-of...
6. Ipod.
Where do you like to sit in your office?
I prefer to sit with my users. As you can imagine, this concept is met with a bit of resistance in corporate America.
I want to dwell with them and be a part of their lives. I want to hear them complain about their apps, their customers and vendors, their bosses, and each other. I want to know what they go through all day every day.
When I sit and suffer with them, the resulting software is "always" better. All the meetings, prototypes, demos, specs, etc., etc., etc. have never been able to deliver the same knowledge needed to develop their apps.
On the other hand, I "don't" want to sit with other programmers, unless we're working on the same thing at the same time. I don't care about your problems, I have my own.
Tuesday, May 17, 2011
Link: How to Quit Your Job, Move to Paradise, and Get Paid to Change the World
People often use Twitter to post links to interesting things, but I'm not a big fan of Twitter so I'm going to use my blog.
http://www.problogger.net/archives/2011/05/18/how-to-quit-your-job-move-to-paradise-and-get-paid-to-change-the-world/
http://www.problogger.net/archives/2011/05/18/how-to-quit-your-job-move-to-paradise-and-get-paid-to-change-the-world/
Saturday, May 14, 2011
A New Try at Blogging
(written on Wed)
Jason on the A Smart Bear blog wrote a post about how people and companies should have blogs so we're visible online. I can't help but agree with points, so I'm reviving my blog where I'll probably post about entrepreneurship, geeky technology, and my startup Exerdare. This may trail off into nothingness again due to my RSI, lack of time, or lack of motivation, but I have little to loose and much to gain by trying.
Speaking of Exerdare, I spent today working on the 3rd generation Exerdare bike prototype. For those who don't know what I'm working on, it's an exercise bike with built in multiplayer gaming to make working out more fun and competitive. The big remaining issue blocking "public" testing is that the data I'm reading from the sound card's line seems garbled. It looks fine when I record it in audacity so I'm probably doing something wrong with pyaudio. I'm writing this on the train on the way to the Columbia Venture Club Demo Night, where I'm presenting Exerdare.
That's it for now. More to come hopefully.
Jason on the A Smart Bear blog wrote a post about how people and companies should have blogs so we're visible online. I can't help but agree with points, so I'm reviving my blog where I'll probably post about entrepreneurship, geeky technology, and my startup Exerdare. This may trail off into nothingness again due to my RSI, lack of time, or lack of motivation, but I have little to loose and much to gain by trying.
Speaking of Exerdare, I spent today working on the 3rd generation Exerdare bike prototype. For those who don't know what I'm working on, it's an exercise bike with built in multiplayer gaming to make working out more fun and competitive. The big remaining issue blocking "public" testing is that the data I'm reading from the sound card's line seems garbled. It looks fine when I record it in audacity so I'm probably doing something wrong with pyaudio. I'm writing this on the train on the way to the Columbia Venture Club Demo Night, where I'm presenting Exerdare.
That's it for now. More to come hopefully.
Subscribe to:
Posts (Atom)