Jeff Geerling's blog

Thoughts on the Acquia Certified Developer - Back End Specialist Exam

A little under a year ago, I took the Acquia Certified Developer exam at DrupalCon Austin, and posted Thoughts on the Acquia Drupal Developer Certification Exam. My overall thoughts on the idea of certifications for OSS like Drupal remain unchanged, so go read that previous post to hear them.

I wanted to post a little more about the additional certifications Acquia is now offering; in addition to the initial, more generalist-oriented Acquia Certified Developer Exam, Acquia now offers:

Earlier today, I took the Back End Specialist Exam, which focuses more specifically on things like Drupal's core API, general PHP syntax and style, secure code, content caching, debugging, and interacting with the Drupal community.

Acquia Certified Developer - Back End Specialist badge

Like the other certification exams, you get 90 minutes to complete the exam (60 questions total), and you have to take the exam either online or in a testing center with an active proctor. This time, I elected to take the exam on my own computer, which was a little more annoying than taking the exam in-person at a test center (as I did at DrupalCon last year).

Solr for Drupal Developers, Part 3: Testing Solr locally

In earlier Solr for Drupal Developers posts, you learned about Apache Solr and it's history in and integration with Drupal. In this post, I'm going to walk you through a quick guide to getting Apache Solr running on your local workstation so you can test it out with a Drupal site you're working on.

The guide below is for those using Mac or Linux workstations, but if you're using Windows (or even if you run Mac or Linux), you can use Drupal VM instead, which optionally installs Apache Solr alongside Drupal.

As an aside, I am writing this series of blog posts from the perspective of a Drupal developer who has worked with large-scale, highly customized Solr search for Mercy (example), and with a variety of small-to-medium sites who are using Hosted Apache Solr, a service I've been running as part of Midwestern Mac since early 2011.

Installing Apache Solr in a Virtual Machine

Apache Solr can be run directly from any computer that has Java 1.7 or later, so technically you could run it on any modern Mac, Windows, or Linux workstation natively. But to keep your local workstation cleaner, and to save time and hassle (especially if you don't want to kludge your computer with a Java runtime!), this guide will show you how to set up an Apache Solr virtual machine using Vagrant, VirtualBox, and Ansible.

Let's get started:

Drupal on Mothballs - Convert Drupal 6 or 7 sites to static HTML

Drupal.org has an excellent resource page to help you create a static archive of a Drupal site. The page references tools and techniques to take your dynamically-generated Drupal site and turn it into a static HTML site with all the right resources so you can put the site on mothballs.

From time to time, one of Midwestern Mac's hosted sites is no longer updated (e.g. LOLSaints.com), or the event for which the site was created has long since passed (e.g. the 2014 DrupalCamp STL site).

I though I'd document my own workflow for converting typical Drupal 6 and 7 sites to static HTML to be served up on a simple Apache or Nginx web server without PHP, MySQL, or any other special software, since I do a few special things to preserve the original URL alias structure, keep CSS, JS and images in order, and make sure redirections still work properly.

1 - Disable forms and any non-static-friendly modules

The Drupal.org page above has some good guidelines, but basically, you need to make sure to all the 'dynamic' aspects of the site are disabled—turn off all forms, turn off modules that use AJAX requests (like Fivestar voting), turn off search (if it's using Solr or Drupal's built-in search), and make sure AJAX and exposed filters are disabled in all views on the site—a fully static site doesn't support this kind of functionality, and if you leave it in place, there will be a lot of broken functionality.

Ansible + Drupal + Raspberry Pi Dramble - Presentation at MidCamp 2015

Earlier today, I gave a presentation on Ansible and Drupal 8 at MidCamp in Chicago. In the presentation, I introduced Ansible, then deployed and updated a Drupal 8 site on a cluster of 6 Raspberry Pi computers, nicknamed the Dramble.

Video from the presentation is below (sadly, slides/voice only—you can't see the actual cluster of Raspberry Pis... for that, come see me in person sometime!):

My slides from the presentation are embedded below, and I'll be posting a video of the presentation as soon as it's available.

Ansible + Drupal: A Fortuitous DevOps Match from geerlingguy

Controlling both the PWR and ACT LEDs on the Raspberry Pi 2

All Raspberry Pi models have a few built-in LEDs; the earlier models had PWR, ACT, and networking status LEDs all lined up on the board itself; for the B+, A+, and 2 model B, the networking LEDs moved onto the network jack itself, leaving just two LEDs; PWR (a red LED) and ACT (a green LED).

Normally, whenever the Pi is powered on—except if the power supply dips below something like 4.5VDC—the red PWR LED remains lit no matter what. If you wanted to 'disable' the LED, you'd have to put a piece of tape or something else over the LED, or get out a soldering iron and modify the hardware a bit.

Luckily, with the Pi 2 model B, you can control both the red and green LEDs in software, in a few different ways. The simplest way to change the way these LEDs work is to modify the trigger for each LED by setting it in /sys/class/leds/led[LED_ID]/trigger, where you replace [LED_ID] with 0 for the green ACT LED, and 1 for the red PWR LED.

For example:

Pages

Subscribe to RSS - Jeff Geerling's blog