Went out yesterday and bought myself a new toy.

It’s a 2012 Harley Davidson Sportster 1200 Custom

I have more pics on flickr.

I’ll be at RubyNation 2012 tomorrow.

Getting my laptop set up and ready to roll so I’ll be ready to code like a madman.

I love conferences ;)

If you’ll be there, find me or Tweet to @victorquinn

Over this past weekend, I installed Mountain Lion Developer Preview 2 (DP2).

It came with another version of Xcode and I was heartbroken to once again see that git svn was broken!

However, I was relieved to find that my previous solution worked like a charm. I was able to copy-paste the exact commands again and everything worked perfectly.

I updated the former post accordingly and it’s available here

Back in October of last year, I wrote an Ubercart plugin for Stripe ^[1], a payment API created to be developer conscious and easy to use. I loved the idea of Stripe ^[2] and was using Ubercart for a project and noticed there was no module so I created it.

It was the first contrib module I had created entirely from scratch on my own which made it through the Drupal.org submission process. I’ve written many custom modules for my employer and for side projects, but this was my first time going through the gauntlet of the review process for getting a contrib module on Drupal.org. For the curious, you can see the whole back and forth on this issue: http://drupal.org/node/1339850

I recently noticed Stripe links back to my module from their site.^[3]

[1] Ubercart plugin for Stripe
[2] Stripe
[3] Stripe link to my Ubercart Stripe Module

Excited to attend the RubyNation 2012 conference next week!

This will be the first year since 2009 that I will not be attending DrupalCon ^[1] and my conference itch needs scratching.

I find generally that conference excitement manifests itself in a handful of ways.

New Things!

My favorite thing about attending a programming conference is the excitement I have during and immediately after for all the new things I will learn at the conference.

Every time I walk out of a room where someone was giving a presentation on a cool new technology or process, in the back of my head I am thinking of how I can work that technology or process into each of my current projects. Or I am pondering what old projects I could revamp or new projects I could start using this technology as a launchpad which were previously out of scope or cost prohibitive.

Setting aside the new things themselves, this type of self-reflection and evaluation is invaluable. I strive for this type of reflection in my everyday life, but it’s much easier in this type of forum, removed from the daily doldrums of life at the office. Having traveled to a conference, often far away, and broken the routine, it is easier to have this kind of perspective.

New things also inherently bring excitement for their new-ness, particularly for a person like myself. Some people enjoy consistency and sameness and have an aversion to change. I am the exact opposite and view a new thing as a new challenge ready and ripe for besting. It also represents uncharted territory and I am definitely an explorer.

High Energy Environment

There is always an extremely high energy level at such conferences.

The speakers have high energy, speaking excitedly about something interesting they have recently worked on in an attempt to proselytize.

This in turn leads me (and others) to similarly get excited about their new thing. This kind of network effect is huge. When high energy people start bouncing ideas off of each other in a sort of feedback loop, great things can result.

I had a reputation with my co-workers of being the guy with the kooky fringe ideas. This is because I was always excited about the possibility of using new and more efficient concepts in our projects. For someone like me, a conference was like crack. Never weary of the cost to implement, I am a constant proponent for whatever will be objectively best. It always led to interesting meals during conferences with me excitedly ranting about how we could use X for this project or Y for that project with my co-workers offering counterpoints to keep me grounded. I’m sure they grew weary at times, but my co-workers generally allowed me to indulge.

My first week back after a conference is always absorbed by planning and trying to implement many of the new things I learned at the conference or figuring out a reason why I couldn’t or shouldn’t. I feel like I’m kicked into high gear, being three times as productive that week as any other while I run on the natural high from learning about new things as most people run on coffee.

I notice myself staying voluntarily late at work and working much longer hours than normal or necessary which, for a salaried employee, was solely for my own personal enjoyment. My employer benefited greatly as a result, but that was not my intent in working like mad. I was rushing to solve a new puzzle, to conquer a new opponent. I was working purely for enjoyment.

Another high energy aspect is that each of the attendees is there to learn. Almost like a wedding, where another new beginning is celebrated, most attendees are embarking on a journey of their own with a technology. Most attendees get a break from their normal day at the office and this fills them with energy and joy they wouldn’t otherwise have.

Being around people in a natural state of high energy serves to amplify the learning and the network effects of the conference.

Networking

And of course there is the value of networking. Many people go to developer conferences primarily for this aspect.

It is incredibly useful to meet other people doing similar things. It is nearly priceless to compare notes on problems, solved and unsolved, and initiate future collaborations.

There are certainly attendees whose primary mission at a conference is to network. At times this can get a bit predatory, but in general it is a net positive.

Particularly in the open source community, finding that someone else has already solved a problem and is willing to share the solution could save days or weeks or more of developer time.

For a seasoned programmer looking for a job, this is a great way to feel out potential employers. Not only would I be hesitant to work as a programmer at a company that failed to value such events, developer conferences are a great way to be introduced to other employees of a company and see what they are working on. It opens the door to talking with these people directly about their work in a manner that is not easy in everyday business. In the case of an open source technology, conference attendance, sponsorship, and the contribution to sessions by an employer are all indicative of a company that contributes back to open source, values the community aspect, and fosters innovation.

It’s Not All Rainbows, But It’s Close

One major downside is that having someone stand in front of you and preach excitedly about their latest thing can, at times, be misleading.

This is not to say the speakers intentionally or negligently mislead, but each one often discusses the highlights of their new thing without strongly discussing the downsides. This makes sense as their intent at speaking at a conference is generally not purely to educate, but also to drum up support for their new thing or for publicity for their company or themselves. This results in many of the sessions having some kind of bias or marketing twist. This unsurprising as the speakers are often incentivized to do so and without such sponsorship most conferences would not exist, but it is necessary to remain cognizant of this facet when sitting in a session whose speakers claims are on par with claiming to have invented a better mouse trap.

Sometimes when I get back from a conference and decompress, I find myself thinking, “Wait, this only works in that specific instance? How is that even helpful?”

Once the honeymoon period ends on some of these new things, it becomes apparent that instead of sliced bread, they’re just the same old bread repackaged in a shiny shell. On the other hand, even the discovery that some of the newfangled technologies offer little benefits over tried and true methods can itself be a significant benefit.

Further, while every new thing cannot itself be directly applicable and useful, each new thing that a developer learns is yet another thing they can add to their arsenal. Then sometime in the future, they will have the knowledge of how a problem was once solved and whether it would be useful in a given set of circumstances. So while it will not all bear fruit, gaining knowledge from a conference, as it does in any realm, serves to enrich the developer’s background for future endeavors.

If you are attending RubyNation 2012, I hope to see you there!

[1] I would love to attend DrupalCon this year, but the timing and travel just didn’t work out. Thankfully, RubyNation is being held right in my backyard!

This is one of those tips that seems almost too easy to be true.

My resume and cover letters are written in LaTeX. LaTeX is a typesetting system often used for creating technical documents as it is particularly good at creating complex documents including scientific equations. I have been using it for a few years to draft documents both because it gives me a lot of control over the output and so that I could prepare myself for working with technical documents such as patents which are likely be written in LaTeX.

I wanted to include my signature in a cover letter. In order to do so in LaTeX, it required a graphic in .eps format. However, my signature was a .png image. I searched for awhile until I came across the answer which was so simple I felt silly for not knowing it.

I thought it may prove useful to someone else. This is a command line trick, so if you are not familiar with a terminal, this tip will not be of much help. Without further adieu:

Simply use the convert command line utility to convert it.

1

$ convert image.png image.eps

Yes, it was that easy! Out came a perfect .eps file which I was able to use in my LaTeX document. The convert command has all sorts of other options for resizing and many other things, but for simply doing a straight conversion, that was all!

Worth noting, while this worked for .png to .eps, it also works for .jpg to .eps and .gif to .eps. Have not tested anything else, but it appears to be pretty versatile!

Wow. It will be interesting to see how this plays out.

link

Can’t stop listening to a band called fun.

Especially this song:

Monster Menus

Over my years working at Amherst College, I have been fortunate enough to have played a part in helping to develop and create a module for Drupal called Monster Menus. The module is a Monster! (pun intended)

The capabilities it adds to out of the box Drupal are quite incredible. It plugs many gaping holes in Drupal which made it suitable for use by a large institution such as Amherst College.

Permissions gaps in core Drupal

Out of the box, Drupal is quite limited in terms of its permission capabilities. It has a concept of roles which it uses for permissions. This is fine for many small sites or sites where there are limited content creators, but on a site with tens of thousands of users creating content, this starts to break down quickly.

In the simplest terms, Monster Menus layers, on top of the standard Drupal access permissions, a series of access permissions which approximate the permissions given to any modern filesystem.

For example, in any linux or unix based system, there are permissions such as read, write, execute which can be given to users and/or groups. This allows for very rich and nuanced access privileges such as John can edit this file but he cannot view this folder. View the screenshot below of the Monster Menus permissions interface for a given page:

As you can see, this is very similar to the permissions structure of a filesystem. As a result, this allows for things such as, “all instructors in the English department can edit the English department website” or “only John Doe can add content to this page and everyone can read it” or “John and members of the English department group can read this page but no one else can.” This kind of nuanced permissions is simply not available in off-the-shelf Drupal.

The Approach Other Large Institutions Have Taken

Many institutions have run into similar issues and have solved it a few different ways.

Organic Groups

The first is by using something called Organic Groups.

It does add the concept of Groups to Drupal, but does not appropriately offer the nuanced permissions described above. For example, it would not allow for something such as “only members of the English department and John and members of the Philosophy department can edit this page.”

Separate Drupal Instances and Subdomains

The second is by creating an entirely different Drupal instance for each site and using subdomains.

This has many downsides, the most notable being that updating can be a monstrous pain.

At DrupalCon last year, I spoke with someone from another college that had ~160 different Drupal instances! They had a different instance for every single educational department in their large university. So they were trying to figure out a way to update the codebase in 160 directories and then run scripts to update 160 databases.

He was asking how other places dealt with the process of updating because it was almost a full-time job just for him to run around and update all of these separate instances. Ouch.

The other major downside is that, by using subdomains like english.college.edu or physics.college.edu is that, since they have different subdomains, they don’t share Google juice.

Amherst College Paved Their Own Path

As a result, when Amherst College wanted to adopt Drupal as their content management system, they needed a solution to deliver these kind of nuanced permissions and, since neither Organic Groups or these Separate Instances scaled, they decided to pave their own path.

Thus Monster Menus was born.

(Monster Menus will likely get a broader treatment in a later blog post as I love discussing it!)

Drupal Multisite

One of the benefits of Drupal is that it can be set up in a multisite configuration. This allows multiple sites to share a single codebase which in turn leads to easier updates downstream. Having to only modify files once per server instead of once per website hosted on that server can be a huge time-saver.

However, as each Drupal instance in a multisite configuration shares the same code, they each have different databases so, for all intents and purposes, each one is an entirely separate and siloed site.

With this kind of configuration, on my web server I have a single instance of the Drupal codebase and, utilize a multisite configuration to have about a dozen different Drupal instances each with their own database. These sites each look like their own completely separate entities to the outside world (most notably because they have entirely different URLs), but under the hood they share a lot of the same codebase.

The primary developer of Monster Menus had the wise foresight to build in the capability to use it with a multisite configuration. His instructions can be found on Drupal’s website:

Multiple Drupal Sites with One Monster Menus Tree

Deploying Monster Menus with Drupal Multisite

I have recently taken some time to work on some web projects for myself. Two of those projects were related and needed some nuanced permissions so I took it as a great opportunity to deploy Monster Menus (MM hereafter) in my own environment and try out the multisite capabilities to share users, permissions, etc. between the two.

So I followed the instructions, installed MM on one instance, then using multisite created another instance, pointing it to use the same database. This leads to the following configuration:

This is when the problems started to arise. First, those instructions say in Step 1 that:

“During setup, it is important to note that you must use the same database for all of your instances.”

Hrm. This sounds like it could cause troubles down the line. Later:

“Choose the newly-created site in the ‘Current Homepage’ column, and click the ‘Set the current homepage’ button. Now, when you visit your site’s homepage, the page you just created will be displayed.”

Anyone familiar with databases will realize there is a problem here. If the two or more sites are sharing a single database, changing the current homepage as in the instructions necessarily also changes it in the other!

Unless I was missing something quite obvious, this wouldn’t work!

Now the primary developer for MM is an incredibly competent programmer so I assume he had some way around this. The instructions mention using the $conf variable in the settings.php file. Assumedly, since the current homepage is stored as a system variable in the variables table and $conf can be used to overwrite these values, it ought to be possible to use this somehow to redirect to a different homepage for each instance. First, I couldn’t figure out how to get that working, and second I noticed some other problems that wouldn’t be solved even if this worked.

Other Problems With the Primary Multisite Method

Since both instances share a single database, it impossible to set any settings on one that would not end up affecting the other. For example, changing the Site Name, E-mail address, Performance settings, and any other configuration setting on one site would change it the other! Unless there is a situation under which both sites have all of the same information and configuration, this setup would not work!

Sure, one could manually override $conf in the settings.php file in an attempt to account for some of these configuration changes, but it gets messy quickly.

Further, this method can only be used to override things in the variables table. It wouldn’t be any help for other database entries.

Things broke down more when it came to the use of modules. One of my sites was reasonably complex, requiring the installation of many modules. The other was relatively simple and I desired to keep it as light as possible. However, it was not possible to do this when they shared a single database! Installing a module on one instance necessarily installed it on the other due to their sharing. This introduced unnecessary bloat to the site I desired to be lighter.

The instructions mention using different database prefixes for tables not used by Monster Menus. However, this gets tedious for multiple reasons:

Reason 1: Installing Modules is a mess

The tables will not be created until a module is installed. So the process for installing a module ends up something like the following:

1. Create a separate database for the non-shared tables
2. Install the module on the shared database
3. Dump and import those tables (and their data) from the shared database to the separate database
4. Create prefix entries for the instance that is using those to point to the separate database for those tables from the instance that will be using the tables outside of the shared instance
5. Uninstall the module on the shared database, setting its state back to before the module was installed.

Note, this would simply break if there was an update to a module that added or removed a table because it’s prefix wouldn’t be in the list of prefixes. The person responsible for performing the module updates would therefore have to read through the module code, search for database updates, and pre-emptively set their prefixes in the settings.php file. If this is missed, the tables will be created on the shared database and will not make any sense.

Reason 2: Difficult for standard Drupal tables

This is difficult for more standard Drupal tables such as system where the entire instance relies heavily on it being set a certain way. Once it gets copied, moved, changed, there is a high probability of things breaking.

So this created many issues.

Finding a Workaround

First, I spent time trying to find a way to workaround this and get things to play nicely. The standard instructions say that it’s possible to use different prefixes for tables not used by Monster Menus, but that they must share the same database and not have prefixes for Monster Menus specific tables.

So I could have manually created a separate database with separate tables and pointed my secondary instance at them. However, this would have the downside of requiring me to create any new table separately in another database as described above!

Put another way, this says that, by default, share all tables, only use different tables if we so specify.

The more I thought about this, the more it seemed backwards. I would much rather it default to using multiple, separate databases, with each instance using its own database tables, and only refer to the other instance’s database for any Monster Menus related tables. This way I can install modules, change settings, etc. on each instance without affecting the other. I envisioned some variation of the following:

The Alternate Method for using Drupal Multisite with MM

There is a very detailed post I made on drupal.org about how to do this. And I explain some of the background, but not in the kind of depth I have done in this post:

Multiple Drupal Sites with One MM Tree (alternate configuration)

I won’t repeat the steps here as that would be needlessly redundant. The magic there though is that the multiple instances default to using their own databases and use the prefixes in the settings.php file to point to a master for any requests for Monster Menus specific content such as the tree itself, permission groups, monster menus blocks, etc.

This alleviates all of the issues with not being able to have different per-instance configurations, of having a different module stack on each site, and all of the other problems that come with requiring all instances to share a single database instance.

Fringe Benefits

Aside from simply remedying the issues described above, this also has corollary benefits.

A major one is that it is now possible to have a single master and X slaves. In my actual setup, I had only one master and one slave. However, as in my diagram above, it’s possible to have one master and two slaves. Or one master and fifty slaves. There is ultimately no limit.

And since they are all sharing the same Monster Menus permissions trees, this means Single Sign On is possible throughout the sites as a single user account is tied to permissions on multiple sites! It’s possible to assign permission groups from any site to any other site that is linked in this fashion.

And configuration on any given site (aside from the Monster Menus configuration of course!) can be entirely separate and siloed off from the others. Now if an administrator on one site changes the contact email or creates a new WYSIWYG profile or installs (or uninstalls) a module or changes the input filters, it will not break any content or configuration on any of the other linked sites.

Conclusion

Monster Menus is is an amazing module. Having the capability, with some tweaks like this, to share its assets and ablilities across multiple sites is unbelievably powerful.

Special thanks to Amherst College for paving the way with this module!

It’s official!

I finished the degree requirements in December, but Western New England University just finished processing everything!