If everytime you go to do a remote connect (e.g. push) to github and it requests your github password, then you have most likely have a problem with your credential helper.

The credential helper is part of a standard github or homebrew install. But sometimes things don’t go as planned, or perhaps your github install was part of a larger “all-in-one” install and something got improperly configured.

The good new is it’s an easy enough problem to fix.

These instructions apply to OS X, but you can check GitHub Help for your platform.

1: First, check to see if you have the credential helper installed:

1

$ git credential-osxkeychain

If you get the following then it is installed, go to step 3:

1

usage: git credential-osxkeychain <get|store|erase>

But if you get, go to step 2:

1

git: 'credential-osxkeychain' is not a git command. See 'git --help'.

2: Then you need to install and configure it with:

1
2
3
4
5
6
7
8
9
10

# Download the file
curl -s -O \
  http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain

# Fix the permissions
chmod u+x git-credential-osxkeychain

# Move it to the right path, sudo may require your password.
sudo mv git-credential-osxkeychain \
  "$(dirname $(which git))/git-credential-osxkeychain"

3: Lastly, modify your git config file to use the helper:

1

$ git config --global credential.helper osxkeychain

The next time you push you’ll be asked for your github password, but after that it should be remembered in your OS X keychain for each subsequent remote access request.

Thanx for reading. Stay tuned for more from the front lines…

What do you despise? By this are you truly known.

We hear the term “agile” all the time in the development world. What does it really mean? Everything seems to have the term agile attached to it.

It came up in class tonight as we were introduced to Pivotal Tracker, and the paradigm behind it.

Sometimes you can figure out what something is by what it is not. A few weeks ago I came across a video on Vimeo that addressed this. Enjoy…

Fred George - Agile is the new black - Railsberry 2013.

Command Line Fu – xkcd.com This cartoon is particularly amusing because…

I’ve spent the last twenty-four hours working through The Command Line Crash Course as homework for class. In addition our instructor had us log our progress in Pivotal Tracker by having us work through “stories” to test our knowledge.

Overall it was excellent, since we got exposure to two parts of the development environment at the same time: using and working the command line, and learning a tool that is a de-facto standard in the development industry.

What did I learn?

Pay attention to the stories, details are important, so don’t rush ahead or you’ll miss something. My first few stories in Pivotal Tracker were rejected for that reason.

Using the command line is both frustrating and confidence inspiring. You get the feeling you are really interacting with the environment. The abstraction of GUI’s has made many people feel that they “understand” computers, but the reality is not that simple.

I grew up using CP/M, DOS, and even did some time on a VAX 11/750 mini-computer. As a result I’m comfortable with basic aspects of the command line. But as I’ve been delving into development I’ve seen command lines that I’ve had to use and have simply cut and paste them without being entirely sure what they do or how they do it.

The classic was grep. I was always fascinated by what it was doing, and how it was so often used in combination with pipes or redirects. Prior to this I never really had a reason to use it. Since we do so much work with text and files, I see how useful it can be.

In other news I did some fiddling with the blog and added a twitter feed for a list of Rubyists that I follow. Check it out in the sidebar to the right.

Thanx for reading. Stay tuned for more from the front lines…

This blog was created using the Octopress blogging framework. I tell you this for several reasons:

1. Because one should give credit for other people’s work.
2. Expect the site to change as I learn how to modify it.
3. Expect the site to break as I learn how to modify it.

The first major hurdle I had, and I suspect my fellow aspiring Web-Belt Jrs had it as well, was getting the blog to deploy using the Github Pages hosting service.

The Octopress documentation does cover this process, but the workflow for the newly minted web-dev can be a bit overwhelming. There’s a lot of stuff happening with git at the command line that may seem unfamiliar. Having said that I’ll throw my $0.02 worth of advice into the ring, and see if I can’t make it easier for anyone reading this.

Set up your username.github.io repo

Go to your github home page and click on the button labeled “New Repository” on the right side of the screen.

On the next page enter the name of the repo, in the form username.github.io where username is YOUR github user ID.

Enter an optional description if you wish and click on the green “Create Repository” button.

The next page will show you the setup for your repo, and the repo name. Make sure that the SSH button is selected and copy the address in the box to your clipboard, you will need it for the next step. It will be in the form git@github.com:username/username.github.io.git

Note: It can take github several minutes to setup your username.git.io page. If you get a 404 error, just go do something else for a little while, and then come back and try again.

Set up your Octopress code base to deploy to github.io

Switch to your terminal program and cd into your octopress directory, and then run the rake setup_github_pages

For my fellow DaVinci Coder’s that would be:

1
2

cd ~/workspace/octopress
rake setup_github_pages

It will ask you for the repo name you copied in the last step. Enter it and continue. When the rake job is finished your local repository will have been set up via series of git commands to push your blog code to your username.github.io page.

The next step is to actually publish the blog.

Workflow for publishing your blog entries

The workflow goes like this:

1
2
3

rake new_post["title"]    # Create a new post.
rake generate             # Generate your blog.
rake deploy               # Deploy (duh!) your blog.

When you deploy you will see a lot of code go scrolling up the screen. This is git committing and pushing the _deploy folder to the master branch of your repo.

Go check out your published blog at: username.github.io.

Also, don’t forget to commit and save your changes, using the standard git workflow:

1
2
3

git add .
git commit -m 'your message'
git push origin source

Just repeat the process to add new posts and publish them.

For more detail on the process see the first link, and for direction in automating the workflow even further see the second link.

From Octopress: Deploying to Github Pages

From Kevin van Zonneveld: Blog with Octopress and Github pages

Thanx for reading. Stay tuned for more from the front lines…

I have just started at the DaVinci Coders “Building the tool-belt of a junior Ruby on Rails Developer” program. An eleven week immersion course designed to take someone with good computer skills and minimal or dated programming experience into the fast moving world of web-development.

Part of our first assignment was to generate this blog, and then to write about our experiences, and the technical and other things that we stumble upon.

Here is my first observation: There is danger in having choices.

This is particularly true in choices for web development environments. It is even more perilous when you are a student in a web development course.

In my case, for various reasons, I had spent the prior two months teaching myself as much as possible about Ruby and Rails so that I would not feel out of my depth in the level II class I was assessed into at DaVinci Coders.

Like most folks, I took the standard path to a working Ruby install, and for a while I used RVM like everybody else. However, for various philosophical, and other reasons I decided to start using rbenv instead.

(For insight into this, see my earlier post. I was an Atari man, after all…)

rbenv takes a more lightweight approach to managing Ruby installs, holding to the Unix tenet of “do one thing well.” Unlike RVM it does not have a concept of gemsets. Instead it relies heavily on another standard of Ruby development: Bundler.

The bundler gem is pure genius, in that it manages gem install and dependencies almost by magic. Bundler takes it cue from the Gemfile that should be configured in each project directory.

So what’s the problem? Isolation, and then duplication of effort.

RVM does an excellent job, via gemsets, of isolating a development environment from other versions of Ruby and associated gems from other projects. Like Bundler, RVM manages various paths to executable gems by some serious techno-magic.

To make sure that project specific gems are run in the context of their gemset or gemfile, you typically need to call a command like this:

1
2

$ bundle exec rake db:migrate, # or
$ bundle exec rspec spec/ 

Even with RVM installed you need to pay the “bundle exec” keystroke tax, just to be sure you are running your code in the right environment.

There are ways to avoid this, you can install bin stubs for your gems and other executables or you can do some clever $PATH editing on a per project basis.

Seems to me like RVM and Bundler are sort of doing some of the same work, which certainly seems to violate the DRY coding principle, “Don’t Repeat Yourself.”

What’s the solution? Blindingly simple: make an alias in your login profile. Oh, and stop using gemsets, since you don’t really need them.

In either .bashrc or .bash_profile simply add the following:

1
2

# an alias to run 'bundle exec'
alias bex='bundle exec'

Now you can type the keystroke efficient bex before any command and be sure it is running in the proper context of your application directory. It rapidly becomes second nature.

I have to give a nod to Michael Hartl and his Ruby on Rails Tutorial, since he proposes this exact solution. However I had seen it before in several other contexts but did not know how or why to take advantage of it.

Additionally, you now know how to create an alias for other often used commands, or for applications with awkward names. For instance subl for the Sublime Text 2 editor:

1
2

# subl runs Sublime Text
alias subl='/Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl'

Lastly, I have to add that in exploring how RVM, rbenv, and Bundler function I also learnt an incredible amount about how things work “behind the curtain.”

I believe this is essential to problem solving. It is not enough to know that things work, you have to understand the how and the why.

For even more on Bundler and gemsets, check out this Ruby Rogues Podcast.

Thanx for reading. Stay tuned for more from the front lines…

A: an individual whose teenage exposure to computing consisted of a plethora of home computers based on the venerable 6502 CPU. This would include, but not be limited to: Commodore VIC-20 or 64, the Texas Instruments TI series, the Apple II (+, e, c), and the Atari 400/800.

If your parents only saw fit to buy you one of the Radio Shack TRS models you have my sympathy.

You likely saw the movie “War Games” in the movie theater when it was first released, but your parents probably had to drive you there. Give yourself extra credit for admitting to having a crush on Ally Sheedy’s character.

Most of my friends were Apple fanboys. I myself trod a different path, and was an Atari man. These were the heady days of home computing, where 48K of RAM, 1.8 MHz clock-speeds and 1200 baud dial-up modems were bleeding edge technology.

If you cut your teeth on these 8-bit machines, then you, too, are a veteran of the 8-bit wars.

While the first hackers came from the mainframed halls of academia (e.g. MIT), the second wave began on these machines. If you got your start on Intel x86 hardware you are not, by definition, an 8-bit Veteran.

P.S. If you had an Amiga or an Atari ST, you have taken a different path, one worthy of particular awe…

For more on the 6502 chipset see this Wikipedia Entry