Drive a LEAF from NC to GA

zero-emission

Well, it’s time to move. Don’t want to forget the car, it has to move with us.

So the total length of the move is 360 miles or so. My leaf is supposed to make it to 70 on a good day. So there will be some adding of energy along the way.

Getting ready, I grab my trusty mapping application and the Plugshare app to scope out charging locations. This looks like a job for a spreadsheet, so I grab an empty one of those, too.

I won’t bore you with those particulars, but suffice to say I have a nice list of intermediate destinations that happen to be charging locations along with the number of miles from the previous and about how long it will take to drive between them.

My concerns are:

  • What if the charger is ICEd or otherwise not available?
  • How far do I have to drive to get to my backup location?
  • Some have no backup locations. Now what?

I started out listing backup locations, but I figure that with the Plugshare app in hand, I should be able to find the nearest one once in the vicinity.

I was fortunately able to find mostly CHAdeMO locations. Only one stretch was too long to comfortably make it without a charge, but fortunately I found a L2 charger on my route, so I can stop there a little longer to bridge the gap.

Drive a LEAF from NC to GA

Ubuntu – Changing US Locale to 24-hour Time

This has been done before, but I took a slightly different tack. In fact, I can’t claim this as unique, as someone in that post suggested it. I followed through, and this is my experience.

First, I agree with many posts I found when researching this that it’s a bad thing™ that Ubuntu doesn’t make this easier. But it is what it is and the alternative is less desirable.

To do this, locate the file /usr/share/i18n/locales/en_US and edit it with your favorite editor. Look for two strings:

d_t_fmt – The string that follows this is the format for commands like date.
t_fmt – This string governs time formats elsewhere.

These were the only two I could find that seemed to deal with the time format. Now on to that format. The Funky US 1:30PM type of format is produced by the characters %r in these format strings. We are going to change those to %T, which gives us the desired 13:30 format we want.

Unfortunately, it’s not as simple as changing lines that look like this:

% "%a %d %b %Y %r %Z

to something like this:

% "%a %d %b %Y %T %Z"

The reason is that these are actually comment lines and just there for us humans to be better advised of what’s going on.

What we do need to change looks like this:

d_t_fmt “<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0072><U0020><U0025><U005A>”

That actually says the same thing as the comment (between the quotes). The bit we’re going to target is the ‘r‘ in there, which turns out to be U0072 in unicode (ASCII-ish). What we want is U0054, which is ‘T‘. Pretty simple, right?

It’s good practice to keep the original stuff around, so use your editor to make a new copy of these two lines:

% “%a %d %b %Y %r %Z”
d_t_fmt “<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0072><U0020><U0025><U005A>”

Place the copied lines immediately before or after the orignal lines. I’m going to choose after here. Now add a comment character (%) to the original line (remember that the human-readable string is already commented), and change the two new lines to use T instead of r. You should wind up with something like this:

% “%a %d %b %Y %r %Z”
% d_t_fmt “<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0072><U0020><U0025><U005A>”
% “%a %d %b %Y %T %Z”
d_t_fmt “<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0054><U0020><U0025><U005A>”

I’ve highlighted the bits you have to change. The first two lines (both are commented with %, now) are the original lines. The next two contain our changes.

So that’s one format. The second format is t_fmt. We do the same thing (copy the two lines and change them), so we have this:

% “%r”
% t_fmt “<U0025><U0072>”
% “%T
t_fmt “<U0025><U0054>”

That’s all there is to the source changes.

The rest is simple:

  1. Recompile the locales using:
    $ sudo localedef -f UTF-8 -i en_US en_US.UTF-8
  2. Log out and log in.

Enjoy the time format!

These were taken from Thunderbird, which stubbornly refuses to do anything but follow your locale settings. I guess that’s ok, once you know how to deal with those:

I did this once before, but I had to redo it after reinstalling 14.04 over 12.04 a while back. You’ll have to remember to do this periodically when locales are overwritten for whatever reason. That’s a problem for another day.

Ubuntu – Changing US Locale to 24-hour Time

A Tale of Two Backups – How I Saved an Afternoon’s Work

Ok, so backups aren’t always on my mind, but it’s a sure bet I think about them every day or so.  Problem was: thinking about them doesn’t make them happen.

Fortunately for me, I thought about them one day in the past and just today reaped the benefits of that thought process — and what I did after I thought about it.

I started rsyncing my source code, .git parts and all, to my workstation about a year or so ago.  I work in a lab where the backups are there mostly for the express purpose of testing the backups.  <googly-eye>  And besides, I have just recently been working in said lab and suddenly everything went up in smoke…. Long story short, /var went *poof* and we had to re-image the machine.

Ok.  Back to the story.  Since I regularly (once an hour) rsync everything personally imporant from the hosts I work on in the lab, I had a copy of the code I knew I had worked on earlier.  All I had to do was:

$ cd ~/Work/backup/lnxdb-svl-17/home/dbbs
$ git checkout feature/noBackupForNonProxyStandbyDB
$ git status
# On branch feature/noBackupForNonProxyStandbyDB
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: common/usr/tools/backup/perlmods/lib/Local/App/Oracle/RMAN.pm
# modified: common/usr/tools/backup/perlmods/lib/Local/App/Script/RMAN.pm
# modified: common/usr/tools/backup/tools/templates/RMAN_nonproxy_10g_db.tt
# modified: common/usr/tools/backup/tools/templates/RMAN_nonproxy_11g_db.tt
# modified: common/usr/tools/backup/tools/templates/RMAN_nonproxy_12c_db.tt
#
no changes added to commit (use "git add" and/or "git commit -a")
$

I had the changes.

Tarballed the files, replicated the new branch on another host, untarred my new files here, and I was back in business.

If there were more changes (I knew there weren’t by looking at the log — more on that in a minute), I could have just as easily produced patch files from git here and applied them to the remote repository.

How did I know there weren’t more changes?  Because the log was telling me:

| * c80be82 (HEAD, origin/develop, feature/noBackupForNonProxyStandbyDB, develop) Merge branch 'feature/fixSnapMultipleSteps' into develop for a quick test

So the feature I was working on (noBackupForNonProxyStandbyDB) was at the same commit (c80be82) as everywhere else: they look identical.  And as we know: if the commit hash is the same, git guarantees the code is the same.

A Tale of Two Backups – How I Saved an Afternoon’s Work

git Rebasing develop branch

I ran into a situation today that I think is best handled by a rebase.  This is along the same lines of my previous blogs, but this time we’re going to use the rebase command, not the -r option to git-flow.

I also discovered a quick way to create a sandbox to play in.  I’ll be using it here, so let’s discuss that first.

Sandbox

Sometimes, especially when you’re new to a thing, you want to try out the command you’re about to issue to see what sort of smoke, wreck and ruin it produces.  Here’s a quick way to do that using git-bundle:

    1. Create a place to put your bundle: a directory in ~ is good:
      $ mkdir ~/gitbundles
    2. Change directory to the repository you wish to emulate and run:
      $ git bundle create ~/gitbundles/project.bundle master develop branch_i_care_about

      Note that branch_i_care_about is the branch or branches you want to experiment with. In the example below, I’m going to use feature.fixsnapMultipleSteps as the branch that I indeed care about.

    3. Go to the directory where your new bundle is:
      $ cd ~/gitbundles
    4. Unbundle into the ‘o’ directory:
      $ git clone --bare project.bundle o
    5. Now clone into a new directory, ‘t’. Clone from the ‘o’ repository you just created.
      $ git clone o t
    6. change to the project working repository and create local branches for the remote (origin) branches you intend to work with:
      $ cd t
      $ git checkout develop
      $ git checkout master
      $ git checkout feature/fixSnapMultipleSteps
      

That’s it: you have your repository replicated in a safe space. You can also reassure yourself by running:

$ git remote -v

That will tell you that your remote repository really is the one in the ../o subdirectory.

Git rebase

Once you have that done, you can move on to the changes you wanted to make, which in the case of this entry is to rebase develop onto one of your branches.

warning warning warning

Don’t do this if people have checked out your feature and are working on it.  If someone has it checked out, makes changes and tries to push after you’ve done what you’re about to do… it will be a very bad day for them.

You can fix this by NOT pushing your feature branches (easiest and is actually the default).  But if more than one person is working on a feature, you’ve got to push them.  What you’re about to do is a joint decision, then.  Make sure everyone has pushed their changes and understands that you’re going to merge them before you do what you’re about to do.  They should remain “hands off this feature” until you are done.  Then all they have to do is check out the new develop branch (pull first, of course) and they’re back in sync.

If you intend to leave the feature branch active… you might want to consider holding off a bit.  This is too complex to do every other day.

Anyway, here’s how we do it:

  1. Checkout the feature branch:
    $ git checkout feature/fixSnapMultipleSteps
    
  2. rebase develop:
    $ git rebase develop
    

The result is something like this:

Screenshot from 2015-04-01 17:09:21

Notice how the feature/fixSnapMultipleSteps branch is on top of the develop branch.  Also notice that on the origin, this branch is orphaned.  We need to fix that.  We won’t be needing those commits any longer.  The rebase has obsoleted them so we can delete them.  That’s actually pretty easy to do.

$ git push origin :feature/fixSnapMultipleSteps

Note that if you try to push the feature instead, you get something like this:

$ git push origin feature/fixSnapMultipleSteps
To /users/fbicknel/gitbundles/o
 ! [rejected]        feature/fixSnapMultipleSteps -> feature/fixSnapMultipleSteps (non-fast-forward)
error: failed to push some refs to '/users/fbicknel/gitbundles/o'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$

But in this case do not pull and push as hinted.  Instead just delete the origin branch first as we just discussed, then you’ll wind up with this, much simpler, picture:
Screenshot from 2015-04-01 17:16:41

Much better.  Now you can go on making changes to the feature branch (and/or develop) and eventually you’re going to want to finish that feature branch.

First let’s talk about pushing your feature branch.  You may wish to push the feature branch to the origin.  Note in the picture above that has not been done.  Don’t forget: we just deleted the origin’s branch that represented previous pushes because we rebased onto develop.  If you decide you want to push the new branch to the origin, the usual push does the trick:

$ git push origin feature/fixSnapMultipleSteps 
Counting objects: 171, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (107/107), done.
Writing objects: 100% (171/171), 25.85 KiB | 0 bytes/s, done.
Total 171 (delta 77), reused 42 (delta 34)
To /users/fbicknel/gitbundles/o
 * [new branch] feature/fixSnapMultipleSteps -> feature/fixSnapMultipleSteps
$

Assuming you do this, you might make changes beyond the commit where the push occurred.  In other words, your repository might eventually be ahead of the origin by some non-zero number of commits.  (Or behind, if the other guy pushes first.)

I highly recommend that if you do any collaborating on a feature that you use git to pull and merge each other’s changes and get to some common point before proceeding.

Once you’re in sync, you can use git-flow to finally finish your feature in the usual way.  Follow that with a push and the others need to pull develop once you’re done.

A bad day

Let’s assume you don’t follow this advice and you decide to finish your feature without syncing with the origin first.  Depending on whether or not others are actively developing, this could be not just a bad day but a tragic day as others’ or your changes are lost or require patching to fix.  Hope that everyone is at least close.

We’re not going to discuss that, however.  Let’s just say that everyone was caught up and stopped (including you), then you made just one more change, forgot to push and finished the feature.  The discussion below examines this.

First, let’s add something to the feature branch so we have this:

$ gl
* 2e4e213 (HEAD, feature/fixSnapMultipleSteps) Made a change
* 522ca7b (origin/feature/fixSnapMultipleSteps) Added -verbose option and some verbose features.

My feature no longer matches that of the origin.  Remember, I would advise you to push first (it’s easier), but what follows is an analysis of what happens if you don’t (because it happens).

Since we’re playing in the sandbox we just created, we need to initialize git-flow to use it:

$ git flow init

Which branch should be used for bringing forth production releases?
 - develop
 - feature/fixSnapMultipleSteps
 - master
Branch name for production releases: [master]
...

You only need to do that once and you wouldn’t have to do it in your live environment since you already did so.

Now we want to finish our feature.  I’m not using the rebase option here, because I didn’t have other branches outstanding.  But I imagine you could use it if warranted.  I have to admit, I’m not sure if that would complicate the solution to the bad day scenario.

$ git flow feature finish fixSnapMultipleSteps 
Branches 'feature/fixSnapMultipleSteps' and 'origin/feature/fixSnapMultipleSteps' have diverged.
And local branch 'feature/fixSnapMultipleSteps' is ahead of 'origin/feature/fixSnapMultipleSteps'.
Switched to branch 'develop'
Your branch is up-to-date with 'origin/develop'.
Merge made by the 'recursive' strategy.
...
warning: not deleting branch 'feature/fixSnapMultipleSteps' that is not yet merged to
 'refs/remotes/origin/feature/fixSnapMultipleSteps', even though it is merged to HEAD.
error: The branch 'feature/fixSnapMultipleSteps' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/fixSnapMultipleSteps'.

Oh no.  Warning and error.

Turns out that this hasn’t caused any real problem, but will require a little fixing up to make it right.  Remember, though: this assumes everyone else is standing idly by waiting for you to finish the feature.

Here is what we have now:

Screenshot from 2015-04-01 17:27:33

Notice the feature branches still there both locally and on the origin.

To fix:

$ git branch -D feature/fixSnapMultipleSteps
Deleted branch feature/fixSnapMultipleSteps (was 2e4e213).
$ git push origin :feature/fixSnapMultipleSteps
To /users/fbicknel/gitbundles/t/../o/dbbsbundletest/
 - [deleted] feature/fixSnapMultipleSteps
$

Now everything lines up.  If we had pushed before we finished, this all wouldn’t have happened.  I did it here just to show that it’s relatively benign.

Screenshot from 2015-04-01 17:31:08

After all that, be sure to push the new develop branch:

$ git push origin develop
Counting objects: 172, done.
Delta compression using up to 24 threads.
...
 3b5a423..33d7260 develop -> develop
$

Final result:

Screenshot from 2015-04-01 17:34:43

git Rebasing develop branch

git rebase features after the develop branch moves forward

More wondering about git rebase vs git merge.  I have come to the conclusion that git rebase beats git merge specifically when you have a feature branch sticking out of the tree somewhere and you want to pluck it off and move it to the top of the tree when a round of development has completed.

Examples abound, but here’s my simple one:

A -> B -> C -> D -> K "develop"
           \-> E -> F  "feature"

Presumably, you’ve merged some other unshown feature into “develop” (commit K), but you’re not yet finished working on “feature”.  You do want to get the benefits of commits D and K from develop into your feature (if for no other reason than testing them with your changes).  You could merge develop onto your feature branch, but a better way is to move the feature branch under construction to the tip of the develop branch, like this:

A -> B -> C -> D -> K "develop"
                     \-> E' -> F'  "feature"

Now your “feature” branch has all the changes that you worked hard on in commits C, D, and K (as well as the ones from the other feature not shown that led up to commit K).

For a real-world example, I provide these two images representing a starting point.

Screenshot from 2015-03-17 16:47:50

Screenshot from 2015-03-17 16:48:20

The first image is at the tip of the commits (develop has been merged).  The second image shows the feature (called FixNotifyInsideConfigBug) that we want to move.  We’re still working on this feature.

The commands issued were:

Screenshot from 2015-03-17 16:55:14

And this is the result:

Screenshot from 2015-03-17 16:55:28

Summary

Maybe I would feel differently if the branch were more complex (but I don’t think so).  I think the desired mode is to merge into develop.  If a feature branch gets split into multiple forks; perhaps to tackle the feature in smaller pieces, then probably merging those multiple forks seems in order.

But when a feature has been finished and merged into develop, this moves develop ahead of other features.  Those features may wish to keep up with changes to develop.  My recommendation is to not merge develop into those open feature branches.  Instead, rebasing your feature onto the new develop branch tip seems more straightforward.

git rebase features after the develop branch moves forward

Git rebase vs. merge with git flow

So I got to wondering what the result would be if I rebased git-flow finished features instead of merging them as I have been for so long.

So here’s what things look like when 3 features are rebased (git flow feature finish -r F[1-3]):

git flow feature finish -r F3
git flow feature finish -r F3

 

 

 

 

 

 

 

 

And here’s what it looks like merged:

git flow feature finish F3
git flow feature finish F3

 

 

 

 

 

 

 

 

Note that features 1 and 2 were both rebased in both examples to avoid (at least some) confusion.

The rebase does come out looking neater, doesn’t it?

Git rebase vs. merge with git flow