The convenience of Ruby 2.1 def returning a symbol instead of nil

Prior to 2.1, if you defined a method, you received nil as a return value:

irb(main):001:0> def fun
irb(main):002:1> end
=> nil

With 2.1, the method definition returns a symbol for the method name:

irb(main):001:0> def fun
irb(main):002:1> end
=> :fun

One impact of this is that the following pattern for declaring a single private method

  def fun
  end
  private :fun

can become:

  private def fun
  end

Now to decide if I like how that looks.

Twitter as Record of the Evolution of Language

In Our Magnificent Bastard Tongue, John McWhorter presents the case that the Celts were the reason for the introduction of the "meaningless 'do'" in the English language, and presents other similar implicit influences that have no recorded evolution in formal language. Counterarguments cite that since the evolution wasn't written down, it didn't happen that way.

Twitter may be the first opportunity for us to actually observe a recorded evolution of language as it actually occurs. Twitter is an extension of text messaging, which is a proxy for the bleeding edge evolution of spoken language. With the Library of Congress archiving tweets, we may have the first official and publicly accessible record of the nuances of change in language.

Before Twitter, most written communication occurred, minimally, in the writer's best dressed understanding of the language. Some email may be a little bit different, but emails are lost to abandonment of accounts and servers, and still follow etiquette more closely than a medium purposely restricted to 140 characters. I thought about its impact of recording speech usage when I mimicked nonstandard use of "because" and "why is" in my social media posts. Regardless of whether our own language use immediately evolves, we are reflecting the "misuse" of language more than ever before, and possibly as a larger sample of overall recording of language.

Why not radio and television? Because access to publishing on TV and radio is restricted to a relatively elite class of publishers, just as scribes, as the only literate class, controlled the language that was written. Art and music is more representative, but is still restricted by the boundaries of was is "good" even if a popularity formula is the judge of "good and proper" rather than grammar rules.

Facebook and other social media have similar impact, but Facebook has privacy controls that limit its visibility and other social media (LinkedIn, Google+, blogging) are prone to professional scrutiny and editing due to longer form.

 

zsh alias to make and apply patch with git diff

I keep having to look up [patching with git diff](http://tamsler.blogspot.com/2009/02/patching-with-git-diff.html) to remember the syntax whenever I want to create and apply a patch file.

Solution?

Create an alias for it. It only uses one file, /tmp/patchfile, so don't try to manage multiple patches with this (maybe I'll make more intelligent/sophisticated someday.

In my .zlogin, I now have:

alias makepatch='git diff --no-prefix > /tmp/patchfile'
alias applypatch='patch -p0 < /tmp/patchfile'

To create a patch, makepatch

To apply a patch, applypatch

Call up JIRA tasks from zsh using .oh-my-zsh

This was called to my attention via

[Current instructions are in the plugin source](https://github.com/robbyrussell/oh-my-zsh/blob/master/plugins/jira/jira.plugin.zsh)

The setup:
In .zshrc, add jira to plugins and JIRA_RAPID_BOARD=true if you use Rapid Board.

#
#
plugins=(git jira)
JIRA_RAPID_BOARD=true
#
#

Create a file .jira-url in your home directory or at the base of your project.

https://my.jira.url/

To constrain to a subproject for your project directory's .jira-url: (Your mileage may vary on how well this improves your experience)

https://my.jira.url/browse/SUBPROJ/

To create a new issue:

jira

To open an existing issue:

jira PROJ-123

When Bad Things Happen to Good Web Clients (aka Why Did You Send Me a HTTP 400 Error?)

I initially thought that I hadn't gotten much out of REST API Design Rulebook, mainly because the prescriptions mentioned in the book don't overlap well with common practice in Rails (or what Rails easily supports).

However, one thing that I developed greater appreciation for was proper use of HTTP status codes. Namely, that HTTP 4xx status codes should indicate that a problem occurred due to something that the client did wrong, regardless of whether improper access or requesting a resource that wasn't there, and that HTTP 5xx status codes should indicate something unexpected went wrong on the server side.

My challenge came when noticing in test routines that problems that were throwing exceptions were generating 400 errors with stack traces embedded within them. Until I dug deeper into the source of the error, I didn't realize that errant code was causing the problem, and therefore spent extra time trying to examine my [test] client setup for the source of the problem instead of quickly identifying bad server code as the source of the error.

rspec before(:all) is tempting but stubs don't play nicely with it.

I was looking at an rspec test with multiple expectations in the same example.

  before(:all) do
     SpecialClient.any_instance.stub(:login).and_return { true }
  end
#
# MUCH SPACE
#
# WOW
#

  it "does stuff successfully" do
    # preceding code, including controller action
    expect(result.valid?).to be_true
    expect(response.body).to match /All is happy/
    expect(response.code).to eq "200"
  end

I wanted to add an additional test, but didn't want it to be lumped in the "does stuff successfully" example, so I went ahead and refactored the expectations into different examples, and ran into:

NoMethodError:
       undefined method `any_instance_recorder_for" for nil:NilClass

I found this answer on StackOverflow that helped me track down that the use of a before(:all) vs. before(:each) might be the problem.