Cole on Software

I get into this situation every time I set up a new server:

git st git: ‘st’ is not a git command. See ‘git --help’.

So I end up running this: 

git config --global alias.co checkout && git config --global alias.br branch && git config --global alias.st status && git config --global color.ui always

I’m currently reading Jeff Atwood’s book Effective Programming: More Than Writing Code. It was only $4.60 on the Kindle marketplace. I see now why the price is so low: The book is his blog, just organized into sections. I’m not complaining, it’s a great book. 

In any case, the book has a section on phone interviewing and which questions to ask. They aren’t stupid questions like “why are manhole covers round”. What does that really tell you about an interviewee anyway? Oh yeah, they can bullshit. I’m not downplaying the grand art of BS’ing, it’s a useful skill, but it doesn’t tell you anything about the interviewee’s programming skills. The seven questions recommended by Mr. Atwood are:

Write a function to reverse a string.

Get the nth fibonacci number.

Print out the grade school multiplication table up to 12x12.

Write a function to sum the integers from a text file. One int per line.

Print out the odd numbers 1 - 99.

Find the largest value in an array of integers.

Format an RGB value as a six digit hexadecimal string.

The one that grabbed me was the fibonacci sequence. It seemed like something every programmer should know, including me. So here it is in javascript:

function getNthFibNum(n) {   var fib = [0, 1];   

   for (var i = 2; i <= n; ++i) {      fib[i] = (fib[i-1] + fib[i-2]);   }   

   return fib[n]; }

More info on the fibonacci sequence.

I recently installed CentOS 7 on my desktop at home. These are my notes:

Download NetInstall ISO 

I just chose the first mirror from the official download page.

http://mirror.cc.columbia.edu/pub/linux/centos/7.0.1406/isos/x86_64/

Create bootable USB:

I used the following tutorial which makes use of the hdutil command:

http://www.myiphoneadventure.com/os-x/create-a-bootable-centos-usb-drive-with-a-mac-os-x

I did give uNetBootin a try, but couldn't get it to work. Too bad too. It has a list of ISOs for many different distros which would allowed me to skip step #1.

Change BIOS of drive to boot from USB.

This is different for every mobo, but usually it requires you hit a key during the load screen, f12 is common, mine requires the delete key to access the bios settings.

Pick an installation source

Once you get to the installation screen, you need to choose an installation source. This is the link I used for CentOS 7:

http://mirror.centos.org/centos/7/os/x86_64/

I love working with Git. It's an essential tool in every coder's toolbox. My interface of choice for Git is good ol' fashioned command line. Working on the command line saves a lot of time over alternatives like Tortise Git or Source Tree. One thing that I do miss about having a Git GUI is the ability to do bulk operations. Say, for example, removing multiple topic branches or deleting deprecated or incorrect tags. Git does not make it easy to do these operations in bulk.

Enter Xargs and Sed. Xargs is a program that allows the user to dynamically feed in a list of arguments to a command. This could be from a file or stdout. Usually a little massaging is needed to make another program's output into a useful argument. This is a job for Sed. Sed takes stdout and performs search and replace operations.

The power of Sed lies in its ability to perform operations on output streams. By output streams I mean any program that writes to stdout. A file also works.  And when Sed combines with Xargs, the possibilities are virtually endless. Take deleting a remote tag, for example. Git provides an easy way to do this:

git push :refs/tags/[tag name]

This is fine and dandy if you only have a few tags to remove. But if it's anything more, things can get really tedious really quick. With Sed and Xargs, this task becomes trivial:

git ls-remote --tags origin | sed -E 's/[a-z0-9]+ +/\:/g' | xargs git push origin

So something like this:

3413b1c452a529082c66bcab9d0374352304e59a refs/tags/1.0

Turns into this:

git push origin :refs/tags/1.0

It's a little tough to wrap your head around at first. The weirdest part, I think, is the last part of the final command 'xargs git push origin'. The final argument to this command is being injected by Xargs from the Sed command that came before it.

One thing to know about Sed is that it makes heavy use of regular expressions. If you don't know about regular expressions, learn them now! Don't sleep! They're something every developer should know and will save you a ton of time. RegexOne.com is a great place to get started.

If you're reading the output from a file, try something like this:

while read line; do echo -e "$line" | sed -E 's/[a-z0-9]+.+refs\/tags\//:refs\/tags\//g' | xargs git push origin ; done < [file name]

PHP Composer is a great way to share libraries with... just about anyone. If you have code you'd like to keep private, however, Composer doesn't cater to that. Packagist, Composer's primary repository, only hosts public packages. The Composer docs have some recommended practices for hosting your own private packages. This post will walk through the steps required to set up your own private composer repository:

1. Get composer. Here is how to install it on *nix system. For other OS'es, check out the Composer installation docs  

curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer

2. Download and install Satis. Satis is a static, lightweight tool for generating a Composer repository. There are other options, but Satis seems to be the quickest way to get up and running. Please note that if you installed composer globally you can omit the 'php composer.phar'part and replace it with 'composer'

php composer.phar create-project composer/satis --stability=dev --keep-vcs

3. Create a satis config file. This lists out all of the packages that your repository has available.  **Important** Each package you want to have in your repository must have a composer.json file located at the document root (see below)

Options Breakdown

require-all: this option tells the repository to focus on all versions and branches of your package. Alternately you can definea 'require' property that will focus on specific versions for each repository

repositories.type: This is the package type. VCS stands for Version Control System. This is the best type to use for, you guessed it, packages under version control such as git or svn. See the Composer documentation about repository types for more info.

satis-config.json for defining a repository

{ "name": "My Repository", "homepage": "[home page url]", "repositories": [ //FORMAT 1 { "type": "vcs", "url": "[http://host.com]/[namespace (usually company name)]/[repo name]" }, //FORMAT 2 { "type": "vcs", "url": "[user]@[host.com]:[namespace (usually company name)]/[repo name]" }, ], "require-all": true }

Composer.json for defining packages

{ "name": "project-namespace-or-company-name/project-name", "description": "Package description!", "version": "0.3.0", "type": "library", "require": { "monolog/monolog": "1.0.*", "joli/ternel": "@dev", "acme/foo": "dev-master" }, "require-dev": { "debug/dev-only": "1.0.*" } }

4. Create the repository. In this step, Satis creates all the files needed for a Composer repository and scans the packages you defined in config file (step 3). The build dir referenced below is an empty directory with a name of your choosing. It's just a place to hold the files generated by Satis. I usually move the config file into the build dir after I created it (just to keep everything in one place).

mkdir [build dir] cd [satis dir] php bin/satis build [path to config file you created in step 3] [build dir]

5. Keep the pacckage details fresh. Composer does not automatically fetch new package details, so you need to set up a cron process to keep the package definitions up-to-date (this is the same command ran to build the repository in step 3).

This step is important because it pulls in new code, branches, and tags. I recommend running this script no less than every hour, but this depends on how often your packages are updated. If you are rusty on your crontab syntax, take a peak at the crontab documentation (this will likely require root access to your server).

php [absolute path to satis]/bin/satis build [absolute path to config file] [path to build dir]

6. That's it! You now have a private composer repository.

7. Make the repository accessible. If you are planning to share the repository with your team members, it needs to be available online. This can be set up like your basic virtual host. Once this is done, restart apache and add a new repository entry to your composer.json (see snippet at bottom).

Usage

To use the packages in your repository, you need to add them as dependencies in the composer.json file in your project. See documentation for composer.json or example below:

Composer.json for requiring packages

{ "repositories": [{ "type": "composer", "url": "[URL to repository]" }], "require": { "package1-namespace/package1-name": "1.0.0", "package2-namespace/package2-name": "1.0.1" }, "minimum-stability": "dev" }

Update

Method #1 (adding the full git path directly to the bower.json file) does NOT play nice with Cygwin on Windows. The error is:

ENOTFOUND No package found

There seems to be nothing wrong with the SSH key auth. I confirmed this by looking at the log (/var/log/secure). Will update if solution found.

-------------------------------------------------------------

The coding community is incredibly generous. Almost everything is shared. Many of the packages we use to make our daily lives easier are open source and for everyone. These are the building blocks that make up the houses that are our projects. The building blocks are free, but the houses are usually proprietary. Many times though, this proprietary code is reusable and needs to be distributed within an organization. Today I'm going to review the options available for private distribution of javascript packages:

Bower, which is a package manager for javascript, is a great solution built exactly for this purpose. The default visibility for all packages in Bower is public. BUT WAIT! There's more! The official Bower site requires that all registered packages be hosted on Github and that if you want to distribute a private package that you shouldn't use their registry. And that's fine, it's their right to ask such things. The great thing about Bower is that you don't actually have to register a package to be able to use it. Here's how:

1. Add the source directly into your bower.json. Bower can take any source that points to a git repository. Here are some examples of possible formats:

HTTP: "git://[host.com]/[username]/[repo name].git#[version]"

SSH: "[username]@[host.com]:[repo name].git#[version]" This is similar to the 'git clone' command and works well for key or password protected repos.

The version number can reference either a tag or a branch. Just make sure to push your tags (git push origin --tags)

So, a the full bower.json would look like this:

{ "dependencies": { //STANDARD "package" : "1.0", //HTTP "package1": "git://host.com/username/repo-name.git#1.0", //SSH "package2": "[email protected]:repo-name.git#1.0" } }

2. Another option is to host your own private bower registry. This sounds intimidating, but is relatively simple to set up. There are many Node packages that help with this task. The one I used is called private-bower. Here are some prerequisites for using private-bower:

Node/NPM installed. Npm is required to install private-bower package.

Open port 5678 or 7891. The server listens on either of those ports (5678 by default). 

Here are the steps to set up the private-bower Node server:

<code> npm install private-bower</code>

Create the private-bower config file.. You can leave all of the defaults. The only file that needs to be updated is the bowerRegistry.json file. This is the main file that tells the registry which packages it serves. See example at bottom.

Start the server: private-bower --config [path to config.json]

Update your .bowerrc to point to the new registry by adding . This is the file that bower uses to configure high-level options. See .bowerrc config file docs for details. 

The final step is to make the server publically available. This is not a step I completed, so I will leave it up to you and Google to figure this one out. This article How to make a Node web server publicly accessible serves as a good starting point.

bowerRegistry.json example