Skip to content

Bulk ammending commit messages in git

At my job I’m using git-p4 to work locally with some rails code in git and push to perforce. It’s working okay but one issue for me is that we require every commit to perforce to have a code review by someone, and we put the reviewer’s name at the bottom of each commit. For example:

Live changes to histograms
-commonized the histograms views & logic

CR: JamesM

Well when I’m working in the git repo, I don’t know who is going to code review it, so I end up having to add CR: JamesM to several commits. It can be done with rebase -i, but it is several steps per commit. I could use git-notes, but that doesn’t follow the format that we like (it puts Notes: in). Because this is a local repo only, changing the commit history is not a big deal. After some searching I found the way:

git filter-branch --msg-filter 'cat && echo "CR: REVIEWER"' p4/master~1..HEAD

This little beauty will append CR: REVIEWER to all of the commits from the master to the current head (all of the local commits).

CloudFront Invalidation from Ruby

Since none of the examples that I could find on the internet of how to invalidate a cloudfront asset in ruby were correct, I decided to post my solution:

require 'rubygems' # may not be needed
require 'openssl'
require 'digest/sha1'
require 'net/https'
require 'base64'

class CloudfrontInvalidator

	def initialize(aws_account, aws_secret, distribution)
		@aws_account = aws_account
		@aws_secret = aws_secret
		@distribution = distribution
	end

	def invalidate(path)
		date = Time.now.strftime("%a, %d %b %Y %H:%M:%S %Z")
		digest = Base64.encode64(OpenSSL::HMAC.digest(OpenSSL::Digest::Digest.new('sha1'), @aws_secret, date)).strip
		uri = URI.parse("https://cloudfront.amazonaws.com/2010-08-01/distribution/#{@distribution}/invalidation")

		req = Net::HTTP::Post.new(uri.path)
		req.initialize_http_header({
		  'x-amz-date' => date,
		  'Content-Type' => 'text/xml',
		  'Authorization' => "AWS %s:%s" % [@aws_account, digest]
		})
		req.body = %|<InvalidationBatch><Path>#{path}</Path><CallerReference>SOMETHING_SPECIAL_#{Time.now.utc.to_i}</CallerReference></InvalidationBatch>|
		http = Net::HTTP.new(uri.host, uri.port)
		http.use_ssl = true
		http.verify_mode = OpenSSL::SSL::VERIFY_NONE
		res = http.request(req)

		# it was successful if response code was a 201
		return res.code == '201'
	end
end

Then just run it with:

puts CloudfrontInvalidator.new('ACCOUNT', 'SECRET', 'DISTRIBUTION').invalidate('PATH_TO_FILE')

Simplicity Itself

I just wanted to share what it took to draw a simple yellow triangle on a black background in OpenGL|ES. I hope it will give my Ruby friends and Haskell friends an aneurysm.

To show this:
Hello Triangle

I had to do this:

//The headers
#include <SDL/SDL.h>
#include <SDL/SDL_opengles.h>

//Screen attributes
const int SCREEN_WIDTH = 480;
const int SCREEN_HEIGHT = 320;
const int SCREEN_BPP = 32;

SDL_Event event;
GLuint programObject;

GLuint LoadShader ( GLenum type, const char *shaderSrc )
{
   GLuint shader;
   GLint compiled;

   // Create the shader object
   shader = glCreateShader ( type );

   if ( shader == 0 )
   	return 0;

   // Load the shader source
   glShaderSource ( shader, 1, &amp;amp;amp;amp;amp;shaderSrc, NULL );

   // Compile the shader
   glCompileShader ( shader );

   // Check the compile status
   glGetShaderiv ( shader, GL_COMPILE_STATUS, &amp;amp;amp;amp;amp;compiled );

   return shader;

}

bool init_GL() {

	const char* vShaderStr = "attribute vec4 vPosition;    \n"
		"void main()                  \n"
		"{                            \n"
		"   gl_Position = vPosition;  \n"
		"}                            \n";

	const char* fShaderStr = "precision mediump float;\n"
		"void main()                                  \n"
		"{                                            \n"
		"  gl_FragColor = vec4 ( 1.0, 1.0, 0.0, 1.0 );\n"
		"}                                            \n";

	GLuint vertexShader;
	GLuint fragmentShader;
	GLint linked;

	// Load the vertex/fragment shaders
	vertexShader = LoadShader(GL_VERTEX_SHADER, vShaderStr);
	fragmentShader = LoadShader(GL_FRAGMENT_SHADER, fShaderStr);

	// Create the program object
	programObject = glCreateProgram();

	if (programObject == 0)
		return 0;

	glAttachShader(programObject, vertexShader);
	glAttachShader(programObject, fragmentShader);

	// Bind vPosition to attribute 0
	glBindAttribLocation(programObject, 0, "vPosition");

	// Link the program
	glLinkProgram(programObject);

	// Check the link status
	glGetProgramiv(programObject, GL_LINK_STATUS, &amp;amp;amp;amp;amp;linked);

	glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
	return true;
}

bool init() {
	//Initialize SDL
	if (SDL_Init(SDL_INIT_EVERYTHING) < 0) {
//		return false;
	}

	//Create Window
	if (SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_OPENGL)
			== NULL) {
		return false;
	}

	//Initialize OpenGL
	if (init_GL() == false) {
		return false;
	}

	//Set caption
	SDL_WM_SetCaption("OpenGL Test", NULL);

	return true;
}

void clean_up() {
	//Quit SDL
	SDL_Quit();
}

void Draw() {
	GLfloat vVertices[] = { 0.0f, 0.5f, 0.0f, -0.5f, -0.5f, 0.0f, 0.5f, -0.5f,
			0.0f };

	// Set the viewport
	glViewport(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);

	// Clear the color buffer
	glClear(GL_COLOR_BUFFER_BIT);

	// Use the program object
	glUseProgram(programObject);

	// Load the vertex data
	glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, vVertices);
	glEnableVertexAttribArray(0);

	glDrawArrays(GL_TRIANGLES, 0, 3);
}

int main(int argc, char *argv[]) {
	//Quit flag
	bool quit = false;

	//Initialize
	if (init() == false) {
		return 1;
	}

	//Wait for user exit
	while (quit == false) {

		//While there are events to handle
		while (SDL_PollEvent(&amp;amp;amp;amp;amp;event)) {
			//Handle key presses

			if (event.type == SDL_QUIT) {
				quit = true;
			}
		}
		Draw();
		SDL_GL_SwapBuffers();
	}

	//Clean up
	clean_up();

	return 0;
}

You will all be happy to know that one of the first things I did (after re-learning make) was dive into google test and get a testing framework working. My last several projects have been with Ruby and Java, and in my spare time I have been building Palm Pre apps in Javascript and messing around with Erlang.

So I thought it was funny that many of my friends have been going to more and more abstract languages, while I, oddly, have decided to go lower. I have been playing around with doing OpenGL|ES and C++ lately in my spare time, hopefully in prep of the release of the Native SDK (PDK) for the Palm Pre.

updating embedded jruby gems with ant

Recently I have been using cuke4duke on a java project (which I’ll discuss in a later article). We have jruby running from jruby-lib/jruby-complete.jar. Our gems are embedded in the project with the GEM_HOME/GEM_PATH being set to jruby-lib/gems. All of this is under source control. We don’t have jruby installed at all on the system, it is only in this project. I’ve mainly been the one on the team (of 4 total) who has been maintaining the jruby stuff as none of the other devs have jruby experience.

So one of the problems I had recently was how to update the gems that are checked into source. One of the other devs wanted to use multi-line strings in cucumber and found that it didn’t work with cuke4duke until cucumber-0.4.4. We had 0.4.2. So what I needed was an easy way for the other devs to be able to update the gems without relying on jruby being “installed” on the machine. Since these are java guys, ant seemed the best solution.

Here is the ant task I used:

<path id="jruby.classpath">
	<fileset dir="jruby-lib">
		<include name="**/*.jar" />
		<exclude name="gems/*" />
	</fileset>
</path>
<target name="update.gems" description="update the installed gems">
	<!-- this updates the gems on the system -->
	<java classname="org.jruby.Main" fork="true" failonerror="true">
		<classpath refid="jruby.classpath" />
		<env key="GEM_PATH" value="jruby-lib/gems" />
		<env key="GEM_HOME" value="jruby-lib/gems" />
		<arg value="-S" />
		<arg value="gem" />
		<arg value="update" />
	</java>
	<!-- this removes any obsoleted / previous version of all gems -->
	<java classname="org.jruby.Main" fork="true" failonerror="true">
		<classpath refid="jruby.classpath" />
		<env key="GEM_PATH" value="jruby-lib/gems" />
		<env key="GEM_HOME" value="jruby-lib/gems" />
		<arg value="-S" />
		<arg value="gem" />
		<arg value="cleanup" />
	</java>
</target>

Testing WebOS Applications Made Easy with jasmine_webos gem

TDD for WebOS applications is still in its early stages, but the guys over at Pivotal Labs have made some great strides in the low level tooling. The Jasmine javascript testing framework provides a dom-less testing implementation which works well in the MVC environment of a WebOS application.

Pivotal is also hard at work at Pockets (not yet released) which provides on emulator testing and integration of Jasmine into your WebOS application. However, as of now (2009/09/21), this has not been released owing to major changes in the debuging environment in the WebOS SDK.

To help with the transition, I have released my initial version of jasmine_webos, which facilitates testing your webos application with Jasmine. Jasmine_webos requires ruby and rubygems as well as the json and thin gems. To install jasmine_webos, simply do:

sudo gem source -a http://gemcutter.org
sudo gem install jasmine_webos

Jasmine_webos provides a generator to create the directories it expects (spec/javascript/spec and spec/javascript/matchers) as well as an example spec so that you can make sure that it is working. This is accessed by running the following from the root of your WebOS Application:
jasmine_webos -g

You can then run the test server (dynamically builds up suites for testing) with:
jasmine_webos -s. You can then run your tests by hitting http://localhost:8888 with any capable browser.

Jasmine_webos server will include any javascript files in your app directory, all matchers in your spec/javascript/matchers, and all tests in your spec/javascript/spec folder. Jasmine_webos keeps the jasmine files contained in the gem so that as new features for jasmine are released, you can get easy access to them by updating the gem. This also keeps you from having to copy jasmine into each of your apps.

In the future I am looking at implementing:
* A config file for additional directories and requirements
* celerity for command line testing / integrated builds
* including mojo framework libraries for fuller stack testing.

Please report any bugs to the github bugs page.

Announcing Mainline

Mainline is a rails plugin which exposes your rails app via webrick to allow
testing with browser automators such as Selenium or Watir. Mainline allows
your rails actions to run in the same transaction as your unit tests so you
can use fixtures, factories, or whatever.

Basically you can now test selenium in your same transaction and don’t have to worry about rolling back your fixtures or factories.

Grab it from Github
Bug Reports at Lighthouse
Docs at RDocul.us

Making your Plugin or Gem configurable

Recently I added a configuration mechanism to Webrat. It was surprisingly easy, and mainly copied from rails core. I would suggest adding somthing like this to any plugin that has more than a few features or ones that users have asked to have turned off.

First off you’re going to have to create the actual configuration object. There are a few good ways to do this. One is to use a config module, another is to create a configuration object that is accessible via a singleton method.

I’m going to go with the second one, a configuration object.

Toss this one in lib/configuration.rb (A simplification of Code | RDoc)

module Plugin

  # Configures Plugin.
  def self.configure(configuration = Plugin::Configuration.new)
    yield configuration if block_given?
    @@configuration = configuration
  end

  def self.configuration # :nodoc:
    @@configuration ||= Plugin::Configuration.new
  end

  # Plugin can be configured using the Plugin.configure method. For example:
  #
  #   Plugin.configure do |config|
  #     config.show_whiny_errors = false
  #   end
  class Configuration

    # Should whiny error messages be shown?
    attr_writer :show_whiny_errors

    def initialize # :nodoc:
      # set your defaults in here
      self.show_whiny_errors = true
      # put as much as you want in here
    end

    # some syntactic sugar for you, the coder
    def show_whiny_errors? #:nodoc:
      @show_whiny_erorrs ? true : false
    end

  end

end

Okay, now we need to test the config object itself. This is why it’s nice to make an object just to house the config, it’s easy to test. What do we test? Well defaults and accessors for two!

(The following lifted from Code) (sorry this is in rspec, it’s not hard to do in test::unit)

require File.expand_path(File.dirname(__FILE__) + '/../../spec_helper')

describe Plugin::Configuration do
  # define matchers for testing
  predicate_matchers[:show_whiny_errors] = :show_whiny_errors?

  it 'should show whiny errors by default' do
    config = Plugin::Configuration.new
    config.should show_whiny_errors?
  end

  it 'should be configurable with a block' do
    Plugin.configure do |config|
      config.show_whiny_errors = false
    end

    config = Plugin.configuration
    config.should_not show_whiny_errors?
  end

end

Now we need to do some stuff to make it nicer for our other users to test. Put the following in your test_helper or spec helper. It will allow you to clear your config after each test. Nice to have to to avoid messy test issues.

(The following lifted from Code)

module Plugin
  @@previous_config = nil

  def self.cache_config_for_test
    @@previous_config = Plugin.configuration.clone
  end

  def self.reset_for_test
    @@configuration = @@previous_config if @@previous_config
  end
end

# configure your test runner / spec runner to always clear the config
Spec::Runner.configure do |config|

  config.before :each do
    Plugin.cache_config_for_test
  end

  config.after :each do
    Plugin.reset_for_test
  end
end

This last bit is somewhat hard to do in test::unit as it is harder to hook into the setup (you only get one in the call chain). I’m willing to take some help on cleaning this one up for test::unit. Currently I have just been putting it in the setup / teardown for each test file.

Finally you need to make use of this in tests, fortunately that is quite easy. Just:

describe SomeObject do
    it 'it shouldn't do it when whiny nils are off' do
      Plugin.configure do |config|
        config.show_whiny_errors = false
      end
      object.should_not_receive(:log)

      object.do_somthing_that_usually_complains
    end
end

Finally, anywhere in your plugin that you think somthing is whiny, just check the config before using it like this:

log(&quot;you should really fix this&quot;) if Plugin.configuration.show_whiny_errors?

chicken and egg

I can’t believe this still hapens. Unzip software that is zipped. I was trying to unzip a file off of the web to install on my palm and they had zipped the 15k zip prc file to save those few extra bytes on the web making it impossible to actually download and use the software without a full computer.

Ugh.

generator_missing plugin release

I just posted my initial cut of my generator_missing plugin. This plugin is meant to be a repository of additional generators to help workflow. The current ones are:

  • Library: Generates a non active record ruby object and a test class.
    • lib/library_name.rb
    • test/unit/library_name_test.rb
  • Module: Generates a basic module under lib and its tests.
    • lib/module_name.rb
    • test/unit/module_name_test.rb, with a mock class that mixes in the library
  • Base Generator: Generates a generator (mmm meta) with a template, usage and manifest.
    • lib/generators/generator_name/generator_name_generator.rb
    • lib/generators/generator_name/USAGE
    • lib/generators/generator_name/templates

The plugin is at: http://github.com/gaffo/generator_missing / git://github.com/gaffo/generator_missing.git
Lighthouse at http://gaffo.lighthouseapp.com/projects/21321-generator_missing/overview.

I am currently taking both suggestions and pull requests for generators that should be added.

RDocul.us launch

I was tired of not having up to date docs for the rails gems and plugins that I use, so I created RDocul.us. Bascially, anyone is free to submit any github based rails plugin or gem and it will be kept up to date on RDocul.us. Once it’s approved it will be automatically updated within four hours of any commit to github.

Currently there is a delay for as I am manually vetting and configuring the libraries. Unfortunately not everyone is creating the .documentation file or using the same rake task (rdoc, doc, docs) or doc directory (rdoc, doc, docs) so I have to give it a quick once over.

Please let check it out and let me know what you think.