Tuesday, February 22, 2011

Glimmer 0.1.2 Release

Just made a new release of Glimmer (version 0.1.2):

New and noteworthy:
  • Official multiple-DSL support ability: You can now switch between the SWT and XML DSLs by invoking the included "dsl" method with the Glimmer module. This feature was needed in order to run all tests without DSL name clashes. Now, each test file specifies its DSL explicitly to ensure that when the XML DSL tests operate, they do not end up rendering SWT widgets for example.
  • Tests were also repaired to pass again given the latest changes in SWT, JRuby, and Facets.
  • Added a new sample app called "samples/hello_combo.rb"
  • License was switched to MIT License
Outstanding issue:

One thing that is not working on the Mac for some odd reason is "rake test" as I included this required Mac Java option in the rake test task (needed for SWT):
test.ruby_opts = ['-J-XstartOnFirstThread']
And, it is making rake bomb with the following message:
jruby: unknown option -J-XstartOnFirstThread
However, when manually running the command that the rake task renders in the output, it works like charm. I will report back once I have found a solution to this odd problem.

In the meantime, enjoy the release and stay tuned for more features.

Friday, February 18, 2011

Glimmer's Officially Back on GitHub

Yes, it's official! Glimmer is back on GitHub with support for JRuby 1.5.6 and Facets 2.9.0.

It also now includes an .rvmrc file to facilitate working with JRuby via RVM and a Gemfile to facilitate pulling in libraries like Facets with the right version.

The project will no longer be hosted on eclipse.org

Check out the GitHub repository over here:

This will be the main home for the project from this point on.

If you need a refresher on the project, here are some good resources:

Happy Glimmering!

Thursday, February 03, 2011

Creating a locally tracked remote branch with Git

Updated May 30, 2013

Git is a distributed source code control system that allows you to clone a remote repository locally, make commits to it on your machine, and then push them to the remote repository when done.

It is often useful to create a remote branch for features that are experimental or will not be going out in the upcoming release as that allows you to work in isolation of the main code repository changes, thus not get blocked.

In order to work with a Git remote branch, it has to be cloned locally, and there are multiple ways of doing it with different levels of complexity. Some have you create the local branch first. Others have you create the remote branch first.

My intention for this blog post is to document the easiest way to date for creating a remote branch that is tracked locally.

Here it goes (assuming origin is the default):

git branch new_branch_name
git push -u origin new_branch_name

Then you can checkout the local branch and work with it by typing:

git checkout new_branch_name

The local branch automatically tracks the remote branch, so you do not have to worry about explicitly setting that up.

Now, if you already have a remote branch created by someone else though, and you want to check it out locally, you can just run this command (assuming remote is origin):
git checkout -t -b branch_name origin/branch_name

Update: A shorter alternative:

git checkout -t origin/branch_name

A Google search turns out a dozen ways, many of which are over-complicated or out-dated, so I hope people find this blog post helpful for providing the simplest approach to date.

Tuesday, February 01, 2011

Setting non-nullable form field defaults in Rails

Recently, I found myself following a pattern for setting non-nullable form field defaults in a Rails model.

Basically, instead of relying on the database schema:
  create_table "user_queries", :force => true do |t|
    t.string   "sort_field", :default => "username", :nil => false

I add an after_initialize hook to the ActiveRecord model:
  after_initialize :set_defaults

  def set_defaults
    self.sort_field = "username" if sort_field.nil?

The reason I do that is because of an issue I ran into when specifying the non-nullable default in the database schema. When the default value requirement changes (e.g. change default from "username" to "last_name"), I end up having to create a migration that modifies the column when using a database that supports column modification (e.g. MySQL), or worse yet for databases that do not support column modification (e.g. PostgreSQL), I create a migration that adds a new column, migrates older's column data to new column, and removes older column.

By having the non-nullable default specified in ActiveRecord models instead, change becomes as easy as updating the model's test and the default value specified in the code.

Of course, the disadvantage to this approach is it does not ensure that the default value is set when interacting with the database without ActiveRecord. But, it works if that is not a requirement in your client environment.

Would be curious to know if others ran into the same problem and whether they addressed it in the same way.