Attending the Ruby User Group Berlin April meetup at Kauferportal

On Thursday we attended the Ruby User Group (RUG::B) April meetup at Kauferportal. With 3 normal talks and 5 lightning talks the program was pretty packed. Good thing I summarized it for you:

Migrating databases like a Pro!

Hans Hasselberg, responsible for Ops at 6wunderkinder, talked about migrating databases. And not just your usual db/migrate, but actually moving an entire database to another server. 6wunderkinder uses AWS with PostgresSQL type db.m2.2xlarge. Preparing to move to a smaller server and improving efficiency (and thus optimizing for scalability), Hans had to simulate production load to make sure the new, tinier server won’t die under its load. How? By enabling query logging maybe, but that would mean touching the database. Or one could sniff the traffic. Say hello to <a href="https://ngrep.sourceforge.net/" target="_blank">ngrep</a>. With a one time operation and a fixed set of operations however, you might miss an important set and you can’t compare how the new database behaves as apposed to the old one.

Ruby User Group meetup Berlin - Hans

To do that, you could mirror live traffic. But that would mean changing code in all the different projects of 6wunderkinder and would take about 2 months. Changing code based on a guess is… well… Ultimately 6wunderkinder decided to change queries on the fly, to better anticipate changes and actually see the impact changes have with a PostgreSQL Cluster table.

What the cache?!

Simon Kröger (VP Technology Sponsorpay) test-drive his talk for this year’s Railsconf. He described Sponsorpay’s old, ‘Vanilla Rails stack’, memcache, MySQL 5.5, Rails 3.2, Ruby 1.9 and ‘a few unicorns’. Life was peachy until their MySQL tool of choice started showing a lot of unsuccessful queries. A new request would come in before the previous one went through the response pipeline and the process would take longer than normal as the two queries were now sharing resources. “This will really start to show when there’s more than 2 queries running simultaneously.” It might look like your database isn’t doing anything, while its working really hard.

Reading the ActiveSupport documentation, Simon came across this piece on cache storing.

Setting :race_condition_ttl is very useful in situations where a cache entry is used very frequently and is under heavy load. If a cache expires and due to heavy load seven different processes will try to read data natively and then they all will try to write to cache. To avoid that case the first process to find an expired cache entry will bump the cache expiration time by the value set in :race_condition_ttl. Yes, this process is extending the time for a stale value by another few seconds. Because of extended life of the previous cache, other processes will continue to use slightly stale data for a just a bit longer. In the meantime that first process will go ahead and will write into cache the new value. After that all the processes will start getting new value. The key is to keep :race_condition_ttl small.

That now made up one of his strategies, setting a ‘time to live’ (:race_conditions_ttl). The strategy that won in the end however is ‘content versioning’. Querying the version number from the database costs less than querying the action object. Whenever you write to the database you need to get a logging number for every query. Instead, we put a version number in memcache and cache that. With the traffic going up they had to add app servers, not to mention garbage collection. ‘Marshalling’ their strings in hashes with messagepack, the ultimate solution was to have a hash (with the version number in it, remember?), plus an LRU algorithm, placing a unique flag to memcache to indicate when the first query is still working and tell the other processes to hold their horses.

Sponsorpay wrote bounded_cache as an internal gem to take care of all this. Bounded_cache is Rails.cache compatible and will be release shortly.

I am a designer (and you can be as well)

Justine Arreche (design at Travis-CI) tells us that if you look professional, you earn respect and you will get results (read: make money). She went on to explain few of the design principles.

Grids and content structure
Creating a grid keeps your content organized and easy to view. Justine refers to a 12 column grid for the sake of the talk, intentionally ignoring ‘the whole responsive thing’ to be able to explain hierarchy: your logo in the left hand upper corner, navigation on the right side, a featured product by means of header, two or more blocks of copy and a footer for your impressum and ‘stuff’.

Ruby User Group meetup Berlin - Justine Arreche

Color scheme
A color scheme is about more than just ‘I like blue’. Justine: “It’s about what’s relevant to your overall message.” Introducing the color wheel for the western world, she goes on to explain how complementary colors – contrasting colors that help draw attention – work very well on your website (hence the name). Picking two colors next to each-other on the color wheel and combining it with a neutral color like white or grey (or black) is also a common practice. For a more neutral pallet, Justine recommends adding white to a color of your choosing, gradually.

But whatever you chose, make sure you stay far away from the color scheme of your competitor.

typography
“Forget the hype on type, let the type work for you.” Justine explains the difference between a serif (traditional, easier to read and thus great for blocks of text) and a sans-serif (modern, makes a bold statement, great for headlines) font as letters with and without ‘feet’. She recommends ‘keeping it in the family’. “There is a reason why it’s called font-family.” Some fonts even have serifs and sans-serifs within the family, like Lucida Type. Else, you might want to choose typefaces that have elements in common, like their x-height. “Go for polar opposites, like a display font and a regular type face, to create contrast.”

Next up were the Lightning talks. Yay, Lightning Talks!

5 refinements

Jan did a refinements (lightning) talk. “I work with Ruby as Ruby reads well and invites to dive into a class and refine stuff.” Jan coincidentally wrote a Gem just for that purpose. Zucker is a collection of Ruby Refinements you might want to check out.

Tech Pro Bono

Ben Green talked about how he wanted to get into pro bono web development work. To do something meaningful for a good cause outside of the tech world. At techprobono.org you can register as a pro bono developer and put your skills to work for charity. The source code is online over at GitHub.

Living Style Guide gem

After creating homify.de, Nico Hagenburger came up with the idea of creating the Living Style Guide gem, to easily create ‘living’ style guides by adding Markdown documentation to your Sass. Recommended is the README, it blew my mind, and if you’re a backend developer it will probably scare you to death. In a good way.

eurucamp 2014

The eurucamp team then announced the final dates for their Summer conference: 1-3 August. The Call for Proposals is open until the 1st of may and there will be mentoring available for every speaker. JRubyconf will take place alongside the eurucamp week again, just like last year. Early Bird tickets will go on sale Monday April 21st.

Rails Girls Summer of Code

Yours truly did a little update on the Rails Girls Summer of Code project as we opened the crowd funding campaign on the day of the meetup. And because we need more coaches, Coaching Companies and Open Source projects looking a fresh pair of eyes (or two actually).

Leave a Reply

Your email address will not be published. Required fields are marked *