The one little problem

Everything goes along happily until git decides you need some help. And so, in a fit of well intentioned verbosity, git coughs up three terminology-packed paragraphs of text that we’ve all seen:

You asked me to pull without telling me which branch you want to merge with, and 'branch.newlayout.merge' in your configuration file does not tell me either. Please specify which branch you want to merge on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details.

If you often merge with the same branch, you may want to configure the following variables in your configuration file:

branch.newlayout.remote = <nickname>
branch.newlayout.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>

I collected the following git-specific terms from this one message:

branch, fetch, git-pull, merge, newlayout, nickname, pull, refspec, repository, remote, remote-ref, url

What’s the difference between a <refspec> and a <remote-ref>? Between a <repository> and a <nickname>? Between a pull and a merge? (I asked for a pull, but git’s giving me merge info.)

My guess: several of these terms are used interchangeably, and git’s docs should be made more consistent. Note how the terms in the text paragraphs do not match the terms in the config file template.

Problem #2: The second paragraph says to add the info to the config file. But the info isn’t in config file format; it’s closer to command line git config format.

About me: I have a track record of making innovative, public service apps for attorneys and law students. I’ve also got years of Linux and Java development experience, and will be able to hit the ground running.

Here are some links to show that I’m serious about following through:

Screenshots of iPhone legal app

My biggest web app

Press I’ve received

My personal home page

(Originally posted on under my id dogweather on reddit)

The first comment reads, “Helpful blog, bookmarked the website with hopes to read more!”  An odd but friendly comment without a link to any website; seems benign.  But now that two have appeared, the pattern is clear:  They are (1) friendly posts that (2) praise the blog (3) using odd English phrasing, (4) without saying anything specific about the content and (5) are sent from the same sub-network.  Google shows 25,000 similar posts on other sites.

I’m not sure what the spammer is after, but my guess is: First become an “approved commenter” on the target sites, then return later to post actual spam.

He replied a few minutes later: the link wouldn’t work.  They never do; they expire after 10 minutes or so.  And so what happens?  Attorneys print out or create PDFs of the USPTO web pages in order to discuss them.

I immediately thought that there must be something that could be done here, and so I started the Trademark Permalink project:

Create links that don’t expire to trademarks at the U.S. Patent & Trademark Office. Use them in emails, on your website, or anywhere else you want to point someone to a trade/service-mark registration.

EDIT:

The story’s gotten a little more complicated:  In the past day or so, I discovered that it’s possible that my work might be superfluous: The “TARR” USPTO web app provides single-document retrieval via URLs that don’t time out.  Many (most?) practitioners seem to only know about the TESS service, though, which *does* time out.  Also, the TARR data seems to come from a different source, and is definitely a different format.  For example, the IBM registration I use as an example:

http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=75871833

1. You find a web page that’s not returning the status code or results you wanted it to (i.e. redirecting to the wrong place).
2. You write a test (which will fail) which “asserts” the behavior you want it to have.
3. You edit your config files, periodically re-running all of the tests.
4. When all of the tests pass, your job is done.

The same benefits of TDD should apply to TDC.

CivicApps.org in a nutshell

Back in the old days, i.e. 2008, cities like Portland would create apps (interactive websites) for us like this:

The old way of making apps

They’d get a team together, look at the Datasets available to it, come up with ideas, and then build the apps.  PortlandMaps, an awesome web app, was made this way.  But there’s a new trend and Portland’s setting an example for other cities.  First, the city adopts a policy of transparency, publishing all of its raw data in addition to the finished apps:

First, cities make their raw data available

Then, curious and entrepreneurial individuals, companies, and other organizations step in and independently create new apps.  This frees up city resources and results in more apps and services coming online:

Then, 3rd parties can step in and contribute

This is the entire purpose of the CivicApps.org project and website: to enable this creative environment.  By the way, this is the same idea behind the federal Data.gov project.

My idea: we can contribute data too

It occurred to me that many organizations have valuable data about the city.  And some even have the expertise to publish the data in “open formats” just like the city of Portland is doing:

My idea: We can provide datasets too

For example, my project, OregonLaws.org, publishes a glossary of legal terms specific to Oregon.  This is already up and running as a Dataset.

It will, though, take some work to implement my idea.  Some questions to answer are;  How will these 3rd party Datasets be integrated into the palette of “official” ones?  How will the data be authenticated or verified?

The near future

The end result of all this is that the city could become a nexus of information.  In addition to providing raw data about itself, it can act as a means of identification and authentication. There’s a precedent for the government acting in this role, e.g. the Secretary of State’s business registry performs a similar service.

Update

Oregon Business Magazine covered the CivicApps contest:  Keeping PDX a Hot Spot for App Development

Background context

Subversion uses a single, central repository which is in a remote place. And in your project, it maintains .svn/ directories in every sub-directory. Git on the other hand, gives each developer their own full-fledged repository. And then, instead of relying on many hidden directories in your project, it creates one that lives only in the top-level directory; in .git/. So again: that’s the only place it stores info; nowhere else in your code.

Interesting, huh?

The advantages I’ve found

So now that I’ve begun to use git, it’s already been a nicer experience than subversion:

Deleting a subdirectory doesn’t screw with the versioning like it does in svn.  (Because no version info is stored there.  In svn, you need to repair things; re-create the empty directory so you can delete it, etc.  I do this to myself periodically.)

It’s totally painless to put existing stuff into git — it stays right where it is. E.g., a website that’s in use. You can initialize the repository and commit the current version of the files while they’re in use. This isn’t possible with svn: you have to check it in, then check it out.

It’s easy to work on a new idea: it’s really easy to create a branch to work on it, and then switch back and forth. In svn, this is enough of a pain that I don’t do it in actual practice.  Git finally makes it easy for me to use revision control like I’ve always wanted: be able to check out our group’s code, test ideas out, and rollback in my own little world without disturbing the others, and finally commit only the changes I want to.

Git assumes you meant to delete that file. That’s been nice and convenient:  I deleted a file without going and telling git first about it.  Git adds a ‘delete’ operation to your list of things to check in.  Awesome.  Svn does it the other way around:  You can’t just do normal file operations; you have to also tell subversion that yes, you did mean to do that.

Git has the GitHub killer app. It’s the Netscape of the WWW.  I haven’t found an equivalent for Subversion — web-based or not.

So that’s what I’ve come up so far; I’ll add more when I see them.

I’m releasing a new open source library, HTTP-Assertions, that I use behind the scenes at OregonLaws.org.  It helps me keep the server running smoothly and make sure that my changes to the config files haven’t introduced new bugs.

It introduces these new assert methods to the Rails testing environment:

  assert_200
  assert_forbidden
  assert_temp_redirect_to
  assert_perm_redirect_to

Here’s an example:

  assert_200('https://www.oregonlaws.org/ors/161.360')

See the README on github for more details.

Basically, software should be held to the same standards we have for people, especially in the field of law. Here’s what that might look like. This is, again, the “development” interface… an end-user would see something much fancier:

>> Abbreviation.abbreviate 'Chief Justice'
=> "C.J."
>> Abbreviation.rule
=> "Appendix 3"

It’s a start.

As far as the technical implementation, I’ve been considering rule-based systems, prolog-based systems and object-oriented decomposition.

>> Abbreviation.abbreviate 'Advance'

=> "Adv."

>> Abbreviation.abbreviate 'Advanced'

=> "Adv."

>> Abbreviation.abbreviate 'Advancing'

=> "Advancing"

So, this has been pretty interesting. Now I need to handle plurals well. This, though, means I’ll have to be able to identify plurals… but I have a couple of good ideas about how to do this.