Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 13 Minuten 37 Sekunden

Dries Buytaert: How to decouple Drupal in 2018?

10. Januar 2018 - 21:16

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures. As a result, Acquia now offers Node.js hosting, which means it's never been easier to implement decoupled Drupal on the Acquia platform.

Let's start with the new flowchart in full:

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways. Moreover, for Acquia customers, Acquia's recent launch of Node.js hosting on Acquia Cloud means that developers can leverage the most modern approaches in JavaScript while benefiting from Drupal's capabilities as a content repository.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Lullabot: Guidelines for Writing Proper Tickets and Commits

10. Januar 2018 - 18:12

Have you ever been assigned a ticket with a title like “Some Images Don’t Work,” or opened a monstrous pull request containing a single commit labeled “bug fixes” as your only clue to the changes made? This level of ambiguity is frustrating and can end up costing exorbitant time and money to research. The titles, descriptions, and messages we provide in our workflow should make the jobs of not only our peers easier but also future team members who will inherit the project.

By tweaking our process just a little to document while we work, we can alleviate stress and save time and money on the project. Now don’t go breaking out the wikis and word processors just yet. Much of the critical documentation can be done within the tools you are already using. Writing actionable ticket titles, informative descriptions, and properly referencing related issues and resources can remove mountains of ambiguity and save yourself loads of time filling in the blanks or worse, making assumptions.

Before we get into the details, we need to think about the motivations behind the madness. If we’re going to spend more time writing up descriptions and details, what do we get for it? Anytime you are writing words that another person will read, think about who that person is. It might be a new developer on the team who doesn't have your background knowledge or you in a few months. Maybe a project manager, maybe a stakeholder. Will a machine be able to read and interpret this? All of these factors should influence what you write, regardless of whether it is a description of a bug or a commit message. What information will the next person need so they can eliminate assumptions about the task? Keeping this concept in mind, consider the following benefits:

  • Hours of time spent onboarding a new developer could be reduced.
  • Determining who signed off on a ticket and the process they followed could be done by inspecting a commit’s notes.
  • Changelogs could be automatically generated in different formats for stakeholders and developers.
  • Stop cursing out the previous development team because you don’t understand why they chose a particular method.
  • Or worse, don’t waste your time refactoring that code, then reverting it because you finally did figure out why they chose a particular method.
  • Spend time developing instead of researching a ticket.

As you’re creating a ticket, a commit message, or a pull request; remove the space for assumption. Explain why you did what you did, and, if necessary, how. Let’s start at the beginning with the ticket queue.

Tickets

In this section, we’ll focus on the most granular of issue types: tasks and bugs. Epics and user stories have their own sets of rules and fall outside the scope of this article.

Ticket titles are the first field that someone reads. As I’m looking at my queue, I should know specifically what the ticket is intended to resolve by its title. Consequently, the title should describe the action that the ticket is to fulfill. Here are a couple of examples of good and bad versions of a ticket titles.

Good: “Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navigation is Wonky”

Good: “Implement Home Page Right Rail Promo Block”  

Bad: “Homepage updates”

A helpful hint to consider when writing a title is that it should complete the phrase “This ticket will….” If you’ve done this correctly, the title will always begin with a verb; a call to action. When I see a ticket with the title, “Some Links are Yellow,” I think to myself, “Yes, yes they are. I’m assuming they shouldn’t be since you created a ticket, but what do you want me to do?  Should all links be yellow?  Or none of them?  What color should they be?”  Now, imagine you are a stakeholder reading over a list of completed tickets.  What would you think as you read this title?

Sometimes you’re going to need more than just the title to convey the complete purpose of the ticket, so make sure your ticket descriptions eliminate any room for assumption as well. For bugs, include the steps it takes to reproduce the issue, the environment where you encountered it (OS, browser, device, etc), and what the desired result should be. For simple tasks, reference any comps that describe how it should be implemented and consider user interactions if there are any.  The description field should provide extra information about the goal of the ticket.

If you are having trouble coming up with a specific enough title, consider breaking the ticket down into smaller subtasks, or promoting the ticket to an epic.

Branches

When you start your work, the best practice is to keep your main line of code clear by creating feature branches in your VCS to work on new tickets.  Branches should be filterable, recognizable, and attributable. That is to say, I want to be able to locate a branch quickly by who created it, which issue it’s tied to, and what it’s about.

I prefer a format like this: "owner/issue-id/short-description"

Which could end up looking like: "keyboardcowboy/proj-1234/fix_jumping_nav"

Think about who will see the branch names: myself, other developers, maybe a project manager, the repo gatekeeper if you have one, and machines. Using this format, I can now easily find my branches to create a pull request; I can check if anyone else has a branch for this ticket number; and I can allow project software, such as Jira or GitHub, to reference this branch by searching for the issue number pattern.

undefined Commit Messages

Developers may recognize the commit message prompt as that annoying thing GIT makes you do before you can push your changes. While it may be annoying when you’re working on your own, I guarantee that coworkers and your future self will appreciate the detailed messages you provide.

The reason for the commit message is to describe the changes taking place in that commit. If you find you can’t describe everything in one sentence, try breaking the commit into smaller, atomic commits. This makes it easier to roll back isolated changes if necessary and allows you to describe each change more succinctly. Just as with the issue titles, describe what the commit does. Someone else should be able to read it and understand to a basic degree what this change encompasses.

It’s also extremely helpful to precede the commit message with the issue number. The software can recognize certain patterns in commit messages and generate links from them. Tools like PHPStorm can help automate this for your process by integrating with GIT.

undefined

Here’s an example of well formatted, atomic commits vs a lazy commit.

Good Commits:

[proj-1234] Refactor white space in CSS so it’s readable. [proj-1234] Remove deprecated classes and definitions from CSS and templates. [proj-1234] Increase transition timing on navigation dropdown. The nav seemed to be jumping when the user scrolled while it was open. Increasing the transition timing allows it to expand and contract more smoothly and alleviates the jumpiness. [proj-1234] Fix merge conflict in update hook number.

Bad Commits:

Nav stuff.

Notice how the third good commit has multiple lines. The other commits in this set were ancillary to the issue.  The third commit is where the critical changes were made, so I explained my reasoning and why it fixes the issue. Without that, it looks like I just changed the timing. You might be able to trace the PR back to the original issue and piece things together, but a brief explanation directly in the commit can save time and headaches.

It may seem like overkill, but commits become very handy for the next developer, especially if you are using an IDE that integrates with GIT.

undefined Pull Requests

Pull requests are a common method to contribute to a project without needing commit access to the repository or to the main code branch.  The title of your pull request should follow the same structure as issues, but with one caveat; like tickets, they should describe the action that will occur if the code is merged, but they should also be prefixed with the issue-id of the issue they resolve. In GitHub, for example, the pattern "#ID" creates a link to that issue number. Even if you are not using GitHub as your issue manager, this is still an important reference, especially if you are running on a standard sprint cycle and need to generate reports for what was completed in each release.  Humans can follow this pattern to reference tickets as well as machines.

When you merge a pull request, a commit is made against the base branch and the title of the pull request is used in the commit message. Wouldn't it be nice if you could search through all the commits between release tags, find any that are pull requests and print them with references to their original issue as a change report? It’s surprisingly simple to automate that process if you follow these guidelines. Here’s an example of a good and a bad pull request title.

Good: “[PROJ-1234] Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navbar Issues”

Imagine reading this as a code reviewer or a stakeholder trying to gauge what was accomplished in the last release. Which is going to be more informative? The title text describes exactly what was addressed, and the prefixed issue number provides the information needed to create a link directly to the original issue.

Just as with the original issue, you have an area for a summary in the pull request. I’ve found the most success in separating business discussions and technical review discussions between the issue management software and the pull request tool respectively. If necessary, provide testing instructions in the proper place and that your team follows any documentation guidelines consistently.

Automated Changelogs

Stakeholders often ask us to provide a list of everything that changed in the last release. Long sprint cycles and large teams can make this a challenge, especially if your issues, commits, and pull requests are vague.  The aforementioned guidelines not only make the project more understandable for people, but also for robots. On a project where the stakeholder required that an email is sent out after every release containing all the changes in that release, we used a simple, custom node script to pull all the commits made between tags and format them into a human-readable list using markdown. That list could be copied and pasted into various places, such as email and GitHub releases.  I’ve found a growing number of utility programs that attempt to do this or something similar. In a single command, you have a perfectly formatted, readable changelog, complete with links to the original issues!

Here are a few helpful tools I’ve found so far:

Documentation doesn't have to be boring and time-consuming. You can clarify your project with just a few simple refinements in your existing process and drastically reduce time spent writing up wiki documentation. Writing more detailed and informative tickets, commits, and pull requests will reduce sunk developer time, provide clarity for your stakeholders, ease your onboarding process, and provide better accountability and understanding throughout the project.

Do you have any suggestions or tips for documenting as you work? I’d love to hear about them!

Acquia Developer Center Blog: Working with BLT: An Automation Layer for Testing, Building, and Launching Drupal 8 Applications

10. Januar 2018 - 16:57

Mike Madison, a Technical Architect in Acquia Professional Services, recently completed a Drupal site build for a major public transit agency in the United States. We spoke with him about his experiences using BLT -- an open-source Acquia product that provides an automation layer for testing, building, and launching Drupal 8 applications -- on this project. Mike said that BLT has been a critical component of the project’s success, and has especially helped in three primary ways: by accelerating project spin-up, improving developer onboarding, and increasing development velocity and delivery consistency.

Tags: acquia drupal planet

Mediacurrent: Do Drupal and Digital Right in 2018: Know Where and How to Start

10. Januar 2018 - 16:30

When you’re solely focused on Digital Strategy and Drupal as your open source website and web application development framework like Mediacurrent has been for the last 10 years, you’re deeply invested in all of the great challenges and rewards that come with delivering products and solutions that are essentially only limited to your creativity and what you can dream up.

Tim Millwood: 10 years of Drupal

10. Januar 2018 - 15:28
10 years of Drupal

At 12:54pm on January 15th 2008 (based on the created time stamp of "1200401651") I signed up for my Drupal.org account while working for International Baccalaureate. Before my interview there I had never heard of Drupal, but managed to ace the interview and get the job, no idea why I didn't bother signing up for Drupal.org until after I started the job, but hey, that's just how it was. I was jamesfk who introduced me to Drupal there and who I worked with building a bunch of community sites in Drupal 5, then 6. I got the chance to visit Toronto for training with Lullabot where I got to meet great people such as James Walker, Matt Westgate, Jeff Robbins, Addison Berry, and fellow student Doug Vann. I also landed a trip to DrupalCon DC 2009, where I met even more great people and many people I now knew virtually from Drupal.org, IRC, and Twitter.

Later in 2009 I started work with Mark Boulton who was already well into his work with the Drupal.org redesign, and starting work on the new admin theme for Drupal 7. It was awesome to be a part of these projects, as well as many Drupal projects which were coming in on the back of these. While working here I got to attend DrupalCamp UK, DrupalCon Paris, and DrupalCon Copenhagen.

In 2011 I moved to a position at Acquia which saw me become the 4th Acquia employee in the UK, along with great Drupalists like Hernâni, and the first support engineer based in Europe, shortly followed by Aurelien. Later that year I co-load organization of DrupalCon London (or Croydon) with Jeff. At Acquia I moved to help form the customer success team, assisting clients getting their Drupal sites up and running and launch successfully.

After nearly 4 years I left Acquia to join Appnovation who were looking to setup a UK office in Wales (where I live). This also saw me start working with Pfizer on their Drupal 8 projects, initially I was contributing to a lot of the Composer related issues, then moved on to start the Workflow Initiative.

Outside of "work" in this time I have contributed to many contrib modules, become the core maintainer for Statistics, Content Moderation, and Node modules, been a DrupalCon track chair three times, attended 9 DrupalCons, written Drupal articles for Net magazine and appeared on some Drupal podcasts. Outside of Drupal I have moved house twice, got married, and had two kids.

It's been a fun time, here's to the next 10 years!

timmillwood Wed, 10/01/2018 - 13:28 Tags drupal planet drupal-planet drupal Add new comment

Valuebound: My first impression of learning AngularJS

10. Januar 2018 - 15:07

Before we delve into the ocean of understanding and learning curves of AngularJS, let me share my insights and experience of working on web development. Later, I will tell you why experiences are worth sharing.

For the past four-and-a-half years, I have been working in an IT industry. Started my career as a Drupal developer, working on web building, site building, extending features, development as well as designing. During this journey, I came across many technologies which I was expected to learn from scratch to bind/ integrate one to another. 

Cutting a long story to short! So why did I started learning AngularJS? What is the scope of AngularJS? And why I am sharing my experiences with…

Glassdimly tech Blog: Overriding Drupal 8's .eslintrc.json File in Your Theme With Extends

10. Januar 2018 - 0:44

I had to do a little RTFMing today, and so I thought I'd post about it.

First of all, this is how you set up PhpStorm to use ES6 eslint settings. You may find it useful

Is the linter getting in your way? The first way to override an eslint setting is inline, disabling it on a one-off basis.

Glassdimly tech Blog: Drupal ES6 Linting in PhpStorm. Or, PhpStorm Drupal Error: Cannot find module 'eslint-config-airbnb'

9. Januar 2018 - 22:40

You may not know this, but support for ES6 was added in Drupal 8.4. It wasn't in the release notes, but I was delighted to learn of it.

You have probably landed here because you have gotten Error: Cannot find module 'eslint-config-airbnb'.

DrupalEasy: Mastering Pantheon Workflows (especially these 5 elements) is Awesome

9. Januar 2018 - 22:28

The following is a guest blog post by Brian Coffelt.

Train to Reign

I’m surprised often by the slow adoption rate of quality development workflows. Time probably plays a big part. One thing I have experienced though, is that in order to get the full value of tools, especially software, you really need to spend the time learning how to use them properly.  

Since I changed my career to become a Drupal developer, I haven’t had a day of regret, nor a day when I did not realize that the key to success is learning more: More about the software, more about techniques, and more about the tools that make Drupal development better. It all feeds into what I learned early on in DrupalEasy’s Career training program, and that I still feel are the best parts of this amazing Drupal-based vocation: to create quality work and become part of the Community.

So when I had the chance to take DrupalEasy’s Mastering Pantheon Workflows course, I jumped at it.  I have been relying on (and loving!) Pantheon’s website management platform since my early career training, and am a huge fan of the great workflow and development tools it offers.  The Workflows class, which is several afternoons a week for six weeks, was time truly well spent. It taught me to really leverage Pantheon’s advantages, and has made me a better developer.

Top 5 Takeaways

The quality of the curriculum and instruction of this course are second to none.  I mean it. DrupalEasy’s insight on what is important provides tremendous value to the time spent in the class and honing your skills. As any professional web developer knows, a great development workflow is worth its weight in gold. This class helped me learn a Docker-based local development workflow that has been directly applied to my everyday routine as well as that of my team.  In addition, learning how Composer manages dependencies was an eye opener for me. It allows my projects to be very lean, efficient, and modular. There are plenty more topics I can point to, but the top 5 area’s we covered that make my day-to-day better and easier are:

  1. Composer integration and dependency management
  2. Drupal 8 configuration management (exporting & importing)
  3. Docksal/Lando local environment structure & setup
  4. Higher level Terminus commands
  5. Development workflows between Pantheon environments and local

The instruction, either direct or via additional screencasts, was always thorough, well planned, and thoughtful. The instructor, Mike Anello (@ultimike), always allows time for questions and troubleshooting. Integrating a class Slack channel was valuable for questions and troubleshooting between classes as well as resource sharing (links, documents, etc.). I still keep in contact with my classmates as often as I can via Slack, email or Drupal events.

Worth the time

It may seem like a few afternoons a week for six weeks will chew up your schedule, but in fact, the opposite is the case. The skills acquired from this class can immediately boost your production, proficiency, and overall value, all of which are well worth the financial and time commitment.

I am definitely a better Drupal developer after having taken the Workflows course. The knowledge, experience, and overall comfort level I achieved has given me valuable skills that I use and share with others every day. The class always stresses the pursuit of best practices to minimize development time and maximize results. I recommend this course to Drupal developers looking to streamline their Pantheon development workflow. It’s certainly well worth the investment.

DrupalEasy’s next Mastering Professional Drupal Development Workflows with Pantheon course starts in February.  Contact DrupalEasy for more information.

Zhilevan Blog: How to write custom Twig filter in Drupal 8

9. Januar 2018 - 22:24
Twig is one of the  good template engines which is provided by SensioLabs, It’s syntax originates from Jinja and Django template, it’s Secure, Flexible and Fast :  Twig is a modern template engine for PHP • Fast: Twig compiles templates down to plain optimized PHP code. The overhead compared to regular PHP code was reduced to the very minimum.

Acro Media: Drupal Commerce 2: How to Add Storewide Discounts

9. Januar 2018 - 20:33

Drupal Commerce 2 comes with an easy to use Promotions sub-module built right in to its core. No add-on modules are needed anymore. The sub-module lets you add a variety of promotions to your eCommerce website, such as discounts off of an entire order, discounts based on the amount spent, product and category specific discounts, and more. The options are extremely versitile, usage statistics are available and coupon codes can easily be added to any promotion that has been created.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to quickly show you how to add a 20% storewide discount through the Promotion sub-module UI. 

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce. The current state of the Promotions sub-module is even more robust than what you see here, and many excellent improvements have been (and continue to be) made.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuratoin and theming.

More from Acro Media Drupal modules in this demo

Matt Glaman: My first day with React.js

9. Januar 2018 - 17:00
My first day with React.js mglaman Tue, 01/09/2018 - 09:00

On New Years Day I sat down over ReactJS and decided to see what all the commotion was about. I primarily work on the backend and have dabbled lightly with AngularJS. Generally, my JavaScript work just falls to basic DOM manipulation using vanilla JS or jQuery. Nothing fancy, no components. ReactJS is fun.

Zivtech: Why We Abandoned SASS in Our Drupal Theme

9. Januar 2018 - 16:25
Why we abandoned SASS and switched to PostCSS in our Drupal theme

A few months ago at Zivtech, our team started to look at best ways to improve the performance of our theme and take full advantage of controlling our markup with twig. We had ported our D7 theme for Drupal 8 and added a lot of great functionalities, such as Pattern Lab, CSS regression tests, etc. We wrote our own utility classes, Mixins and SASS functions, integrated flexboxgrid, and used Gutenberg as a responsive typography system. While we had all that we needed, we still ended up with too much convolution in our process and bloated CSS bundles at the end of our projects.

While SASS has helped us tremendously and allowed fast paced development in the past few years, we lost track of our CSS output. It’s a common complaint about preprocessors, and if we take a closer look at the important CSS conventions we need to watch for (DRY, reusable, less specific, no deep nesting, etc.), I can see how we slowly drifted away from a rigorous implementation. There are several reasons for it, SASS not necessarily being the culprit. It is a very versatile tool, and as such, the responsibility falls on its user. The real question is how to implement a proper workflow that we can enforce as a team in order to:

  • Deliver a consistent product
  • Improve performance and quality
  • Facilitate development among developers

The answer may be…write less CSS! Not LESS, less. Leverage TWIG to write or generate dynamic classes based on a solid set of utility classes. The concept is not new, but front-end Drupal developers have been burned by the lack of control of the markup for a long time. We don’t have excuses now, so let’s change our ways and enter the postmodern era.

Read more

Agiledrop.com Blog: AGILEDROP: 2017 in review

9. Januar 2018 - 12:50
Happy new year! Here at AGILEDROP, we will remember 2017 as the year when we became more focused and systemised. We worked hard, learned new things and had fun, lots of fun. Along with the growth in personnel and revenue, I can say it was a good year.     New business model, new processes At the end of 2016, we changed our business model and moved away from being a full-service agency to become trusted partners with digital agencies in building Drupal websites. With great foundations from 2016, we started tweaking processes and documenting them. To become more productive we also… READ MORE

Droptica: Droptica: Summary of the year 2017 in Droptica

9. Januar 2018 - 12:42
Another year is over, and we are glad to acknowledge that we are very proud of what happened during this period! In short, 2017 was the best year in the company’s five-year history. That is why we decided to share a brief summary of the year with you. See what we achieved over the last 12 months and what we have in store for 2018.    Reasons to be proud

Amazee Labs: Extending GraphQL: Part 3 - Mutations

9. Januar 2018 - 12:20
Extending GraphQL: Part 3 - Mutations

The graphql_core module bundled with the graphql module automatically exposes types and fields to traverse Drupal’s entity system. However, since beta 1 it does not do the same for mutations anymore. The fact that it is not possible to write or update data using GraphQL caused much confusion. I want to shed light on this topic and explain the way mutations are intended to work.

Philipp Melab Tue, 01/09/2018 - 11:20

Before releasing the first beta version of the GraphQL module for Drupal, we removed a feature that automatically added input types and mutation fields for all content entities in the GraphQL schema. This may seem to be counter-intuitive, but there were ample reasons.

Why automatic mutations were removed

While GraphQL allows the client to freely shape query and response, mutations (create, update or delete operations) are by design atomic. A mutation is a root level field that is supposed to accept all necessary information as arguments and return a queryable data object, representing the state after the operation. Since GraphQL is strictly typed, this means that there is one mutation field and one distinct input type for every entity bundle. Also, because Drupal entities tend to have a lot of fields and properties, this resulted in very intricate and hard to use mutations, increasing the schema size, even though  90% of them were never used. 

On top of that, some entity structures added additional complexities: For example, just trying to create an article with a title and a body value while the comment module is enabled results in a constraint violation, as the comment field requires an empty list of comments at the least. 

These circumstances led to a technically correct solution that unfortunately burdened the client with too much knowledge about Drupal internals and was therefore not usable in practice. It became apparent that this had to break and change in the future. Now, because we removed it, the rest of the GraphQL API can become stable. The code is still available on Github for reference and backwards compatibility, but there are no plans to maintain this further.

How to use mutations

So there is no way to use mutations out of the box. You have to write code to add a mutation, but that doesn’t mean it’s complicated. Let’s walk through a simple example. All code is available in the examples repository.

First, you have to add an input type that defines the shape of the data you want your entity mutation to accept:

<?php namespace Drupal\graphql_examples\Plugin\GraphQL\InputTypes; use Drupal\graphql\Plugin\GraphQL\InputTypes\InputTypePluginBase; /** * The input type for article mutations. * * @GraphQLInputType( * id = "article_input", * name = "ArticleInput", * fields = { * "title" = "String", * "body" = { * "type" = "String", * "nullable" = "TRUE" * } * } * ) */ class ArticleInput extends InputTypePluginBase { }

 

This plugin defines a new input type that consists of a “title” and a “body” field.

The first mutation plugin is the “create” operation. It extends the CreateEntityBase class and implements only one method, which will map the properties of our input type (above) to the target entity type and bundle, as defined in the annotation.

<?php namespace Drupal\graphql_examples\Plugin\GraphQL\Mutations; use Drupal\graphql\GraphQL\Type\InputObjectType; use Drupal\graphql_core\Plugin\GraphQL\Mutations\Entity\CreateEntityBase; use Youshido\GraphQL\Execution\ResolveInfo; /** * Simple mutation for creating a new article node. * * @GraphQLMutation( * id = "create_article", * entity_type = "node", * entity_bundle = "article", * secure = true, * name = "createArticle", * type = "EntityCrudOutput", * arguments = { * "input" = "ArticleInput" * } * ) */ class CreateArticle extends CreateEntityBase { /** * {@inheritdoc} */ protected function extractEntityInput(array $inputArgs, InputObjectType $inputType, ResolveInfo $info) { return [ 'title' => $inputArgs['title'], 'body' => $inputArgs['body'], ]; } }

 

The base class handles the rest. Now you already can issue a mutation using the GraphQL Explorer:

The mutation will return an object of type EntityCrudOutput that already contains any errors or constraint violations, as well as - in case the operation was successful - the newly created entity.

If you try to create an article with an empty title, typed data constraints will kick in, and the mutation will fail accordingly:

The update mutation looks almost the same. It just requires an additional argument id that contains the id of the entity to update and extends a different base class.

<?php namespace Drupal\graphql_examples\Plugin\GraphQL\Mutations; use Drupal\graphql\GraphQL\Type\InputObjectType; use Drupal\graphql_core\Plugin\GraphQL\Mutations\Entity\UpdateEntityBase; use Youshido\GraphQL\Execution\ResolveInfo; /** * Simple mutation for updating an existing article node. * * @GraphQLMutation( * id = "update_article", * entity_type = "node", * entity_bundle = "article", * secure = true, * name = "updateArticle", * type = "EntityCrudOutput", * arguments = { * "id" = "String", * "input" = "ArticleInput" * } * ) */ class UpdateArticle extends UpdateEntityBase { /** * {@inheritdoc} */ protected function extractEntityInput(array $inputArgs, InputObjectType $inputType, ResolveInfo $info) { return array_filter([ 'title' => $inputArgs['title'], 'body' => $inputArgs['body'], ]); } }

 

Now you should be able to alter any articles:

And the delete mutation is even simpler.

<?php namespace Drupal\graphql_examples\Plugin\GraphQL\Mutations; use Drupal\graphql_core\Plugin\GraphQL\Mutations\Entity\DeleteEntityBase; /** * Simple mutation for deleting an article node. * * @GraphQLMutation( * id = "delete_article", * entity_type = "node", * entity_bundle = "article", * secure = true, * name = "deleteArticle", * type = "EntityCrudOutput", * arguments = { * "id" = "String" * } * ) */ class DeleteArticle extends DeleteEntityBase { }

 

This will delete the entity, but it’s still available in the response object, for rendering notifications or for subsequent queries.

That’s a wrap. With some trivial code, we can implement a full CRUD interface for an entity type. If you need multiple entity types, you could use derivers and services to make it more DRY.

Plans

This way we can create entity mutations that precisely fit the needs of our current project. It requires a little boilerplate code and might not be the most convenient thing to do, but it’s not terrible and works for now.

That doesn’t mean we are not planning to improve. Currently, the rules module is our best hope for providing zero-code, site-building driven mutations. The combination would be tremendously powerful.

If you want out-of-the-box mutations in GraphQL, go and help with #d8rules!

Palantir: The Commonwealth of Massachusetts

9. Januar 2018 - 1:45
The Commonwealth of Massachusetts brandt Mon, 01/08/2018 - 17:45 Helping Massachusetts Improve the State of the Web

Helping improve the digital experience for constituents.

Highlights
  • Migration to flexible, open-source platform

  • Restructure of content for easy search

  • User-centric design based on common tasks

We want to make your project a success.

Let's Chat. Our Client

Home to more than 6.8 million people, the Commonwealth of Massachusetts is the most populous state in New England. Like everywhere in the U.S., those 6.8 million people rely on their state government to provide them with services and support, which includes providing the information they need to perform vital tasks required by law. Whether those tasks include renewing a driver’s license, applying for food assistance, or registering a new business, constituents need to be able to find relevant information efficiently. Mass.gov is the flagship website for the Commonwealth, and its main goal is to provide online support to its constituents.

The Challenge

The challenge facing the Commonwealth was two-fold, one part a challenge for the constituents of Massachusetts, and one part a technology problem for the government dedicated to serving those people. The Commonwealth’s website reflected its internal organizational structure instead of organizing content in a way that made sense to its users. The old site also was on an antiquated, proprietary content management system that had not been able to address changing needs over time and was about to be decommissioned.

The Solution

Complex problems are best solved by having smart and talented people think and work passionately. It was a privilege for Palantir to be part of a team that included designers and strategists from another vendor, along with data scientists, content authors, and developers from the Commonwealth’s Executive Office of Technology Services and Security (EOTSS). This multi-party engagement saw many opinions and thoughts brought to light and explored, as the various groups coalesced into a single, functional team.

The team knew all of Mass.gov’s information needed to be pulled together into a constituent-focused model, so the team took a data-driven approach that began with using proxy indicators (search being one of them) to determine what top tasks users were trying to complete online. This allowed Palantir to build a framework to serve content related to those tasks. By figuring out what people were trying to accomplish on the site (such as renewing a driver’s licence or reserving a campsite in a state park), the Mass.gov team would then be able to write helpful content about those items.

In a nutshell, the main goals were to:

  • Identify high-value content
  • Write related high-value content
  • Structure that content in a way that was intuitive to constituents

The minimum viable product was a proof of concept focused on 10 of the most common tasks performed on Mass.gov. A scalable framework was then built for any pages after those initial 10. By taking this approach, Palantir was able to help prove value in the tools chosen for this project quickly, which helped EOTSS validate that the tasks highlighted were useful to the constituents. It also validated that the process of entering content was scalable for Mass.gov’s editorial team.

After the first 10 pages, the team worked with the rest of Mass.gov’s content based on the concept that 20% of the site’s content addresses 80% of constituents needs. The team identified the top 20% of content by traffic (and deleted a large amount of unnecessary or redundant content), and then started optimizing the new Drupal 8 platform. Placing focus on constituents first throughout the entire build helped frame conversations and decisions for Palantir’s development team. From the way layouts were considered to feedback mechanisms, focusing outcomes on “what is best for the constituents” gave everyone on the team a common place from which to start any conversation.

Flexibility in Drupal 8

Undertaking a large overhaul of a public service is no easy feat. From 2003 to 2012 alone, only 6.4% of federal IT projects with $10m in labor costs were successful; a whopping 93.7% failed.

In choosing Drupal as the framework for the new Mass.gov site, the Commonwealth was able to execute its vision with an extremely versatile tool. Unlike its previous CMS, building on Drupal meant the ability to pivot easily and adapt to changing needs. As more feedback was received from stakeholders and constituents during the first year of the engagement, the needs of the project changed a lot. Drupal also provided a stable platform of established tools, eliminating the need to build important features from scratch, thus helping to minimize costs in quickly getting to a working version of the site.

“We’ve redesigned Mass.gov for you, the people of the Commonwealth. We have one goal: to make it easy for you to find what you need.” — Mass.gov homepage

The Results

For Mass.gov, the big win is for the constituents of Massachusetts. Bay Staters now have a website designed specifically to help them accomplish their goals. The new Mass.gov site is an accessible, mobile-friendly, platform for the future that cuts down on the time users spend wandering through the site, trying to find what they need.

We want to make your project a success.

Let's Chat. Drupal 8 mass.gov

Mediacurrent: UX Design Evolution: Top UI/UX Design Trends for 2018

8. Januar 2018 - 23:56

As we begin a fresh, brand-spanking-new year, several UX design practices and technologies stand out as the most exciting and relevant. While they are not all necessarily bleeding edge or super trendy, these considerations are becoming more and more vital to our clients and will be at the forefront in the year to come and beyond. Here’s an overview of what we’re watching, how the UX landscape is shifting, its impact on marketing and consumer experience, and what it means to you!

Elevated Third: Drupal’s Release Cycle: Understanding What’s Next

8. Januar 2018 - 22:13
Drupal’s Release Cycle: Understanding What’s Next Drupal’s Release Cycle: Understanding What’s Next Nick Switzer Mon, 01/08/2018 - 13:13

We’re officially two years past the release of Drupal 8.0.0, arguably the most important release of Drupal to date. Drupal 8 is loaded with game-changing features and has more now than the day it was released. All this is thanks to what may be one of the least talked about, most impressive features: a completely overhauled release cycle.

Whether you realize it or not, if you use Drupal (7 or 8) you are affected by these changes and should have a clear understanding of what’s in store for the Drupal project while planning future projects and budgets. To shed some light on what the future holds, I’ll walk through how releases have worked in the past, how they work now and what we have to look forward to. As an added bonus, we’ll briefly discuss the pros and cons of migrating from Drupal 7 to 8, so stick around until the end!

The Past: How releases worked through Drupal 7

Until Drupal 8 was released on November 19, 2015, Drupal was known for a notoriously slow release cycle that focused on security updates and bug fixes in supported releases. These releases are numbered as incrementing versions of the major release - for example, 7.1, 7.2, 7.3, all the way up through the current major release: 7.56. Active development and improvement were typically focused much more on the next major release of Drupal. This allowed core developers to direct a lot of development time towards large changes in upcoming releases of Drupal, which could leave current versions of Drupal core feeling relatively stagnant. The D7 release cycle relied on the contrib ecosystem to fill gaps in functionality that may have been better suited to Drupal core.

The Present: How does Drupal 8 release updates and how does this mesh with the Drupal 7 release cycle?

With Drupal 8, the dream of frequent feature updates in core has become a reality. With the release of Drupal 8, Drupal core has officially moved to a number system called Semantic Versioning. The basic idea of Semantic Versioning, sometimes called “semver,” is to regulate when and what features are released as part of a software project. Rather than using versions with just two numbers, Drupal 8 uses three, for example, the current release of Drupal 8 is 8.4.3 (find a translated version of the release notes here).

With Semantic Versioning, each number has a distinct purpose: the first number is the major version (8), the second number is a minor release (.4) and the third number is a patch release. Each type of release has specific requirements that I won’t get into here, but you can visit the release cycle page of drupal.org for more detailed information. On top of the requirements for each type of release, there are specific dates and times they will--or can--occur. A major release occurs much less frequently than the other two. In fact, major releases are infrequent enough that there is not a set schedule for future major release of Drupal. Minor releases are scheduled every six months, so we can expect two minor releases in the upcoming year (2018). 8.5.0 will be released on 3/7/2018 and 8.6.0 will be released on 9/5/2018. Finally, patch releases have a month release window that can be used to address bugs in the current minor release.

If you skimmed that last paragraph, slow down and pay attention here. The most important thing to know about minor releases in Drupal 8 is that only the most current, stable minor release will receive security updates. Occasionally, there may be an exception if a minor release is really new, but I wouldn’t count on that happening often, if at all. To further clarify, Drupal 8.4 is the current minor release, so if you’re running 8.0, 8.1, 8.2 or 8.3, you will not receive security updates and are at risk.

Now that we’re all clear on the Drupal 8 release cycle, it’s also important to keep in mind that this does not change anything about the Drupal 7 release cycle. Drupal 7 is still supported by the community but is essentially in maintenance mode. At this point, we strongly advise against building any new sites on Drupal 7 unless you have a very compelling reason to do so - we haven’t had a reason to build a new site on Drupal 7 in over 18 months.  

The Future: What do we have to look forward to?

The future looks very bright for the Drupal project. Drupal 8 is a truly powerful platform that is capable of supporting a huge variety of enterprise projects and ambitious digital experiences. The release cycle adopted by Drupal 8 helps push the project forward in a lot of major ways because it makes rapid iteration much more possible.

The most exciting part of this whole thing is this: Drupal 9 will not be a completely breaking update in the same way every major release of Drupal has been. What this means for Drupal 8 site owners is that Drupal 9 will not require a ground-up rebuild!

That all sounds good, but when should I upgrade?

This is a tough question to answer because the reality of a site rebuild/upgrade can mean such drastically different things to different people. The Drupal community supports two current major releases of Drupal, meaning that right now, Drupal 7 and 8 are both supported and actively receiving security updates. No release date has been announced for Drupal 9, but as soon as Drupal 9 is released, Drupal 7 will no longer receive security updates and will become a potential vulnerability issue for anyone still using it.

At the very least, it is absolutely the right time to start planning and budgeting for a Drupal 8 build. You can count on a much less complicated upgrade process in the future. Moreover, Drupal 8, along with the ecosystem of contributed modules, is stable, powerful and a vital tool for anyone looking for an innovative, ambitious web presence.

For more on Drupal 8, download our whitepaper.

Download asset

OhTheHugeManatee: I'm Joining Microsoft, Because They're Doing Open Source Right

8. Januar 2018 - 21:32

I’m excited to announce that I’ve signed with Microsoft as a Principal Software Engineering Manager. I’m joining Microsoft because they are doing enterprise Open Source the Right Way, and I want to be a part of it. This is a sentence that I never believed I would write or say, so I want to explain.

First I have to acknowledge the history. I co-founded my first tech company just as the Halloween documents were leaked. That’s where the world learned that Microsoft considered Open Source (and Linux in particular) a threat, and was intentionally spreading FUD as a strategic counter. It was also the origin of their famous Embrace, Extend, and Extinguish strategy. The Microsoft approach to Open Source only got more aggressive from there, funneling money to SCO’s lawsuits against Linux and its users, calling OSS licensing a “cancer”, and accusing Linux of violating MS intellectual property.

I don’t need to get exhaustive about this to make my point: for the first decade of my career (or more), Microsoft was rightly perceived as a villain in the OSS world. They did real damage and disservice to the open source movement, and ultimately to their own customers. Five years ago I wouldn’t have even entertained the thought of working for “the evil empire.”

Yes, Microsoft has made nice movements towards open source since the new CEO (Satya Nadella) took over in 2014. They open sourced .NET and Visual Studio, they released Typescript, they joined the Linux Foundation and went platinum with the Open Source Initiative, but come on. I’m an open source warrior, an evangelist, and developer. I could see through the bullshit. Even when Microsoft announced the Linux subsystem on Windows, I was certain that this was just another round of Embrace, Extend, Extinguish.

Then I met Josh Holmes at the Dutch PHP Conference.

First of all, I was shocked to meet a Microsoft representative at an open source conference. He didn’t even have bodyguards. I remember my first question for him was “What are you doing here?”.

Josh told me a story about visiting startup conferences in Silicon Valley on behalf of Microsoft in 2007, and reporting back to Ballmer’s office:

“The good news is, no one is making jokes about Microsoft anymore. The bad news is, they aren’t even making jokes about Microsoft anymore.”

For Josh, this was a big “aha” moment. The booming tech startup space was focused on Open Source, so if Microsoft wanted to survive there, they had to come to the table.

That revelation led to the creation of the Microsoft Partner Catalyst Team. Here’s Josh’s explanation of the team and its job, from an interview at the time I met him:

“We work with a lot of startups, at the very top edge of the enterprise mix. We look at their toughest problems, and we go solve those problems with open source. We’ve got 70 engineers and architects, and we go work with the startups hand in hand. We’ll sit down for a little pair programming with them, sometimes it will be a large enough problem that will take it off on our own and we’ll work on it for a while, and we’ll come back and give them the code. Everything that we do ends up in Github under typically an MIT or Apache license if it’s original work that we’re doing on our own, or a lot of times we’re actually working within other open source projects.”

Meeting with Josh was a turning point for my understanding of Microsoft. This wasn’t just something that I could begrudgingly call “OK for open source”. This wasn’t just lip service. This was a whole department of people that were doing exactly what I believe in. Not only did I like the sound of this; I found that I actually wanted to work with this group.

Still, when I considered interviewing with Microsoft, I knew that my first question had to be about “Embrace, Extend, and Extinguish”. Josh is a nice guy, and very smart, but I wasn’t going to let the wool be pulled over my eyes.

Over the next months, I would speak with five different people doing exactly this kind of work at Microsoft. I I did my research, I plumbed all my back-channel resources for dirt. And everything I came back with said I was wrong.

Microsoft really is undergoing a fundamental shift towards Open Source.

CEO Sadya Nadella is frank that closed-source licensing as a profit model is a dead-end. Since 2014, Microsoft has been transitioning their core business from licensed software to platform services. After all, why sell a license once, when you can rent it out monthly? So they move all the licensed products they can online, and rent, instead of selling them. Then they rent out the infrastructure itself, too – hence Azure. Suddenly flexibility is at a premium. As one CTO put it, for Azure to be Windows-only would be a liability.

This shift is old news for most of the world. As much as the Hacker News crowd still bitches about it as FUD, this strategic direction has been in and out of the financial pages for years now. Microsoft has pivoted to platform services. Look at their profits by product over the last 8 years:

The trend is obvious: server and platform services are the place to invest. Office only remains at the top of the heap because it transitioned to SaaS. Even Windows license profits are declining. This means focusing on interoperability. Make sure everything can run on your platform, because anything else is to handicap the source of your biggest short- and medium-term profit. In fact, remaining adversarial to Open Source would kill the golden goose. Microsoft has to change its values in order to make this shift.

So much for financial and strategic direction; but this is a hundred-thousand-person company. That ship doesn’t turn on a dime, no matter what the press releases tell you. So my second interview question became “How is the transition going?” This sort of question makes people uncomfortable: the answer is either transparently unrealistic, or critical of your environment and colleagues. Over and over again, I heard the right answer: It’s freakin’ hard.

MS has more than 40 years of proprietary development experience and institutional momentum. All of their culture and systems – from hiring, to code reviews, to legal authorizations – have been organized around that model. That’s very hard to change! I heard horror stories about the beginning of the transition, having to pass every line of contribution past the Legal department. I heard about managers feeling lost, or losing a sense of authority over their own team. I heard about development teams struggling to understand that their place in an OSS project was on par with some Rando Calrissian contributor from Kansas. And I heard about how the company was helping people with the transition, changing systems and structures to make this cultural shift happen.

The stories I heard were important evidence, which contradicted the old narrative I had in my head. Embrace, extend, extinguish does not involve leadership challenges, or breaking down of hierarchies. It does not involve personal struggle and departmental reorganization. The stories I heard evidenced an organization trying a real paradigm shift, for tens of thousands of people around the world. It is not perfect, and it is not finished, but I believe that the transition is real.

When you accept that Microsoft is trying to reorient its own culture to Open Source, suddenly all those “transparent” PR moves you dismissed get re-framed. They are accomplishments. It’s incredibly difficult to change the culture of one of the biggest companies in the world… but today, almost half of Azure users run Linux. Microsoft’s virtualization work made them the fifth largest contributor to the 3.x Linux kernel. Microsoft maintains the biggest project on Github (by contributor count). They maintain a BSD distribution and a Linux distribution. And a huge part of LXD (the container-based virtualization system for Linux) comes from Microsoft’s work with Canonical.

That’s impressive for any company. But Microsoft? It boggles the mind. This level of contribution is not lip-service. You don’t maintain a 15 thousand person community just for PR. Microsoft is contributing as much or more to open source than many other major players, who have had this in their culture from the start (Google, Facebook, Twitter, LinkedIn…). It’s an accomplishment, and it’s impressive!

In the group I’m entering, a strong commitment to Open Source is built into the project structure, the team responsibilities, and the budgeting practice. Every project has time specifically set aside for contribution; developers’ connections to their communities are respected and encouraged. After a decade of working with companies who try to engage with open source responsibly, I can say that this is the strongest institutional commitment to “giving back” that I have ever seen. It’s a stronger support for contribution than I’ve ever been able to offer in any of my roles, from sole proprietor to CTO.

This does mean a lot more work outside of the Drupal world, though. I will still attend Drupalcons. I will still give technical talks, participate, and help make great open source communities for Drupal and other OSS projects. If anything, I will do those things more. And I will do them wearing a Microsoft shirt.

Microsoft is making a genuine, and enormous, push to being open source community members and leaders. From everything I’ve seen, they are doing it extremely well. From the outside at least, this is what it looks like to do enterprise Open Source The Right Way.