Tag: ActiveAdmin
Active Admin monthly downloads nearly doubled last year
According to this blog post Active Admin monthly downloads nearly doubled last year to almost 3,000 times a day. Part of that can probably be attributed to increasing use of continuous integration, but more interesting is that Active Admin has outpaced the competition. Possible contributing factors include three releases, including a 1.0 release that coincided with RailsConf and was featured by Ruby Weekly, a GoRails episode by Chris Oliver at the end of 2016, and the blog post by Charlie Gleason on using Active Admin as a back end to a React application, that has been discovered and tweeted by new fans repeatedly. I’ld love to think that timely responses to GitHub issues and pull requests and StackOverflow answers have helped also, along with the curated wiki and continuing contributions by plugin authors. Also there have been Japanese blog posts and activity so more adoption there. At this point Active Admin has 7,800 GitHub stars and 2.9M downloads, it will interesting to see how things are another year from now.
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.
Year 7 with Rails
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.
From Rails 3.2 to Rails 4.2 If We Really Must
Rails 5 is almost upon us and we’ve spent the last two months, amongst other things, moving our 45,000 lines of Rails e-commerce code from 3.2 to 4.2. For better or worse the move has been less about embracing new features and more about compliance and maintaining security bug fix support. The move has been a rapid succession of stages, from 3.2 to 4.0 in development, 4.1 in production, and finally 4.2 in production. Overall it has been a significant effort and a learning experience.
The biggest challenge we encountered was not fixing our 175 models and 40 controllers, but dealing with our nearly 100 open source gem dependencies. The project started from a proof of concept elegantly scaffolded with ActiveAdmin’s DSL and has accreted functionality and third party interfaces for the past four years. ActiveAdmin remains the leading Rails admin interface, but with the departure of Greg Bell momentum has slowed. Sean Linsley, Timo Schilling and others have put a significant amount of effort into answering questions and applying bug fixes, but the ambitious 1.0 milestone has remained unmet for two years, and gem releases have been infrequent. To update ActiveAdmin first we switched from stable 0.6 gems to the master branch in GitHub, replacing meta-search with ransack, then we worked our way down the master branch to 1.0.0.pre1 in 90 day increments, isolating and working around the issues that impacted us (#2233, #2679, #2771, #3038/#3324, #3145, #3147, #3486, #3591, #3776, #3784). Critical to this effort was our test suite coverage, which remains a disappointing, but so far adequate, 90% (and yes, we upgraded to RSpec 3.x as well).
Apart from gem dependencies the most dramatic issue updating Rails was the breakage of non-strict mode used with our old MySQL database (and thus nearly everything). For Rails 4 we needed to configure ‘strict: false’ to ignore our true mode setting in the database, then with Rails 4.2 this changed again and we needed to explicitly set variable sql_mode to the required value.
So what has Rails 4.x brought us? ActiveRecord foreign keys and enums, but we embraced the foreigner and enumerize gems long ago. Spring, but we so loved Zeus. secrets.yml but we already use environment variables and dotenv. Web Console, but we are happy with Better Errors and Pry. An improved cookie serializer that fouled up our ‘seamless’ rolling production upgrade. Autoloader vexation. Millisecond DateTime rounding errors (or is that due to OS X?). ActionMailer::Preview and ActionMailer#deliver_later, but we have already built out more sophisticated solutions. Strong parameters for sure. New bin/ scripts. Stricter routing with Patch. An end to ActiveRecord’s old dynamic finder API and tweaks to callbacks and ActiveRecord::Relation. Better performance, please, from Aaron’s AdequateRecord. ActiveJob as a wrapper for Resque or Sidekiq. ActiveSupport::Testing::TimeHelpers. Perhaps for us most importantly a step closer to greater concurrency with Puma (and LiveStreaming?), Sidekiq, Celluloid, who knows?
More detailed ActiveAdmin update notes