Some time ago, I wrote about putting HTTP status code to use for your Rails application. For my reinvigorated project, I wanted to apply the same technique. Instead of re-implementing it once again, I created a Rails plugin called http_status_exceptions to easily add this functionality and I have put it on Github. For more information on how to install and use the plugin, see the project’s wiki.
I just started working on an old Rails project after having neglected it for 15 months. Most of the view files still had the good old .rhtml extension. I was too lazy to rename these files by hand, both on my file system and in the git repository. I used the following Bash commands to do the job:
First, I renamed all the partials to the .erb extension. Note: I am not using .html.erb, as some of these partials are used in js-formatted responses as well:
for i in `find app/views/**/_*.rhtml`; do \ git mv $i `echo $i | sed s/\\.rhtml$/.erb/`; \ done
The remaining files could now be renamed to .html.erb with a similar command:
for i in `find app/views/**/*.rhtml`; do \ git mv $i `echo $i | sed s/\\.rhtml$/.html.erb/`; \ done
Note that this technique works with Subversion as well: just substitute git with svn in the command above. A regular rename is possible as well by leaving out git altogether!
Now my file names are Rails-compliant again, I can start refactoring all the code that is not up to current Rails standards anymore. Ah, the virtues of developing with a rapidly evolving framework…
Last week we had to convert our existing Rails application, which uses Gettext to the new I18n API in combination with the SimpleBackend. I personally never liked Gettext, there was simply not enough control over translations as PO/MO files are not native ruby or at least can be easily accessed by Ruby (like YAML files).
We therefore decided to switch to the brand new, not even released, I18n API. But now we had a serious problem, our code base isn’t small and all that code had to be converted in some way. We could do it by hand, but hey, that’s a lot of work and especially very error-prone. Some convertor had to be written. Here it is as a rails plugin: GettextToI18n.
It scrapes your whole application and searches for gettext calls, like this:
_("to be translated")
It will convert this gettext call to the newly I18n format:
I18n.t :message_id
Then it builds up a big hash containing all the the translations. We decided it was handy to use the scopes that are introduced in the new I18n api. So it stores the translations in the following format:
For models:
["model"]["model_name"]={:message_1 => "to be translated"}
For controller:
["controller"]["controller_name"]={:message_1 => "to be translated"}
After this hash of translations has been built up, the convertor writes it as a YAML file to: config/locales/template.yml.That’s all!
It supports basic gettext calls. We have run it over our code base and it converts all gettext calls we use without any problem.
A normal gettext call
_("to be translated")
converts to:
I18n.t :message_0, :scope => [:txt, :controller, :controller_name])
_("My name is %{name}" % {:name => "Jaap"})
converts to:
I18n.t :message_0, :name => "Jaap", :scope => [:txt, :controller, :controller_name])
A gettext call with variables that contain gettext calls
_("Click %{link} to go to the homepage" % {:link => link_to(_("Here"), root_path)})
converts to:
I18n.t :message_0, :link => link_to(I18n.t(:message_1, :scope => [:txt, :controller, :controller_name]), root_path), :scope => [:txt, :controller, :controller_name])
./script/plugin install git://github.com/japetheape/gettext_to_i18n.git
To convert your application:
rake gettext_to_i18n:transform
Please make sure you backup your complete application as it can screw things up.
Please contribute to this plugin and make it better, as I won’t use it anymore, cause we are not going to convert another time (I think 
). Things that has to be done are:
unnamed variables:
_("I play the %s" % "saxophone")
Go to the development location at github and fork this plugin!
I have been using git for a while now, and I believe I have the the basic workflow under control. Committing, reverting, using local branches for major refactoring work: been there, done that! However, I recently got some collaborators on my github-projects, I had to start working with other remote repositories and branches.
I found this blog post, which was really helpful. I am sharing some others things that helped me in the last couple of weeks. Hopefully, this saves other people some time Googling. If you know a better ways to accomplish these tasks, please let me know!
Because I had some troubles discovering how to properly work with remote repositories, I am sharing what I found. The most important things to remember:
git checkout local-branch). This is easier if you setup your command prompt to include your current branch. .git pull remote-name remote-branch in your local branch.
Bart is implementing Merb log parsing for request-log-analyzer. He has put his progress in a separate branch of the github project. My local repository does not yet include this branch, but I want to check it out. Note that I am using a different name than the branch name on the github project.
$ git branch merb origin/generic_base $ git checkout merb
Update: The same can be accomplished with a single command, which sets up remote tracking as well:
$ git checkout -b merb origin/generic_base
When the new functionality is finished, the following commands will merge the changes in the merb branch to the master branch.
# goto my local master branch and merge the merb-branch $ git checkout master $ git merge merb # push the changes to the master branch on github $ git push origin master
Wes Hays is helping me out on the scoped_search plugin. He implemented OR in the query language in his own fork. I wanted to merge his changes back to master branch:
# add a reference to the remote repository # and fetch the latest data from that repository $ git remote add gbdev git://github.com/gbdev/scoped_search.git $ git fetch gbdev # create a local branch for the fork to follow a remote branch $ git branch gbdev-fork gbdev/master $ git checkout gbdev-fork
Now, my local gbdev-fork branch contains Wes’s code. Because Wes’s repository was forked from my repository, git will know that most of the history of my master branch and gbdev-fork branch is the same.
After some testing, I was ready to include his changes by merging the gbdev-fork branch into my local master branch:
# go back to my master branch, and merge the changes $ git checkout master $ git merge gbdev-fork # push the changes to the master branch at hithub $ git push origin master
Update: I found out that you do not have to create a local branch when merging a remote branch. You can do read-only work directly on the remote branch:
# Add a new remote to your repository and fetch updates $ git remote add gbdev git://github.com/gbdev/scoped_search.git $ git fetch gbdev # Checkout the remote branch for testing (read-only) $ git checkout gbdev/master # After successful testing, merge the branch into the master branch: $ git checkout master $ git merge gbdev/master $ git push origin master
You can create tags locally, but you probably want to send them to the remot repository as well:
# create a local tag "tagname" with the given message. $ git tag -a "tagname" -m "message" # send your tags to the remote repository "origin" $ git push origin --tags
Sometimes, you want to remove a faulty tag. If you already pushed your tags to a remote repository, you probably want to delete it from that repository, too,
# remove local tag $ git tag -d tagname # remove tag from remote using colon syntax $ git push :tagname
Today I learned a couple of new things about the use (and trouble) of BitmapData in combination with loading content from other domains. I thought we solved it a while ago, but it in some situations it didn’t work… I definitely hope this is my last post about the subject!
When you load content from another domain and you want to use BitmapData, then you always have to load a policy file (crossdomain.xml) from that other domain. What I discovered today is that you have to do this for ALL the content you’re loading, otherwise the BitmapData just doesn’t work. Even if it’s content you don’t want to use for the BitmapData, you still need to load the policy file. It took me quite a while of debugging to figure this out.
This is our current setup. Every server has its own domain.
The other thing I learned today is a small trick to remove the Warning in your logs. Jeffry Houser explains it in his post Fixing your CrossDomain.xml File.
