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.
As I've been learning about the JAMstack I've often heard really good things about using Netlify for hosting. I had a chance to try it out yesterday and I must say that the hype seems pretty warranted.
I often call my blog the least important site on the internet, but the real winner of that award is Camp Perry, a blog that I created as a joke for the unofficial neighborhood camp that happens in my back yard every summer. I wanted to move the blog to Gatsby and also take better advantage of the campperry.fun domain than I could on my current Github Pages configuration. Seemed like as good an excuse as any to try out Netlify. After granting access to my github repo, Netlify was able to:
All of that in a few minutes, and on the free tier. They also offer one click https, which I haven't gotten around to yet. Well worth checking out if you're looking for a place to host a static site build. I'd like to migrate this site to Netlify at some point as well to take advantage of some of the build automation and also https.
Update: with my custom domain stuff all squared away I was able to try the one click https features. One click to enable https via letsencrypt, a second click to force https on the site. Took about 90 seconds start to finish. And Netlify will autorenew my letsencrypt certificate before it expires. Pretty amazing.
Photo by Yes Moon
Had an excellent, jam packed time at Texas Camp in Austin. It was an extremely well organized event attended by a bunch of super engaged and friendly Drupalers. A bit of a short trip for me as I had tickets to see How Did This Get Made back home on Saturday night, but that just resulted in things being focused around a couple of clear themes.
Visual Regression Testing
Visual Regression Testing is a topic I’ve been interested in quite a while now, but I’ve fallen out of practice as of late. I was really excited to see that there was a bunch of content on visual regression testing planned for the camp, much of which was focused around BackstopJS. I’ve tried a number of other solutions in the past (Wraith, PhantomCSS, WebDriverIO) but not Backstop JS which seems to be gaining momentum in the Drupal community.
On Thursday the folks at Pantheon held a training session on BackstopJS, which I attended. It provided a great overview of how they use the tool, along with some example repositories for learning. By the end of the training I had completed a first pass at adding a suite of regression tests to this blog. I would have liked to see a little more content in the training about the general functionality of BackstopJS rather than the Pantheon team’s use cases, but any training where I can walk out with a real world example implemented is a big win.
Continuing on the Backstop train I also doubled down and attended Ryan Bateman from Hook 42’s session on BackstopJS. He provided a little more of the general functional overview that I was looking for after the training, and also talked about the Backstop Generator module that he had recently created. Backstop generator allows you to quickly create a backstop.json file that tests against specific pages on your site and/or a random selection of pages. Seems like a great way for Drupal projects to take advantage of BackstopJS with very little effort. It was also great getting a chance to talk with Ryan later on in the camp - I think he stands as the only Alaskan Drupalist I’ve ever met.
Due to travel I wasn’t able to catch David Stinemetze from Rackspace’s related Archiving and Visual Regression Using Drupal 8 session, but I’m planning on catching up on the video later.
Texas Camp featured two very excellent keynotes that I was lucky enough to enjoy over breakfast burritos. Both are very much worth watching, so rather than try to recap, I’ll just paraphrase a few things that really stuck with me.
Michael Schmid - The Future of Drupal
A Whole Bunch of Me Talking at People on Friday
I was initially scheduled to do my UI Patterns Talk, but was also asked to fill in for a presenter who was unable to attend. As a result I got to give two talks in a single afternoon. This is fine for me because I love hearing myself talk, but to the brave souls who attended both of my sessions - I salute you.
Was exceptionally happy with the lively Q&A that followed the session. Even if you've heard me give this talk before, I'd encourage you to jump to the Q&A at the end.
It was fun revisiting this talk after DrupalCon, but I was especially excited to hear from people who either have, or were planning to use the examples in this project to learn more about decoupled Drupal and React. That was main motivation behind the talk in the first place, so I'm extremely happy that this project may have helped a few people find a starting point to experiment with decoupled Drupal and React.
I also caught a handful of other great talks.
Had some great BBQ and craft beer at the after parties, and can't stress enough how convenient it was having breakfast tacos around to start the day. And then Saturday night I met up with some old Boston friends and did the tourist-y bat bridge thing, saw a fun band called Quiet Company play at Stubbs BBQ, and closed out the night with some Austin food trucks.
All in all, a great trip. And I barely got this post online before the end of the next camp on my list.
Jen Simmons’s suggestion is spot-on: it just got a lot more important to design from a sensible, small screen-friendly document structure built atop semantic HTML.
I'm less excited about WebKit coming to watchOS than I am about the overall impact it will have. The more we focus on developing experiences that can be consumed at any size on any fidelity device, the better the web will become.
Sometimes, a CMS gets built and the work is done. It gets used by content editors and is occasionally upgraded, but the development team and budgets are reallocated to other priorities, and the world moves on. This pattern is especially common with time-sensitive projects (event websites, marketing campaigns, etc.).
Design systems don’t make sense here because a design system demonstrates its value in times of active development. It’s when a designer is working on a new notification message and needs to know what colors to use. Or when a developer is building a new form and needs to see what field types already exist.
If you don’t anticipate a lot of new development on a project, then a robust design system may not make sense.
Had some related discussion in the Q&A during during my UI Patterns session at Texas Camp this weekend - specifically on the actual value of creating an external pattern library in a typical Drupal project. I'm a believer that even just the opportunities to decouple front end and backend efforts can be worth the effort in many projects, but I also agree that you need to sensible in the amount of effort that gets invested into the pattern library. If the pattern library starts to feel like its own product, you might be going overboard. This post encapsulates those concerns pretty nicely.
tldr; I’ve recently been working on the UI Patterns Pattern Lab module which automatically discovers components in a Pattern Lab instance for use with Drupal. I’m looking to test it with a variety of Pattern Lab instances - can you help?
If we’ve run into each other at Drupal camps over the past couple of years, you’ve probably heard me talk about component based development and most likely also the UI Patterns Module. I’m a big supporter of a pattern library driven approach to building a Drupal site, but also feel that some common practices can be complicated - especially for those new to the approach or those not focused on the front end. In my opinion, UI Patterns can reduce that complexity quite a bit.
When the UI Patterns module came along it seemed too good to be true. It allowed patterns to be formally defined as Drupal plugins and took the data mapping that was commonly happening behind the scenes in Twig templates and exposed these in the admin UI where a wider audience could configure and understand them. But if you were using an external pattern library in your project, configuring these patterns for use with the UI Patterns module felt a little redundant.
In Pattern Lab for example you would commonly have a json or yaml file that specified sample data for each of the fields in your pattern. Much of that same data would be once again defined in the yaml file for the related UI Pattern in Drupal. The UI Patterns project has always envisioned that there would eventually be supporting modules that could automatically discover patterns from pattern libraries like Pattern Lab and Fractal, which would make it unnecessary to re-define patterns for use with Drupal. The module even contains classes that could be extended for this purpose. But similar to my initial feelings about the module, that just sounded too good to be true.
I should have seen this coming, but it might not be too good to be true after all.
On an issue in the UI Patterns repository, Pierre Dureau shared his work creating such an integration module for use with UI Patterns and Fractal. It made a lot of sense to me when I looked at the code, and seemed like something that would be reasonable to adapt to a Pattern Lab version. I asked around to see if folks would be cool with me taking a shot at that, and the UI Patterns Pattern Lab module was born.
As of now, UI Patterns Pattern Lab supports the following:
More detailed documentation is available in the documentation guide on Drupal.org
So the call for help part…
I think that the more Pattern Lab instances we can test this against, the more useful it can be (I did some initial testing using Emulsify and was able to fix a handful of bugs as a result.) If you have a Pattern Lab instance that you’d be willing to try with the module (or even just one you’d be willing to share with me), it would be a huge help.
There are a wide variety of ways to configure patterns in Pattern Lab, so don’t be surprised if your pattern library is the one that causes the module to blow up. Also, the thing I’m struggling with right now is how realistic is is to use this with an existing pattern lab instance, especially ones that were set up to do a lot of complicated mapping in twig templates. It remains to be seen if the real use of this module would be with existing pattern lab instance, or along side a pattern library built with this approach in mind. Hopefully after putting this through the paces with a handful of Pattern Lab instances a trend will become obvious.
I’d appreciate any of the help you or your pattern library can lend here. Feel free to get in touch, or comment on this github issue. Thanks!
In an effort to stay on the absolute cutting edge of web technology, I've added an RSS Feed. Enjoy!
Completed a soaking wet Chicagoland Half Marathon yesterday. Finished 1:56:49. About a minute and a half off of my best time, but far from my worst. Hoping for better weather next year.
I’m going to be honest: I’ve had a hell of a time getting my head around React. More than any other technology I’ve touched over the last 10 years of my career, I just haven’t had it click for me. It’s very frustrating as I really want to learn it, and it’s clear the library has legs.
I found React very difficult to learn the first time I attempted it. So much so that I actually just gave up and moved on to other things. Given that, I find Brad's honest take here extremely relatable (except for the part where Dan Abramov personally helped him through his React struggles.) And from a purely selfish perspective, knowing that a developer (sorry, frontend designer) that I admire had similar struggles with React makes me feel a bit better about myself.
I still don't consider myself a React expert, but three specific things made it click for me:
I'm glad I pushed through. Even though I have a lot to learn and a limited amount of time to do so, I really like React.
Saw some useful clarification in the #pattern-lab channel on the Drupaltwig slack about which version and edition of Pattern Lab is recommended to use with Drupal going forward.
So in summary, the next time you need Pattern Lab for a Drupal project, go here.
Helpful clarification given all of the Pattern Lab forks and editions floating around out there.
If the photo above of me forcing Evan to perform much of the show as a talking broom didn't make it clear, being back at ImprovBoston for the 10th anniversary of Harold Night was a blast. It was strange being back in the building at first, but once I set foot on stage it felt as if no time had passed at all. And I even had an opportunity to publicly shame my brother for his eating habits, which makes the night a success by any measure.
Thanks to all who took in this over the top show, avoided my flailing limbs when I repeatedly climbed over audience chairs, and humored a now dad-heavy group of improvisers as they gave comedy one more spin. Being able to see so many great friends that I hadn't seen in years makes getting stuck on the red line for an hour more than worth it.
The show was such a success that I'll once again be retiring from improv effective immediately. I'll see you all at the 20 year reunion.
Hard to believe, but it has been years since I've been on stage doing anything resembling improv. I would have guessed that my comedy days were over for good. Well, they still are! But for one night I'm getting back on stage with some old friends at my old stomping grounds to improvise like it was 2008. Will we change the face of comedy forever? Will we mostly talk about our kids while hanging out in the green room? Will we even be able to stay awake past 10:30 PM? Join us on Wednesday May 2, 2018 to find out.
I’m more than a little late on the traditional DrupalCon recap this year, but even with some time between me and Nashville what I took away is still quite vivid. Better get it in writing before the remaining echoes of country music drown it out.
My most important takeaway from my trip was that the Nashville Predators let fans smash a car painted with the opponents logo before games. Beyond that, I did also learn some things while at DrupalCon.
There is a lot of excitement behind Layout Builder and layout related initiatives
What the Layout Initiative was able to accomplish with the release of Layout Builder as an experimental module in Drupal 8.5 was extremely impressive. It is a great foundation that the initiative already appears to have clear plans to flesh out and improve. It was promising to see many well attended sessions on this topic, coverage in the Driesnote, and quite a bit of excitement about layouts and Layout Builder buzzing through the halls of Music City Center.
The biggest gap I see in what exists thus far is the disconnect between the block based layout builder and the blocks UI. You currently have to leave the layout builder interface to create new custom blocks before you can add them to a layout, and these blocks have the potential to flood the main Drupal custom blocks UI. I was very happy to hear that there is an issue related to inline creation of custom blocks that should help bridge this gap. In a BOF on Components and The Layout Initiative a number of other relevant issues were identified that could potentially improve the experience and make Layout Builder play even more nicely with component based workflows. I’m hoping to follow along with these, go hands on frequently, and help out where I can.
Many are decoupling, but approaches vary
To poorly paraphrase Matt Davis:
Many people build websites this way outside of the Drupal world, they just don’t call it decoupled
There was a lot of great discussion at the Decoupled Summit (Lullabot has a good recap) but also a feeling that while decoupling continues to gain momentum in the Drupal community, there are still a wide variety of strategies and some alignment on best practices yet to come. That said, I think some of that feeling may just come with the territory of the flexibility of an API based approach and the wide array of application frameworks that can consume these APIs.
An interesting topic that came up was the concept of content preview and managing editorial layouts. In the developer case studies portion of the summit we saw a number of attempted solutions to these problems, including an amazing offering from 1XInternet that allowed content managed in Drupal to be edited in either the Drupal or React UI with updates syndicated in near real time. Wow factor aside, conversations later in the summit brought that entire approach into question. The counterpoint being that these editorial conveniences are page-centric in nature and thus won’t always make sense in a truly decoupled context. In this case we’re either putting in a large amount of effort to replicate the traditional coupled website editing experience, or this only represents one portion of the editorial experience we’re trying to manage. It is understandable that we’re often falling back to the page centric approaches we’re familiar with, but this is more evidence that our approaches to decoupling are still maturing.
Discussions during the summit also often crossed into two key initiatives...
The Drupal community is pushing to modernize...
Another common theme that kept coming up is that the JS initiative has a small group working on these issues and could really use additional help. This is another area where I’d love to find a way to contribute in the coming months.
In addition to serving as a proof of concept for how Drupal might utilize React, this UI also crosses over nicely with the API-first initiative since the alternative admin UI that is being developed depends on Drupal’s API. The API-first initiative aims to advance Drupal’s web services in support of decoupling and other new types of integration. Closing gaps in Drupal’s API (file upload support was one that came up as a high priority for 8.6) that could support a decoupled admin UI would also make Drupal’s API more suitable for consumers outside of core.
…but there could be more alignment on how we’re approaching modernization
Complete with its admittedly clickbait title, core conversation A Farewell to Twig received the passionate discussion that the session appeared to be aiming for. This early and theoretical discussion focused on the concept of making client rendering a first class citizen in Drupal and potentially focusing more on decoupling rather than solving all aspects of front end development. One possible approach involved enhancing Drupal’s front end to be decoupled out of the box and then offering one or more decoupled front ends that could optionally be used with Drupal. There were various theories on how far this would go - from shipping with a Twig front end by default (a common concern from the audience was related to continuing to support Twig for small to mid range projects, and also for general consistency) all the way to the concept of not shipping with a front end by default.
It was a thought provoking discussion that also sparked some dissonance with the other things I’d been hearing and thinking about throughout the conference. Much of Dries’ focus in his keynote was on improving the content creator and site builder experience, along with promoting Drupal to non-technical decision makers. This aligns nicely with the layout work (which also featured prominently in the keynote,) but it feels at odds with the focus within the community on decoupling. Can both directions be correct? Should both efforts be happening in parallel? Should I just relax and enjoy all of the new functionality and improvements Drupal has to offer? No easy answers here, so I’ll just link to a relevant meme.
Wordpress: Democratize publishing
Drupal: Ambitious Digital Experiences
I’d agree that Drupal’s mission statement isn’t as easy to hang your hat on when compared to WordPress. And does ‘Ambitious Digital Experiences’ really represent what was focused on during the Driesnote? I’m not so sure.
Presenting at DrupalCon was a ton of fun
I also had the pleasure of presenting Hot JAMS(tack): Building a Music Discovery App with Drupal and React. This was my first time speaking at DrupalCon and I had a ton of fun doing so.
Probably my most interesting takeaway from the session was from an informal poll before the recording even started. The vast majority of people in the room either identified as being new to decoupled Drupal, or new to React. In fact, the vast majority was new to both. This seems to confirm my working theory that there are a lot of people interested in decoupled concepts in the Drupal community but are struggling to find a way to get started. I hope this talk provided a decent starting point and inspired some people to dive in and start experimenting.
Thanks to everyone who attended, packed the room, and provided thoughts and feedback.
This was my most social sprint experience
This DrupalCon sprint was different for me in that I spent the majority of my time having some great conversations rather than actively writing code. I finally had a chance to meet Kaleem Clarkson face to face and talk about how he’s been using the Foundation Patterns theme. I also got to meet and have a nice conversation with Murray Woodman talking to him a bit about how I’ve been using the UI Patterns module, along with his work with Bricks and Modifiers. Especially interesting as earlier in the week I had been talking with Scott at HS2 about how he’s been using the Modifiers module.
And I got lunch at the best BBQ place in Nashville (according to one of my many Lyft drivers anyway.)
It was a damn pleasure to be there in person to see Kevin Thull accept the Aaron Winborn award
Looking forward to continuing the momentum
As always, DrupalCon has me energized and ready to run with this Drupal related excitement (although not enough to get this post out quickly for some reason.) I hope to continue speaking at camps, find some ways to contribute to the initiatives that took up most of my focus at DrupalCon, and an episode of the Developing Up podcast that I recorded with Mike Miles at DrupalCon will be released sometime in the future as well.
Other Great Sessions:
Sessions I’m Still Hoping to Watch:
See you in Seattle!
This pretty much sums up my DrupalCon Nashville experience. Thanks to Chris Greatens for the goofy photo.
Very much looking forward to spending next week in Nashville attending my 4th DrupalCon. The spontaneous and unplanned stuff is half of the fun, but there are a few things that are locked on my schedule.
Monday: Decoupled Summit - I'm excited to hear more about what people are doing in the decoupled Drupal space. This will be my first time attending a summit at DrupalCon as well.
Tuesday 1 PM: Components and the Layout Initiative BOF - I'll be leading an open discussion on how the Layout Initiative might impact our component-based workflows. I've really enjoyed the BOFs I've led in the past and expect this to be no exception.
Wednesday 3:45 PM: Hot JAMS(tack): Building a Music Discovery App with Drupal and React - I'll be sharing my experience building a music discovery app with Drupal and React in my first ever talk at DrupalCon.
Thursday: Who knows!
Can't wait to say see friends old and new, learn a bunch of cool new stuff, and land a country music recording contract.
As always, I learned a few things this week upgrading projects to Drupal 8.5 and applying the most recent highly critical Drupal security update.
The first is yet another reminder to carefully read and consider the documentation. The highest priority projects that I needed to apply the security release to were on 8.4.5 at the time of the pre-announcement. I took this as a good opportunity to upgrade to 8.5 and then kind of got tunnel vision about getting these projects, and also my lower priority D8 projects up to 8.5 in preparation for the security release. Not having looked back at the security advisory since my initial read, I lost sight of the fact that I could easily apply the patch to their current D8 version and worry about 8.5 when the pressure was off a little bit. Thankfully I was reminded of this during a well timed check in meeting with the Drupal practice at HS2 - a few of my 8.5 upgrades were a little behind schedule. Having the flexibility to apply the security update to older versions of D8 really helped and most likely prevented us from rushing a few upgrade related regressions out into production.
Speaking of the 8.5 upgrade getting a bit behind schedule, minor Drupal updates (8.4, 8.5 and so on) are still more challenging than I'd expect them to be. Jeff Geerling's post Updating drupal/core with Composer - but Drupal core doesn't update proved invaluable as I ran into the same issue. I also had another pretty tricky dependency conflict that eventually required me to remove and work around a dependency (again, Jeff Geerling's post helped quite a bit here.) After successfully upgrading to 8.5 composer-wise, I found that a patch to Page Manager needed to be applied for the site to even run.
I'm getting better with managing Drupal projects via composer, but still have some room to grow. Lowest hanging fruit is that I need to start managing patches via composer. Once that clicked in my brain it was a little to late to experiment with it. Next time. I also still sometimes get tripped up with the difference between the ^ and ~ version constraints in composer.json which is embarrassing to admit.
I also ran updates on Drupal instances based on API-first distributions. Those were a bit of a different beast. In my case, most were single purpose enough that I was able to just run composer update and call it a day. That said, each distro had their quirks. The version of Reservoir I was using had a dependency conflict that prevented the upgrade until I manually locked Reservoir at Alpha 4. Contenta seems to have a patch that won't apply to 8.5
I'm all for learning, but also looking forward to this process becoming smoother sailing in the future.
A great listen that could serve as a solid introduction to the JAM Stack concept. Especially interesting was the focus on some common counter arguments to the JAM Stack (dynamic things like forms, comments and so on) and how those may be more achievable than one might originally assume. As I try to add a little more punch to the JAM Stack focused portion of my DrupalCon talk I see myself going back for another listen.
With a new critical Drupal security release on the horizon, static site builds are looking better and better. I'm glad I won't have to won't have to worry about this site (Drupal isn't accessible to the public) while I scramble to apply the security release elsewhere.
Another year, another great MidCamp!
I wasn’t able to attend for training and sprints on Thursday (1st grade play FTW!) but ended up talking to a former co-worker who attended the training 'What Am I Getting Myself Into? A Drupal Crash Course for Non-Developers.’ While it's easy to get wrapped up in the new and advanced at a camp like this, it is also really important to see newcomers, beginners, and people with Drupal-adjacent roles take steps into becoming more hands on with the CMS. She specifically mentioned that the training helped her have some revelations about a few Drupal-isms that us crazy developers have been talking about all this time.
After some really enjoyable traffic, Friday brought me to the first day of sessions. A couple of highlights:
Local Dev Environments for Dummies - the bulk of this presentation reviewed data from a 2018 Drupal Developer Survey, and the data alone was extremely fascinating. It also provided some interesting perspectives on Vagrant vs. Docker for local development (go Vagrant if matching your prod environment exactly is important, and Docker for pretty much everything else.) I also walked out of this one itching to learn more about Lando.
Component Based Drupal - Surprise! After a cancellation, Adam Bergstein and I stepped in without much of a safety net (I learned that I was co-presenting this session due to a mention on twitter) to talk about the current state of building and theming with components in Drupal. I’ve always enjoyed my conversations with Adam on this topic because while we primarily agree, we also have some differences of opinion and take some different approaches in our workflow. Continuing this conversation out in the open seemed to be useful to people, and I even got to joke around a little bit. I wouldn’t be surprised if Adam and I presented in a similar format in the future.
Saturday - less traffic, more sessions.
OOP - The Pokemon Journey / Bending Behat's Benefits: A live coding adventure - A journey followed by an adventure? Hell of a way to spend a groggy Saturday morning. I love hearing from both Fatima and Steve whenever I can. The OOP Pokemon Journey was a fun and easy to understand talk on a topic that I honestly don’t yet consider myself an expert on. And Bending Behat’s Benefits made me anxious to incorporate some more test driven development into my process after some time away.
Too many cooks! Supporting augmented teams without getting salty - I wasn’t able to attend in person, but heard great things. It’s next up in the YouTube queue.
American Medical Association: Topic Landing Pages (A D8 Case Study) - an excellent, and extremely relatable talk about the challenges of Drupal 8 landing page building integrated with a pattern library based approach to theming. I’ve felt so much similar pain/joy on recent projects. They also closed with the reminder that we all need to look into how Layout Builder in 8.5 and the Layout Initiative will impact this process going forward, which I think is extremely important.
Hot JAMS(tack): Lessons from Building a Music Discovery App with Drupal and React -This is my attempt to demystify the process of creating a decoupled app with Drupal and React by way of a fun side project. It was my first time giving a talk that I’ve had brewing for a while, and I was happy with how it went. Heard a lot of positive and helpful feedback and have a few things that I think I can tweak to make it more useful for people. Looking forward to presenting it again at DrupalCon Nashville.
Plus, this was pretty cool:
Funny slide! https://t.co/LLqwuVXFb3— Dries Buytaert (@Dries) March 11, 2018
Sunday was sprints, and unfortunately more traffic on the way home. I was dragging a little bit at this point, but still feel like I was able to get a few things done. I got back to the Foundation Patterns theme and responded to the first issue submitted against the project. I helped Tony Klose set up a Pattern Lab instance for a Drupal theme, and realized that I don’t have a clear personal process for including a pattern library as an external dependency of a theme. I also collaborated with Adam Bergstein a bit more looking at a possible React front-end for simplytest.me
A huge thanks goes out to the MidCamp organizers who overcame some pretty steep challenges to put on another great camp. I’ll see everyone next year at O’Midcamp!
Have been hedging my bets about learning Redux, but was getting close to taking the plunge. Now I'm wondering if React's upcoming Context API can meet my needs. Looking forward to more takes on advantages and disadvantages of the context API in comparison to things like Redux.
While Drupalers are rejoicing at these exciting advances allowing newfound front end freedoms, there are still a few hoops to be aware of in order to make the most of Drupal, especially for a newcomer who might be eager to shove aside a lot of what Drupal provides. ...things that are easily dismissed in a component-driven approach, like letting Drupal fully render fields, can cause headaches further on if they’re ignored, and make life difficult when it comes to keeping your front end forward-compatible with Drupal.
The UI Patterns module really does solve many of the problems outlined in this post, so my preference is to embrace that approach and leave these complicated presenter templates behind. But for those who haven’t embraced UI Patterns, this post really is essential.
When explaining some of the gotchas with this approach, I often use images as a simple example. Creating a component from scratch the instinct is often to pass in src and alt values as variables to get the cleanest markup possible. You can get that stuff out of Drupal, but it really is a pain. You’re better off just using the image markup Drupal renders, even if it isn't exactly as clean as you want it to be. Sometimes not fighting this battle at all is the right way to go. But if you want the perfect markup this post has everything you need to do it the right way.
Went down a bit of a CSS-Tricks rabbit hole over lunch today.
Started with Complexity. I've enjoyed all of the recent point / counterpoints about the increasing complexity of front end development. This is a nice summary.
That led me to The Future of Front End Web Development. Totally agree with everything in there, maybe with the exception of 'the line between native and web is blurring.' I'd probably just put that one in the future-future of front end web development category. Not quite there yet, but looking forward to when it is more of a reality.
And then that led me to When Does a Project Need React. The more comfortable I become with how state is managed in a framework like React, the more insane our old jQuery tricks to jam state into the DOM seem. That said, not all projects have complex state.
It's very hard to explain why, but I consider 'U Talkin' U2 2 Me?' to be the greatest podcast of all time. Possibly just one of my favorite things of all time. I don't like U2 all that much, yet somehow hearing Scott and Scott break down U2's entire discography over 24 episodes was something I saved for special occasions and often laughed to the point of tears while listening to. And boy, did they ever spend a lot of time talking about the band U2 (not really.) They even knew the names of every single member of the band. Truly encyclopedic knowledge.
And now Scott and Scott are back with 'R U Talkin' R.E.M. RE: ME?' in which they explore the output of the band R.E.M in what I'm sure will be painstaking detail. I like R.E.M. more than I like U2, but I can't say I would ever want to go through their entire back catalog. Yet somehow here we are again, and I'm excited to hear all about the album Monster. Listening today was just like old times. Can't wait to save for long road trips and laugh to the point of nearly driving off the road.
If you're looking for more info on what the hell this is all about, this Stereogum interview is as good a place as any. It might just confuse you more, which is par for the course.
I noticed last weekend that the build was broken for this site - post switching on the homepage wasn't working, and as you scrolled down, posts started to be wrapped in the container for the previous post. I tried a new Gatsby build and saw the same thing. Next, I zeroed in on the post where content started overlapping and eventually noticed that I had some malformed markup in my post in Drupal - a missing closing quote for a href attribute. After updating the post to add the missing quote and doing another build, everything was fine again.
You could chalk most of this up to me - if I was using a wysiwyg editor it would have added the correct link markup for me, and I should probably be taking a closer look at my build after it goes to GitHub Pages. But I think this hiccup was a nice reminder of the reality of these super sexy decoupled architectures. We lose a bit of the protection that Drupal provided us from something like malformed markup in a body field making a page explode. Builds will break in ways that they didn't with Drupal alone - the site worked fine in development mode but broke when the production bundle was built. And while testing is always important, we likely need to test in ways that are different from when we were testing Drupal by itself.
There are lessons to be learned even in the dumbest of problems. I'm sure I'll run into some more.
Learned the hard way recently that Drupal 8.4 upgrades jQuery to jQuery 3. This kills a few methods that were deprecated in previous versions of jQuery including .load(), .unload(), .error(), and .size(). The release notes cover this, but it didn't fully click until I actually ran into the issue.
Related: is a minor release really a minor release if it contains major release upgrades for a couple of your largest dependencies?
Theresa Nicholls was eager to get back home as she packed her bags at the Hyatt Regency Chicago on Friday.
Her weeklong conference of school psychologists had been rocked by the mass shooting at a Florida high school. A day earlier, a Chicago police officer had been shot and killed in the Loop, just blocks from where she and her colleagues were staying.
As she was getting ready to check out, a friend texted her: There had just been a shooting in the lobby of her hotel.
“What the hell is going on?" she thought. "What is happening? It’s like the world is falling apart around us.”
My wife was at this conference. There are a lot of reasons we need to do something about America's access to guns. Let's add this one to the list.
A great collection of resources on creating decoupled applications with Drupal and React from the Lullabot folks. Hope to contribute a link or two at some point.
I say that I'm a 'full stack' developer, even though it is a term I've never really liked all that much. The main reason that I don't like the term is because I feel like it doesn't mean that much to people. Full stack developer kind of feels like someone saying 'I'll do whatever'.
I'm not sure if it is directly related to being a full stack developer, but over the years I've seen a pattern in how I'm utilized. In my various roles as a developer, I often start out doing front end work, and then over time find myself doing predominantly back end work. This could be because back end work has a higher value at the places I've worked. It also could be because I suck at front end and just don't know it (hopefully not that one.) It's almost as if what people take full stack to mean is that the developer is exaggerating about their skill level on either the front or back end of the stack. Or maybe that they just haven't figured out which end of the stack their real talent lies.
I've always considered myself someone who prefers front end, so that is a bit of a challenging pattern to be stuck in. But lately I've been wondering, am I not being honest with myself?
Maybe I'm just describing myself wrong. I often describe myself as is a full stack developer with a preference for front end. While that sounds kind of like a line from a personal ad, it does describe what I like to work on. I prefer front end work, can do back end work, and especially enjoy back end work when it is in service of making front end work possible or better.
Drilling down on that last part brings us to the section where perhaps I'm not being honest with myself.
I can do back end work, and especially enjoy it when it is in service of making front end work possible or better.
Maybe my real thing is what lies in the middle. The overlapping part of the venn diagram between front end and back end.
There is so much in the middle.
Maybe I've been a middle end developer all along.
iO West, the Los Angeles branch of Chicago’s iO Theater (formerly ImprovOlympic) founded by Del Close and Charna Halpern, is closing its doors for good next week.
At first it struck me as odd that many of my comedy friends on social media were talking about this like someone close to them had passed away, but I eventually realized that I've just been out of the comedy scene too long. If this happened to my home theater back in the ImprovBoston days, I probably would have reacted the exact same way. Running a theater is an inherently risky business and 25 years is quite an accomplishment. I hope everyone finds a new home to keep doing what they love.
Fatima Khalid (sugaroverflow), web developer with Digital Echidna, and DrupalCon Nashville track chair and sprint mentor joins Mike Anello to talk about how to be a first-time sprinter at a local Drupal event or a DrupalCon and how she came for the community and stayed for the code.
Thought this was a really fun and accessible overview of what a sprint is like. I found them very intimidating at first and I think hearing an overview like this in advance would have helped. Don't know how many first time sprinters are avid listeners of Drupal podcasts, but any little bit helps.
Each of these have trees of components which are made up of other components and elements (often named different things). Each element in the tree is independently styled. It's not built around cascading styles and the expectation is that you can copy any element and place it anywhere else and it will look identical.
Interesting way to think about this - the end result of CSS-in-JS might just be what our designers wanted all along.
I also really like the term "Component-Oriented Styles." Be it a methodology like BEM or a library like Styled Components, we're really just trying to make styles predictable within the scope of of a reusable component.
The IndieWeb movement has provided two clever names for these models:
- PESOS or Publish Elsewhere, Syndicate (to your) Own Site is a model where publishing begins on third party services, such as Facebook, and then copies can be syndicated to your own site.
- POSSE or Publish (on your) Own Site, Syndicate Elsewhere is a publishing model that begins with posting content on your own site first, then syndicating out copies to third party services.
I've been thinking about this as well as I build out this website. I fall into the POSSE camp, and right now it's completely manual and mostly just me posting links on Twitter. To some extent, I'm even fine with this website just being its own disconnected thing. It will always be a small subset of my social network that would make it here and actually read something, and that seems just about right.
When initially setting up gatsby-source-drupal for this site I started thinking about how I could adjust my GraphQL query to only include published posts. I eventually realized that the plugin was already doing that by default. That isn't always the case for stuff like this, so it was a nice time saver.
MidCamp is my home base Drupal camp and one that I've attended for years. This week the organizers apparently ran into a pretty major snag with some budgeting issues with the venue.
Clarification regarding #midcamp news: Since we just found out we won't qualify for our venue discount for this year, we are looking to raise an additional $15,000 in sponsorship before 2/15 before making drastic cuts.— Kevin Thull (@kevinjthull) February 8, 2018
For me, MidCamp is a really important part of staying connected with the Chicago-area Drupal community. It is also the first Drupal event I ever presented at, and I'm scheduled to speak again this year. I'd really hate to see MidCamp have to scale back and not be the MidCamp we all know it can be.
There are many ways you can help. If you have a company (or a rich uncle) that could sponsor, that could make a huge difference. If you have the means to become an individual sponsor, that would help too. Word is that they are also working on an option to accept smaller donations as well. And if none of that is possible, registering or volunteering helps.
Do what you can, and hopefully we can all make it happen. Looking forward to seeing everyone in Chicago in March.
Update: MidCamp is also accepting donations of any size
Really enjoying Celeste so far. pic.twitter.com/YAHpq2XdhJ— Brian Perry (@bricomedy) January 27, 2018
Can't recommend Celeste enough. Perfect for Switch.
The call for DrupalCon Nashville session proposals closed this past Wednesday and I was able to get my act together enough to submit two of them. The process of putting together a session submission is always an interesting one for me. For DrupalCon it is usually a wonderful mix of overanalyzing, combined with good old fashioned imposter syndrome. That said, I feel like I improve each time around, and I think these are my strongest proposals yet.
Submission one was 'Component Based Theming with UI Patterns.' I've given this talk before and was happy with how it turned out. I submitted this one very early, and also noticed that Mario Hernandez had submitted another talk on the topic as well. In hindsight, I should have reached out to him and seen if there was any way to collaborate as he ended up joining up with another speaker for his session. Lesson learned for next time.
Submission two was 'Hot JAMS(tack): Lessons from Building a Music Discovery App with Drupal and React.' Strong competition as well here with many Decoupled Drupal and React related topics, but Im hoping I have a slightly different angle that might garner some interest. True to my usual form, I also went with a goofy, high-concept approach with the submission. Almost got cold feet about going in that direction, but decided I'd rather have fun with it. Ironically, with a proposal that heavily references music, I didn't even make the Music City connection until writing this post. Would have been fun to play that angle up more.
This will be my third time submitting sessions to DrupalCon North America (which I guess is now just DrupalCon?) I've never been selected, but I have been asked to be on call as a back up speaker, which I had no idea was even a thing. Regardless of the outcome, I enjoyed the process putting these session proposals together and look forward to Nashville this year. I've never been!
Update: Was a little wrapped up in the DrupalCon deadline, but I also submitted both of these sessions to MidCamp in Chicago. In addition to being my home camp, MidCamp is always really, really great. You should go!
Today, the company revealed a new initiative dubbed Nintendo Labo, which involves DIY cardboard accessories that can transform the Switch’s Joy-Con controllers into everything from a fishing rod to a piano to a full-on robot suit. These accessories are then used to control a variety of mini-games, essentially turning the Switch tablet into a tiny arcade.
Paraphrasing, but when I told my wife about Labo she said, "Nintendo is going to get you to buy a cardboard box, aren't they?"
It wouldn't be a new year without the desire to relaunch my personal website. Happy 2018!
It could be another case of New Years delusion, but this year I think the timing might actually make sense. Over the past year I've been exploring React and the world of Decoupled Drupal. After working through Wes Bos' React For Beginners course and having some concepts finally click, I took another shot at creating a web app based on the Album of the Year Project. Having a project I could slowly chip away at over the year provided a great low pressure way to learn, and also prevented me from having to re-learn things as they vanished from my brain. I'd love to duplicate that situation in 2018.
Next up learning wise I'm planning on continuing my experimentation with the JAMstack by way of Gatsby.js. I like what I've seen of Gatsby thus far. It allows me to leverage all of the things I've enjoyed about React, while combining that with the features of a static site generator like Jekyll or Hexo. And it plays nice with Drupal 8 as well, which is a plus.
So welcome to my new Gatsby site. It will be nice to have an active personal website again, but perhaps even more exciting is the fact that this serves as another low pressure project I can chip away at throughout 2018 to learn more about React and decoupling Drupal. I'll start out with a site very close to nothing - little content, little styling - and slowly add new stuff as time and interest allows.
With any luck this site will look completely different by the time 2019 approaches. And hopefully I will have learned a thing or two along the way. If you're curious, the code is available on GitHub.