development

Introduction Drupal 8 is a great platform for storing structured data and exposing web service endpoints. This offers Drupal a competitive advantage when creating a decoupled application or building Drupal as part of a larger enterprise of systems. Core offers many complementary out-of-the-box features to publish web services and configure them in different ways. This includes roles/permissions, Rest Web Services, Serialization, Views, and more. Since Drupal is so robust out of the box, it often minimizes the need for custom development. But, Drupal’s framework has support for any customized

It’s a classic computer science concept: Static versus Dynamic. This fundamental concept is what separates content management systems from static HTML, as a practical example. But, how does this apply to design systems like Pattern Lab and any system(s) that consume Pattern Lab artifacts? The key point to understand is around anticipated changes. What aspects of a pattern can change either based on application, anticipated updates over time, or their conditional placement? Understanding what changes are possible help drive decisions on the use of static or dynamic. Bear in mind, each pattern

IntroductionHere we are. It’s been over a year now that our community has explored design components (integration of design systems, pattern libraries, etc) and Drupal. The community has shared different tools and solutions, presentations from many individuals representing different companies and perspectives, and processes/workflows that enable the different teams and disciplines. I would classify the time spent to date as research, exploration, and innovation. While this is expected for something new, we need to define best practices. The purpose of this blog post is to help us start a

SimplyTest.mePatrickD, the maintainer of SimplyTest.me, recently expressed interest in transitioning the application to a new maintainer. Let me first acknowledge how valuable this tool is for the community. It helps first time contributors who want to rapidly test a patch. It helps community members prototype modules or distributions without the concern of standing up a server. It’s really helped people, especially those not deeply technical, and should continue to as far as I’m concerned. I’ve used this at code sprints, I’ve tested patches on d.o, and generally point people to this in lieu

This terminology has never sat well with me. I haven't had the time really to articulate why. Allow me to explore my thoughts further. I fully recognize that people need to use the right tool for the right job. But, this philosophy suggests Drupal is not the right tool for less ambitious digital experiences. What about sites for local non profits, web presence for a local restaurant without any digital staff, or local religious organizations that desire a straight forward way to communicate their mission to the world on a shoestring budget. Drupal was built on the backs of people creating

Over the last few years, there have been substantial discussions around ReactJS, especially with regard to its former license. This has little to do with the fact that ReactJS offers an attractive and innovative front-end development framework and that it has the backing of a major commercial entity. While I'm not an expert, the most controversial bits do not appear to be driven by copyright concern, but how their license applies to patents. I've learned that legal and licensing can be a significant consideration in determining the technology we select on behalf of our clients, how

Component-based architectures have become both a popular and fairly crowded space in the Drupal community. For over a year, I have followed the progress of some tools created by those leveraging Pattern Lab as a component based design library. I can’t claim to know the full breadth of problems these individuals encountered, many of which are experienced technologists in our space. But, every solution I have seen has been complex and demonstrates some architectural red flags. I wanted to take a fresh look. I paid a designer to redesign my blog for a migration to Drupal 8. This presented the

In an earlier blog post, I described my ideal local environment for developing Drupal based projects (DrupalVM). My primary objectives included separation from the host OS, persistence in config (affording disposable sandboxes), and extensibility to customize around project specific configuration (mirroring other environments). In those respects, DrupalVM has spoiled me and I've likely saved hundreds of hours in large part to these efforts (thank you, Jeff and other contributors). Core development is a different story. Technically speaking, you need Composer, Git, and an environment mirroring

It is safe to say that people like talking about themselves. I'm guilty of that, but I don't think I have actually given any real consideration or focus to the matter. That changed this morning. I had a friend ask me: "What are you passionate about?" I was disappointed by how lame I responded. At my core, I'm a problem solver. I'm also a social nerd - I love people; I'm an extrovert; I'm nerdy. I'm also a self-recognizing honey badger as this has traditionally served as my "winning strategy". None of these things define what I'm passionate about - they just define aspects of who I am and how I

Drupal has a full vocabulary of Drupalisms. While I think that is fine for Drupal-specific features, it also is a sign that we seem to promote our own island when there are similar concepts that exist in the technology space. When possible, we should try to align with more conventional terms that others outside of Drupal understand. If anything, this can make Drupal more approachable and better understood in broader context. I think I identified one such term: the term "Site Building" has never sat well with me - both as an activity and as a role. Site Building is an activity generally