So, git pre-commit hooks are executable files (yes, you have to declare them as chmod +x - for some reason I forget this every time I write hooks) that are run right before you commit. This type of stuff lets you verify that your application is working, run a few tests, etc before it gets committed. At least the current use case I have (that probably illustrates the point of this particular hook fairly well) is related to this website. So, as I started working on this, I realized that categories are implmented as user plugins which aren't allowed by github-pages for security reasons. Since all I'm doing is generating a static website, that doesn't really matter as long as I copy the categories directory to the root, right? Why not automate that shit?

First I wrote a script "./run_extensions" with

#!/bin/bash
rvm use 1.9.2
bundle install
bundle exec ejekyll
cp -rf _site/categories .
git add .

not too surprising - I initialize rvm environment (I have that set in both bash and zsh shells that I use but it's better to be explicit), bundle install and bundle exec ejekyll commands install the dependencies declared in the Gemfile and then run the static website generation using Jekyll. Now that I have plugins goodness, I can copy the categories folder from _site and make sure everything is staged.

Now the next step would be to make the pre-commit hook itself. So, the pre-commit hook runs from the parent directory of .git folder itself and can be anything. I have a bash script. The location is .git/hooks/pre-commit

#!/bin/bash
./run_extensions.sh

after this, make sure to run chmod +x .git/hooks/pre-commit so that it's executable. From now all, each commit is going to generate all the necessary categories structure.

I wont try to justify PHP hacking but I was working on a project that's based on CodeIgniter. It's on a cycle of heavy refactoring. I was wondering if I could do something like

isset("variable_name");

similar to python

"variable_name" in globals() 

Same idea with locals() in python.

Thankfully, php has the equivalent of globals() being $GLOBALS which would return you all the variables declared so far. Now you can just write your own isset_varname(). get_defined_vars() is equivalent in php to locals(). in python.

<?php
function isset_varname($varname){
  return array_key_exists($varname, $GLOBALS);
}
$test= "test";
var_dump(isset_varname("test")); // should print bool(true)
var_dump(isset_varname("test2")); // should print bool(false)
?>

you'd probably need to check for the variable name regex and store output from get_defined_vars() in another place too. Of course, if there's some other similar function that anyone else knows about, I'd be happy to find out.

So, I've been thinking about this for a while and I finally decided to pull trigger on moving my site fully to github. Let's see where this goes. Also, I want to give a little intro on how to build a site like this (very bare-bones right now, I'm not very fancy).

Originally, nextdoorhacker.com was running on a Linode box that I owned since 2008 (summer of freshman year, oh the times), since I was doing a lot of PHP around then, I ran wordpress on it. Later on, I ran 4legs.org on it along with a wide-assortment of side projects. But wordpress tends to get really annoying to manage if someone isn't paying you to do it. For me, blogs have always been luxury. So signing in, writing some stuff in a textbox, obsessing over the typeface, getting annoyed over wordpress messing up the format and above all, keeping up with the security patches, new versions becomes work for a blog that probably total of two people ever read.

Mind you, I didn't start from scratch in moving the site. I took the basic style from flyerhzm.github.com and removed a lot of things from the site. So, it's not really a fork, just me being too lazy to write the stylesheets, pages from scratch again. Just FYI, if you're ever in the situation to take a git repository and making your own, you can just remove the .git folder and run git init again. Of course, you should only do this if you do have the rights, etc.

Creating new posts is just about running, of course after replacing blog_title with something else.

vim _posts/$(date +%Y-%m-%d-blog_title.markdown)

After that, it's just about writing Markdown files