Ammu is studying Newton's laws of motion this year in Physics, but she can never remember what the three laws are (partly because they don't seem to be stated clearly in her textbook).
I learned the three laws from a very old-fashioned British textbook that belonged to my great-grandfather—long before I had internet access—so it was a treat to be able to look up Newton's original formulation in the "Philosophiæ naturalis Principia Mathematica" on Gutenberg. After the preface and a series of definitions followed by explanatory notes, the laws of motion are presented in a section entitiled “Axiomata sive Leges Motus” (“Axioms; or, The Laws of Motion”).
Lex. I.
Corpus omne perseverare in statu suo quiescendi vel movendi uniformiter in directum, nisi quatenus a viribus impressis cogitur statum illum mutare.
In other words, “Every body perseveres in its state of rest or uniform motion in a straight line, unless a force upon it compels it to change that state.”
Lex. II.
Mutationem motus proportionalem esse vi motrici impressæ, & fieri secundum lineam rectam qua vis illa imprimitur.
“The change in motion is proportional to the force impressed and takes place in the direction of the straight line in which that force is impressed.”
Lex. III.
Actioni contrariam semper & æqualem esse reactionem: sive corporum duorum actiones in se mutuo semper esse æquales & in partes contrarias dirigi.
“To every action, there is always an equal and opposite reaction: or the actions of two bodies upon each other are always equal, and directed to opposite parts.”
I don't know enough Latin to follow along comfortably, but I can see what's happening just by looking at the diagrams.
For a more educated translation of the Principia Mathematica, archive.org provides a copy of Andrew Motte's 1846 translation (which includes a biography of Newton).
I learned how to type by trial and error on my mother's green Olivetti typewriter, and after a few years of using computers, my four-fingered technique served me well enough that I didn't think about learning how to touch-type "properly".
Over the past few months, however, I've tried to use more fingers efficiently, so that I don't have to move my hands as much. I adopted the conventional finger positions for a week, found they didn't suit my big hands (reaching non-alphanumeric keys on the keyboard was painful). Now I've found a more comfortable position, and I can type accurately and reasonably fast (though not as fast as before) without hurting my hands.
Unfortunately, the price I paid was in losing the ability to fall back to my earlier technique, and the loss of speed—though not an impediment in practice—has rankled.
Today I discovered the perfect cure: ztype
This is a "Space Invaders"-style game where you have to type falling words to eliminate them before they reach you. It has a few annoying bugs (sometimes the word you're typing is hidden behind others), but it's extremely addictive nevertheless.
A letter arrived by email today addressed to "Dear Advisory Boar" and asking for advice about working a freelance job while learning how to program.
The boar felt oddly pleased, and duly rendered the advice sought.
I've been using vim for more than a decade(!) now, but every so often, I still learn something new that makes my life a bit easier. Here are two things I learned today.
Emacs users have enjoyed the convenience of using M-x shell to run shell programs inside an Emacs buffer for years. I found a Python plugin named conque that does the same for vim. It works well enough to run vim inside vim (not that I plan to do that often), and using it to talk to psql while experimenting with schema changes is very convenient.
A friend pointed out that vim built with X11 support could yank text to and from the X clipboard using "*yy and "*p. Ubuntu's vim-gnome package gave me a console vim built with +X11 and +xterm_clipboard support, and I got the feature working as advertised after I set "clipboard" to just "autoselect" (the default setting of "autoselect,exclude:cons\|linux" caused vim to not connect to the X server at all).
I can now use * and + like any other registers, but one uses the primary X selection, and the other the X clipboard.
After less than a day of using this feature, I'm already hooked. It's so much nicer than pasting text into vim in insert mode, and also makes it easier to exchange text between two vims running in different terminals.
Recently at work, I needed to import a substantial quantity of data from some spreadsheets into an SQL database. Due to multiple maintainers and changing needs, the spreadsheets were a mess of special cases, shorthand notation, and minor errors. I gave up on importing them as-is, and asked for the relevant data to be extracted into a format I defined. Writing a converter for the latter was much easier (although errors kept cropping up even in the new spreadsheet).
Today I read about Google refine, a program dedicated to dealing with messy data. The video demonstrations on the project page show off some useful capabilities, such as grouping together and canonicalising values from a column in a few steps, scaling numeric values, and rearranging the data in various ways.
Google refine is a Java program that you install and interact with using a web browser. I've never used such a program, and I suspect it may be painful to install, but I'm going to try it if any more spreadsheets appear on the horizon.
I can understand wanting to make sure that Sai Baba Mark II was actually dead, and not just setting the stage for a miraculous resurrection, but I think it was in poor taste for Prime Minister Manmohan Singh to do it personally.
I've always had trouble fitting my 190cm+ frame into airline seats. Only on the rare occasions when I've made it to the airport before the hordes of (usually much shorter) people who want the front row or emergency exit row seats, have I had a reasonably comfortable flight.
While checking in on a 0615 flight to Kolkata this morning, the chap in queue ahead of me was told that there were no more aisle or window seats available. I resigned myself to an uncomfortable two hours, but asked for an exit row seat anyway. To my pleasant surprise, I was told that some were available, and I could have one for an extra INR 300.
I lost no time forking over the money (which seemed to surprise them), and was duly assigned seat 13F (emergency exit over the wing). At least four of the exit row seats over the wings were unoccupied during the flight, and there were no takers despite an announcement that premium seats were available for a small fee.
If this means I can get an exit row seat on my return flight too, I'm not complaining.
I've read many arguments about source code comments, from "comments are good, they help you understand code" to "comments are bad, they become obsolete and mislead you" and everything in between. I've seen enough good comments and bad comments to think that trying to draw a line in the sand is a waste of time. I write comments when I think they might be useful, curse them when they aren't, and find something else to occupy my attention the rest of the time.
Today, I happened across a blog post entitled Don't Waste Your Time Commenting Source Code. It's a fairly typical rehash of the usual arguments, written with much conviction and authority, but thankfully without the traditional "// Increment i" example. A couple of sentences caught my eye:
Contra: Automated unit tests explain what the program does just as well, and they never become obsolete.
I appreciate the argument that comments are unaffected by unintended code changes, while (sufficiently detailed) tests break immediately, but I have yet to see a good test suite that explained how a program worked just as well as good documentation. If the tests are a clear and straightforward explanation of how the program should work (which is not their function), they're not good enough at testing edge cases where the program breaks (which is their function); conversely, a thorough test suite has too much low-level detail to serve as a cogent exposition of the code's functioning. Not for a library, and certainly not for an application.
Besides, the "tests will break" argument is too simplistic. Test suites are also ultimately the product of fallible programmers. I've made many changes that were wrong but broke nothing. I've seen tests that blessed the entirely wrong behaviour. I've seen and made many changes that were not accompanied by enough tests, and others that came with lots of tests but were broken anyway. Every non-trivial test suite I've seen has been a complex maze of "historical reasons" and tests for long-forgotten (and always poorly-described) bugs rather than a clear explanation of anything at all.
Frankly, I would rather have developers spend time polishing their design skills than technical writing skills.
The way I see it, good design and good explanations go hand in hand. Neglecting one does no favours to the other.
My old server, fugue.toroid.org, is no more. After five years of sterling service, it has been retired and replaced with one of Hetzner's new entry-level root servers (with sixteen times the RAM and a very much faster CPU). It took me a long time to migrate the services across, but everything works now.
The new server is named raven.toroid.org.
For many months, we have been planning to be away from Delhi during the Commonwealth Games 2010 (October 3–14). Thanks to extra school holidays and invitations from friends, we're spending 25 days in Karnataka. I'm looking forward to this holiday very much.