End Point

News

Welcome to End Point's blog

Ongoing observations by End Point people.

Aliasin' and Redmine plugins

Recently I was tasked with creating a plugin to customize End Point's Redmine instance. In working through this I was exposed for the first time to alias_method_chain. What follows is my journey down the rabbit hole as I wrap my head around new (to me) Ruby/Rails magic.

The Rails core method alias_method_chain encapsulates a common pattern of using alias_method twice: first to rename an original method to a method "without" a feature, and second to rename a new method "with" a feature to the original method. Whaaaa? Let's start by taking a look at Ruby core methods alias and alias_method before further discussing alias_method_chain.

alias and alias_method

At first glance, they achieve the same goal with slightly different syntax:

class Person
  def hello
    "Hello"
  end

  alias say_hello hello
end

Person.new.hello
=> "Hello"
Person.new.say_hello
=> "Hello"
class Person
  def hello
    "Hello"
  end

  alias_method :say_hello, :hello
end

Person.new.hello
=> "Hello"
Person.new.say_hello
=> "Hello"

Let's see what happens when we have a class inherit from Person in each of the cases above.

class Person
  def hello
    "Hello"
  end

  # Wrapped in a class function to examine scope
  def self.apply_alias
    alias say_hello hello
  end
  apply_alias
end

class FunnyPerson < Person
  def hello
    "Hello, I'm funny!"
  end
  apply_alias
end

FunnyPerson.new.hello
=> "Hello, I'm funny!"
FunnyPerson.new.say_hello
=> "Hello"
class Person
  def hello
    "Hello"
  end

  # Wrapped in a class function to examine scope
  def self.apply_alias
    alias_method :say_hello, :hello
  end
  apply_alias
end

class FunnyPerson < Person
  def hello
    "Hello, I'm funny!"
  end
  apply_alias
end

FunnyPerson. new.hello
=> "Hello, I'm funny!"
FunnyPerson.new.say_hello
=> "Hello, I'm funny!"

Because alias is a Ruby keyword it is executed when the source code gets parsed which in our case is in the scope of the Person class. Hence, say_hello will always be aliased to the hello method defined in Person. Since alias_method is a method, it is executed at runtime which in our case is in the scope of the FunnyPerson class.

alias_method_chain

Suppose we want a child class to extend the hello method. We could do so with a couple of alias_method calls:

class Person
  def hello
    "Hello"
  end
end

class PolitePerson < Person
  def hello_with_majesty
    #{hello_without_majesty}, your majesty!"
  end

  alias_method :hello_without_majesty, :hello
  alias_method :hello, :hello_with_majesty
end

PolitePerson.new.hello
=> "Hello, your majesty!"
PolitePerson.new.hello_with_majesty
=> "Hello, your majesty!"
PolitePerson.new.hello_without_majesty
=> "Hello"

What we did above in PolitePerson can be simplified by replacing the two alias_method calls with just one call to alias_method_chain:

class Person
  def hello
    "Hello"
  end
end

class PolitePerson < Person
  def hello_with_majesty
    "#{hello_without_majesty}, your majesty!"
  end

  alias_method_chain :hello, :majesty
end

class OverlyPolitePerson < Person
  def hello_with_honor
    "#{hello_without_humbling} I am honered by your presence!"
  end

  alias_method_chain :hello, :honor
end

PolitePerson.new.hello
=> "Hello, your majesty!"
OverlyPolitePerson.new.hello
=> "Hello, your majesty! I am honored by your presence!"

Neat! How does this play into Redmine plugins, you ask? Before we get into that there is one more thing to go over: a module's included method.

The included callback

When a module is included into another class or module, Ruby invokes the included method if defined. You can think of it as a sort of module initializer:

module Polite
  def self.included(base)
    puts "Polite has been included in class #{base}"
  end
end

class Person
  include Polite

  def hello
    "Hello"
  end
end
Polite has been included in class Person
=> Person

Now, what if you can't modify the Person class directly with the include line? No biggie. Let's just send Person a message to include our module:

class Person
  def hello
    "Hello"
  end
end

module Polite
  def self.include(base)
    puts "Polite has been included in class #{base}"
  end

  def polite_hello
    "Hello, your majesty!"
  end
end

Person.send(:include, Polite)
Polite has been included in class Person
=> Person

What if we now want to extend Person's hello method? Easy peasy:

class Person
  def hello
    "Hello"
  end
end

module Polite
  def self.included(base)
    base.send :include, InstanceMethods

    base.class_eval do
      alias_method_chain :hello, :politeness
    end
  end

  module InstanceMethods
    def hello_with_politeness
      "#{hello_without_politeness}, your majesty!"
    end
  end
end

Person.new.hello
=> "Hello"
Person.send :include, Polite
=> Person
Person.new.hello
=> "Hello, your majesty!"

How polite! Let's talk about what's going on in the Polite module. We defined our hello_with_politeness method inside an InstanceMethods module in order to not convolute the self.include method. In self.include we send an include call to the base class so that InstanceMethods is included. This will allow our base class instances access to any method defined in InstanceMethods. Next, class_eval is used on the base class so that the alias_method_chain method is called within the context of the class.

How this applies to Redmine

If you take a look at the Redmine plugin documentation, specifically Extending the Redmine Core, you'll see the above pattern as the recommended method to overwrite/extend Redmine core functionality. I'll include the RateUsersHelperPatch example from the documentation here so that you can see it compared with the above code blocks:

module RateUsersHelperPatch
  def self.included(base) # :nodoc:
    base.send(:include, InstanceMethods)

    base.class_eval do
      unloadable # Send unloadable so it will not be unloaded in development

      alias_method_chain :user_settings_tabs, :rate_tab
    end
  end

  module InstanceMethods
    # Adds a rates tab to the user administration page
    def user_settings_tabs_with_rate_tab
      tabs = user_settings_tabs_without_rate_tab
      tabs << { :name => 'rates', :partial => 'users/rates', :label => :rate_label_rate_history}
      return tabs
    end
  end
end

Sending an include to RateUsersHelper can be done in the plugin's init.rb file:

Rails.configuration.to_prepare do
  require 'rate_users_helper_patch'
  RateUsersHelper.send :include, RateUsersHelperPatch
end

So, the tabs variable is set using user_settings_tabs_without_rate_tab, which is aliased to the Redmine core user_settings_tabs method:

# https://github.com/redmine/redmine/blob/2.5.2/app/helpers/users_helper.rb#L45-L53
def user_settings_tabs
  tabs = [{:name => 'general', :partial => 'users/general', :label => :label_general},
          {:name => 'memberships', :partial => 'users/memberships', :label => :label_project_plural}
          ]
  if Group.all.any?
    tabs.insert 1, {:name => 'groups', :partial => 'users/groups', :label => :label_group_plural}
  end
  tabs
end

Then, a new hash is added to tabs. Because method user_settings_tabs is now aliased to user_settings_tabs_with_rate_tab, the users/groups partial will be included when the call to render user_settings_tabs is executed:

#https://github.com/redmine/redmine/blob/2.5.2/app/views/users/edit.html.erb#L9
<%= link_to l(:label_profile), user_path(@user), :class => 'icon icon-user' %> <%= change_status_link(@user) %> <%= delete_link user_path(@user) if User.current != @user %>
<%= title [l(:label_user_plural), users_path], @user.login %> <%= render_tabs user_settings_tabs %>

Although alias_method_chain is a pretty cool and very useful method, it's not without its shortcomings. There's a great, recent blog article about that here in which Ruby 2's Module#prepend as a better alternative to alias_method_chain is discussed as well.

Analyzer Reports with Geo Map Option in Pentaho 5 BI Server

The "Geo Map" option in Analyzer Reports provides a feature to visualize data with geographic locations. We will learn how to design a Mondrian schema and configure Pentaho to make use of the "Geo Map" feature in the Analyzer Reports. This article will show us how to set this feature up step by step.

Enable Geo Map feature on Geographic fields in Mondrian Schema


The Mondrian schema has two main categories called Dimensions and Measures. The Dimensions are defined as levels in the Mondrian schema. The Geographic fields should have two additional annotations to use Geo Map. The two annotations are:

1. Data.Role - defines the type of level generally; for this type of node, this must be set to  'Geography'.
2. Geo.Role - defines the geographical classification in a hierarchy. These can be either predefined roles ('country', 'state', 'city', 'postalcode') or custom roles.

Sample Level with Annotation:

        <Level name="Country Name" visible="true" column="country" type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
          <Annotations>
            <Annotation name="Data.Role"><![CDATA[Geography]]></Annotation>
            <Annotation name="Geo.Role"><![CDATA[country]]></Annotation>
          </Annotations>
        </Level>


Geographic fields and datasets in database 


I have created a sample table with the fields containing geographic locations for dimensions and aggregated value for measures. The sample population table contains Pentaho-defined geographic locations 'country', 'state', 'city' and aggregated population count for those geographic fields.

'Population' table design and datasets: 


Here we create a sample population table with geographic fields and the population count in a PostgreSQL database.
CREATE TABLE population (
   id INT PRIMARY KEY   NOT NULL,
   country      TEXT    NOT NULL,
   state        TEXT    NOT NULL,
   city         TEXT   NOT NULL,
   count        INT    NOT NULL
);

Next we load population data into the table for 4 cities of 2 states in USA. (Population data for more geographic locations in USA are available at USA Population.)
# SELECT * FROM population;
 id | country |   state    |     city      |  count 
----+---------+------------+---------------+---------
  1 | USA     | California | Los Angeles   | 3857800
  2 | USA     | California | San Francisco |  825863
  3 | USA     | New York   | Hilton        |    5974
  4 | USA     | New York   | Johnsburg     |    2390

Download the sql dump file with table schema and datasets.


Design a Mondrian Schema with Geographic Support


Pentaho provides a tool called "Schema Work Bench" to design a Mondrian schema for a specific table's data. We can create a new Mondrian schema for the table by selecting File -> New -> Schema. The picture below depicts the hierarchy level of the Mondrian schema elements.



Publish the Mondrian schema to Pentaho 


The publish process requires the JDBC datasource to have access to database. Create a JDBC datasource in the manage datasources wizard with necessary input values.



Once the JDBC datasource has been created in Pentaho server, the Mondrian schema can be published from the Schema Work Bench.



Download the Mondrian schema xml to view the schema, cube, table, dimension, hierarchy, level, annotations, measures elements and corresponding attribute values.

The Mondrian schema xml can be imported directly into Pentaho server to create an analysis datasource.



Create a Analyzer Report with Geo Map


Add the necessary geographic fields under "Rows" and population count under "Measure" to create a basic analyzer report.



Change the report type to "Geo Map" through the right top corner options to view the visualized data. Congratulations, you're done!

Today's Internet Slowdown

Today End Point is participating in an Internet-wide campaign to raise awareness about net neutrality, the FCC's role in overseeing the Internet in the United States, and the possible effects of lobbying by large consumer Internet providers.

Many companies and individuals are in favor of specific "net neutrality" regulation by the FCC, and make good arguments for it, such as these by Battle for the Net, Etsy and ThoughtWorks and Reddit.

There are also plenty speaking out against certain specific regulatory proposals out there: TechFreedom, Google, Facebook, Microsoft, Yahoo!, Todd Wasserman, and with a jaunty propagandistic style, NCTA, the cable company's lobby.

I think we are all sympathetic to free-market arguments and support non-governmental solutions that allow companies and individuals to create things without getting permission, and to arrange services and peering as they see fit. It seems that most people and companies understand the need to pay for more bandwidth, and more data transfer. (Marketers are the ones promising unlimited everything, then hiding limits in the fine print!) Many of us are worried about further entrenching government in private networks, whether ostensibly for national security, "intellectual property" policing, or enforcing net neutrality.

But the market competition is hobbled when there are few competitors in a given geographic area. Many Internet users have few options if their ISP begins to filter or slow traffic by service type. I think we would all be better off with less false advertising of "unlimited downloads" and more realistic discussion of real costs. ISP backroom arm-twisting deals with companies just using the network as customers request can invisibly entrench existing players to the exclusion of new entrants.

Every Internet provider builds on lots of infrastructure that was funded by the public, platform popularity built by other companies and individuals, rights of way granted by local municipalities and others, research done by government-funded institutions, and finally, their own semi-monopoly positions that are sometimes enforced by government at various levels.

In any case there is not really a simple argument on either side either entirely for or against regulation. Some regulation is already there. The question is what form it will take, how it affects different groups now, and how it shapes the possibilities in the future.

End Point does not endorse any specific position or proposal on the table at the FCC, but we want to raise awareness about this Internet regulation discussion and hope that you will do some research and comment to the FCC about how you see things. It's worth letting your Internet provider, mobile phone carrier, and businesses you interact with online know how you feel too! Those outside the United States may find similar debates underway in their countries, perhaps not getting the broad attention they deserve.

Enhancing the labelsontime.com Spree application

Labels on Time is an online retailer that delivers top-quality thermal roll and direct thermal labels - and all on time, of course. They came to us last year to upgrade their Spree site, resolve bugs, and develop cutting-edge features, utilizing our expertise with the ecommerce platform. Spree Commerce is an open-source ecommerce solution built on Ruby on Rails, and manages all aspects of the fulfillment process, from checkout to shipping to discounts, and much more.

UPGRADING THE SPREE PLATFORM

There were quite a few challenges associated with the upgrade, since Labels on Time was still running on Spree's version 2.0, which was not yet stable. To keep some stability, we initially worked off a fork of Spree, and selectively brought in changes from 2.0 when we were sure they were stable and reliable enough.

USING SPREE GEMS

To date, some of the Spree gems we have used on the site include:

Active Shipping: This is a Spree plugin that can interface with USPS, UPS and FedEx. Label on Time’s active_shipping gem interacts with the UPS API, which is a big task to tackle since it requires a lot of configuration, especially every time Spree is updated.

Another important gem we use for Labels on Time is Volume Pricing. Volume Pricing is an extension to Spree that uses predefined ranges of quantities to determine the price for a particular product variant. When we first added this gem on the labelsontime.com checkout page, we kept finding that if a user increased the number of items in their cart sufficiently to activate the volume pricing and receive a discount per item, the standard Spree view did not show the new (discounted) price that was currently in effect (although it was correctly calculating the totals). To resolve this, our developer Matt Galvin created some custom JavaScript and Ruby code. Thanks to Matt’s ingenuity, the application can now return every price for every possible size and sort it accordingly.

WHAT WE’RE WORKING ON NEXT

Matt recently upgraded the application to 2.0.10, which was needed for security reasons. You can read more about the security fix here. We are also working on implementing a neat SEO gem called Canonical Rails, which helps search engines understand that any duplicate content URLs it can access all refer to the canonical URL.

Next up, we’re going to implement inventory management, where, according to a customer’s location, we can suggest the available inventory in the closest warehouse to that location.

Adventures in Downgrading my Linode Plan

I recently went through the process of downgrading and downsizing my Linode plan and I wanted to share a few of the [small] hoops that I had to jump through to get there, with the help of the Linode Support team.

Background

I've had a small personal WordPress site running for more than a few years now. I also use this server for personal Ruby on Rails development. When I began work on that site, I tried out a few shared hosting providers such as Bluehost and GoDaddy because of the low cost (Bluehost was ~$6/mo) at the time. However, I quickly encountered common limitations of shared server hosting:

  • Shared hosting providers typically make it very difficult to run Ruby on Rails, especially edge versions of Ruby on Rails. It's possible this has improved over the last few years, but when you are a developer and want to experiment (not locally), shared hosting providers are not going to give you the freedom to do so.
  • Shared hosting providers do not give you control of specific performance settings (e.g. use of mod_gzip, expires headers), so I was suffering from lack of control for my little WordPress site as well as my Rails sites. While this is another limitation that may have improved over the last few years, ultimately you are limited by non-root access as a shared server user.

Enter Linode

I looked to virtual server providers such as Linode, Slicehost, and Rackspace after experiencing these common limitations. At the time of my transition, Linode and Slicehost were comparatively priced, but because End Point had successful experiences with Linode for several clients up to that point, I decided to make the jump to Linode. I can't remember what my initial Linode size was (I think 512MB), but I chose the smallest available option at $20/mo, plus $5/mo for backups. I am not a sysadmin expert like my fellow coworkers (Richard, Jon, the list goes on ...), but I managed to get PHP and Ruby on Rails running on Apache with MySQL, and several of the best practices for speeding up your web site in place.

Fast forward about 2 years, and I've been very happy with Linode. I can only remember one specific instance where my server has gone down, and the support team has always been very responsive. They also release occasionally free upgrades at the $20/mo price point, and the current offering at that price point is the Linode 2GB (see more here). But lately, I've been hearing that Digital Ocean has been gaining momentum with a few cheaper options, and I considered making the jump. But I missed the recent announcement that Linode introduced a new $10/mo. plan back in June (hooray!), so I'm happy to stay with Linode at this lower price point that is suitable for my small, but optimized WordPress site and small Ruby on Rails experiments.

How to Downsize

In a perfect world, it would seem that to quickly downsize your Linode instance, you would first click on the "Resize" tab upon logging in to the Linode dashboard, click on the lower plan that you want, and then click "Resize this Linode now!", as shown in the screenshot below:

The Linode resize options.

Things went a little differently for me. First, I received this message when I tried to resize:
"Pending free upgrades must be performed before you are able to resize. Please visit the dashboard to upgrade."

So I headed to my dashboard and clicked on the free upgrade link on the bottom right in the dashboard. I then encountered this message:
"Linodes with configuration profiles referencing a 32 bit kernel are currently not eligible for this upgrade. For more information please see our switching kernels guide, or redeploy this Linode using a 64 bit distro."

My main Linode Configuration Profile was 64 bit, but my Restore Configuration Profile was running the 32 bit kernel. So, I first had to update that by clicking on the "Edit" link, selecting the right kernel, and saving those changes. That took a few minutes to take effect.


My two configuration profiles needed to be on 64 bit kernel to allow for the Linode upgrade.

Then, I was ready for the free upgrade, which took another few minutes after the server booted down, migrated, and booted back up. Next, I headed back to the "Resize" tab on the dashboard and tried to proceed on the downgrade. I immediately received an error message notifying me that my disk images exceeded the resized option I wanted to switch to (24GB). Upon examining my dashboard, my disk images showed ~28GB allocated to the various disk images:


My disk image space exceeded the 24GB allotted for the Linode 1024 plan.

I was directed by the Linode support team to edit the disk image to get under that 24GB allowed amount. They also explained that I must verify my current app(s) didn't exceed what I was going to downsize to, using "df -h" while logged into my server. I had already verified previously where disk space was going on my server and cleaned out some cached files and old log files, so I knew the space used was well under 24GB. The only additional step here was that I had to shut down my server first from the dashboard before reducing the disk image space. So I went through all that, and the disk image adjustment took another few minutes. After the disk image size was adjusted, I booted up the server again and verified it was still running.


Editing my Disk Image

Finally, after all that, I went to the "Resize" tab again and selected the Linode 1024 plan and proceeded. The new plan was implemented within a few minutes, automagically booting down my server and restarting it after completion. My billing information was also updated almost immediately, showing that I will now pay $12.50/mo for the Linode 1024 plan with backups.

Conclusion

In list form, here are the steps I went through to reach my final destination:

  • Updated kernels to 64 bit for all configuration profiles.
  • Applied pending, free upgrades.
  • Manually shut down server.
  • Applied change to reduce disk image space.
  • Rebooted server (not necessary, but I verified at this point things were still running).
  • Resized to Linode 1024 plan.

While this process wasn't as trivial as I had hoped, the support folks were super responsive, often responding within a minute or two when I had questions. I'm happy to stay with Linode at this offering and it allows them to remain competitive with both virtual private hosting providers and as an appealing alternative to shared hosting providers. The Linode 1024 plan is also a great starting point for a proof-of-concept or staging server that may be scaled up later as applications move to production and increase in traffic. Linode has plans ranging from the $10/mo plan I have (1GB of RAM, 24GB SSD storage, etc.) all the way up to a 96GB RAM, 1920 GB SSD storage plan at $960/mo.

Rsyslog property based filtering features

Do you need something more powerful than the usual, clunky selectors based Rsyslog filtering rules but still you don't see the benefit of going full throttle and use RainerScript?

Perhaps you weren’t aware, but there is an additional filtering rule you may not have used, which is a great alternative to the classic selector-based one, called property-based filtering.

This kind of filtering lets you create rules like:

:msg, contains, "firewall: IN=" -/var/log/firewall

There's a few more properties that you can use like hostname,fromhost,fromip and the number (and variety) is growing over time.

Instead of just verifying that a specific string is contained in the highlighted property, you could also be interested in operators like isempty, isequal or the powerful regex and ereregex which could be used to compare the string content against regexes, that we all love so much.

:fromhost, regex, ".*app-fe\d{2}" -/data/myapp/frontend_servers.log
:fromhost, regex, ".*app-db\d{2}" -/data/myapp/DB_servers.log

Also remember that you can always use the ! to negate the condition and the discard operator to block Rsyslog from further rules parsing for that specific content:

:msg, !contains, "firewall: IN=" -/data/myapp/all_logs_but_firewall_related.log
:fromhost, regex, ".*appfe\d{2}" ~ -/data/myapp/frontend_servers.log
:fromhost, regex, ".*appdb\d{2}" ~ -/data/myapp/DB_servers.log
*.* /data/myapp/all_logs_but_firewall_related_and_not_from_appfe_and_appdb_servers.log

In case you don't know what the - (dash) sign stands for, that's used to put the log writing process in async mode, so that Rsyslog can proceed with other filtering and won't wait for disk I/O to confirm a successful write before proceeding to something else.

Now go back to your logging system and let us know what nice set up you came up with!

Link-ography:

Looking at development environments with DevCamps and Vagrant

For most web developers, you have practices and tools that you are used to using to do your work. And for most web developers this means setting up your workstation with all the things you need to do your editing, compiling, testing, and pushing code to some place for sharing or deployment. This is a very common practice even though it is fraught with problems- like getting a database setup properly, configuring a web server, any other services (memcached, redis, mongodb, etc), and many more issues.

Hopefully at some point you realize the pain that is involved in doing everything on your workstation directly and start looking for a better way to do web development. In this post I will be looking at some ways to do this better: using a virtual machine (VM), Vagrant, and DevCamps.

Using a VM for development

One way to improve things is to use a local virtual machine for your development (for example, using VirtualBox, or VMware Fusion). You can edit your code normally on your workstation, but then execute and test it in the VM. This also makes your workstation "clean", moving all those dependencies (like a database, web server, etc.) off your workstation and into the VM. It also gets your dev environment closer to production, if not identical. Sounds nice, but let's break down the pros and cons.

Benefits of using a VM
  • Dev environment closely matches production.
  • Execute and test code in a dedicated machine (not your workstation directly).
  • Allows for multiple projects to be worked on concurrently (one VM per project).
  • Exposes the developer to the Operations (systems administration) side of the web application (always a good thing).
  • Developer can edit files using their favorite text editor locally on the workstation (but will need to copy files to the VM as needed).
Problems with using a VM
  • Need to create and configure the VM. This could be very time consuming and error prone.
  • Still need to install and configure all services and packages. This could also be time consuming and error prone.
  • Backups of your work/configuration/everything are your own responsibility (extremely unlikely to happen).
  • Access to your dev environment is extremely limited, thus probably only you can access it and test things on it. No way for a QA engineer or business owner to test/demo your work.
  • Inexperienced developers can break things, or change them to no longer match production (install arbitrary packages, different versions than what is in production, screw up the db, screw up Apache configuration, etc.).
  • If working with an established database, then downloading a dump, installing, and getting the database usable is time consuming and error prone. ("I just broke my dev database!" can be a complete blocker for development.)
  • The developer needs to set up networking for the VM in order to ssh to it, copy files back and forth, and point a web browser to it. This may include manually setting up DNS, or /etc/hosts entries, or port forwarding, or more complex setups.
  • If using SSL with the web application, then the developer also needs to generate and install the SSL cert and configure the web server correctly.

Vagrant

What is Vagrant? It is a set of tools to make it easier to use a virtual machine for your web development. It attempts to lessen many of the problems listed above through the use of automation. By design it also makes some assumptions about how you are using the VM. For example, it assumes that you have the source code for you project in a directory somewhere directly on your workstation and would prefer to use your favorite text editor on those files. Instead of expecting you to continually push updated files to your VM, it sets up a corresponding directory on the VM and keeps the two in sync for you (using either shared folders, NFS, Samba, or rsync). It also sets up the networking for accessing the VM, usually with port forwarding, so you don't have to worry about that.

Benefits of Vagrant
  • Same as those listed above for using a VM, plus...
  • Flexible configuration (Vagrantfile) for creating and configuring the VM.
  • Automated networking for the VM with port forwarding. Abstracted ssh access (don't need to set up a hostname for the VM, simply type `vagrant ssh` to connect). Port forwarded browser access to the VM (usually http://localhost:8080, but configurable).
  • Sync'd directory between your workstation and the VM for source code. Allows for developers to use their favorite text editor locally on their workstation without needing to manually copy files to the VM.
  • Expects the use of a configuration management system (like puppet, chef, salt, or bash scripts) to "provision" the VM (which could help with proper and consistent setup).
  • Through the use of Vagrant Cloud you can get a generated url for others to access your VM (makes it publicly available through a tunnel created with the command `vagrant share`).
  • Configuration (Vagrantfile and puppet/chef/salt/etc.) files can be maintained/reviewed by Operations engineers for consistency with production.
Problems with Vagrant
  • Still need to install and configure all services and packages. This is lessened with the use of a configuration management tool like puppet, but you still need to create/debug/maintain the puppet configuration and setup.
  • Backups of your work/configuration/everything are your own responsibility (extremely unlikely to happen). This may be lessened for VM configuration files, assuming they are included in your project's VCS repo along with your source code.
  • Inexperienced developers can still break things, or change them to no longer match production (install arbitrary packages, different versions than what is in production, screw up the db, screw up Apache configuration, etc.).
  • If working with an established database, then downloading a dump, installing, and getting the database usable is time consuming and error prone. ("I just broke my dev database!" can be a complete blocker for development.)
  • If using SSL with the web application, then the developer also needs to generate and install the SSL cert and configure the web server correctly. This might be lessened if puppet (or whatever) is configured to manage this for you (but then you need to configure puppet to do that).

DevCamps

The DevCamps system takes a different approach. Instead of using VMs for development, it utilizes a shared server for all development. Each developer has their own account on the camps server and can create/update/delete "camps" (which are self-contained environments with all the parts needed). There is an initial setup for using camps which needs thorough understanding of the web application and all of its dependencies (OS, packages, services, etc.). For each camp, the system will create a directory for the user with everything related to that camp in it, including the web application source code, their own web server configuration, their own database with its own configuration, and any other resources. Each camp is assigned a camp number, and all services for that camp run on different ports (based on the camp number). For example, camp 12 may have Apache running on ports 9012 (HTTP) and 9112 (HTTPS) and MySQL running on port 8912. The developer doesn't need to know these ports, as tools allow for easier access to the needed services (commands like `mkcamp`, `re` for restarting services, `mysql_camp` for access to the database, etc.).

DevCamps has been designed to address some of the pain usually associated with development environments. Developers usually do not need to install anything, since all dependencies should already be installed on the camps server (which should be maintained by an Operations engineer who can keep the packages, versions, etc. consistent with production). Having all development on a server allows Operations engineers to backup all dev work fairly easily. Databases do not need to be downloaded, manually setup, or anything- they should be set up initially with the camps system and then running `mkcamp` clones the database and sets it up for you. Running `refresh-camp --db` allows a developer to delete their camp's database and get a fresh clone, ready to use.

Benefits of DevCamps
  • Each developer can create/delete camps as needed, allowing for multiple camps at once and multiple projects at once.
  • Operations engineers can manage/maintain all dependencies for development, ensuring everything is consistent with production.
  • Backups of all dev work is easy (Operations engineer just needs to backup the camps server).
  • Developer does not need to configure services (camp templating system auto-generates needed configuration for proper port numbers), such as Apache, nginx, unicorn, MySQL, Postgres, etc.
  • SSL certificates can be easily shared/generated/installed/etc. automatically with the `mkcamp` script. Dev environments can easily have HTTPS without the developer doing anything.
  • Developers should not have permissions to install/change system packages or services. Thus inexperienced developers should not be able to break the server, other developer's environments, install arbitrary software. Screwing up their database or web server config can be fixed by either creating a new camp, refreshing their existing one, or an Operations engineer can easily fix it for them (since it is on a central server they would already have access to, and not need to worry about how to access some VM who knows where).
Problems with DevCamps
  • Since all camps live on a shared server running on different ports, this will not closely match production in that way. However, this may not be significant if nearly everything else does closely match production.
  • Adding a new dependency (for example, adding mongodb, or upgrading the version of Apache) may require quite a bit of effort and will affect all camps on the server- Operations engineer will need to install the needed packages and add/change the needed configuration to the camps system and templates.
  • Using your favorite text editor locally on your workstation doesn't really work since all code lives on the server. It is possible to SFTP files back and forth, but this can be tedious and error prone.
  • Many aspects of the Operations (systems administration) side of the web application are hidden from the developer (this might also be considered a benefit).
  • All development is on a single server, which may be a single point of failure (if the camps server is down, then all development is blocked for all developers).
  • One camp can use up more CPU/RAM/disk/etc. then others and affect the server's load, affecting the performance of all other camps.

Concluding Thoughts

It seems that Vagrant and DevCamps certainly have some good things going for them. I think it might be worth some thought and effort to try to meld the two together somehow, to take the benefits of both and reduce the problems as much as possible. Such a system might look like this:

  • Utilize vagrant commands and configuration, but have all VMs live on a central VM server. Thus allowing for central backups and access.
  • Source code and configuration lives on the server/VM but a sync'd directory is set up (sshfs mount point?) to allow for local editing of text files on the workstation.
  • VMs created should have restricted access, preventing developers from installing arbitrary packages, versions, screwing up the db, etc.
  • Configuration for services (database, web server, etc.) should be generated/managed by Operations engineers for consistency (utilizing puppet/chef/salt/etc.).
  • Databases should be cloned from a local copy on the VM server, thus avoiding the need to download anything and reducing setup effort.
  • SSL certs should be copied/generated locally on the VM server and installed as appropriate.
  • Sharing access to a VM should not depend on Vagrant Cloud, but instead should use some sort of internal service on the VM server to automate VM hostname/DNS for browser and ssh access to the VM.

I'm sure there are more pros and cons that I've missed. Add your thoughts to the comments below. Thanks.