For a while now, I’ve been backing up the few WordPress blogs that I run for various people with a very simple script that followed this algorithm:
Copy files to a temporary directory. Dump the MySQL data into a file in that directory. Tarball it up. Scp that file to another server that I run. At the time, I did this because it was the simplest thing that could possibly work.
Being the data and visualization nerd that I am, I’ve been delving into R on occasion. For this purpose, I am using R.app on my Mac. To start it up for a certain working directory (to keep different projects separate), I run “open -a R <working dir>". This worked great until I noticed that my history wasn’t getting saved to the .Rhistory file in each directory. When I use the command line R executable it does, but not in the R.
I’m always looking for ways to improve myself as a programmer. It usually involves something fun, but after reading this post, I think my new area of improvement is to stop increasing my technical debt.
From a related post from Steve McConnell:
Other debt accumulates from taking hundreds or thousands of small shortcuts–generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on.
Well, I didn’t get much of a chance to blog about the NDWall milestone 2 before it flew past this last Saturday. Dave and I agreed a few weeks ago that milestone 2 would include the following features:
Add a configuration/settings area for the application. The keys are: Display Name, Username, Password, URL Move the downloading of new messages into a thread so that it happens in thebackground. We set the deadline for this milestone to be last Saturday, the 17th of January.
Just after 1:30PM today, I finished up my implementation of the first milestone of the NDWall project. The best part was trying to figure out to construct the request to post new messages. Here are a few screen shots of the app:
It really doesn’t do much other than the two required features. I haven’t profiled it to make sure there are no memory leaks, but I’ll do that soon.
The best way to learn a new programming language/environment is to make something practical with it.
To that end, Dave and I started a little side project called (at this point) NDWall. It’s an implementation of a “wall” where new messages can be posted and the 10 most recent can be viewed. The server-side api is very simple. Just two methods (GET and POST) on the api resource. The data transport is JSON, the lingua franca of web APIs.
One of the things that’s been on my mind recently has been optimizing my work life so that I can either spend less time doing the same stuff or accomplish more in the same amount of time.
In the back of my head has always been Joel’s test, and in my feed reader the other day, I found a similar list; the humorously titled “Your Doing it Wrong if…” I had to laugh hard at the fourth entry on that list, as I have written my own database abstraction layer (hereafter DAL).
What Ruby on Rails is to web programming,
and Capistrano is to deployment,
now Castanaut is to screencasts:
#!/usr/bin/env castanaut plugin "safari" plugin "mousepose" plugin "ishowu" launch "Mousepose" launch "Safari", at(20, 40, 1024, 768) url "http://gadgets.inventivelabs.com.au" ishowu_set_region at(4, 24, 1056, 800) ishowu_start_recording while_saying " Tabulate is a bookmarklet developed by Inventive Labs. You use it to open links on a web page. It's meant for iPhones, but we'll demonstrate it in Safari 3.
I was handling a customer support request today and it read something like this:
I changed a setting and now I get an error. What’s wrong? My knee-jerk reaction was to think, “Well, then what was the error?!?” You see, I’m a problem solver. I love to dismantle things and figure out why something isn’t working properly. To me, the first step toward the solution is to figure out what the problem is.
With insight into why people don’t read manuals and why features sell products:
From the Norman essay:
Logic and reason, I have to keep explaining, are wonderful virtues, but they are irrelevant in describing human behavior. Trying to prove a point through intelligent, reasonable argumentation is what I call the “engineer’s fallacy.” (Also, the “economist’s fallacy.") We have to design for the way people really behave, not as engineers or economists would prefer them to behave.