Work experience at Lonely Planet

Dublin, Ireland
March 2016 – June 2020

Mainly worked on in-house Ruby on Rails CMS for Lonely Planet’s travel book production that has three parts: An Offline first progressive web app, administrative section, and an API. Automated tasks to improve book production process, software deployment and testing.

I’ve also got to Improve my debugging skills which I was praised by other team members for debugging and fixing most complex and annoying bugs in variety of software and automated processes.

Being part of an small but high-efficient agile team, I helped new team members to get adapt to the platforms, do pair programming, and perform code peer-reviews to ensure code quality and automated tests are up-to-standards.

Used ChefDK and other open source infrastructure management tools to ensure the IaC repositories are well maintained so the releases and deployments are efficient and smooth on AWS.


Ruby, Ruby on Rails, ES6 JavaScript, Backbone.js, SASS/CSS, Cucumber, Rspec, Jasmine, PostgreSQL, Amazon AWS, Jenkins, ChefDK

Work process

We have a daily stand up in the morning where we discuss what we did yesterday, are currently doing, and also mention any road blockers and then what we are planning to do ahead.

All our project progress is tracked on Trello. We use Trello as we heavily practiced Kanban process in an agile team.

In our main Trello board, we have following columns:

  • Queue
  • Doing
  • Testing
  • Deployed to Devint
  • Deployed to Prod

When there is a EPIC (big feature implementation), we would gather and discuss what needs to be done and break them into smaller cards on Trello.

Usually the team lead would put cards in the queue where we will pick the top card and kick-off(discuss the feature with product owner/QA engineers) and clarify questions. We would also discuss what needs to be prioritize from the backlog, once every week.

We use Github to keep our project code and for each card that involve code changes, we would have a separate issue branch on GitHub. Depending on the card, The work can be done by ourselves or do pair programming.

Once we finish working on the card and there are relevant Unit, Integration, or System tests are in place, we do Peer Code Reviews. At the same time we would parallel run all the automated tests on virtual machines to ensure product is working as expected.

We utilize GitHub’s inbuilt code review feature to help the code reviewer to make comments or approve the code changes. When we get thumbs up(approved) by the code reviewer, the card is moved to testing column. There a QA engineer will pick it, build a test environment, test and report bugs or merge the changes to master branch. Then the card will get deployed to Devint(staging) environment with other cards where they will perform regression tests and finally when they are happy they will do a release to production.

Utilizing tools such as Jenkins CI, we would typically do 4-5 production release per week for the main products and 2-3 times for other products (mentioned below) depending on the pipeline.

Typically cards are categorized into three:

  • Bug fixes
  • Feature Implementations
    • Can be feature request change or part of a bigger feature change called an Epic
  • Spike – to research and develop solution or gather findings
  • Infrastructure – to manage technical debt

The cards can be coming from different products or due to infrastructure changes.


During the time at Lonely Planet, I took ownership of delivering changes multiple range of products and tools that are mentioned below where the CMS and single page web app being the most important.

  • Rails Application: CMS for core content management and API for content delivery
  • Backbone.js + ES6 Single page web app with offline capability for users to edit and submit content
  • Rails Application: To compile LP content into various formats
  • Rails Application: Template engine to generate book production manifest based on user provided information and CMS data(CSV reports or CMS APIs)
  • Sinatra Application: The utility tool to manage apps and do deployments to AWS
  • Chrome extension: To give persistent offline storage for single page web app

Infrastructure & Tools

  • AWS – RDS, EC2, Cloudwatch, Cloudformation, S3, Lamda
  • ChefDK cookbooks for AWS AMI creation
  • Envato StackMaster for AWS Stack definition
  • Hashicorp Packer for AMI definition
  • Hashicorp Vagrant for local development
  • Hashicorp Vault for secrets management
  • Logstash for production logging
  • Jenkins CI to automate AMI building, running tests, deployments
  • Docker for some apps
  • PagerDuty for on-call alerting
  • GitHub for source code management of the Git repositories
  • Chrome Web Store to manage the Chrome extension
  • Atlassian Confluence for knowledge management
  • Slack for communication
  • Trello for project management

Notable achievements

  • Migrated from the use of Application Cache to Service Worker to ensure the offline front-end application is future proof which also meant to adapt a new set of web APIs for offline data storage for the application while keeping the changes compatible with other parts of the application. Additionally developed a Chrome extension to manage persistence storage as it was required to move from Firefox to Chrome. As a result, the end-users smoothly transitioned from Firefox to Chrome browser to use the application without causing data loss or any roadblocks.
  • Actively participated to transition from AWS EC2 to AWS RDS for the PostgreSQL databases which helped to reduce AWS costs as well as database management. A good team communication and proper planning helped us as a team to deliver the results in a timely manner without any issues.
  • Worked on upgrading Ruby on Rails for the core CMS application from 4.2 to 5.x where I took ownership of fixing front-end and back-end errors due to broken packages. With an upgraded platform, the developers were able to use the latest and secure software libraries and code which helped the platform to be future-proof.
  • Implemented “Find and Replace” functionality across the offline web application addressing multiple different types of content types.
  • Actively participated design and implementation of robust opening hours sub-system where users can enter opening hours in plain English and the system converts it to an object format. As a result the system is capable to provide rich opening hours information to book publishing formats, mobile apps and LP website.
  • Added new content filtering features for the application which helped users to be more efficient when creating content
  • Researched and implemented solution for the users to get generated reports available on their Google Drive rather than as a downloaded CSV file. This helped end-users to create and use reports freely especially during the sudden necessary to work from home policies.
  • Replaced basic authentication in favor of session based authentication to improve application security
  • Updated CkEditor where I addressed multiple issues involving compatibility issues as well as asynchronous bugs. As a result users were able to use the latest version with improved performance and features which increased their productivity.

What was it like at Lonely Planet

The job came with a lot of responsibilities and at some point it felt like there are too many moving parts for one developer to work on. But being part of a small team, it was necessary and being able to diverse and adapt myself quickly I usually enjoyed the work.

As a company also, it was not Lonely at all. 😛 I was part of a talented and nice team of developers and also the office was filled with nice people. Overall it was a rewarding experience seeing our products used by the same colleagues who we work with in our office and other LP offices around the world.

Most importantly I had a really enjoyable time at Lonely Planet. From Day 1 everything was really great. Following are some photo captions of office night outs/hang outs and with some team members here and there to show a glimpse of the time.