Use Git commit sha to keep track of running version in production

Git is the de facto standard version control system in software development. For organizing Git Logoour issues and keeping track of the status we use the Kanban view of Jira.

Our last two columns on our Kanban board are:

  • Awaiting deploy
  • Done

All issues in the column “Awaiting deploy” are fully implemented and tested. The code has been reviewed by a 2nd developer and as result of the review process merged from the feature branch into our master branch. They are ready to be released to production.

Releasing to production is merging master branch into production branch and push it to our git repository. After this step all issues are moved from the column “Awaiting deploy” to “Done“. Now this column holds all issues that are new in production.

Our deployment script on server side will now pull this branch and restart the servers with the new code. A common way how to deploy Ruby On Rails applications. That means that the full repository is available on our production servers. This comes in handy if we want to determine the actual HEAD commit of our production branch.

We do this by calling “git rev-parse HEAD“.

To have this information available in our application we use the following code in a Rails initializer:

if Rails.env.production?
   commit_hash = `git rev-parse HEAD 2>/dev/null`.to_s.strip
   APP_VERSION = Time.now.utc.strftime("%Y%m%d-%H%M-") + commit_hash[-8..-1]
else
   APP_VERSION = Time.now.utc.strftime("%Y%m%d-%H%M-development")
end

To have this information easily accessible we render this information as html meta tag into all our sites:

<meta name="lingohub-version" content="<%= APP_VERSION %>"/>

results in:

<meta name="lingohub-version" content="20130412-1646-0ab4b155"/%>

This version will be now assigned to all issues in the “Done” column. We now know the date and the last git commit sha that runs in production.

For other SCMs these CLI commands would do the trick:

  • SVN: svn log -r HEAD
  • Mercurial: hg id -i

links:

i18n Resource File Formats: YAML files

We are continuing our series on localization resource file formats, this time with a closer look at one of the most popular formats, especially since the rise of Ruby/Rails in web development. For those not so familiar with YAML I suggest the very good basic introduction that the Wikipedia article provides.

YAML is a human-readable data serialization format. Its syntax was designed to be easily mapped to data types common to most high-level languages (lists, associative arrays and scalars). YAML is what we use for localizing Lingohub in our Ruby on Rails application. It has proven to be a very efficient production environment, especially used in conjunction with Github integration that Lingohub supports natively.

Unlike some other formats, YAML has a well defined standard. Let me outline some key features below followed by an example. As always, feel free to send us questions on these file types or others that you want to use to localize your apps.

Key features of YAML resource file format:

  • key-value pairs are delimited with colon ( : )
  • values can be surrounded by quotes
  • correct and consistent line indentation is important
  • comments start with a hash sign ( # ), and are ignored by the parser
  • in the Lingohub context, all comment lines directly preceding a key-value pair (with no blank lines in between) are treated as translation descriptions or LingoCheck rules belonging to that line.
  • place-holder syntax is: %{name}, where “name” can consist of multiple non-white-space characters
  • we use UTF-8 encoding for YAML resource files exports by default, but we also support other encodings our users might prefer.

An example of a YAML localization resource file format:

References:

We are continuing our series on localization resource file formats with with some other popular file types soon, stay tuned and feel free to post questions below.

Syncing your resource files with the lingohub CLI client

By using lingohub you’re providing your translators with a sophisticated editor for your resource files. Now they have the chance to edit these files presented in a human-readable format.
lingohub will ensure that they cannot break anything by accident and that they know how to encode characters correctly in ISO-8859-1.

Let us assume a very common case: you forgot to upload the latest version of your resource files currently in development (i.e. your translators were translating the old stuff), or you forgot to download the files from lingohub and to push them to your repository.
You released a new version of your software and 17 of your 18 localizations are not fully translated, although the translators finished their work. Now don’t panic, lingohub has got your back.

How lingohub can help you solve this problem

How to import/export the files at the right time as part of your build process? Well, one option is to use our github integration. Every push to your repository will automatically trigger a new resource file import. lingohub will always be synced to your development branch. However, a lot of our users do not use Github. That’s why we provide you with a second option, the “lingohub CLI client”.

lingohub CLI client help


lingohub CLI client help

Prerequisites

Our CLI client is written in Ruby. In order to install it, follow these steps:

  • install Ruby (follow the instructions for your platform)
  • run “gem install lingohub” in your terminal to install our CLI client

Getting started

“lingohub help” will show you all available actions you can now perform with the CLI client. At first you have to give the client your credentials, to determine as which user the client will connect to lingohub. Please do this with “lingohub login”. Now please enter your email and password that you are using to log in to lingohub.com.

You can leave the password blank if you prefer to use the API Token for the connection. It can be found under your authentication settings:


Now you can use every client command on the projects where you have the appropriate permissions.

Pushing files to lingohub

With “lingohub resource:up <file1> <file2> … –locale <iso2_code> –project <name>” you can now import the latest resource files into your lingohub project. The locale parameter is optional and only needed if it is not possible to determine the ISO2 code from the file name.

You can write a shell script for example that imports all your files to lingohub. This script can be run manually, on a timed basis or as commit hook of your SCM, so lingohub will always be up to date with your development branch.

Retrieving files from lingohub

For retrieval, you can use
“resource:down –locale <iso2_code> –all –directory <path> –project <name>”
to download the newest files from lingohub.

We do this on a daily basis, just to feel great about knowing that our translators already translated phrases that we’ve pushed to development just the day before.

What else can you do with the lingohub CLI client?

  • list your projects
  • create a new project
  • rename a project
  • manage your collaborators
  • manage invitations

I hope you liked the introduction to our CLI client and will find it useful to integrate our application in your build process. If you have some more ideas on how we could improve the client or if you have questions, please feel free to contact us or leave a comment.

Đorđe is a lingohubber

Another addition to our lingohub team we would like to introduce to you, is Đorđe, who also joined us from Novi Sad, Serbia. Welcome on board!
Đorđe Andžić
Đorđe graduated from Subotica Tech College of Applied Sciences. He is currently falling in love with Ruby and Rails, some of lingohub‘s base technologies, and is soaking up new knowledge about web development, as well as sports (basketball), education and music, when he is not programming.

“If you talk to a man in a language he understands, that goes to his head. If you talk to him in his own language, that goes to his heart.” ‒Nelson Mandela

BaRuCo – Barcelona Ruby Conference


Last weekend I had the great chance to be part of BaRuco. A Ruby conference in sunny Barcelona. Believe it or not, it was my first time visiting this great city.

BaRuCo, organized by :codegram, was a fine Ruby conference with a bunch of great talks. The agenda was quite dense. 8 talks per day. Maybe a bit too dense but I will talk about that later.

Cosmo Caixa

First of all I really want to thank the organizers for choosing the venue: Cosmo Caixa, a technology museum, is a great place to stay for two days. Actually it is a kind of museum I have never seen before. Cosmo Caixa exhibition is quite unstructured with no real topic and it is a good thing. If you visit Barcelona you have to visit this place!

Talks

There are some talks I like to mention:

PROGRAMMING WORKOUT, BY MICHAŁ TASZYCKI

Michal talked about the passion to continuous learning. How you keep your fire burning to improve yourself and stay focused. Plus some tricks to set your goals wisely.

TRACING YOUR WAY THROUGH RUBY, BY ELISE HUARD

A great talk about using dtrace and how to probe your Ruby application if anything else does not give you that granular level of insight. Aaron Patterson already added dtrace probes to MRI, but we have to wait for Ruby 2.0.

RUBYMOTION FOR FASTER CLIENT/SERVER DEVELOPMENT, BY RANDALL THOMAS & TAMMER SALEH

The two guys of Thunderbolt Labs gave a good insight to using RubyMotion in client projects. RubyMotion promises to develop iOS application in Ruby. The presentation included information how RubyMotion development differs from your known Ruby development (eg. you cannot use require and gems).

IT’S NOT HOW GOOD YOUR APP IS, IT’S HOW GOOD YOU WANT IT TO BE, BY JOSH KALDERIMIS

If you have never seen Josh on stage – go for it!
This talk explained how the guys of Travis CI use several techniques to monitor what’s going on in their application. Ranging from using ActiveSupport Notifications to add custom log entries. Papertrail to aggregate and browse their logs. Josh told me that his talk will be online soon.

Seen crititical

As I mentioned the schedule was quite dense, hence most of the time was spent sitting in the Auditorium. But besides listening to great talks, most of us who attend at a conference want to use some time to meet other developers. Chat about what you do and how you enjoy it. There was no real chance to skip a talk in advance to prolong a nice chat you just started during the short coffee break. The space outside of the auditorium was shut off for the “real” guests of the museum, so everyone automatically moved in again.

See you there next year!