DevOps with Opscode Chef

Posted on February 18, 2011 by Joe Scharf

I’ve been using Opscode Chef to automate infrastructure deployments for the last year and a half. Before Chef (and predecessors) came on the scene, I had toyed with various version control methods to achieve the same result, but they usually failed to scale with the complexity of the system.

Chef recipes are idempotent, meaning multiple applications of the same recipe will not affect the end result. This is probably the biggest benefit Chef has over a straight scripting language or rolling your own system. Traditional scripting languages typically require a bunch of error checking or a well-defined server state pre-execution to accomplish a similar task.

Chef uses an ever evolving Ruby DSL that allows a systems integrator to specify through Ruby code the necessary packages, services, and configuration needed to run their network applications. Chef’s Ruby DSL is made up of Resources which are the lowest-level “atomic” actions that can be performed on a server.

Search and templating are powerful features that give the ability to create and automate dynamic infrastructures. Searching for all the production server roles is simple and adding all the production roles to a monitoring or load-balancing configuration, even more so. Chef also provides data-bags which give additional flexibility to search, allowing a developer to store arbitrary data which can be searched and incorporated in templates. This is useful for managing account credentials and profiles infrastructure wide.

Posted in Operations, Technology | Tagged , , , , , | Leave a comment

Presentation: Email Metrics that Matter

Posted on February 9, 2011 by Joe Scharf

Email Metrics that Matter, presented at Marketing 2.0 Bootcamp February 9, 2011

Posted in Email, Presentation | Tagged , , , , | Leave a comment

Foreign Domain Request Routing in Rails

Posted on April 6, 2009 by Joe Scharf

Ruby on Rails routing with support for RESTful and named routes is one of the most useful features of Rails, but is also very frustrating and limited at times. I ran into this frustration a couple times while developing “QuantiPay”:quantipay, specifically when dealing with foreign domains and differentiating between http and https.

Routing Foreign Domains

The first requirement of QuantiPay involves routing and serving pages for foreign domains. For example if quantipay.com is our native doman, then payment.example.com would be a foreign domain. We use this functionality in QuantiPay to support fully-branded payment pages with custom URLs. I quickly found Foreign Domain Routing Plugin, which was an extension of Subdomain-fu, that extended Rails routing and quickly solved the problem of detecting and routing foreign domains.

Routing Request Protocol

The next requirement was a need to create multiple root routes differentiated by protocol. I wanted an https request with no URI do route by default to the application’s login page, while http requests should route to the front-facing homepage describing the service. I found Request Routing which solved this problem, while adding support for many additional properties usable in the :conditions hash.

Foreign Domain and Request Routing Combined

The problem I now faced was that these two plugins did not work together. I could route based on protocol, but I could not detect foreign domains, and vice-versa. I believe this is mainly due to the design of the request routing plugin which directly overrides the recognition_conditions method in the rails routing module, versus calling alias_method_chain as does Foreign Domain Routing.

To get these two to work together, I went ahead and forked the Foreign Domain Routing repository, and added Request Routing to it, as well as updated unit tests for both and packaged it as a gem. You can find the merged repository here.

Install as a gem via:

sudo gem install quantipay-foreign_domain_routing

Or add to environment.rb

config.gem “quantipay-foreign_domain_routing”, :source => “http://gems.github.com/”, :lib => “foreign_domain_routing”

Example usage in routes.rb

On line 2, we are mapping a default route for the front-end homepage describing the service, thus we only match this route if  :conditions => { :protocol => /http:/ }

On line 3, we are mapping a default route for the secure area of the site. This default route will send logged-in users to their dashboard, otherwise they will be redirected to the login page. We only want to match this route if it is being requested via our native domain and through the https: protocol.

On line 4, we are mapping all foreign domains to the payments controller. Anything that matches this rule will be redirected to SSL automatically by the ssl_requirement plugin.

Posted in Ruby on Rails | Tagged , , , , | 3 Comments

Working Green – Don't Forget to Reduce

Posted on December 10, 2008 by Joe Scharf

For all the talk I’ve heard over the last several years about sustainability and eco-friendliness, It always amazes me how little the subject of energy and waste reduction is discussed. The typical sustainable discourse usually focuses on recycling, energy efficiency, and especially alternative fuels.

It seems to me that we could have a greater and more immediate sustainable impact on the world if we took a harder look at reducing our energy consumption. The area of reduction that always, to me, seems like the most wasteful from an energy consumption standpoint is the daily commute to and from the workplace.

According to the US Census 2000 Journey to Work data, over 97 million (75.7%) workers aged 16 or over commuted alone to work. The mean travel time to work being 25.5 minutes. Multiply this time by two and you have a round-trip commute of 51 minutes, almost a whole extra hour added to the workday. New Yorkers have the wost commutes, according to a US Census Bureau press release, “New York City residents spend an average of 38.4 minutes getting to work each day, the equivalent of one full week per year.” My question: is the job and compensation worth it? Have you factored this extra commute time into your pay and incentive packages?

With the rise of the information age and the knowledge worker, there are many options and tools available to support robust remote working arrangements. Small businesses, entrepreneurs, and consultants often rely on these remote working options and tools by default, but corporate America, in all of it’s rush to jump on the sustainable bandwagon and label itself green, still requires the 8+ hour day of face-time.

Corporate America should really make an effort to rethink the structure of the workplace and the insatiable need for face-time. By doing so, Not only would we be reducing the time, energy, and stress of the daily commute, but also reducing the energy footprint of the corporation itself. Corporate America can benefit from reduced energy, facilities, and maintenance costs by embracing remote working arrantgements for their employees. Some large companies have already embraced remote work arrangements (i.e. Sun Microsystems Open Work program) and are reaping the benefits. Perhaps it’s time for the rest of corporate America to follow.

Posted in Entrepreneurial Workforce, Sustainability | Tagged , , | Leave a comment