The Tao of Programming
http://www.canonical.org/~kragen/tao-of-programming.html
Was a fun read.
February 12, 2006
February 10, 2006
Enlarging text
Well I decided to post about making text larger on a web page. Why is it such a pain with most sites out there. I have a 20.1″ LCD. I like to have larger than 8 pt text to read. So I make the text larger with ctrl +. the text gets larger, but is confined to a 3″ wide column. So if I want larger text, I get 3 words per line. WTF :/ So I have a 3″ wide center column, with 3 words per line, and 3″ wide columns on either side with ads and links to other “stuff” and the 7″ of space is empty. This, to say the least, sucks.
I think this has to do with CSS (or maybe poorly implemented CSS) I’m pretty sure I have seen CSS designs that allow you to use all of you screen real estate for browsing. I need to find a firefox plugin to “fix” this. I think grease monkey has the ability to fix this as well.
January 15, 2006
XP/agile programming/pair programming
Well I had my first experience with eXtreme programming. More specifically “pair programming”. I must say it was rather fun. Pair programming has 2 people one keyboard. It allows you to bounce ideas off each other as you code. This has advantages and disadvantages. Most everything I’ve read talks about a coder “getting into the groove” and pounding out code. Any interupptions cna get you out of the groove. This didn’t appear to be the case. I think it boils down to both people thinkg about the same problem.
We discussed different ways to tackle the problem, and both explained why we thought a certain solution wouldn’t work. We did this untill we both decided on a solution that would work. This actually allowed us to solve the problem faster. Kevin, the guy I was working with, is a much more experienced developer than I am, and he said we probably saved about an hour, maybe 2 hours worth of time.
I hope I get to do more of this in the future.
technorati tags: XP, agile programming, pair programming
December 10, 2005
Do one thing and do it well
Well I was just reading something and the unix philosophy of “do one thing and do it well” came up. This is a rather good way to go about things. It was also mentioned that that would not be a philosophy os a *nix OS. I would think quite the contrary would be true. With computers if you can do one thing well, you can take that same one thing at make it run simultaneously. To the OS it is only doing one thing. It doesn’t care that it is doing “one thing” so fast that to us it appears it is doing 10,000,000 at once.
technorati tags: os, programming,
April 6, 2005
Programming Rules
Shamelessly stolen from Basics of the UNIX Philosophy
Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say [McIlroy78]:
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
He later summarized it this way (quoted in A Quarter Century of Unix [Salus]):
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
-
Rule of Modularity: Write simple parts connected by clean interfaces.
-
Rule of Clarity: Clarity is better than cleverness.
-
Rule of Composition: Design programs to be connected to other programs.
-
Rule of Separation: Separate policy from mechanism;
separate interfaces from engines. -
Rule of Simplicity: Design for simplicity; add
complexity only where you must. -
Rule of Parsimony: Write a big program only when it is
clear by demonstration that nothing else will do. -
Rule of Transparency: Design for visibility to make
inspection and debugging easier. -
Rule of Robustness: Robustness is the child of transparency and simplicity.
-
Rule of Representation: Fold knowledge into data so program
logic can be stupid and robust. -
Rule of Least Surprise: In interface design, always do
the least surprising thing. -
Rule of Silence: When a program has nothing surprising
to say, it should say nothing. -
Rule of Repair: When you must fail, fail noisily and
as soon as possible. -
Rule of Economy: Programmer time is expensive; conserve it in
preference to machine time. -
Rule of Generation: Avoid hand-hacking; write programs
to write programs when you can. -
Rule of Optimization: Prototype before polishing. Get it
working before you optimize it. -
Rule of Diversity: Distrust all claims for
“one true way”.
-
Rule of Extensibility: Design for the future, because
it will be here sooner than you think.
If you’re new to Unix, these principles are worth some
meditation. Software-engineering texts recommend most of them; but
most other operating systems lack the right tools and traditions to
turn them into practice, so most programmers can’t apply them with
any consistency. They come to accept blunt tools, bad designs,
overwork, and bloated code as normal — and then wonder what Unix
fans are so annoyed about.
Shamelessly stolen from Basics of the UNIX Philosophy