A Day (or Two) in the Life of a Drupal Camp
Last week I shared with you some high-level thoughts about why I enjoy attending Drupal events. Now, for those of you who haven't had an opportunity to get to one, I'd like to share a little experience of what these events can be like.
Obviously, not every Camp is the same. And there are Cons, which are even larger. So I thought I'd share what my days were like at the recent DrupalCamp NJ, what the sessions were about, and what the key takeaways were. It’s also perfect timing as a few Echidnas are currently en route to the Sunshine State to attend Florida DrupalCamp.
Maybe I’ll get to see you at a Drupal event in the near future too!
Friday - Code Sprint
Though we attend Camps and Cons to learn, sprints are an opportunity to take that learning and put it to good use. Sprints are about gathering developers together to write code and create working software.
Camps and cons offer you a great chance to gather diverse developers in one place -- so why not take advantage of that?
On Friday, there were anywhere from five to 10 people at a given time attending the code sprints. Many of the attendees were experts or maintainers of modules, so that gave me the opportunity to ask a lot of questions and gain a lot of insight.
What we participated in is known as a Major Triage sprint. While triaging issues can be difficult, it gives you a lot of exposure to different modules and APIs. I imagine this can come handy later.
In a triage, you need to read the entire issue, be able to follow the discussion, and understand why certain decisions were made. Once you understand what’s going on, you can start to reproduce the issue, add to the issue summary, determine whether the last patch is still up to date, etc. Based on your findings, you can change or add tags to the issue.
Saturday - Camp Day
Saturday marked the actual camp, which was structured around four session tracks. The New Jersey Drupal Camp did not have a keynote address, so the sessions ran a little longer than at other camps.
The session tracks included site building, development, front-end and design, and case studies. Each session was also tagged as either beginner, advanced, or intermediate. Of course, there were also the BOFs that I mentioned in the last post.
Some camps last for two full days, so the tracks and events are more spread out. This one packed a lot of information in one full day.
The tracks I attended were:
D8 Module Mad with Power
It was facilitated by Ted Bowman (modules used can be found on github) and he went step by step, showing us how these modules were or were not OOP. In the real author example, he traced back to the parent interface he was extending and showed us which hook he was overriding to change the implementation.
His advice for anyone building a custom plugin was to start with a similar plugin and see if you can extend it, or its parent. If not, investigate it’s interface - what else implements them?
Beheading Drupal, a Love Story
This was facilitated by Williamson Vedder, BlueCadet. While headless Drupal 8 is very popular, it has its pros and cons.
Site Architecture in Drupal
This was a very unusual session as they gave out handouts and post its. I partnered up with my new friend from BlueCadet, Will Vedder, and we worked on the handout together.
The first handout was a wireframe for the Montana Ranch site; The second was a worksheet was an open field architecture plan we had to fill out.
We worked together to identify the various parts of the wireframe and “plan for development.” It was an interesting experience and they really highlighted the importance of planning. There were a lot of things that really made me think twice.
One takeaway I had was that custom blocks are a lot more useful in D8. Custom blocks can now be used more than once and there’s a custom block library in D8 where you can display them all, too!
Rescue Me... Recovering a Broken Drupal Site
Matt Corks described some processes and scripts he uses to recover sites that don’t have database backups after an infiltration. He also talked about how to rescue sites that contain multiple major unsupported core patches.
It was also somewhat of a shared disaster stories therapy group. We discussed the methods by which hackers usually get in and the ways you can be prepared for these situations.
One interesting thing from the presentation that stuck with me was “How to regain user trust” which is something I wouldn’t have thought of. Just being honest with the user and letting them know what data was lost or stolen and communicating what is being done to protect that data in the future.
Communicating Design between Designers and Developers
Benjamin Melancon presented a case study of MASS Design Group website by TLDA, a Providence-based design firm, and Agaric, the developers for the site.
He advocates for the notion that it’s a designer’s responsibility to at least speak HTML and CSS and that developers be ready to throw away code. “Writing code is a way to explore ideas” and allow improvements over time.
And after two days, we all end up going our separate ways. My friends hopped in the car to drive the eight hours back; I steeled myself for a trip back across the border.
But the exciting thing is that when you attend these events, you know you're going to make some new friends and contacts, you're going to recognize their names as they contribute to the Drupal community, and you're likely going to see many of these people at future events.