Updates from December, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • ThomasPowell 12:52 pm on December 30, 2014 Permalink
    Tags: github,   

    Open Your Github Repo in a Web Browser from the Shell 

    This assumes that your first remote is a github remote. Put the following in the appropriate bash or zsh initialization script and that you’re on a Mac. You might need to change “open” to whatever will launch a URL in a web browser on a different *nix system.

    function gitweb() {
      git remote -v | head -n 1 | awk '{print $2}' | sed 's/.git$//' | sed 's/[email protected]:/https:\/\/github.com\//' | xargs -I {} open {}
  • ThomasPowell 5:11 pm on December 27, 2014 Permalink
    Tags: , , smalltalk, style   

    Programming Style: Language Specific Domains 

    My Beginner and C Days

    The visual presentation of the code has mattered to me, from the first days I wrote C code in Microsoft editor. In those days, it was a Microsoft C 5.0 IDE on either DOS or OS/2.

    #include "stdio.h"
    	int rows,columns,ROW, COLUMN;
    	scanf("%d %d",&ROW,&COLUMN);
    	rows = 0;
    	columns = 0;
    	while(columns++ < COLUMN)
    	rows += 1;
    	while(rows++ < (ROW - 2)){
    		columns = 0;
    		while(columns++ < (COLUMN - 2)){
    			printf(" ");
    	columns = 0;
    	while(columns++ < COLUMN) {

    Ok, not *that* far back, but I did have strong opinions about C from the early days of my being paid to program in it:

    • TABS, not spaces
    • 3 (in Microsoft land) spaces per tab (eventually switched to 4)
    • always include braces for if clauses
    • generally no parentheses for return values
    • ternary operator GOOD

    That made the code look like this (except that tabs are tabs in pre blocks).

    int compare(const void *a, const void *b)
    	return(strcmp(*(char **)a, *(char **)b));
    int checkDictionary(char *word)
    	if(bsearch((void *)&word, (void*)dictionary, wordCount, sizeof(char *), compare))
    		return 1;
    	return 0;

    But I remember so much variation in coding style preferences, as evidenced by the Indent Style article on Wikipedia. Everyone had their own preferred style, and everyone had their own preference for how much everyone else should adhere to a common style. On one team I worked, they eventually developed code reviews which were nothing more than berating people for not adhering to an arbitrary style guide: an in-house version Hungarian Notation, exactly one return per function, etc.

    Java and Perl days

    In Java land, my preference for camelCasing was reaffirmed. Working with Perl and Java, I eventually started putting the opening brace on the same line as if statements and function declarations.

    if(iAmAChangedProgrammer) {

    I think the brace thing was a result of a block that evaluated differently in awk or perl if it didn't hug the clause. I don't remember, but from that point on, I was convinced of that way being the only way.


    Coming into ruby has been interesting. Multiple returns (which never bothered me) are common. Implicit returns are the norm as well. There's a style guide which, for the most part, experienced rubyists adhere to (even if there are slight variations in practice). I find some disagreement with some of the style recommendations (I think I have found legit use for and over &&, etc...), but I'm happy to fall in line with the style recommendations and help enforce them.

    Some of the styles have obvious purpose, but some seem rather arbitrary. Why are guard clauses so accepted in Ruby when C was so scared of them, etc...


    In reading Smalltalk Best Practice Patterns, it all came together.

    As part of the style guide near the end of the book, the author talks about using the line-wrapping of the browser window to naturally wrap argument lists instead of taking up vertical space with them. That's when it dawned on me how much preferences in code styles also come from the languages that influenced the current language.

    Ruby's heritage from Smalltalk means that it carried forward that aversion to deep nesting that performs poorly in small code browser windows (even in Squeak and Pharo, the code windows can get pretty tiny.)

    C coders may have come from GOSUB type languages where there truly was only one return (unless an IF clause buried another) and there could be multiple entry points. Multiple entry and exit point aversion came from languages in which you could GOSUB to anywhere before a RETURN statement, and a nested RETURN could be harder to detect than one on the main logic level.


    Early language coding styles likely came from specific pain points experienced by a prior guru and then arbitrarily passed along because "We've always done it that way." At some point, tasks and readable code become hindered by following rules that we don't have a rationale behind.

    Community style guides hopefully have the benefit of thousands of years of cumulative experience in challenges and best practices collaborating on equal footing, but that assumes that we're not just agreeing with our technical elders because that's the way it's always been done.

    Try to understand the problem domain of coding in a specific language as it relates to coding style. Maybe your coding style thinks its still programming in COBOL or BASIC.

  • ThomasPowell 2:12 pm on December 27, 2014 Permalink
    Tags: helicopter   

    Toy Helicopter Review and Durability Test: Flutterbye Deluxe Fairy 

    We’ve bought several cheap toy helicopters that have usually met their demise via the breakage of one of the components that rotates at high speed breaking. Air Hogs has been a favorite brand because they are usually cheap and your face on retail shelves. [The charging port on this doll bears the Air Hogs brand, as well.]

    [Somewhat related: our big dog doesn’t like any of these flying things and thinks it’s his mission to “kill” them, giving us an extra obstacle to their longevity.]

    This fairy doll is the first one we’ve had that doesn’t look like a standard helicopter for us.

    When taking off from its base, the doll floats fairly gracefully to the floor. The doll mostly hovers within a foot or two of the surface underneath her. However, you can cup your hands directly below it and it’ll float above your hands briefly instead. I noticed when I did this, the fairy would float steadily to the ceiling and hover and gradually come back down.

    The doll will also take off from your hand, but it’s very easy to not be vertical at take-off and/or to present an uneven surface below it, causing to lift off erratically. I recommend letting it take off from the base stand each time.

    We’ve had 5-10 crashes with the doll. One thing I noticed with this doll (unlike manually controlled helicopters) is that power is immediately cut to the rotors when a collision happens. This minimizes the high speed damage that the blades and balances endure when you don’t react quickly enough to cut the power on a remote control.

    Between the ease of flight, the safety cut-off, and the relatively more durable structure overall, this doll seems like the best value in the under $50 helicopter department for those of us who really don’t know how to successfully fly a toy helicopter, anyway.

    The doll in the video is the Deluxe Light Up Flutterbye Fairy – Rainbow (Amazon affiliate link)

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc
%d bloggers like this: