RubyConf 2017

Rubyconf 2017 was held this year in New Orleans.  There were nearly 60 keynotes and presentations from four tracks over three days.
Wednesday 15 November. Opening keynote from Matz, cautious of making any divisive changes to Ruby now that it is nearly 25 years old.  Significant progress this year on a register based VM rewrite that should result in ambitious performance improvements.  Unicode 10 support due this year in Ruby 2.5, but features such as frozen strings by default, tail recursion optimization, guilds and type support are still on hold pending more community feedback.
Minqi Pan with an wildly innovative approach to packaging application binaries using a custom Ruby integrated with a virtual file system.
Triptych of presentations on the future of Ruby by Justin Searls, Jason Charnes and Eric Weinstein.  First Justin with a retrospective of influential Ruby conference presentations, then Jason with a bedtime story exhorting rubyists to study other ecosystems, maintain gems and teach; finally Eric touching on Crystal, Opal, WebAssembly and Guilds.
Closing keynote by Chad Fowler as entertaining as ever, drawing on his polyglot experience at Wunderlist to suggest that to build systems that will last use cells that can easily be replaced.
Thursday. Kevin Deisz exploring the Ruby 2.3 API underpinning BootSnap compilation caching, writing his own compiler macros and a math macro language targeting YARV.  Daniel Azuma of Google demonstrating how surprisingly simple it is to build a command line Ruby debugger with the TracePoint API. Andrew Metcalfe of Stripe discussing the challenges of performing static analysis on a 1M lines of Ruby spaghetti and how to leverage Ruby autoload without Rails. Evening lightning talks including Cameron Dutro, Noah Gibbs and Akira Matsuda.
Friday. Another inspring keynote by Sandi Matz: teamwork requires being your best self.  Aaron Patterson’s ‘impossible’ compacting garbage compiler with savings unknown. Yusuke Endo demonstrating his obfuscated quines. Tekashi Kokubun trying to explain the many complexities and tradeoffs of YARV-MJIT.
In summary Ruby is a mature and constrained language: performance improvements will continue but new feature adoption will be conservative. Ruby will continue to face increased competition, but its focus on programmer productivity keeps it relevant.

Arbre vs React

Arbre is a component based server side DOM rendering library written in Ruby.  Arbre was extracted from Active Admin from 2011-2012  but has not gained widespread use elsewhere.  As of September 2017 there were around 4M downloads to date from RubyGems and barely 450 stars on GitHub.

class Panel < Arbre::Component
  builder_method :panel

  def build(title, attributes = {})
    super(attributes)

    h3(title, class: "panel-title")
  end
end

React is a component based isomorphic DOM rendering library written in Javascript.  npm downloads have reached 40M in the past couple of years and the project has 75,000 stars on GitHub: it’s no contest really.  If you prefer Ruby over ES6 an Opal wrapper is available as hyper-react .

class App < Hyperloop::Component
  render(DIV) do 
    MainNavigation {} 
    PageContents {} 
    Footer {} 
  end
end

The APIs for both are relatively simple.

Arbre has builder_method to register components.  Each component has a build method which adds tags to an Arbre::Context that is eventually output using to_s.

React components have a render method that adds elements to a virtual DOM that is synchronized with the browser DOM as needed.

The most obvious difference is that Arbre does not integrate Javascript event handlers: it uses an unobtrusive approach that leaves registering event handlers to accompanying ES6/Coffeescript/Opal files.

Being exclusively server-side means that Arbre can and has been used with ActionView helpers and templates.  There are bugs but it mostly works.  Arbre is relatively simple and provides what Active Admin needs without further dependencies.

React components are careful about maintaining state and re-render when state is changed.  Arbre components get re-instantiated for each request and are more ad hoc.

Is anything to be learned from this comparison?  The prospects of widespread adoption of Arbre are slim to none.  An increasing number of developers are going to be looking to use a Rails admin framework with React, and that is where opportunity lies.

TIOBE Index for August 2017: A new set of languages is gaining ground…

TIOBE replaces their index content each month, so I quote:

“The top programming languages are in a long term decline: both Java and C have all time low scores in the TIOBE index. And almost all of the other top 10 languages are going down as well year to year. So what languages are taking advantage of this? It is all happening down in the charts around position 40. A new set of languages is gaining ground, notably Crystal (#32), Kotlin (#41), Clojure (#42), Hack (#43) and Julia (#46). Especially Crystal with its jump from position 60 to 32 in one month is doing very well. The Crystal programming language is a statically typed Ruby variant. Since it is compiled it is superfast and has a small memory footprint without losing the feeling of being easy to use. It seems worthwhile to give it a try.”

Year 7 with Rails

In my seventh year with Rails I started allocating ’20% time’ to maintenance of Active Admin and related open source gems.  As the universe of web technologies continues to expand and fragment there has been increasing acknowledgement at GitHub and elsewhere of the stresses on volunteer contributors and the consequent rise in the number of projects falling into disrepair.  Active Admin at least now has an official 1.0 release and timely support for Rails 5.1.
On the plus side competition and the exodus from Rails has brought back innovation, most notably Rails 5.1’s integration of NPM, Yarn and Webpack.  Beyond Rails in the wider Ruby community an object-functional style of programming is gaining popularity, championed by dry-rb and embraced by Hanami and Trailblazer.
This year has been one of considerable progress (and hype) around containers and microservices.  Microservices are not without tradeoffs but Docker containers have proven themselves useful in both development/CI and production.
At my employer our codebase has reached 50kloc, now 60% componetized into gems, but a new joint venture has doubled our infrastructure and provided incentive to switch to Docker (and Elastic Beanstalk).  Containerizing legacy applications is not always trivial, however, as adopting a 12-factor approach means simplifying and standardizing sometimes disparate logging and configuration solutions, as well as changing to process supervision in a stripped down POSIX environment instead of a full blown Linux host.  Our monitoring stack now includes Pingdom, Airbrake, Loggly, PagerDuty, Skylight, (CloudWatch) and Librato.  Moving CI to Docker has been challenging, with initially only CodeShip providing a SaaS solution with parallel tests each with multiple sets of containers.
Looking forward Rubyconf last November continued to raise hopes that performance and concurrency will be improved… eventually.  Meanwhile there are numerous projects working on integration with compiled languages: helix with Rust, swig with C/C++, Loren Segal’s gorb with Go, and rubex.  Crystal has gained attention as a Ruby-ish experiment on LLVM with its own MVC frameworks.
On the front end React may now be a ‘safe’ choice for front end development but possibly disruptive innovation continues with VueJS, CycleJS and Elm.  The next twelve months will see either our further adoption of React on Rails or a shift to a different approach.

RailsConf 2017, Phoenix, AZ

Tuesday. Day 1. Keynote by DHH on belief systems. Fascinating talk by Lance Ivy on JSON Web Tokens, Justin Weiss on sessions, Dave Tapley with an entertaining exploration of VueJS, ActionCable and image processing. Eileen Uchitelle with a much anticitpated presentation on adding a significant feature (SystemTestCases) to Rails. Alex Kitchens with a great primer on using Git to explore the history of the Rails codebase. Finally Sam Phippen, now with Digital Ocean, in much better health than last year, giving an upbeat tour of fixing some RSpec issues.

Wednesday. Day 2. Justin Searles keynote with a tongue-in-cheek programmer personality test inspired by Myers Biggs. Back to back presentations on Elm, Phoenix, React and Helix highlighting various Rails related technologies. Nate Berkopec with clear and practical guidance on configuring app servers on Heroku or elsewhere. Evening lightening talks, most notably Isaac Sloan building a Crystal Kemal blog in five minutes.

Thursday. Three talks on distributed teams, including Maria Gutierrez, Glenn Vanderburg, formerly of Living Social, and David Copeland of Stich Fix. Simon Enskilden on the decision at Shopify to embrace flash sales and scale from MySQL sharding to multi-datacenter ‘pods’. Tony Drake pitching his active_reporting gem, then Nate Berkopec and Eilieen Uchitelle again with Rafael Franca and Richard Schneeman on a performance panel before the final keynote from Aaron Patterson with his traditional trolling of DHH and, eventually, h2o with Rack 3.0.

Active Admin 1.0

Note: This post is by Varyonic, not the ActiveAdmin organization.

So after nearly seven years Active Admin 1.0 is out. It has been a long and sometimes uncertain journey of which I have witnessed only part. The original author has moved on, subsequent maintainers have burned out, changed jobs, started families… The bug list remains longer than we would like, the features list remains longer than we can handle, but Active Admin has been in production use for years at companies, NGOs and agencies, and there is commitment to keeping the project alive through quiet pragmatism rather than grand plans.

Not all of us have the time, money, or even need for the next shiny thing, and even if Active Admin sometimes cuts across ‘the Rails Way’ it can be a significantly productive tool. I encourage you to give it a try, to upgrade if you are already using it, to give us feedback if you find issues. General help is available on StackOverflow (tag #activeadmin); search the GitHub issues, both open and closed (~5,000 in total), before submitting anything new. If you are using Active Admin regularly consider looking through the code, issues and the commit log, maybe you will be inspired to contribute, even if just documentation or translations. If you are working for an agency with multiple customers you may be able to provide valuable insight and encourage adoption.

So thank you to all 500+ contributors so far and especially Timo for the past couple of years, here’s to the next 1M downloads.

Developer Cloud Tools Ripe For Consolidation

A dogfight is evolving for developer cloud tools.

The dominant player recently has been GitHub, raising $400M… GitHub achieved developer mindshare by giving away free hosting to open source projects such as Rails.

A close follower of GitHub has been Atlassian, a strong enterprise tools vendor with products such as JIRA, that bought BitBucket and offered free private git hosting. Atlassian went public end of 2015.

Other startups in this space that were popular a few years ago but have lagged include Unfuddle and CodebaseHQ.

More recently GitLab attended Y-Combinator and gained funding, building on an open source UI with many of the features of GitHub.

Large public cloud (IaaS/PaaS) vendors are now increasingly encroaching on this space. Why? Because the trend towards dev-ops and infrastructure as code is bringing developers more and more into the realm of infrastructure management. Projects like Docker are driving increasing commoditization of cloud infrastructure. To create and capture value IaaS/PaaS vendors need to gain and hold developer mindshare by offering more and better tools.

Amazon AWS has added CodeCommit.

AWS’s strongest competitor, Microsoft Azure offers hosted Visual Studio with free private git hosting and kanban boards for small teams, an attractive option to developers already used to Microsoft’s ecosystem.

Similarly, IBM has Bluemix DevOps Services, f.k.a. JazzHub that includes Rational Team Concert.

Google has now added Source Repositories that sync with GitHub and BitBucket and include a browser based source editor.

Meanwhile innovation in the developer tools space has shifted from repository hosting and issue tracking to continuous integration, cloud IDEs and developer chat.

CI startups include Travis CI, Circle CI and CodeShip, which recently raised a $7M series A. Atlassian BitBucket recently added CI pipelines. AWS has added CodePipeline/CodeDeploy for CI/CD.

In the cloud IDE space the strongest player appears currently CodeEnvy (IBM?). AWS has acquired Cloud9 (interestingly Atlassian was an early investor and customer) and GitLab has announced a collaboration with Koding.

Chat has been getting lots of attention recently because of Slack. Atlassian acquired HipChat. GitLabs partnered with Mattermost. Gitter? Microsoft has Skype for Business.

Given the forces at work more consolidation seems likely. Will Atlassian and GitHub remain independent from AWS, Google or IBM?

Year 6 with Rails

In my sixth year with Rails the Ruby community has been experiencing a sea change: gem innovation has peaked and leading Rails developers have been moving on to JavaScript 6 Node, Dockerized microservices in Go, functional Clojure on the JVM or highly concurrent Elixir Phoenix on the fault tolerant Erlang VM. Despite these defections Ruby adoption has resurged (as, coincidentally, has Java) given new versions that have improved garbage collection and performance. Rails 5 has embraced concurrent-ruby and websockets, while HTTP/2 looks set to drive further significant change to all web application frameworks in the near future.

Meanwhile our in-house multi-currency e-commerce solution has grown to 45kloc, 2,100 tests and nearly 100 gem dependencies thanks to ever expanding integration with fraud detection services, fulfillment providers, payment gateways, email marketing solutions and an autodialer. Between daily business requirements we have been addressing technical debt by straggling to Ruby 2.2, Rails 4.2, RSpec 3.4 and ActiveAdmin 1.0.0.pre2. We have adopted CBRA and gemified the persistence core of the application. New gems adopted have included VCR, Wisper and React on Rails.

On the tools side this year has seen widespread adoption of Slack for distributed teams, but we have stuck with Atlasssian HipChat, configuring integration with Airbrake for production exceptions, Assembla for tickets, BitBucket for code reviews, CodeShip for CI and Coveralls for test coverage. Increasingly global sales have raised expectations of operations to provide 24×7 uptime, monitored by PagerDuty and requiring MySQL hot backups.

‘In Container’ Rails Development With Docker

Why Docker? Because it promises to make dev-ops easier. Dockerizing an existing production environment is not trivial, moving development to Docker is perhaps a useful stepping stone. It might also make developer on-boarding easier but I haven’t tried that yet.

Docker can be installed on OS X in various ways, most notably Docker Toolbox or homebrew. I was previously using docker-machine with Parallels but recently I discovered Dlite which simplifies using docker by creating a local OS X docker.sock that forwards requests to the docker VM. Dlite also sets up a an NFS server that exports /Users to the VM. Instead of VirtualBox or Parallels Dlite leverages a lightweight hypervisor called xhyve which requires Yosemite and hardware virtualization support (sysctl kern.hv_support). Note that as of writing Docker for Mac and Windows in public beta is using a similar approach.

With Dlite started I can get a usable bash session with:

docker run -v /Users:/home -it ruby:2.2 bash

I can then cd to the project directory and bundle.

To run browser based tests I was previously building a docker image with Xvfb, Chrome and Selenium Server installed. Recently, however, I found a different approach that uses standalone selenium-server as another docker service. On a Mac workstation installing selenium-server as a service is as simple as

brew install selenium-server-standalone chromedriver
selenium-server

Once tests are passing with a local selenium-server then adding selenium/standalone-chrome to docker-compose.yml and running browser based tests inside the container is quite achievable. The location of the selenium-server is exported to the app container as SELENIUM_PORT, eg. tcp://172.0.0.5:4444

Posts navigation

1 2 3 4 5 … 11 12 13
Scroll to top