I shit you not...
Was sitting at a red light when I remembered that I needed to look into GitX (thanks for the tip, Byron and Andrew). So I commit a minor no-no and flip out my cell to send myself a voice-to-text note via jott.com. As I’m doing so, the cross-street’s light changes, and I step on the gas. That’s when I realize my light hasn’t changed.
Fortunately it was late at night, so there was no traffic to have an accident with. But I did find this message in my e-mail:
Jott Networks to Jay: Reminder. Computer research Getex(?). Wooh! Jesus!Read more...
Notes from Kernighan and Pike: The Practice of Programming...
Borrowed The Practice of Programming from the Gangplank library on Jade Meskill’s recommendation… It’s pretty C++ and Java-centric, but a lot of it is applicable to Ruby, and these notes were taken through Ruby-colored glasses.
Style:
Why 'waste time' on good coding style? Once it becomes automatic, even code
you produce under pressure will be better.
Using long names regardless of context is a mistake: clarity is often achieved
through brevity.
"queue.queue_capacity" is redundant, "queue.capacity" is better.
The ?: operator is fine for short expressions where it can replace four lines
of if-else with one, but if full conditional statements make the code clearer,
use those.
If you work on a program you didn't write, preserve the style you find there.
The program's consistency is more important than your personal preference.
Learn your language's idioms. Those with experience can read and write them
easily without mistakes. And if there's a mistake in using the idiom, it's
usually easy to spot.
Sprawling code goes onto multiple pages/screens; scrolling reduces readability.
If there's no good logic to put as the default in case statements and if-elses,
throw an exception; it catches conditions that "can't happen".
On comments:
Harmful comments:
Don't restate what the code already clearly says. (Carefully
chosen names are better than comments.)
Don't write comments unless you're sure they will be updated as
the code changes.
Good comments:
Aid understanding of a program by briefly pointing out
important details.
A comment that introduces each function will speed comprehension when
reading code.
If the code uses an unfamiliar algorithm, consider referencing a
document/URL/book the maintainer can read.
Comment anything unusual or potentially confusing, but only after
considering refactoring.
Design and Implementation:
"Show me your tables, and I won't usually need your flowcharts; they'll be
obvious." --Frederick P. Brooks, Jr., The Mythical Man-Month
Program design can be colored by the language used, but is usually not
dominated by it.
Issues to be worked out in a design:
Interfaces: provide services that are uniform and convenient, without
so much functionality as to be unwieldy.
Information hiding: provide straightforward access to your components.
Hide details of your implementation so they can be changed without
affecting users.
Resource management: is the user responsible for managing storage,
memory, and other limited resources, or is the framework?
Error handling: who detects errors, who reports them, and how? What
recovery is attempted?
Build a prototype for new systems. It's not until you've built and used a
version of a program that you understand the issues well enough to get the
design right.
Read more...
Diana got tickets for us and Mom to the Chihuly blown glass exhibition at the botanical garden… The artist is one of the few I know of that allows cameras into the exhibition, and shutterbugs came out of the woodwork for it. All 3 of us were armed with our own point-and-shoots (one on loan from Diana’s mom), and we fired off hundreds of shots between us until batteries started running out.
This one’s off my camera phone; the proper pictures will be posted later. Some will be going into a photo contest they’re running, and judging from the unimaginative entries in the gallery, we might actually have a chance.
MountainWest RubyConf - a travelogue...
Integrum at MountainWest RubyConf 2009 from Jay McGavren on Vimeo.
Notes from Jim Weirich - Building Blocks of Modularity...
Update 2009-05-05: Saw this talk again today at RailsConf and had a chance to fill in some missing pieces…
Is there a grand unified theory of software development?
Principles:
SOLID
Law of Demeter
Method chains not good - only talk to objects in local environment.
DRY
Small Methods
Design by Contract
Myer on Coupling: old, imperfect model that doesn't extend well to dynamic languages. From best to worst:
No coupling
Data coupling
Data local to two modules: simple data
Stamp coupling
Data local to two modules: structured data
Control coupling
Method usually has a "flag" parameter that controls which algorithm it uses
ex: Array.instance_methods(true) #What does true mean?!
ActiveRecord#find (:first, :all, etc.)
External coupling
Global data: simple data
Common coupling
Global data: structured data
Content coupling
Connascence
Things that are born together, and change together. A change in one requires a corresponding change in the other.
Originally applied to software by Meilir Page-Jones in early 90's.
Connascence of Name:
class Customer
def email; blah; end
end
def send_mail(customer)
customer.email #Change Customer#email's name, you must update this call.
end
Rule of Locality:
Connascence of name between method parameter and a reference in the same method doesn't matter at all.
Connascence of name between two separate libraries matters a lot. It's why APIs must be frozen.
Connascence of Position:
:orders => {"3" => "1", "5" => "2"}
[ [ Order.find(3), true], [ Order.find(5), false ] ]
Order of parameters decides behavior.
Really bad:
def process(order, expedite, confirmation_number, ...); blah; end
[order, true, 2374]
Easy to forget order of parameters, especially if you're passing 3, '
Better:
class OrderDisposition
attr_reader :order
attr_reader :expedite
attr_reader :confirmation_number
end
Methods that take hash parameters are better than positional arguments, because each argument is labelled and can be re-ordered or omitted.
Degree matters:
Some types of connascence are worse than others.
Connascence of Name better than Connascence of Position.
Rule of Degree:
Convert higher degrees of connascence into weaker forms.
Example: refactor from positional method params to an options hash with named keys (CoP -> CoN).
Connascence of Meaning
Consider "magic numbers" (these are bad):
<input type="checkbox" value="2">
if params[:med][id] == "2" #Have to do case-like statement in totally different module.
@medication.given = false
end
Contranascence
Things conflicting with each other. (Always in name?)
#my_xml_lib
module Kernel; def node; end; end
#my_graph_lib
module Kernel; def node; end; end #Conflict!
Example is classes that must be namespaced to avoid conflict (XML::Node, YAML::Node)
Connascence of Algorithm:
Logic repeated in multiple places - not DRY.
Bad:
def add_check_digit(digits); digits + ((10 - digits.foobar{|d| d + 5} % 10).to_s; end
def check?(digits) check_sum(digits.foobar{|d| d + 5}) == 10; end
Change digits.foobar{|d| d + 5} in one place, you must change it in both places. Better not forget!
Better:
def add_check_digit(digits); digits + ((10 - foobar(digits) % 10).to_s; end
def check?(digits) foobar(digits) == 10; end
def foobar(digits); blah; end #Shared routine
Change the shared routine, and you change the logic everywhere you need to.
Connascence of Timing
Race conditions.
Bad if called from multiple threads:
def increment
@amount += 1
end
Use Java-like synchronized declarations on methods to ensure they are thread-safe.
Connascence of Type
See What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones
Connascence of Execution
See What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones
Connascence of Value
See What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones
Connascence of Identity
See What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones
Read more...