May 8, 2008

Something of a test...

Just testing whether scheduled posts are working now...

September 28, 2006

The Google Way

Steve Yegge has writen a lengthy post about how development at Google works. I wish there was some way to apply some of what he talks about here. Or for me to work at Google. Either/or.

August 1, 2006

Organization

I know, I'm posting, it's a miracle.

The reason I've been so lax lately is that I've had the busiest summer of my life... we're finally buying a house! But I learned something during this experience that I thought I should share, as it has totally saved my hide dozens of times over the course of this totally harrowing and exhilarating experience:

The Internet is Your Friend.

Shocking, I know. But maybe I should elaborate.

Buying a house and, indeed moving, like most of life (and work's) projects, requires attending to dozens if not hundreds of little details, and it can be nearly impossible to keep them all straight. It just so happens that the internet, or at least Google, which, at last count was half of the useful stuff on the intenet, has provided for this problem. Google Spreadsheets has been a godsend. My wife and I have shared about a dozen spreadsheets, covering everything from a new homeowner's budget to how many lightbulbs we need to buy for the new house, to the room's dimensions, to the people we need to contact with our new address.

To repeat: collaborative tools, such as Google Spreadsheets and Writely let you keep in sync when working on big projects. Try it out!

June 13, 2006

As Bad As Ever

Two posts in two days! A record!

Over at Wired's Web Monkey, there's an article about Eight Web UI Problems -- a very interesting read that goes into detail about the differences between how novice users and experts treat web information. I have to admit to having had a few of these bad design urges in the past myself. *shame*

June 12, 2006

Learning a New Language

A fellow named Prashant N Mhatre wrote an article called " 15 Exercises for Learning a new Programming Language", which he posted to his blog. It got dugg, and I had a devil of a time getting to it. Now that I have, and I've found it good, I'm republishing it here. I don't have his permission. I don't see any copyright notices on his page. I'm being (very slightly) naughty. Prashant, if you want me to take this down, just let me know. I've made a few (minor) edits.

On to the list:


First of all, get familiar with the compiler, compiler options, editor shortcuts or integrated
development environment (IDE). Start with a simple 'Hello World' program. Compile it. Use basic functionalities of debugger like setting break points, printing variable values, moving to the next or specific position, stopping debugger etc.

To grasp basics of a new language quickly, here are the exercises I use. Remember some programs may not good for beginners.

(1) Display series of numbers (1,2,3,4, 5....etc) in an infinite loop. The program should quit if someone hits a specific key (e.g., "ESC").

(2) Fibonacci series, swapping two variables, finding maximum/minimum among a list of numbers.

(3) Accepting series of numbers, strings from keyboard and sorting them ascending, descending order.

(4) The Reynolds number is calculated using formula (D*v*rho)/mu Where D = Diameter, V= velocity, rho = density mu = viscosity. Write a program that will accept all values in appropriate units (Don't worry about unit conversion) If number is < 2100, display Laminar flow, If it’s between 2100 and 4000 display 'Transient flow' and if more than '4000', display 'Turbulent Flow' (conditional statements).

(5) Modify the above program such that it will ask for 'Do you want to calculate again (y/n), if you say 'y', it'll again ask the parameters. If 'n', it'll exit (Do while loop). While running the program give value mu = 0. See what happens. Does it give 'DIVIDE BY ZERO' error? Does it give 'Segmentation fault..core dump?'. How to handle this situation. Is there something built in the language itself (i.e., exception handling)? If there is, write an exception handler for it.

(6) Write a simple scientific calculator supporting addition, subtraction, multiplication, division, square-root, square, cube, sin, cos, tan, Factorial, inverse, modulus.

(7) Test IO operations -- Printing output in different formats, say, rounding up to 5 decimal places, truncating after 4 decimal places, padding zeros to the right and left, right and left justification.

(8) Test file operations and strings -- Open a text file and convert it into HTML file.

(9) Time and Date : Get system time and convert it in different formats 'DD-MON-YYYY', 'mm-dd-yyyy', 'dd/mm/yy' etc.

(10) Create files with date and time stamp appended to the name.

(11) Input is HTML table, Remove all tags and put data in a comma/tab separated file.

(12) Extract uppercase words from a file, extract unique words.

(13) Implement a word wrapping routine that can wrap a string to an arbitrary number of columns, without breaking words over lines (this can be done recursively).

(14) Adding/removing items in the beginning, middle and end of the array.

(15) Are these features supported by your language: Operator overloading, virtual functions, references, pointers etc. -- if they are, try out some routines to exercise them.

Is there something called 'namespace / package / module' supported by your language? If they are, try it out.

May 29, 2006

Spare (!) Time

While boxing up the contents of my office for move #2 (due to occur some time while I'm on vacation, I think), I came across my (uncracked) copy of the Python Cookbook -- which reminded me that one of my goals this year was to learn Python. Well, the year's half over and I haven't. So I picked up a copy of Learning Python, since I've discovered that the Beginners Guides on the Python Wiki are a little more scattershot than I normally prefer my reading material to be. So far so good, I devoured the first five chapters over the weekend. I'm the kind of person who actually likes to read programming texts from cover to cover, even if one of the chapters so far was "fifteen different ways to launch a python script" (sort of). It gets me in the mindset of the language.

From what I understand, there's a healthy dose of animosity between Perl hackers and Python coders... and from what I've read so far, I can see why. Python offers some things that Perl doesn't (or that Perl doesn't do optimally, at least)... and central to this is one of Python's core design goals: "There should be one -- and preferably only one -- obvious way to do it." Miles different than Perl's "There's more than one way to do it", with the unstated corollary that every Perl hacker thinks their way is the obvious one. Another gem of Python wisdom: "Explicit is better than implicit". That's one of my guiding coding principles too.

Could it be that I've been a Python coder trapped coding Perl all these years?

May 19, 2006

Procrastinate / Think

An interesting article -- Are you procrastinating or just thinking?

Often times when I'm presented with a new project, I learn everything I can -- attend meetings, soak up details of the problem domain, then go away for a day or two and actively try not thinking about it. Then I sit down, glance over my notes, and start to gin up a requirements document. Even if the project doesn't require one, I throw together something -- even if it's just a set of comments.

Like the article says, the worst thing you can do is sit down and start coding immediately -- code is work, and people are loathe to throw out something they've put any amount of work into, even if it was intended just to be a quick-and-dirty prototype.

I'm not suggesting you shouldn't prototype -- prototyping is necessary and a great tool for developers. But thinking is even more powerful.