A FEW WORDS WITH GREG BELL, ACTIVE ADMIN’s CREATOR

The Challenge starts this Sunday (July, 1) and before you’ll make your first RubyOSC pull request, find out what Greg Bell, the guy behind the Active Admin and the Chief of our Expert Panel, thinks about the whole fuss ;) 

RubyOSC: Hi Greg! It’s really really great to have you on board! By the time of the interview, we have around 600 registrations for the RubyOSC and the amount is rapidly growing(update: by the time of the post it’s almost 700;). How do you feel knowing that so many bright Ruby minds from all over the world is going to contribute to your project?

Greg: It is both very exciting and incredibly overwhelming. I am humbled that over 600 people from around the world find the project valuable enough to be willing to invest their own time to help it grow. I am continually impressed by the Ruby community’s effort to build high quality open source tools. I am very excited to see what the outcome is!

RubyOSC: Active Admin was launched as free software about a year ago. What was the motivation for kickstarting that effort?

Greg: Although the project was released publicly a little over a year ago, it actually started way back in 2008. The primary motivation for Active Admin was and still is to create reusable components to build usable back office applications faster. I was running a consulting company that needed to quickly build backend applications for our clients, so I built an internal toolset called the Citrus Modules. It would look vaguely familiar to anybody who is currently building applications with Active Admin.

In 2010 I joined a company called VersaPay where we built enterprise payments and invoicing software. As with my previous consulting company, back office applications were needed for the VersaPay operations teams to manage their clients and transactions. To address this need I decided to rebuild the Citrus Modules as an open source project. I looked back at all my consulting work, extracted the most common patterns and codified them into a framework that is now known as Active Admin.

RubyOSC: What have you found most challenging so far in developing Active Admin?

Greg: The most challenging part of developing Active Admin has been building the community. I started the project because I love to design and build software. What I wasn’t expecting was the amount of time required to track down issues, write documentation, and help the community grow. I think that community management has been the biggest learning area for me. It’s exciting to see a group of developers from around the world work together to create a great piece of software.

RubyOSC: What kind of issues do you feel are the most pressing at the moment?

Greg: The most pressing issue for Active Admin is quality documentation. While docs for Active Admin exist, there is a lot of functionality that is completely undocumented. Over the course of the next few months, I would love to see this change.

Also, there is a lot of refactoring to be done. The core team is actively working on decoupling the components within Active Admin so that it is more composable. Completing this task will help us deliver the next generation of features on our roadmap.

In addition, there are many small Github issues that have been sitting in our bug tracker for too long. To be able to bring down the number of those issues over the next month would be a huge accomplishment.

RubyOSC: Software development is a never ending story. Are there any particular new features that you would like to see added to Active Admin?

Greg: While endless feature ideas exist, I feel that there are 3 major new features that Active Admin needs.

The first is an ORM adapter layer. Instead of only connecting to Active Record models, we want the project to be able to connect to any data source (ORM or otherwise). By far, this is the most requested feature and has been on our radar since the project first started. To implement this feature some refactoring needs to be done, but we can imagine an abstract data adapter that would give immense power to Active Admin. If data adapters are simple to write, there could be all sorts of interesting tools created using Active Admin

The second is expanding on existing UI components. For example I would love to see built-in inline tabs, modal windows, inline editing, and other reusable components that would allow for richer user interfaces to be generated quickly.

Finally, I would like to see us develop a more formal plugin layer which would make it easy for the community to create plugins without having to add them to the core Active Admin codebase.

RubyOSC: As a Ruby practitioner, are they any practices you wish the contributors to follow?

Greg: There definitely are! We have a documented process for submitting pull requests to Active Admin available at github.com/gregbell/active_admin/blob/master/CONTRIBUTING.md. Basically, we use Cucumber and RSpec for testing. Since Active Admin supports any version of Rails > 3.0, we have an extensive test suite that runs against all the supported versions. We love, trust and use TravisCI extensively.

Also, code quality matters! We want the project to live on, so any code we write today will have to be maintained tomorrow. I am not interested in maintaining poorly written code, so we want to work together as a community to write the best code possible.

RubyOSC: You are the Chief of our Expert Panel and will have the right to decide one of the winners - any tips or hints for the devs?

Greg: I am going to be looking at overall contributions to the project, not just the new features that are added. Writing clean, well factored and documented code (or even just writing documentation!) will be just as important as writing a new feature.

We also have a ton of open issues on Github, so triaging solved or dead issues will also help you get noticed.

RubyOSC: Thank you! ;) 

Active Admin       Active Admin’s GitHub       @gregbell       @RubyOSC       RubyOSC page      RubyOSC facebook