The challenge with DCFL's structure is that there are five concurrent sessions during each session block, which makes it particularly challenging to choose which one you want to attend. In each session block, I was forced to miss at least one session I really wanted to see but luckily, all of the sessions were recorded and are now available on [the DCFL website](https://www.fldrupal.camp/).
### **Tips for technical documentation with Kurt Trowbridge**
Given that I don't do much directly in Drupal anymore, I decided to start the day with [*Documentation for developers: A gift to your future self*](https://www.fldrupal.camp/session/documentation-developers-gift-your-future-self) by [Kurt Trowbridge](https://www.drupal.org/u/kurttrowbridge). Documentation is a crucial part of developer relations given it is often one of the first touchpoints a developer has with your product so I hoped that Kurt would challenge some of my conceptions about what constitutes good documentation and possibly bring up some ideas I had overlooked, and I was not let down.
While Kurt brought up some points I already agree with—including documentation being everyone's responsibility and making documentation part of your definition of done—he also shared the concept of chunking which I had not thought of previously in relation to our documentation strategy.
If you're not familiar with chunking, it refers to the concept of grouping information into *chunks* to reduce the overall number of items to remember in an effort to improve our ability to recall the information later from memory. The concept was created by cognitive psychologist George Miller in 1956 and published as [an article](https://en.wikipedia.org/wiki/The%5FMagical%5FNumber%5FSeven,%5FPlus%5For%5FMinus%5FTwo) in Psychological Review. It explains why it is easier to remember the number 5,732,562,145 as (573) 256-2145 by *chunking* the information into distinct groups of information, our brains are more efficient at committing it to memory and later recalling it. I remember Miller's Law from my college psychology classes but had never considered it in terms of how it might be applied to technical documentation. We're now discussing internally how we might use this concept to break up some of the more dense documentation into more easily digestible, and memorable chunks.
Another thing Kurt mentioned that really resonated with me is to document where you're going to see it. We have fairly thorough documentation; almost everything you can do is explained in the documentation. However, we still see issues where customers are confused and ask questions that are answered in the docs. There's obviously a disconnect and this statement gave me pause; maybe we're not surfacing the information they need where they'll see it. We're now going back and trying to see where we can inject this information so it's exposed more directly where a developer is most likely to see it when needed.
### **Git going with GitHub Actions**
The next session was my session! [*Introduction to GitHub Actions: Understanding Key Terms and Building Your First GitHub Action*](https://www.fldrupal.camp/session/introduction-github-actions-understanding-key-terms-and-building-your-first-github-action)—[recording now available](https://www.youtube.com/watch?v=q-Dm2lre1Gg). I had a great group of attendees who were engaged and willing to interact as we moved through the materials, walking through the steps of building our first GitHub workflow, our first GitHub action, and then combining the two to begin the journey of automating tasks surrounding our codebase.
### **Tighten up your Drupal code with PHPStan**
After a fabulous taco lunch, catered by [Gringos Locos](http://gringoslocos.com/)—I highly recommend if you ever have a chance to visit one of their locations—it was back to learning. The next session for me was [*Tighten up your Drupal code using PHPStan*](https://www.fldrupal.camp/session/tighten-your-drupal-code-using-phpstan) with [Matt Glaman](https://www.drupal.org/u/mglaman). I've used PHPStan numerous times in the past, but since I haven't done much PHP development over the last year or so, I was a bit behind on where the project is currently. Not only has it been busy keeping up with the latest PHP versions, but they've greatly improved its capabilities in improving your code, catching bugs and issues, and overall improving the developer experience. But the most surprising thing I learned is that Drupal core and contributed modules now run PHPStan for every commit against [Rule Level 0](https://phpstan.org/user-guide/rule-levels), with an [active initiative to move the entire codebase to passing Rule Level 2](https://www.drupal.org/project/drupal/issues/3322735).
### **Accessibility through alternative text with AmyJune Hineline**
Next up was [Beyond "99 Red Balloons" - A Pragmatic guide to alternative text](https://www.fldrupal.camp/session/beyond-99-red-balloons-pragmatic-guide-alternative-text) with [AmyJune Hineline](https://www.drupal.org/u/volkswagenchick). While I do still generate content, I generally do not need to worry about being responsible for alternative text for images. Nevertheless, I have a deep passion for all things accessibility; not to mention, AmyJune and I have known each other for many years but I've never had an opportunity to see her give a presentation and I was not disappointed. Using classic album covers from the past four decades as her examples, she covered various ways the image could be described and how that description might change based on the context around the image. She shared a statement from Eric Meyers that resonated with me, "When you call something an 'edge case' you're really just defining the edges of what you care about." Given everyone will face a disability at some point, accessibility touches us at all. It was refreshing to see others feel the same that accessibility to content and an online experience should be available for everyone, and that there is no edge case when it comes to accessibility.
But the biggest *ah-ha* moment for me was when she showed how you can have Google provide live captions when giving a presentation using Google Slides. As long as your computer mic can pick up your voice it will add the captions to the top or bottom of your presentation. Then, if the presentation is recorded (like they were at DrupalCamp) they're burned into the recording. I sincerely wish I had known about this for the last couple of years as I would have added it to every presentation but now I know for the future.
### **Why Drupal developers should be using Laravel**
The last full presentation I attended was [*Why Drupal developers should also be using Laravel*](https://www.fldrupal.camp/session/why-drupal-developers-should-also-be-using-laravel) by [Lee Walker](https://www.drupal.org/u/mr%5Fscumbag). The core idea was that if you have any CRUD-style requirements, it's far easier and more efficient to build it in Laravel instead of in Drupal. In addition, most developers' experience and knowledge in Drupal will directly transfer over to Laravel. Lee also gave a walk-through of the various offerings in the Laravel ecosystem, as well as the various offerings available for learning Laravel, like [Bootcamp Laravel](https://bootcamp.laravel.com/) and [Laracasts](https://laracasts.com/). He also discussed how great care is given to the Laravel docs; from what he described every docs page is touched when a new update comes out. I've always been impressed with the quality of Laravel's documentation, and somehow am now even *more* impressed.
### **Quickfire takeaways from DrupalCamp Florida 2024**
DrupalCamp ended with Lightning Talks: short, 5-minute or less impromptu sessions that anyone can volunteer to do. There were the typical calls for attending DrupalCamp Asheville and random facts about Florida—I did not know Florida is one of the few places that has both alligators **and** crocodiles and has 6 different species of monkeys— but also several other interesting items I was unaware of including:
* [Coderabbit](https://coderabbit.ai/): an AI-based code review tool for your pull requests. Particularly useful if you're a team of one and don't like having to review and approve your own code reviews
* [https://claude.ai/](https://claude.ai/): an alternative to ChatGPT
* [Stable Cascade](https://stability.ai/news/introducing-stable-cascade): a text-to-image AI generation tool
* Microsoft's Co-pilot can use ChatGPT 3.5 and gives you 30 requests per day
* [Cursor.sh](https://cursor.sh/): an AI-powered pair-programming tool
* There is a somewhat [long, passionate debate](https://www.drupal.org/project/drupal/issues/3082958) over whether the Drupal Recommended project should include a .gitignore file by default, or an example.gitignore, or nothing
* Even though [DDEV](https://ddev.com/) was not officially at this year's DrupalCamp FL, it did make a surprise appearance—one of the door prizes they gave away was a DDEV pillowcase. I had no idea such a thing even existed, but as it turns out, you can [buy your very own DDEV ](https://ddev.threadless.com/designs/ddev-darklogo/home/throw-pillow)pillowcase if you desire.
* F.A.S.T. stroke detection
* F = Face drooping
* A = Arm weakness
* S = Speech issues/difficulties
* T = time to call 911
I'd like to thank all the organizers of DrupalCamp Florida again for putting together a well-orchestrated conference and a solid line-up of presenters and presentations. I hope I'm able to join you again next year!