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:
If you get the following then it is installed, go to step 3:
2: Then you need to install and configure it with:
# Download the filecurl-s-O\http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain# Fix the permissionschmodu+xgit-credential-osxkeychain# Move it to the right path, sudo may require your password.sudomvgit-credential-osxkeychain\"$(dirname $(which git))/git-credential-osxkeychain"
3: Lastly, modify your git config file to use the helper:
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…
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
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:
Because one should give credit for other people’s work.
Expect the site to change as I learn how to modify it.
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
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 email@example.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:
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:
rakenew_post["title"]# Create a new post.rakegenerate# Generate your blog.rakedeploy# 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.
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:
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:
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:
# an alias to run 'bundle exec'aliasbex='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:
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…