The Drupal community is a great educator for the platform. On July 26th and 27th I was happy that I could attend my first CapitalCamp: A two-day, education-packed event held at George Washington University in Washington D.C., all for $20. My wife, Shelley, also happens to be ramping up her web design and Drupal knowledge, so the timing couldn't have been better. She and I mauled over the schedule of 40 sessions, highlighting those that we didn't want to miss (which was a little tough). Aside from sessions that you would expect from a Drupal camp, there were also several targeting government related topics, which covers a pretty large market in this area. We made our picks, booked our hotel, boarded our dog, found a cat-sitter, and hauled our butts down to D.C. for some brutal Drupal knowledge fun times.
These are a few of the sessions that we really enjoyed:
Almost as if Anthony Glynn and Emeline Glynn knew that my wife was starting her Drupal learning process. They nailed it! As most know in hindsight, learning Drupal isn't a walk in the park. There are, however, certain key points that catapult one towards a quick and successful experience. For Emeline, her journey started by creating a drupal.org account and diving head-first into her first Drupal website. Anthony showed Emeline some base-level resources for Drupal learning and helped her configure a good development environment. The flood gates opened with tons of new concepts and terminology pouring in. Site building and theming ahoy! With an establishing foundation, Emeline dug into Drupal programming books, video tutorials, and the Drupal API. Although Emeline hit some problems while building, Anthony propped her up with good troubleshooting techniques and encouraged her to go forth and break things (with a good backup solution in place) in the name of learning. Emeline started to dig into Drupal's hook system and review other people's code. Within the last few months she wrote patches to fix issues she identified and wrote her first custom module. She also documented her experiences in a blog and helped other developers in forums. I commend Anthony and Emeline on their efforts as a powerful couple and would like to congratulate them on their marriage! You both did an excellent job with the presentation that was quite truly inspiring.
Shelley has strong interest in learning more about User Experience (UX). I also wanted to attend Danielle Sheffier's session. Danielle's presentation was well organized and highlighted a good diversity of UX testing techniques. While acknowledging that there is hardly enough time to delve deeply into any of these areas and glancing over others, she was able to instead guide her audience through some best practices. There are clear considerations that may work for one project or budget, but may make no sense for another. Danielle covered various testing types, surveys, card sorting, focus groups, and various tools available to assist in those processes. With the pros and cons of each in mind, I feel better equipped to understand and participate in the UX testing process. This session deeply inspired Shelley and compelled her to consider UX as a great addition to her growing palette of career/educational goals.
Having had some industry experience in accessibility, I instead opted to attend Erik Webb's session. While the presentation was geared toward the ever popular Drupal "site builder" role, I found the subject quite applicable to us developers and site admins. He started by explaining common complaints that people have about various Drupal components. In many cases these claims may be unfounded or based on poor assumptions. Instead, he encouraged a proper evaluation of modules for clues. How popular is the module? Is it configured properly? Erik suggested testing the performance of your website before and after the addition of each module to have better supporting evidence through the building process. He emphasized understanding how/when a module is utilized and whether or not it is really needed for the site. Erik also summarized the pragmatic approach to diagnosing technical problems by suggesting areas of investigation. This allows someone to appropriately target instead of search blindly, or worse, falsely assume/blame. SCIENCE (empirical data for the win)! There are several settings in a Drupal install that are tailored for development, which need to be reconfigured for a production site. Erik stated that things should be properly tested before considered "done" and to incorporate this in the QA sign-off process, especially in an Agile approach. Erik dug into the various levels of caching: Application (pre-built in Drupal), Component (e.g. Views), and Page (full HTML, relatively static content). He showed the difference between production and development configurations in Drupal, and various ways to approach those configurations. There are various Drupal components that Erik suggested for diagnostics and optimizations, like Devel, Boost, Memcache, CDN, Entity Cache, Block Cache Alter, Views Litepager, Views Content Cache, Cache Actions, Cache Expiration, and Purge. Erik also mentioned some third-party tools to help test and diagnose issues with your site.
Since I am a web developer that works with various other team members, I know the importance of jetting off my little island to join others in the waters of productivity. Shelley and I sought out this session presented by Grant Skalak (a developer) and Dario Tadic (a designer). They used their guitargate.com website as a way to demonstrate working through the development and design process without butting heads. Grant took the client requirements to create a working prototype and flesh out any technical hurdles in advance. This allowed Dario to begin his designs with real functionality limits in mind. Their approach to a user-centered agile project felt very natural, simple, and complete. I feel that many projects suffer by starting the design process too early, then forcing the development implementation to jump through hoops to satisfy that appearance. Grant and Dario outlined the evolution of their project with the client, starting with initial research and discovery to prototyping and wireframing. They followed by branding, design, and UX. They finished with development and design refinements as the project came to a close. As someone that both works with teams and on solo projects, I found they did an excellent job with both the project and presenting their method for our benefit.
Another Baltimore Drupal dude, Nick Hepner, presented the last session that we attended. He set things up by describing the typical deployment workflow from local to development, to staging, to production, and back again as content is created. Most things like functionality and configuration go upstream, except for content, which should always come downstream. In Drupal, this can be tricky, since the database contains both content and configuration. The Drupal strategy is that only code moves upstream and only the database moves downstream (when needed). While Nick didn't deeply cover the concepts of utilizing Git with Drupal (admittedly a very large topic), I would suggest reviewing the article titled "A Successful Git Branching Model" by Vincent Driessen for a platform agnostic approach. To capture configuration changes, options like the Features module are often used. Nick shifted focus to utilizing the Features module in a safe way. The Features module provides you with configuration items exported to code and can be moved upstream. He then reviewed Install Profiles, which is a great way to update your site configurations using Drupal's install update system. This was a surprisingly more involved process than I anticipated, so his review was quite helpful in a way that was digestible by developers and site builders alike.
I get lost in work most days and frequently miss meet-ups. Camps can be a great way to catch up with technology and the community. They are frequently more affordable than dedicated training or DrupalCons, so I cannot recommend them more highly for folks on a tight budget or just starting to consider Drupal as a part of their career. If you're seriously interested in Drupal, regardless of your role, you should start by interacting with people that know Drupal when they have Drupal on the brain: At events like this.