I had the pleasure of attending my first DrupalCamp New Jersey this year. I was happy to go as an ambassador for the Project Browser Initiative and a representative for Redfin. Princeton is an amazing venue, and the camp really ran rather smoothly, including free parking a short walk away from the main happenings of the camp.
While I have a lot to say about all of the great sessions I was present for, the highlight for me was the contribution day. (I did not attend any trainings at the training day, so I cannot speak to those.)
Friday was the day of sessions and everything I went to was very well presented.
Editoria11y v2: Building a Drupal-integrated Accessibility Checker
First I saw John Jameson, author of Editoria11y, talk about his journey to writing the second version of this project. Forked from Sa11y, Editoria11y came up in the jQuery days, and when it was time to get a 2.x version underway, much of the client side stuff needed to be re-learned, and re-written. An accessibility engineer at Princeton, John was granted the time needed to rewrite and maintain the project (thank you, Princeton!).
Besides hearing about the journey, I learned what an amazing tool Editoria11y is, and it is definitely something we’ll be bringing to future projects.
Security in Drupal: what can go wrong?
Who doesn’t love a man in a yellow hat? Benji is always a great, smart guy to see speak. He seems to have his hands in a lot of Drupal pies these days, so I bump into him everywhere lately it seems. Usability, security, you name it.
What struck me most here was Benji’s main message–want to know something you can do to improve your health that takes only 4 minutes a day? Brush your teeth. What a boring answer to that question! No macronutrient shakes, no energy crystals? But that’s what it is with security–do the basics. In all my time around the web, though, I never was aware of the “OWASP Top 10” vulnerabilities, so that was my biggest takeaway from Benji’s talk, before he had to scoot off to give a similar presentation at NERD Summit the next day!
A Drupal Core Maintainer shares peer code review best practices
I’ve never met Jess at any Drupal event in the past, so it was an honor to hear her speak about a topic that was particularly relevant to me as Project Browser advances further on down the road towards inclusion in core.
What Jess was able to emphasize first and foremost, was the human element of code review. This is something that someone has crafted and produced on their own, so making sure to treat it more like art than science is the right frame to approach with.
After that, she offered some very concrete guidelines around how to perform best when your job is doing code reviews. All of a sudden, all the things that I thought were so annoying from the Drupal code review process made so much more sense once seen from the reviewer’s side!
Keep your changeset as small as possible, for one. About 200 lines is ideal. And, you as the reviewer need to take a break at about 60 minutes. Fatigue sets in and it’s not worth it to continue reviewing. It also makes sense why reviewers don’t want you to, for example, fix coding standards issues while you’re in there fixing something else. When you scope creep your changes, they no longer match against the actual issue, and there’s more work for a reviewer. So don’t do it! Finally, automate away the nitpicks. It’s so tough to be told to go back and fix coding standards issues for an otherwise good issue. Make sure your project is capitalizing on automatic linters in the testbot so there’s no human having to “be the bad guy.”
Wrapping up with Package Manager and Project Browser
To end the day, Ted and Adam from Automatic Updates presented about the paradigm Package Manager uses to bridge the gap between the Drupal UI and Composer, for installing software. Admittedly, I knew a bit about this already from my work with Project Browser, of course, but also because I saw Ted present this topic at the last DrupalCon. The session was very clear and explained all the parts of the process and the event fired so that consumers of Package Manager can interact with it.
This dovetailed nicely into my presentation on Project Browser, which I referred to as a “Technical Deep Dive.” Let me tell you, though, it’s hard to go deep on anything in 45 minutes. But, I did manage to speak to a technical audience about how Project Browser is architected under the hood. While I wasn’t able to get deep down into the function signatures, I was able to cover the most important classes as well as how to write your own Project Browser source plugin for presenting your own modules to the UI (with the caveat that composer namespaces that don’t start with drupal/* are not supported yet). I encourage anyone to watch the video when it comes up on DrupalCamp New Jersey’s YouTube channel.
I think my favorite part of that session was when I offhandedly demo’d installing a project through the UI in order to show the API endpoints being called and got spontaneous applause! It really reminded me what a feat we’ve accomplished so far, and there’s only more to come.
As I mentioned before, Contribution Day was my favorite part. As can happen at these events, there’s either a lot of folks coming and a lot of newcomers, or hardly anyone comes and people can focus and do deep work. I truly enjoy both, but at this camp we got the latter–and I was particularly excited about it.
Most of the reason that justified me coming down to Jersey (besides having some very dear friends who live just 15 minutes away) was being able to meet Tim Plunkett in person for the first time. Tim and his team have been instrumental in spearheading a lot of the development of Project Browser, especially on the front-end side, and it was a great day to work with him. We were able to work toward getting Project Browser compatible with Package Manager 3.x, especially because Ted and Adam from Automatic Updates were also in attendance that day. It was truly a day of feeling a bit “starstruck,” if I can humbly say that, to be able to spend the day with some real big names in the Drupal community.