To show this:

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.

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>

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.

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

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("you should really fix this") if Plugin.configuration.show_whiny_errors?

Ugh.

• 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.

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.

Say we have a named scope in our member object which looks like this:

class Member < ActiveRecord::Base
  named_scope :active, {:conditions => {:status => Member::STATUS_ACTIVE}}
end

There are 2 things we need to do to test them.

First would be to make sure that the conditions are the same as we think they are. This one is open for debate a bit as it is somewhat tying the implementation directly to the test.

Second, we actually have to USE the scope. Just calling Member.active does not actually use the scope. This is because named scopes can be cascaded. If I had recent scope on a member that only showed me those that signed up recently, I could actually do Member.active.recent, and it would not execute against database, it would just nest the conditions.

So how do I use the scope? Use any collection method on them. I like size, but I’m completely open to suggestions. So below is how I am testing named scopes.

class MemberTest < ActiveRecord::TestCase
  context 'named scope active' do
    setup do
      @scoped_find = Member.active
    end

    should "have condition active" do
      expected_conditions  = {:conditions => ["member.status == #{Member::STATUS_ACTIVE}"]}
      assert_equal expected_conditions, @scoped_find.proxy_options
    end

    should "have results" do
      assert_not_nil(scoped.active.size)
    end
  end
end

The first test does part 1, the 2nd, part 2.

I had been getting this issue quite a bit recently. The cause actually turned out to be a conflict between McAfee and MySQL. What was happening is that McAfee scans any file that is recently written to, especially those in tmp directories. McAfee reading the file causes the above issue to MySQL. The fix is 2 fold. First, if you have not already, move the location of the MySQL tmp file. You can do this by editing my.ini in your MySQL directory. For Example:

tmpdir="C:/Program Files/MySQL/tmp/"


You may also have to add an exception to your antivirus so that it will no longer scan this file. I had to do this because I was using corporate antivirus. You may have to get your Sysadmin to do this.

Here is a post on mysql’s forums describing this issue as well