PEAR not installed by default on Snow Leopard and later

In OSX Snow Leopard and later pear isn't installed by default. The installer is already available to you though.

sudo php /usr/lib/php/install-pear-nozlib.phar
pear config-set php_ini /private/etc/php.ini
pecl config-set php_ini /private/etc/php.ini
sudo pear upgrade-all

If you're using php for the first time on osx you may also need to copy this config file into existance.
(normally I'd use vim but to not explain vim we're using nano here)
sudo nano /private/etc/apache2/httpd.conf
Delete the # from the line that reads:
#LoadModule php5_module libexec/apache2/libphp5.so


cd /private/etc
sudo cp php.ini.default php.ini


And since you're already messing with PEAR, we really should take full advantage of this opportunity to install PHPUnit.

sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover components.ez.no
sudo pear channel-discover pear.symfony-project.com
sudo pear install phpunit/PHPUnit

If you have issues running phpunit a common cause is a misconfigured php.ini where the include path needs to be updated to:

include_path = ".:/usr/lib/php:/usr/lib/php/pear"

Adding a mime type to IIS vis powershell

You must have the WebAdministration snappin or module loaded (this should come as part of the IIS install) then simply:

add-webconfigurationproperty //staticContent -name collection -value @{fileExtension='.otf'; mimeType='application/octet-stream'}

Solving permissions problems where IIS Application Pool cannot read a file.

Occasionally when setting up a new site in a host environment you'll run across an error like: "Cannot read configuration file due to insufficient permissions"

Sometimes all you need to do is add security permissions for IIS_IUSRS to read the directory, I've also needed to grant the application pool user permissions before.

To see the application pool user you need to do something similar to the following command.


icacls C:\inetpub\wwwroot\mysite\ /grant:r "IIS APPPOOL\defaultapppool":(OI)(CI)(RX)

Then when we check the security settings, yay we have the option to grant more permissions.

More information about icacls:
http://ss64.com/nt/icacls.html
http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx

Getting started with Git on Windows

For those completely unfamiliar with what Git is/does. Git is a source control / revision control management program.  More specifically it is a Distributed Version Control System.  If you’re used to using Subversion or Team Foundation Server, you’re used to having to create a repository on a server, then check out that repository, then commit your changes back to the server.  The key difference with distributed version control is that you get your whole project history sitting on your PC, and you can commit local changes before sending it all back to the central server(if you’re using one).  You’ll also notice that Git much better at merging, and wickedly fast.

 

In this post we’re going to do 5(ish) things:

1. Install Git Extensions and its dependencies
2. Create our public and private keys
3. Download a repository from Github
4. Commit a change back to Github

First go out and download the necessary installer from: http://code.google.com/p/gitextensions/downloads/list

Download the latest version and run it.  If you hammer the next key you’ll end up where you probably want to be, but I personally make two changes.

 

Installing MsysGit and KDiff.  You can change your diff tool later or choose not to use KDiff at all.

 

 

 

 

The next few are only for KDiff installer

 

 

 

 

KDiff Ends here, might want to uncheck Show Readme

MSys Begins

 

 

 

This scree asking you to modify your PATH environment variable is important.  If you already have a lot of batch script and rely upon some of the basic windows command line utilities this could be dangerous.  If you don’t do that already just install all of the msys utilities to your windows path and enjoy finally having some of the utilities linux/unix/mac/cygwin users have had for years.  (Or play it safe and don’t, personally I like to run with scissors here because I <3 grep and curl)

 

Here you can change the format of you line endings when you check in code.  Check them in as unix and check out as windows.  When everyone does this it makes for a much more happy windows/mac together in peace kind of thing.

 

Yay msys is complete, don’t view the readme and get back to the Git extensions installer.

Git extensions is complete, now lets open it and get some authentication setup.

 

A quick note about authentication:

We’re showing an example of using github here, so we’ll be using public keys for authentication.  You aren’t forced to use public keys with all git server configurations, but using them is a bit more secure since it requires the machine you’re using to have your private key.

 

Onward to configuring git extensions:

Open up gitextensions.

You should be greeted by a settings dialog asking you to configure diff/merge tools etc, if you installed KDiff and used Putty you should only see the username and email address message. Click Repair.

Fill in your username and email address. And make sure the line endings setting is correct.

Click OK.

On this main Git Extensions screen(if you see a cow you’re in the right place) click Remotes then Putty then Generate or Import Key.  This will pop up the PuTTY Key Generator window.

Click Generate.

Move your mouse around until the green bar fills in then goes away.

There are three things to do on this screen.  First is type in a “passphrase”.  This phrase is used to add a password to your keys so that just having your key files is not enough for someone to present themselves as you.  Don’t worry you won’t have to type this every commit, but you will want to remember it.

Once you’ve typed you passphrase and confirmed it, you want to save your public and private keys by clicking those two buttons.

The default save location is in C:\Program Files(x86)\GitExtensions\, I personally don’t like this and I move the location to my own user directory C:\Users\Seth\.  For this example I’m going to name my key seth@brocksamsonPuttyKey  which is [username]@[hostname]PuttyKey.

Save the file and we’re brought back to the key generator, click Save Private Key and it should open whatever folder you saved the public key to(C:\Users\Seth\ in my example).

Enter the same filename that you did for the public key, but add .ppk to signify that this is a putty private key.

Click the X or alt-f4 out of the generator, we’re done with it.  Now its time to add our keys to the PuTTY Authentication Agent. 

Click the Remotes Menu, then PuTTy, then Start authentication agent.

This will start up the agent and you should see it running in the task bar tray by your clock.

 

Right click on that little guy.

 

Click “Add Key” (I took to long adding this screenshot so my tray icon hid)

This defaults us back to the Git Extensions folder in Program Files, go to wherever you stored your private key and choose that file then click open.

This will ask you for your passphrase assuming you entered on

Type in your passphrase and click OK and you should be back to the default Git Extensions Screen.  It seems like that was a lot of configuration, but in the long run using keys will save you a decent amount of time with how often you’ll be committing.

Cloning the first repository

I’ve already have set up a github.com user and uploaded my public key to it.  This example uses github, but the steps apply to any git repository.

On the main Git Extension screen

Click “Clone Repository”

Fill in the repository location and this will auto-fill your Subdirectory to Create.  Fill in the Destination, and name the branch master.

Click Clone

The checkmark in a green circle means "Great Success” so we can continue.  If you’re interested the git commands used to accomplish this task are displayed.  A dialog opens telling you that we’ve cloned successfully and presents the option to open the repository in git extensions now.

Click yes

At this point we want to go make a change on the file system so that we have something to commit.  Go to the directory that you clone the repository (C:\gitRepos\Documentation-Demonstration in this example) and create a text file.  I’m creating a file named “Dummy Text.txt”.

Once you’ve created that text file click “Commit”

Click “Stage” to prepare your file for commit, and enter a commit message.  Staging files is probably a new concept if you haven’t worked with a DVCS before.

Click “Commit” to commit your file.

 

You should get another green circled checkmark of goodness.  In my screenshot I do have some missing configuration examples due to some reconfig I did midway through this post, but git is nice enough to tell me how to fix it if I want.

So now that the file is committed we could go see it out on github since that’s where we cloned from right?

So the key difference on distributed version control systems is that commit is a local thing.  When you commit you’re saying “Hey I did some stuff that’s important”.  You want very small granular commits so that if something you do causes a problem later you can remove just that single commits change set, or so that you can get a nice small patch without having to weed through lots of crap to make it.

But in this case we do want to push our changes out to the server we’re using.  Guess what the name of the command to push our changes out is?  Yup, its Push.

Back on our Git Extensions main screen you can see a menu called commands.

Click “Push”

Quick concept here, remotes are Git repos external to your local machine.  The remote that you clone from is by default named origin.  You can push multiple branches to a remote, most people use master as the branch that always travels.  In some cases you’ll have master, integration, and feature branches.  If you want a backup of a branch you’re working on to exist outside of your machine push it to a remote.

Since we want to push to origin, click “Push”

Since the repo we’re pushing to is empty even master is a new branch.  Click “Yes”

Since we see the happy green checkmark we know things worked.  We can now see that [master] and [origin/master] are at the same point in the Git Extensions GUI.

In case you don’t believe that, you can look out on Github and see the changes as well.

 

So that’s the basic “Clone, commit, push” process using Git extensions.  In a real project we’d have branched from master, and worked in our branch then merge the changes back to master, but for the intro to the tool we’re skipping those steps.  Play around with it and read a bit to figure out what you want your personal workflow to be.  I’ll put out some more step by steps depending on requests.  This post is freakishly long, but really the steps we cover only take 15-20 minutes to actually do, and even faster if you choose to learn command line over GUI tools.