Moving Data
A couple months ago someone hacked into a perfectly innocent server some friends and I use for things like storing backups of our dissertations and running Perl scripts. I was in Seattle when this happened so couldn't be much help in the recovery process. The helpful people at SI Computing recovered all the data from the server and put in on another server ("SIC") for me to access. My job was to move all the data from SIC to a third place so that SI Computing could have their Projects space back. I haven't ever had to remotely administer such a data transfer task. So, I had to learn a few new UNIX commands. Here's how I was able to move 57GB of data from the "SIC" server to the "Hosted" server. I used "screen" and "scp" commands to securely copy my data without requiring a Terminal window to stay open for the 36 hours it took the data transfer to complete. The most helpful websites I could find for those are
screen: http://jmcpherson.org/screen.html
scp: http://kb.iu.edu/data/agye.html
1. ssh libbyh@sic.edu
2. screen
3. scp MyData libbyh@hosted.com:MyData
4. Ctrl+A, d
5. exit
That should do it. You can check in on the data transfer by typing this at the prompt:
screen -r
Hopefully your next big data migration will go as smoothly as mine did.
Special, so special
Earlier today, I was plowing through some old emails, and I came upon a link Cory sent me a couple months ago. He knew I was off to Microsoft to study new software engineers and thought I might be interested in a post from Paul Johnson's blog about how there is no process for programming. I commented on some of the details of his post, namely that I thought professionals deserve a little more respect than I thought he gave them by saying, "Think about other important areas of human endeavor: driving a car, flying a plane, running a company, designing a house, teaching a child, curing a disease, selling insurance, fighting a lawsuit. In every case the core of the activity is well understood: it is written down, taught and learned." What a load of crap. (On my own blog, I can say that. On his, I thought I was polite.)
I was excited to get an email response from Paul about my comment; he addressed specific points within my comment and clearly took some time to consider his responses. The gist ended up being, "If you tried programming, you'd know I'm right, and then I would respect you." Another load of crap. Clearly he thinks programming is different in kind from other professions. While I agree that it is, I don't think programming is different because it doesn't follow a process or isn't easily described as a process. Instead, I think it's different because it requires an approach to thinking about problems (Paul made a nice comparison to mathematics) that seems procedural to an untrained, inexperienced eye. I think what Paul's missing is that the same is true about professions like management and medicine. What looks to outsiders like process is often not at all. Software engineering is not alone. Many professions include something akin to "write the code" where the magic happens, and we should respect that.
I could've titled this post, "Why I Should Never Comment on Blogs." I appreciated that Paul took the time to reply to me, but I did not appreciate the slapping he gave me. Perhaps I'm being overly sensitive, but the stress I've felt since reading his email and then responding and now blogging is disproportionate to the importance of our conversation. I love studying people, especially at work, because I get to learn how different they and their jobs are. And today I stood up for similarity. Now, I'm schizophrenic. Sigh.