In the previous post we shared some notes from our first day at RubyConf Argentina. We now share some notes from the second day there.
First talk for second RubyConfAR day was “REST in peace” presented by Martin Salías. Some ideas he emphasized were:
- REST APIs must make proper use of HTTP verbs and not other conventions. As an example he brought the well known case about Googles accelerator that used to prefetch pages, and those who used a GET query with a /DELETE to perform deletions, lost data just by not using the proper HTTP verb.
- messages should be self descriptive. HTTP codes should be properly used.
- think of hypermedia as the engine of Apps state. We should add URLs to associated resources to allow resources autodiscovery. This also avoids APIs versioning maintenance.
- GET, HEAD should be safe operations
- REST calls must be idempotent. There is one exception: POST
- URLs we provide, must be absolute. User should not deal with the complexity of composing URLs
- API versions can be described on requests headers. An example can be found here
- if we make proper use of REST, we gain web caching
Jeff Casimir presented “Internationalization Isn’t a Bad Word”. First he defined internationalization and localization. Internationalization is a one time process to make the app support multiple languages. Once internationalization is provided, we provide a locale. Localization provides better UX, means reaching more users and greater revenue.
Why should devs care about internationalization? Allows us to create better code. We should isolate data strings from the application: no magic data should be spread; no domain strings are coded! Keys and text can be stored in a yaml/json dictionary.
How should we structure keys?
- keep keys short
- don’t just snake-case the text: focus on core meaning
- don’t mind about reusability here!
Is there a gem to help with this? Yes! Check drapper.
How do we deal with localization? How do we keep translations in sync?
Jeff Casimir listed three tools he found useful:
As for locale selection strategies, we could use:
- geolocation: don’t use it. Locale does not correlate to location. Ex.: if we travel, we still want the same locale preferences regardless where do we go
- browser preferences: you can get information from HTTP_ACCEPT_LANGUAGE header and find users locales, your supported ones and look for an intersection.
- use URL parameters: this makes it easy to switch between locales for dev/debug purposes and ensures a shared URL will be viewed in the same state when reopened by others
- user preferences
If building a lookup chain to determine the locale to be used, you should consider using this hierarchy: url parameters, user preferences, browser preferences, default to determining locale by geolocation.
Are there other ways to use internationalization concepts? Yes! Why can’t we just localize the css and js references? This way we could change site themes by just switching a locale.
“Rapid Prototyping with Sass, Compass and Middleman” was presented by Bermon Painter. He shared his experience at Torquebox. They work with big companies where they usually create a lot of documentation about a product before they start to implement them. They try to speed up the process by creating rapid prototypes where they can try concepts. To build them, they use Middleman, Slim templating engine, SASS, zepto.js and CoffeeScript.
They use a base css defined entirely with partials. About teamwork, he mentioned they use pair programming with a designer and a programmer, so that programmers do learn about design, and designers get introduced to js programming.
David Calavera presented “Scalability at the unknown: GitHub Enterprise”. He exposed some principles and how are they applied on GitHub:
- “simple is strong”: they deliver VMs so that enterprises can run GitHub on their infrastructure without need to perform some installation. The VMs are distributed in OVA format, what means that the VM is just zipped and can be easily replicated. How do they deploy a new VM? “hubot deploy ova”. How are updates applied? An app applies the update and redeploys GitHub on Unicorn.
- “be flexible, but don’t break”:
- implement log forwarding, so that logs can be forwarded to log servers
- implement internal monitoring and make use of SNMP to forward statistics that can be leveraged using Nagios, Ganglia, etc.
- provide admin credentials
- provide means to zip logs and statistics so that complete information can be provided to support when needed
- “be deeply rooted, yet flexible”:
- always deploy from master branch.
- if needed, they may take away something from it.
- everything is a feature! When you start GitHub, you can start it with an enterprise or .com profile, and certain features will be enabled according to the selected profile
- “slow down your busy mind”: by default they deny feature requests from clients, but they do keep track of them for eventual decisions and to notify them if implemented.
After lunch there was a session of lighting talks and some more presentations.
Ernesto Tagwerker presented “The Lean Startup Hacker” where he presented some Lean Startup principles, so that products would get a better product-market fit and decrease project failures.
He emphasized that we do agile development but the whole process follows the waterfall model: we plan, develop, release betas and ship it. When shipped, we face the market and contrast if our perceptions were correct, but we do not get quick feedback if considering the whole process. Lean Startup methodology attempts to fix this:
Lean Startup focuses on apprenticeship validated with objective results from market. Development and client validations should be performed simultaneously. We can create hypothesis and design experiments to validate them against the market.
How do we validate ideas against the market?
- we can create a smoke test, ex.: a login page to see how many people would really apply to certain product
- perform AB Testing
- collect useful metrics
- perform cohort analysis
“Ruby (sometimes) sucks” was a talk about Go programming language presented by Krzysztof Kowalik and Pablo Astigarraga.
They started defining concurrency (processes use the same resource for the period of time assigned to them) and parallelism (every process has its own resources). Ruby has no concurrency and cannot deal with high performance computing. If we need to perform such tasks, we use C-extensions, but are difficult to maintain. Another alternative would be to use rubinius, JRuby or… develop in another language.
Go is a static typed language that provides message passing and concurrency. Provides goroutines that are lightweight threads that communicate via channels. Data is shared via messages. If interested on learning a bit more on Go concurrency patterns, the presenters recommended to check Rob Pike’s talk on GoogleIO 2012. Sounds interesting? Would try it? Go on and explore the docs!
We all heard about DevOps. Augusto Becciu presented “Infrastructure as Ruby code” where he introduced us to Chef.
At first he stated that managing infrastructure as code is a consequence of consumption growth and services complexity, which requires horizontal scalability to keep reasonable costs. In such an infrastructure, resources should be ephemeral, provisioning should be immediate and require APIs to control it.
How do we apply software engineering practices to system administration and operations to get automation, repeatability, agility and scability?
Chef provides configuration management, system integration and idempotence. Receipts are coded in Ruby, and you should take care that execs are idempotent.
Last talk was presented by Steve Klabnik and was about the importance of philosophy and humanities for us. He stated that we build software for people, so we should not care just about the tech side, but also try to better understand people. He also presented several examples about how some concepts we are familiar with at software, are also explored on other fields. Learning about them brings us different perspectives and new ideas.
