When referring to URLs there are valid reasons for avoiding hard-coded string manipulation in models, controllers or views. One reason is the DRY principle. Having a central representation of a resource eliminates the need to adjust all depending URLs when a change becomes necessary.
The Rails router generates helper methods for paths and URLs for exactly this reason. Suppose we define a route for a patients resource as follows.
get '/patients/:id', to: 'patients#show', as: 'patient'
Then, for a given Patient with id 17 initialized in the controller, we can call the following path or url helpers in a view.
patient_path(@patient) # /patients/17
patient_url(@patient) # http://www.example-app.com/patients/17
Using the Rails path and url helpers is a common best practice. However, there is no clear best practice for building external URLs, i.e. URLs not belonging to the application.
In this post we suggest using URI Templates with the Addressable gem for building external URLs and we outline an example implementation.
A few weeks ago, I wrote about the 1st Babbel Hackday.
Meanwhile we have produced a video clip using the on-site recordings.
Also the results of our survey are available. They are very encouraging. See the nice infographic below!
View “1st Babbel Hackday” on YouTube.
You might have experienced this yourself: Over time, Rails models are getting fatter and fatter and the complexity of helper classes increases.
It is good practice to keep complicated logic away from your views. But dealing with a lot of helper methods is also tedious and adding view-related logic to the model is not an option either.
The Decorator design pattern helps to solve this problem.
We are ramping up our team of currently 30 engineers in all areas (see current job openings).
You can also visit us at TechStartupJobs Fair Berlin on 14.05.2014.
There are free tickets available for jobseekers - get them here.
Friday, April 4th, we held the first Babbel Hackday. Starting at 10 a.m, more than 40 developers, designers, analysts and product managers gathered at Co-Up at the backyard of the Adalbertstraße in Berlin-Kreuzberg for a full day of hacking madness.
The complete staff of Babbel’s Product and Engineering departments and the BI team took part in the event. At Babbel Product, Engineering, and BI work closely together on various apps for web and mobile platforms. While our main goal for the Hackday was to bring people together through temporary teams for light-hearted, hackday-only projects, we also intended to provide some space for any ideas lying dormant in the existing teams. We also just wanted to have a fun day, and we were anticipating some great results.
On Tuesday, the up.front meetup about Webdesign and Frontend will take place at Co-up in Berlin.
- Changing Behavior with Design
- Confessions of an Alien: Attracting Non-coding People to Your Open Source Project
- A Video Game Revolution is Happening… In Your Browser
Also on Tuesday, the support for Windows XP will officially end! Watch the countdown here and come to Co-up to celebrate this.
Save the date!
Tuesday, April 8, 2014 7:00 PM at Co-up
Babbel’s mobile apps continue to be a huge success. After we shipped our new iOS7 apps, it was time to give the Babbel Android App a treat and turn it into a full-feature app. Babbel is striving to provide the same user experience across all devices. No user should ever be hindered in her/his learning activities by having to adapt to different user experiences on Android, iOS or the web.
Device images licensed by the Android Open Source Project under CC-BY 2.5. The aforesaid does not apply to the screenshots of the Babbel Android App.
On Thursday, 6th March there will be the next meetup of RUG::B, the Ruby User Group of Berlin.
There will be talks about
- It Takes a Village to Make a Programmer
- Death to Cookies
- Ruby Storm - Distributed work on a self-scaling system using RabbitMQ
Find out more at the events page
TL;DR: Trigger a deployment of an app in AWS OpsWorks via a GitHub service hook when pushing a branch to your repository.
There are use cases where you want to deploy something straightforward, just by pushing your changes to a git repository, e.g. an update of an internal tool or a typo in a blog post.
For web applications, Heroku has such a workflow. You configure a Heroku remote repository, push to its
master branch, and Heroku’s after-push hook takes care to roll out the new version of your application.
For hosting of static pages (or simple blogs like this one), GitHub Pages provide the same approach. If you push the content of your page organized as Jekyll project to a special branch called
gh-pages then GitHub Page will compile the templates and host the result.
We wanted to have the same comfort for AWS OpsWorks. Most of our web applications and internal tools are running on OpsWorks, and at least for the internal tools, the deployment through Capistrano or the AWS Console has been too cumbersome.
We’ve proposed a service hook to GitHub which can trigger an application deployment on OpsWorks. And GitHub has integrated it.
TL;DR: If you need to build dynamically regular expressions memoize them. Compiling them is expensive.
I don’t like memoizing methods, or caching in general. Obviously, caching adds more complexity to your source code and might lead to more errors, or even worse, errors which are harder to reproduce because they only happen due to a specific history. For memoized methods, you have to ensure that there are no other dependencies for the result than the passed arguments. Or that the result of a memoized method does not reference a larger object tree ending with a memory leak. There might be even more pitfalls.
Hello World! Welcome to the Babbel Tech Blog.
From today on, we, the Babbel engineering team, would like to share our experiences about developing and maintaining the Babbel platform: The website, various mobile apps and the infrastructure behind it.
Some information about us and our infrastructure:
- We are currently 25 FTE in the engineering department growing rapidly and about 12 FTE in product development.
- We are developing mobile applications for iOS, Android and Windows (Phone and 8), and thus, using Objective C, Java and C#.
- Most of our web applications are Ruby on Rails applications, some special purpose applications like our tracker is written in node.js
- The infrastructure running our web applications is hosted on AWS, mostly on OpsWorks, some an Elastic Beanstalk.