1. Getting a site out of a Drupal Multisite install into a “stand-alone” Drupal install

    Recently I participated in a project that required to take a Drupal site out of a multi-site install into it’s own server.

    The site in question was part of a regular Aegir-Drupal multi-site install, to manage the site’s development phase and once ready for production, it had to be moved into its own server.

    After making several tests to see how to make it work and confusing myself everytime I tried, I found drush’s own archive-dump and archive-restore, so I decided to give it a try. What was my surprise? After a full week reading here and there and trying this and that… all it really took was:

    SSH into development server, cd into Drupal platform install directory and do:
    $ drush ard sitename.com —destination=~/site-backup-filename.tar.gz

    Move site-backup-filename.tar.gz into the production server

    SSH into production server, cd into Apache document root and issue:
    $ drush arr site-backup-filename.tar.gz —db-url=mysql://dbuser:dbuserpasswd@dbhost/dbname

    This will restore the sitename.com directory inside a full Drupal install taken from the development server’s platform, e.g. drupal-7.10-x

    Change owner for the whole Drupal directory:
    $ chown -R www-data:www-data drupal-7.10-x

    Just in case, also issue the same command for the following directories:

    Create sites/sites.php file with the following content:
    $sites = array(
      ‘sitename.com’ => ‘sitename.com’
      // the first sitename.com in the file, refers to the url content in the browser’s window,
      // you may replace this with the a FQDN.
      // the second sitename.com appearing after ‘=>’ is the directory name inside sites/ where
      // the site files are stored.

    Just to be completely sure, remove anything from sites/sitename.com/settings.php that is not db related, when the site is restored, drush appends the new db settings to this file, so pretty much what’s before this new db declaration is “useless”.

    Issue several times:
    $ drush cc all
    just to be sure we cleared all cache from this new install… remember to do this inside sites/sitename.com directory.

    Point your browser to the production server url and enjoy.

  2. Working with Rails and DataMapper

    I’ve been working remotely for a company in Colorado as a Rails developer lately.

    I can’t say much about what is exactly I’m working on, but one topic I find very interesting in my day-to-day job is the fact that I am currently working with the latest and greatest version of Rails (3.1.rc4, although by now 3.1.rc5 has been released) and since day one I began working with them, ditched Active Record in favor of DataMapper.

    I will not start a mini-debate about which of them is better, there’s no point there. All I’ll say is that, as Fernando Castellanos once commented in a Tijuana.rb meeting, it is nice to have an annotated model, so you don’t have to revert to your schema, migrations and/or actual database to see what attributes your models include.

    As a plus, I have to mention that as I want to play with Mongoid anytime soon, I find DataMapper and Mongoid syntax much alike. That’ll come in handy when finally using it.

    Of course there are a few considerations to make, but none of them are show-stoppers as to frustrate the developer. I have needed to modify only two gems to make them work with DataMapper since I began working with it. That says a lot about this ORM. There is a commited group of developers working hard to pair it with the default (Active Record), in order to ease developers work when implementing it in their applications.

    As for Rails 3.1.rc4, the only thing I can say is (since I haven’t written a single line of Coffescript code), Wooow!. How cool is it to have all your assets compressed and included automatically? Yes, it’s that cool… you don’t have to worry about remembering to include this or that file, Rails will do it for you, all you need to do is place it in its proper folder inside assets/

  3. Releasing a new :registra.me version

    registrame0.2 is the second version of my app to register attendees to an expo or trade-show. Originally written in Rails 2.3, this new version updates to Rails 3.

    Not only Rails version has been updated, but also the following behavior has been added.

    • Admin user is the only user authorized to configure application via a login/password and Admin namespace.
    • Name Badge includes attendees info in a QRCode.

    Everyone is invited to clone the app, use it, check the code and most important of all improve it, I’m not a Rails guru after all, but a newbie working my way through Rails.

    Code is available at https://github.com/antillas21/registrame0.2

    About the app

    The app contains three areas: admin for configuration and report generation; data for data capture during an event; and public for those interested in pre-registering online.

    It is currently using the rqr gem to generate QRCode. This is a first attempt and works well, unfortunately, this gem compiles only in Ruby 1.8.7 (which for my specific case is OK, because I’ll be deploying a version of this app to manage on-site registration on a server with Ruby Enterprise Edition).

    Later this year, as I learn more about Ruby (and Rails for the matter) I will update the app, mainly focusing the following areas:

    • Change the gem responsible for QRCode generation to one that is compatible with Ruby 1.9.2 (I have found several around, but due to time constraints, couldn’t try any of them for this release).
    • Switch Ruby version to 1.9.2
    • Make code cleaner

    Meanwhile look at snapshots below:

     Registration formSample Person record

    Sample printed name badge

  4. Managing a temp wireless network for 900+ concurrent users

    Last week I was part of the staff of a trade-show in my city. My responsibility was to provide internet access to exhibitors and visitors alike during the event.

    The requirement was both easy and vague at the same time: All exhibitors and visitors with mobile wi-fi capable devices should have access to the internet while attending the event.

    It is easy, because we have users identified: visitors and exhibitors. And it’s also vague, because we don’t know how many of them will be and how many wi-fi capable devices and what sorts they’ll bring into the event. At least it’s hard to tell in the beginning and also during the trade-show (unless you keep checking the logs for assigned IPs).

    So, how do we start to plan a wireless network with this input?

    First I asked for the exhibitor count and planned for 2.5 wi-fi enabled devices per exhibitor. The tradeshow organizers came with a total 108 exhibitors, so that gives us 270 devices for a start.

    Then I asked for pre-registered visitors count and planned for 1 device per visitor, that resulted in 5XX devices. Total visitors count would change during the event, but not all visitors would stay the same amount of time, nor they’d show up at the same time, so I decided to play it safe and bump this number to 700.

    Simple math states that 270 + 700 = 970

    Now the tricky part begins

    Resources for the trade-show were rather limited, so I knew I had to deal with a poor man’s solution that would get the job done efficiently and at low cost.

    I have been aware of open source solutions for building internet gateways and have tried several of them, being Untangle the one that shined over all the others for simplicity and ease of use. This is just my opinion, perhaps someone else might argue the point and I welcome the suggestions and opinions, as long as they’re polite and fact-based. I believe it’s never late to learn new approaches.

    What comes next? Planning. Planning how to deploy the gateway, planning what the phone company can provide to connect to the internet considering it’s almost a remote location, planning devices I may need considering budget constraints.

    What did I came up with? I believe an image helps to illustrate better.

    The configuration above will allocate 1,024 hosts for the network and after discarding IPs for the gateway and each of the access points, I had 1,014 IPs available to allocate.

    Obviously, we need to assure that the limited internet connection (see diagram) was not abused with NSFW content, so I decided to implement the following policies:

    • No erotic and/or porn content
    • No gambling and/or gaming content
    • No hate, racial discrimination content
    • No peer-to-peer services
    • If the user has spyware and or malware installed, prevent it from making internet request that may use bandwidth.

    I was aware that the trade-show wanted people to be able to access their e-mail accounts, company networks, corporate websites, streaming services and social accounts; so no policies were created to prevent them from doing so.

    How did it turn out? Glad you asked.

    Excellent. That is just the end result. Untangle is capable of managing such a load without abusing hardware resources.

  5. Configuring Rails 3, Mongoid, Cucumber, RSpec, Devise, jQuery

    A few days ago I decided to finally begin writing a small app as an exercise to practice how to use Rails3 and Mongoid. In lack of a better example I decided that this exercise app will allow me (a somewhat freelancer) to control my invoices under Mexico’s new digital fiscal certificate disposition (CFD in Spanish).

    Encouraged by the fact that I had completed all exercises in the RSpec Book from Pragmatic Programmers and that in one of Tijuana.rb meetings @FCastellanos commented that MongoDB is an excellent alternative when dealing with models that emulate documents… and what is an invoice model but a document in the end? Thus began my journey into configuring the initial skeleton for my exercise app.

    A quick note. If the following steps are not implemented, when executing:

    $ rake cucumber:ok

    for any given set of feature files, the result will come as:

    0 scenarios

    0 steps

    no matter how many features, backgrounds, scenarios and steps you declare, your result will always be that. Which provides no way to effectively test the application.

    Well, with that out-of-the-way, most of the heavy-lifting will be provided by a Rails Wizard template, there are some files that need some editing in order to fully integrate all the components.

    Take for example Cucumber and RSpec, who work out-of-the-box with relational databases, but MongoDB is not a relational database, so that gives some config files to tweak.

    Let’s begin:

    Create the app with the following template

    rails new APP_NAME -m http://railswizard.org/d87652cae598fe1b11e1.rb -T -O -J

    After everything is installed and the installers for Devise, jQuery, RSpec, Cucumber and Mongoid are automatically executed. Then proceed to edit the following files:

    After all this is done, the first .feature file can be written and tested as usually is done:

    $ bundle exec cucumber features/first.feature [-f pretty] or

    $ rake cucumber:ok