Yesterday (Tuesday, August 28) the Amsterdam.rb meetup, for Ruby enthusiasts, took place at TQ, Muntplein. Two very different talks made for an enjoyable evening.
In Rails… Still?!?!, PJ Hagerty (@aspleenic) told us why Ruby on Rails still prevails, after all these years, and abundance of alternatives. The talk's timing couldn't be better coordinated with David Heinemeier Hansson's tweet that evening:
The reason you shouldn't use Rails is that the community is full of experienced, senior developers who might have families and therefore are EXPENSIVE. No, listen, you should pick whatever new thing those 20-year olds without demands are using 😂 #StartupAdvice #HackerNewsHits pic.twitter.com/WDSYD0qJ9a— DHH (@dhh) August 28, 2018
A devrelate.io founder, PJ previously worked with Engine Yard. These days he runs the CodeDaze conference in Buffalo (we're giving away a free ticket!) and pushes prompt, an organisation that promotes a much needed discussion about mental health in tech.
What's the right framework?
"Rails was meant to abstract away from all the deep seeded Sequel stuff. Nowadays Rails is huge, it's gigantic. Its 'magic' parts are simultaneously great for speeding up development and clogging. Who needs Turbolinks or Coffeescript? What are Turbolinks even?"
"Bootcamps adopted Rails to teach people to program because the learning curve isn't as steep as with other languages or even Ruby itself. But is Rails the best framework still?"
Sinatra was designed and developed by Blake Mizerany in 2007 and currently maintained by Konstantin Haase (Travis CI). "Sinatra is great with routes and APIs. It's quicker than Rails."
With Sinatra you can plug in Rails elements, like an ActiveRecord database. "Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using Rails."
By means of a joke, Konstantin Haase developed micro-framework Almost Sinatra, bringing down the lines of code to 6 (!).
Padrino is Rails' younger, cooler sibling. "It's beefier than Sinatra, but still lightweight. Unlike with Sinatra it's not easy to convert your Padrino app to Rails when you find yourself using more Rails elements."
Cuba is a Rack based framework, much like Sinatra and Padrino. "It's documentation was great, at a time where Rails' and Ruby's Docs felt old and convoluted." Michel Martens threw Cuba on GitHub with the idle hope other people would help make it fly.
Hanami (previously: Lotus) is no micro-framework like the others. "Luca Guidi thought of Hanami as a direct competition to Rails. Which wasn't realistic. I would urge you to contribute to Hanami though", says PJ.
With the Volt framework your Ruby code runs both on the server and the client (via the Opal gem). The DOM automatically updates as the user interacts with the page, which, theoretically, makes Volt really fast. "Its tight coupling to MongoDB, among other things, sadly put a brake on Volt's adoption."
Nick Sutterer's Trailblazer was meant as an abstraction layer on top of Rails. "Trailblazer was and is very much what Nick wanted Rails to be, but couldn't get commited to Rails core."
And then there's the Phoenix framework. Chris McCord wanted this MVC framework for Erlang, where Elixir is based on Erlang, used mostly for large scale backend systems. And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."
"In summary, we 'still' use Rails as it works just fine. It has helped a lot of people get into programmming. If you need something more fit for prototyping you can always give Volt or Sinatra a try. If you need speed, try Trailblazer. But don't discard a framework just because it's 'old'."
What is metaprogramming, anyway?
In Metaprogramming for generalists Chris Salzberg (@shioyama), tries to define what metaprogramming is and how more people could make use of this thing most programmers refer to as a "bag of tricks".
We lack a clear definition. Some argue that if programming is writing code, metaprogramming is writing code that writes code. Wikipedia claims it's a technique in which computer programs have the ability to treat programs as their data. Others say metaprogramming is a way for a program to find out things about itself, or other programs.
Chris is the author of the Mobility translation framework for Ruby, and a frequent Open Source contributor. He works at Degica, in Japan, and is originally from Canada. He gave this talk at last week's EuRuKo conference in Vienna as well, in case you're looking for a high-quality recording:
"We label methods in Ruby and call those metaprogramming,
eval is probably the most commonly known. Many developers see metaprogramming as a fringe topic within ‘normal programming’." Suffice to say Chris sees it as central to the Ruby community.
"The role it plays in our ecosystem is filling the gaps between the language and our applications, it’s the libraries and gems that almost blend into the underlying programming language as they tackle vital and common problems. But why is metaprogramming so prevalent in our libraries, and virtually non-existent in our application code?"
"Gems generalise problems into components we can use in all our applications." Wikipedia says on 'generalisation': formulation of general concepts from specific instances by abstracting common properties. Chris shows us a concrete example of generalizing solutions by creating a simplified version of the Equalizer gem. Honestly, I needed to see his talk a second time to grasp what he's doing, so naturally I'm very happy with the EuRuKo recording.
Chris quotes Jeremy Evans in ’The Development of Sequel’ (May 2012): “One of the best ways to write flexible software is to write generic software. Instead of designing a single API that completely handles specific case, you write multiple APIs that handle smaller, more generic parts of that use case and then handling the entire case is just gluing those parts together.” And that glue, that's metaprogramming.