Git is the de facto standard version control system in software development. For organizing our issues and keeping track of the status we use the Kanban view of Jira.
Our last two columns on our Kanban board are:
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:
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]
APP_VERSION = Time.now.utc.strftime("%Y%m%d-%H%M-development")
To have this information easily accessible we render this information as html meta tag into all our sites:
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
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
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
“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
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.
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 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
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.
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!
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.
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).
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.
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.