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/git@github.com:/https:\/\/github.com\//' | xargs -I {} open {}
}

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"
main()
{
 
	int rows,columns,ROW, COLUMN;
	scanf("%d %d",&ROW,&COLUMN);
	rows = 0;
	columns = 0;
	while(columns++ < COLUMN)
		printf("\xdb");
	printf("\n");
	rows += 1;
	while(rows++ < (ROW - 2)){
		columns = 0;
		printf("\xdb");
		while(columns++ < (COLUMN - 2)){
			printf(" ");
			}
		printf("\xdb\n");
		}
	columns = 0;
	while(columns++ < COLUMN) {
		printf("\xdb");
		}
 
 
}

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(!dictionary)
	{
		loadDictionary("WORD.LST");
	}
	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) {
   hugWithBraces();
}

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.

Ruby

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...

Smalltalk

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.

Conclusion

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.

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.

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

Toy Helicopter Review and Durability Test: Sky Rover Aero Spin

The Sky Rover Aero Spin was a pretty impressive little toy helicopter.

It has a hover mode that stabilizes flight a certain distance off of the ground and a "controller" mode which allows you to try controlling the spin rate of the propellers to fly the helicopter.  A good video demonstration is on the rcgroups forums.

This helicopter has been by far the easiest budget (<$50) helicopter to fly, at $10 at Wal-Mart ($7.51 online now).

Unfortunately, a collision within the first minute of flight broke the ring holding the blades together onto the spin shaft. [See Flutterbye Deluxe Fairy for a "helicopter" from this Christmas that's still going.]

We played around with Gorilla Glue to try and repair the ring (should have used crazy glue. After the glue was allowed to set, the helicopter was mostly back in flying shape, with the exception of a bit of constant roll due to the imbalance.

We were able to fly the helicopter for another few minutes prior to a collision that snapped the same fragile ring yet again, both in the glued spot and in the spot opposite to it.

Ease of flight is definitely an A+. There's virtually no thought to it.

Durability is a bit worse that most Air Hogs brands that we've had.

To be determined: If there will be any support from the company who manufactured the helicopter.

Gorilla glued one side, it worked until until side broke along with it
Gorilla glued one side, it worked until until side broke along with it

Using jquery us map to Create a Map of States That Can Be Toggled

The us-map plugin was already in use elsewhere and I wanted to create a clickable map that would display an anchor state and allow for configuration of related states.

Also in use is the gon gem to allow passing of data directly into Javascript, included in a Rails 4.1 project.

Controller code:

  # assume @state is the current state
  gon.current_state_code = @state.state_code 
  gon.regional_states = @state.related_state_codes # returns ["AL", "AK", ...]

View code:

<%# this is inside a form and states_list maintains the current list of selected states%>
  <div id="map" style="width: 800px; height: 600px;"></div>
  <%= hidden_field_tag 'states_list' %>

Associated CoffeeScript:

 
states = ->
  # initialize the hidden field for states selected
  $('#states_list').val(JSON.stringify(gon.regional_states))
  $('#map').usmap(
    stateStyles:
      fill: 'lightGray'
    stateSpecificStyles: do ->
      # current state is red, selected states green
      specificStyles = {}
      specificStyles[gon.current_state_code] = fill: 'red'
 
      for state in gon.regional_states
        specificStyles[state] = fill: 'green'
 
      specificStyles
    click: (event, data) ->
      # don't allow current state to be selected
      if data.name != gon.current_state_code
        # add green as a specific style or delete to toggle state highlight
        if this.stateSpecificStyles[data.name]
          delete this.stateSpecificStyles[data.name]
        else
          this.stateSpecificStyles[data.name] = fill: 'green'
 
      # this could be more intelligent, but I'm just recalculating along the way
      regionalStates = []
      for key of this.stateSpecificStyles
        if this.stateSpecificStyles[key]['fill'] != 'red'
          regionalStates.push(key)
      $('#states_list').val(JSON.stringify(regionalStates))
  )
 
$(document).ready ->
  if gon? && gon.regional_states?
    states()

Sites That Have a Problem Working in Google Chrome

I've been hitting issues with site compatibility with Chrome lately, so I decided to start with a list of sites that I've had issues with in the last day, and I'll build on from there.

As of Chrome 39.0.2171.71 (64-bit) on Yosemite:

  • panel.dreamhost.com - Rebilling edit does not allow you to check the checkbox to limit billing on one day or specify an amount. (Only happened when my recurring was expired. Cannot reproduce now.)
  • Fidelity.com - Quicklinks dropdown after login collapses immediately instead of allowing you to select a menu item.
  • playstation.com - Password Reset password fields don't register that you're typing in any information (strength meter doesn't change), and when you submit, you password hasn't actually been changed. Same functionality worked in Firefox.
  • GWT Developer Plugin installed but not recognized.

The story behind rspec kung fu hamster

rspec-kungfuhamster originated as a joke on a POS development team I worked on almost 10 years ago. In the battle of scope creep and requirements changes, we all got a bit loopy and a couple members of the team drew up an ASCII animated "kung fu hamster" as a terminal-based spinner while the credit card authorization (often by modem) was taking place.

Strangely, product ownership didn't see the humor in so much time being spent on the animation.

I decided to revive kung fu hamster as an rspec formatter in honor of those days of solving technical problems on out-of-date SCO Unix boxes without access to anything but standard and home grown libraries, as well as the two team members that have passed away at far too young an age since.