I've got some good news and some bad news recruiter. Good news: you got my attention by reading the about page on my website and using the subject line "Update on the Fish." Bad news: by asking "I noticed from the portfolio that you have (currently) two fish - is this up to date??" I now have to regretfully inform you that one of my fish has died. Related question: do you have any connections with people who are able to keep fish alive?
I've always found that one of the best ways to learn something new is to get my hands dirty and start writing code. But it also helps me to have a project to work on, and a goal in mind. You could always go the traditional route and build a to-do list. I need something that's going to hold my attention a bit longer though. With that in mind, here are a couple of ideas that have inspired me recently.
Hot JAMS(tack): Building a Music Discovery App with Drupal and React
Brian Perry gave a talk at DrupalCon Nashville about how he created an application for visualizing trends in popular music using Drupal and React. It's an interesting example, and I love how he's taken something he's passionate about and turned it into a learning opportunity. Find something to play with in this huge list of publicly available APIs.
With projects like Gatsby continuing to grow, the static site generator trend does not seem to be going anywhere. While Gatsby can play nice with Drupal (this site being an example,) the process could be a little easier. As a result, I was happy to see the announcement of Tome yesterday.
Tome is a self described "static site generator lovingly crafted with Drupal 8." I think having a solid Drupal-only alternative could be really useful for folks who aren't ready to dive into something like React in order to use Gatsby. I ran through the getting started tutorial and while I did run into an issue with generated images, I was impressed with what I saw so far.
Sure, I missed the Friday night camp party to go to the Twins game for Prince night, but how can I complain when I got this photo out of it?
I wasn't sure I was going to be able to make it to Twin Cities Drupal Camp this year as I had a little too much travel lined up. I even went as far as telling Tim Erickson at DrupalCon that I wasn't going to attend. However, after hearing that a few other HS2 folks would be submitting sessions I couldn't resist. I eventually decided that I'd lean into the Drupal Camp wave and attend as many as I could this season. So I walked into the University of St. Thomas atrium with my head held high, but as a dirty liar.
Once things kicked off, I was immediately glad that I had this change of heart. Twin Cities has a wonderful Drupal community with a camp that is well run and has been very supportive of me and my craziest ideas for a few years now. I would have been really sad to have missed it. I was even able to continue the good community vibes with the first session of the camp I attended - Drupal and the Music Industry - Learning from our Success. Hearing about all of the music industry sites that are or have been powered by Drupal was a nice reminder that our work can impact the world at large, and even sites our parents and/or kids use. Who needs whitehouse.gov when we've got Justin Bieber?
The camp also served as a nice opportunity to catch up with past and present co-workers, many who were giving talks.
This was my second time in 7 days speaking about the UI Patterns module, but I added a little Pattern Lab specific content this time around. It was another well attended UI Patterns talk which tells me that more folks are understanding the value in the functionality offered by the UI Patterns module, and also that pattern library driven theming workflows still continue to gain popularity in the Drupal community. Thanks to all who attended, to Michelle for this nice photo, and also to Eric from Mediacurrent who I had a chance to walk through the UI Patterns Pattern Lab module during a quiet Saturday AM BOF block.
Also in the general neighborhood of design components I sat in on Steve Persch's session Everything is a Block: How WordPress Rewrote the WYSIWYG. It shared some overlap with his State of Wordpress session from DrupalCon but dove even deeper into the new hotness that is the Gutenberg editor. While I have some issues with the underlying structure of Gutenberg content (tons of content jammed into a body field,) the upsides to a consistent block based approach in the editor resonated with me.
Given that, I asked Steve how he thought we could move to a more consistent use of blocks in Drupal. With all of the possible approaches to this problem in Drupal, he thought that the community needs to align on the things we want to stop using. For him in the past his approach was based on layout plugins (which aligns well with the experimental layout builder module now in Drupal Core.) Alongside this layout based approach he also focused on limiting preprocessing as much as possible so that the admin UI could accurately reflect what ends up rendered on the front end. The latter point especially resonated with me as it is a disadvantage of the common Twig mapping approach to component based theming that I think can be improved by the UI Patterns module or something like it. Speaking of that, thanks to Steve for giving a nice shout out to my UI Patterns presentation during his talk.
The last session I caught at the camp was Conscious Uncoupling -Drupal 8 meets Metalsmith. I was already familiar with many of the concepts here through my experimentation with Drupal and GatsbyJS, but it was great to hear someone else's positive experiences with the JAM Stack and decoupled Drupal. It also me amped to finally try Netlify, which I ended up liking quite a bit.
A few talks I missed but want to go back to:
See you next year Twin Cities. I'll just leave this here.
When I changed the conversation and started talking about ‘Building Blocks’ (what we call our Drupal paragraph types), site blocks (Drupal's search block, branding block), display types (Drupal's view modes such as teaser, search result), etc, they immediately understood.
I'm setting up some front end tooling for an upcoming project and was also considering not using the atoms/molecules/organism naming conventions this time around. My naming conventions will likely vary based on the approach to the build, but the general approach here makes a lot of sense to me. Not surprised that it makes sense to clients as well.
After that, I have Backstop.js set up to regression test all of these, so each time I create a new component I can quickly run the visual regression tests and check that nothing has broken. Since all my CSS/JS is scoped to each individual component, it's rare if something is.
This. For this next build I was planning on having full visual regression testing coverage in the pattern library and then some sampling in Drupal, most likely assisted by the Backstop Generator module.