Account security is a difficult problem to solve that is of growing importance. With more and more personal information being stored in online services, developers need to provide security options to drastically reduce the likelihood of unauthorized account access. A password on its own provides a very low level of security. This is especially true, since most users won't use a truly strong password. Users tend to be angered by requirements for passwords with adequate entropy. One solution to this issue is multifactor authentication.
I was fortunate enough to have my talk selected for JRUBYCONF.eu this year, held August 1st. JRUBYCONF.eu is held alongside and as part of the larger European Ruby conference, eurucamp. This was my first time traveling outside the United States as well as my first time speaking at a tech conference, so the excitement (as well as nervousness) I felt in the days leading up to my departure was quite intense. Fortunately, the conference organizers did an absolutely amazing job taking care of everything on their end, from hotel rooms during the three days of the conference and airport pickup to having sound and projection work flawlessly. They even hired a professional stenographer, providing transcriptions of the talks. And while I had concerns about not being able to speak German, it turned out that everyone I met spoke flawless English.
Inspired by Mark Otto's post Github's CSS I thought I would quickly jot down how Lonely Planet's CSS is structured. I thought it was interesting to read some of the parallels and it's good to share how we work.
Coding tests seem to be a big hurdle for many developers. Here's some tips to help you get to the next stage.
GitHub is awesome, here's how to get more out of it.
Anyone who has attempted to maintain a UI Style Guide over a long period of time will attest that it is a very difficult process. They are generally prioritised below the maintenance of your applications themselves and as such are likely the first candidates to fall behind and the last to be brought out of tech debt.
In response to the OpenSSL vulnerability (known as Heartbleed and labelled CVE-2014-0160), Lonely Planet conducted a thorough review of our infrastructure and where necessary, updated software with the appropriate security patches, replaced affected infrastructure, and replaced our Lonely Planet SSL certificate.
Every software project I've worked on has, over time, built up technical debt, and the platform we work on here at Lonely Planet is no exception. Even just trying to keep libraries up to date and employ new recommended techniques means that the code gets inconsistent and some becomes stale, which means that over time we'll start moving more slowly because the codebase becomes harder and harder to add to. We have a few techniques to try and avoid paying too much "interest".
Returning hierarchical data in a timely fashion
What kind of pair programmer are you?
Our team has been interested in trying to figure out how to measure our ability to improve both personally and as a team. Our teams purpose is to deliver high-quality software as quickly as possible. This is hard to measure, so the next thing to consider is what the best proxies are. We decided that we would instead measure and improve each developers skills and hope that this would lead to team progress.
At Lonely Planet's Melbourne headquarters, we occasionally sample some of the beverages on offer at local spots like The Reverence and Station Hotel, and we've even talked about getting a beer fridge in the office, but did you know that you can tap some rare and delicious brews right on your Mac?
Tips and tricks for porting plugins from Sublime Text 2 to 3
Detecting problematic Chef changes before rolling out updates.
One of the major tasks in Lonely Planet's switch to producing guidebooks from our shiny new CMS was writing an engine to convert data to fit templates in the ContentXML format required by our automated layout system. This seemed like a simple enough XML-to-XML conversion problem, so we initially tackled this with XSLT, but it soon became clear that the mapping was way more complicated than one-to-one.
We recently upgraded a Rails 3 project here at LP to Capybara 2 from 1.1.2. Ran into a few minor bumps along the way which we've shared below. Hopefully it helps others choosing to upgrade.
Tips and tricks on writing your very own Sublime Text 2 Plugin
When we created IAM accounts for our team, we had a desire to as self service as possible. Ideally, we wanted to provide a username and temporary password and then have users be able to set themselves up an access key, security certificate and MFA and be able to manage this themselves ongoing. However, this obviously couldn't be at the expense of security. We needed to ensure that users could only modify their own information and if we remove a user from our account theyre gone.
Broken Promises: Counter-intuitive Exception Handling with jQuery's Deferred or, why "always" doesn't always mean always
I've spent the last couple of months learning the lovely language of Ruby. It has many delightful features, and I can see why all the cool kids are using it. Convention over configuration works often enough to be very useful. The language itself is, mostly, wonderfully concise and easy to read. Built in support for testing and deployment makes life so much easier. The amount of time it takes to create an application and get it into a usable (by users!) state is astounding for those of us coming from a Java/PHP background.
There are many reasons to limit Work in Progress (WIP). This is explained well by Tonianne DeMaria Barry and Jim Benson in their Personal Kanban blog.
Kanban provides a snapshot of how things really are without trying to assign blame. This provides the opportunity to make genuine improvements, because issues are visible and can be owned by the whole team.
Identifying and resolving Rails3 & SASS issues
Tools and resources mentioned in our VelocityConf talk
Fozzie was good, and we were happy with progress. We were monitoring applications in real time, the code was looking ok, and the stats looked good on the big screens. On reflection of the code though, we felt there was room for improvement on the way in which we were referencing Fozzie for the timing of code.
A target of ours has been to improve the monitoring of our applications. I'm sure this is true for nearly all Software companies. We have applications written in various languages, the main "must-monitor" ones in Ruby and Java. This article explains how we implemented statsd into our Ruby applications.
Performance review, reflection and improvements
One of the great things about working for Lonely Planet is the opportunity to get out and about at meetups and conferences. Last week we organised and sponsored the first London ElasticSearch user group meetup.
Want to join our team of coding sloths?
Screamingly fast is now a requirement of all our projects. We've only made incremental improvements to our page performance over the past couple of years but this is about to change dramatically. Ill be sharing our progress on this blog. Were also experimenting with tools to help us capture performance data in real time and well share some of this data when we can.