drupal

SimplyTest.me From The Ground Up

admin — Wed, 22 Sep 2021 22:58:00 +0000

SimplyTest.me From The Ground Up

When I took over as the project lead for SimplyTest.me, the previous lead shared three primary things with me:

The system had a non-trivial amount of technical debt and was rising more with time
Significant changes were coming with Drupal 8, Composer, Drush, and more
His interest was elsewhere

As part of my proposal, I promised to do what I could to revitalize this. While this effort has taken years, we have hit another major milestone in our journey:

We launched a completely new version of SimplyTest.me. We rebuilt the system from the ground up in an effort to revitalize the project. It’s time to tell the story.

The Old System

Architecturally, the SimplyTest I inherited had three basic systems: the web server front-end, the worker server backend, and a proxying system that glued everything together. Everything was manually maintained and largely custom.

The servers were hand-built and required a ton of maintenance. All of the scripts to run the system were custom.
The worker backend was a glorified, monolithic LAMP stack that would provision and deprovision virtual hosts, databases, and hostnames on the fly.
Cleanup routines would fail commonly on system updates, disks would fill, logs wouldn’t rotate, and the maintenance burden was high.
Major upgrades to components or the operating system would have caused an indeterminate amount of breakage. If you tried to fix and subsequently broke any part of the system, this would impact all of the running instances.
And, there was no failover or load balancing.
The application was running on Drupal 7, which means it was almost three major versions behind.
Backups did not readily exist.

SimplyTest did not have an infrastructure that afforded easy development or encouraged contribution from others in a safe and straight-forward way (without basically using the fragile production systems). Making changes often broke things and the systems would go down routinely. It was not good.

People would complain. A lot. We tried to keep up. But, the service wasn’t stable, nor was it easy to keep up with the latest innovations our community was developing. People routinely let me know about it. They also would routinely blame SimplyTest for issues with their own projects by expecting me, the maintainer of the service, to debug their issues. I recall a vocal community member persistently accusing the system of being broken because “it works on their local system” only for us to find one of the dependent third-party assets had a broken link in their module’s library file (which they already had downloaded locally and they didn’t properly test it).

It was an incredible effort to just keep the lights on. And, it wasn’t sustainable. It was important that we created a new future.

Rebuilding SimplyTest

While a fresh approach was desperately needed, we have finally reached a point where SimplyTest.me has been rebuilt from the ground up. We spared no opportunity to modernize the project, which allowed us to shift our attention back to serving the community. The following sections highlight our accomplishments around revamping SimplyTest.

Goals

Revitalizing the project needed to be prioritized around what our users would get value from. As an example, lowering technical maintenance or eliminating technical debt affords more time to develop the features of SimplyTest.me or more quickly introduce changes tied to new community innovation (see: Gitlab workflows in drupal.org, updated PHP version support in Core, Composer/Drush improvements, and more). Time spent working on the system would not go toward keeping the lights on, but actual value built into the project our users would benefit from.

Increasing contribution and available contributors is a long-standing goal. Not only do I want SimplyTest to be used for lowering the technical barriers of contribution, it is the perfect platform for learning and contributing something meaningful back. We made conscious architectural decisions with an eye for contributor growth tied to technologies we felt people wanted to learn. And, revitalizing the systems happened with an eye toward a cleaner, modern architecture that would afford more straight-forward contributions without the overhead of legacy systems.

A better, more stable service offers more value. If our users get value and they continue to get value, I believe they will help sustain the project through donations or contributions. And, they can focus on the great things Drupal offers. Put differently, if people routinely experience challenges with the service or have trouble getting value from it, this lowers confidence and they are less likely to invest. SimplyTest must seek and be in a position to drive more contribution to remain viable. As such, we hope our work to build a new SimplyTest will hopefully position it to reach its fullest potential.

Another goal is to have SimplyTest be a showcase for the best that Drupal offers. It wouldn’t just be built for Drupal but with Drupal as well. If we found ways to make Drupal or it’s dependencies better through our efforts, we did so. This is how the ecosystem works and we wanted to be fully responsible for this.

Any modernization would be adding value, not losing it. We aimed to have at least 100% feature parity with the old version. I’m proud to say we achieved this goal.

Finally, we stuck to our core tenets. We remain committed to open source. The service would be and will forever be free to our users. And, our actions reflect our fundamental goal to lower the barrier of entry for those who want to use Drupal and learn about the wonderful community we’ve established.

Donations and Paid Labor

I don’t expect people to work for free. Some choose to volunteer and I’m really grateful for that. But, when I took over, I had no money to pay for anything. I established an Open Collective to help with this. I began accepting donations. Initially, this helped pay for expenses like SSL certificates and various attempts to make development infrastructure. But, I saved up money to help pay for sponsored contributions. I was proud to offer some people work when they were out of jobs. I hope to do a lot more of this in the future.

Most importantly, this allowed me to spend some funds toward the revitalization. The project started to get some much needed help and velocity toward our goal. I was able to pay people with specific skills to come in and do work faster and of higher quality.

A lot of this progress was made possible by donations of small and large from both individuals and organizations. It was really cool to also see Drupal Camps, who often leverage SimplyTest for contribution days, make donations with some of their funding. And, companies like Centarro, sponsored development of specific features (the one click demos).

PaaS Hosting

With a volunteer team and limited time/budget, you need to be very careful about what you maintain with a project like this. We learned the hard way how difficult it is to maintain your own infrastructure. In my mind, you can’t waste time reinventing the wheel. While it may seem to conflict with our open source roots, we chose a service and vendor that was closely aligned with our identity: Amazee Lagoon. We are grateful they sponsored the use of their service to help run our Simplytest Drupal 9 website. While their PaaS service is a paid offering, their product is open source. And, it had relevant features and a high degree of customizability we needed to be effective. Amazee also offered use of it’s CDN services, which help with both performance and security. Worrying less about a website affords time for us to build more value into the system. We’re fortunate to have access to this service to allow us to improve the service itself.

Drupal 9 Website

What a better way to showcase Drupal by using Drupal itself. We wanted to harness the best Drupal had to offer as part of our revitalization. We actually started our efforts with Drupal 8 when we began to create the new application, but we then upgraded to Drupal 9. We have leveraged many cutting edge features, like the Typed Data system and the web service capabilities, which help modern Drupal applications shine. We’ve been able to leverage core features and the underlying framework to create a set of services, data models, and API endpoints that pair perfectly with our React-based front-end.

SimplyTest has also innovated significantly around the Drupal community project metadata. Because our efforts were “experience first”, we ran into challenges implementing the ideal experience in support of semantic versioning, compatibility of major versions of core within projects, and more. Major props to Matt Glaman and Benji Fisher for helping research and innovate around these challenges.

Fresh Design

Comic Sans is a sign of the nineties, and the nineties want it’s website back. We’re happy to oblige. With a totally revamped system, we needed a modern design that best represented the technical innovations under the hood. Ana Laura Coto helped with this by producing designs for us, including a new logo! This will help our experience, allow our work to shine, and best represent how cool and modern the new system actually is.

Updated Theme

Iris Ibekwe set up our initial efforts when we implemented the Drupal 8 theme. It was responsive, leveraged modern grid systems, and established build tooling with Gulp, NPM, and more. This work helped get the ball rolling toward implementing our new designs.

A lot of time passed from when the original theme was set up and when we got the new backend fully built. Some newer tools came out that allowed us to upgrade some of the older tools and innovate further. Matt Glaman implemented Laravel Mix, which allowed for live refresh and replaced the theming framework with Tailwind CSS.

QED42 stepped up majorly to finish the job. Their team did a significant amount of theming work and QA. They applied some updated design revisions made by Ana Laura to address identified accessibility issues. As the backend was evolving, the theme was being completed in parallel by their team. The QED42 team got the job done and their team was a pleasure to partner with. Front-end work is one of my technical limits. I was grateful I had such great help with this area.

ReactJS Front-end

The interface for SimplyTest has a lot of conditional behavior. It’s highly interactive. This presents our users with an experience that simplifies much of the underlying Drupal complexities. Users enter a project, they pick a branch, they then only see relevant options to them based on what they want to test. Drupal has evolved a lot and putting the experience first for our users has meant a lot of work behind the scenes to abstract complexities. This work is never done, but our new ReactJS front-end is a major step forward.

Matt Glaman created the React front-end and the connecting backend APIs from Drupal. ReactJS is a great compliment for the web services sponsored by Drupal. The React app maintains state, which can help to address conditional needs and guide users through the experience we want to offer. This was a complex task and Matt’s leadership helped make something from nothing. I am just learning ReactJS and was struggling to make the kind of progress on this we needed. Matt’s expertise was critical to connect both systems and make this a huge success. I’m far more confident that others can contribute to this part of the system and use the React app as a reference for learning (I certainly will be).

Automated Testing

We were making sweeping changes throughout the last several months. When you add in development activities in parallel, it is much easier to break things. Thankfully, automated testing was implemented throughout our process.

As Matt was implementing the Drupal backend and the ReactJS front-end, automated testing continued to be developed at the same time. PHPUnit tests were helping with the Drupal endpoints. Cypress was used to test all of the front-end and interactivity. Having automated tests allow us to have a stable development workflow that ensures we’re less likely to break things when pushing changes.

Website Repository and Quickstart

SimplyTest is a Drupal profile maintained on drupal.org. But, our application runs like a conventional Drupal website managed by Composer. Having a repository with SimplyTest installed allows for more key outcomes. First, the repository maintains the Drupal website running SimplyTest.me in a conventional manner to other Drupal applications. This repository serves as the integration with our new PaaS hosting and it looks and feels just like a standard Drupal application (because, it is). Second, the repository is a quickstart for contributors to load the website locally with minimal work. Community members can readily contribute just like any other Drupal project. This helps save time for those who want to participate and don’t want to waste their time with all of the manual setup. We also maintain both DDEV and Lando support within this Quickstart, with some basic documentation we aim to continue to improve with time.

Violinist

Again, we don’t want to waste time with manual work if we don’t have to. Matt installed Violinist on our SimplyTest website repository, which scans Composer.json files on the main branch for Composer updates. If updates are found, Violinist creates a pull request for the update. This works for Drupal core, all of the contributed modules, and even the SimplyTest code on Drupal.org. Pull requests trigger our automated tests to get immediate feedback. And, it sounds wild, but I can basically update the site from my phone. This is immensely cool and something that comes in handy for rapidly applying security updates.

Modern CI/CD

Our new CI/CD workflow offers smaller, incremental changes we can test iteratively before deploying to production. Our workflow with Violinist, pull requests, Github Actions, and on-demand environments on Lagoon allow us to get testing feedback, deploy small changes frequently, test them before pushing to production, and deliver with high quality. We have moved from having a monolithic infrastructure that wasn’t change friendly to being able to rapidly test and deploy changes in an ephemeral, highly automated, and change-friendly infrastructure. It’s been awesome and it’s such a sharp contrast from where we were before.

Monitoring and Alerts

I leveraged the free version of Pingdom to put basic alerts on the website and worker backend when I took it over. I got alerted for outages, which were frequent before. All monitoring and alerting has been switched to the new PaaS website and leverage TugboatQA service notifications (and Linode as their vendor) that could impact our backend. I believe there are more opportunities to improve this in the future, but the basics are there.

Live Coding Streams

Not only did Matt Glaman help with development and architectural guidance, he had an idea to do live streaming sponsored by his company, Bluehorn Digital. I learned a lot from these streams and am confident many others have as well. Streams cover development, testing, issue queues, development tools, and more. It’s great having someone talk through the process the entire time to understand the details. The streams were great for smashing bugs, working on new features, diving into the architecture, and advocating and promoting SimplyTest itself. They continue to be something I look forward to and were an immense help to launching the new site.

Partners Program

Between Bluehorn Digital, QED42, TugboatQA, Centarro, and Lagoon, it is very clear SimplyTest would be in rough shape without these partners. SimplyTest would not even exist without Druid and Maloon who sponsored the legacy systems. It is equally important to say thanks and highlight their contributions to the project, so I established a partners program. For companies who continue to invest in SimplyTest, we will continue to recognize you and offer incentives as we are able. One incentive is the “first right of refusal” for sponsored SimplyTest work. Partners get first dibs when we choose to pay for enhancements or bug fixes. Please see my previous blog post on the topic to learn more about the kinds of partnerships we’re offering.

Social Media Presence and Talks

It is incredibly important to engage with the community. We sincerely want to know what you think, where we can do better, and how we can deliver the best service possible. Thanks to AmyJune Hineline, we have established a Twitter presence, we are active on our Drupal Slack channel, and we have given talks at several camps that have highlighted our plans and why we’re doing this. AmyJune routinely uses SimplyTest as part of new contributor workshops. Because of this, we see much more engagement. Users routinely file issues, send messages, offer ideas, and help us be better each day. We’ve seen donations from the community. It’s such a stark difference from when we had no presence when I took over the project. And, AmyJune has been a critical part of helping establish and build this community from basically nothing.

Contributors

There are too many people to thank that helped us get where we are today. And, this was a collection of things that led up to the big reveal of our brand new Simplytest.me application. None of it would have been remotely possible without several people and companies stepping up to help. I mentioned several people already in this post and there are countless more who cheered us on, offered advice, pitched in, made donations, and so much more. This effort is no longer “my” side project, it’s now “our” community project. Thank you, thank you, thank you.

Parting Thoughts

We have finally put SimplyTest back in a good place. This is worth celebrating. Our technology is best-in-class and is appealing for anyone to use or learn. We managed to drastically reduce the code and simplify the application, lowering the barrier of entry for SimplyTest itself. We reduced maintenance activities down to nearly zero for both the application and the underlying infrastructure to allow focus on value creation. We’ve built a community that has promises of growth. And, we have the tools in place to sustain it. In retrospect, all of these small steps have added up to something significant in the few years I’ve led the project. It truly was a team effort. I couldn’t be more excited to finally be at this point and share this with everyone. I am grateful for those who pitched in and even more happy to say, “we did it.”

This whole thing has taught me a lot. In a lot of respects, SimplyTest is both the best and the worst of open source. It’s not only a free service but all of the code is open sourced. It’s a great example of both companies and individuals pitching in toward a common cause. But, after having led these efforts, I have seen first hand how people can treat open source maintainers when they get behind a keyboard. Some users expect a lot but fewer are willing to pitch in and make it a success. Our system remains largely volunteer-led, donation funded, and services sponsored. We’ve been highly resourceful with what we have (which is very little in the grand scheme of things). At times people just seem ungrateful. On a personal level, I wish this was more harmonious. I’d love for more help (financially or through direct contribution). I’d love for more awareness for those who expect more than we can reasonably offer. Regardless, we try to put our users' needs at the forefront of the service. We welcome the challenge to serve everyone. And, we are in a much stronger position to serve people now but it took so much time and effort to get there.

Another lesson in open source is how hard it is to have a big impact without resources. Working alone requires investing a lot of time and effort outside of your day job. It’s a fast way to burn out. SimplyTest.me historically relied on volunteer labor, sponsored systems, and had no money. Druid and Maloon graciously paid for all of the web, worker, and proxy servers. But, without funds, we couldn’t pay to get help from subject matter experts when it was needed. We just had to roll up our sleeves, work hard, figure things out, and be really scrappy. We picked up the phone to call friends when it was urgently needed to keep things running. But, one can only do this so long. And, I became fully aware of why the previous maintainer decided to move on. A large portion of time was focused on incidents and “keeping the lights on” while wanting to build the future. Wholesale change was needed and it makes it even more rewarding to launch our brand new system.

One more side note… the largely volunteer Drupal community is an amazing example of what can be accomplished at scale. A small number of contributions by a lot of people can add up to something significant. And, yes, SimplyTest is a part of the community. But, SimplyTest certainly has not seen the vast contribution that the Drupal ecosystem benefits from. We will continue to aspire to reach and achieve the kind of scale the broader community benefits from.

The Future

We need to grow into this new project we just launched. We just shed a ton of technical debt and can finally breathe easier after a rough few years. We still have a lot to learn and improve upon, and we need to work out the bugs. It was a lot of change in a (relatively) small amount of time, but we feel confident in the decisions made and to put us in a position of success. It’s incredible what a small number of highly motivated and capable people can do with clear goals, clear strategies, and clear purpose.

In the coming weeks, I will be publishing a quarterly roadmap talking about key objectives we wish to hit moving forward. We will start with a pause in new features to fix bugs, stabilize, and identify improvements. We will then announce a prioritized set of features which will be informed by the feedback we get.

We thank all of you who supported the service through our transition and when the system did not live up to your expectations. We’re confident that the future is bright, and we look forward to having SimplyTest serve the needs of the community for a very long time to come.

admin Wed, 09/22/2021 - 18:58

Tags

SimplyTest.me Partners Program

admin — Sun, 18 Apr 2021 15:33:26 +0000

SimplyTest.me Partners Program

SimplyTest.me, like other large efforts in our community, requires many types of contributions to be effective. Effective today, I am announcing the creation of a new partners program. While this program will evolve with time, we wish to kick off the effort of recognizing both the individuals and companies that helped us get here and are helping us transform. All types of sponsors will be recognized through ongoing social media campaigns. This is especially important as we look to formalize a roadmap and need trusted partners to help us execute.

Financial Sponsors

Nearly three years ago, we established our Open Collective. We have since raised $8,045 in funds from individual community members, community groups, and businesses both in the form of one-time and recurring contributions. Several companies and groups, like Tugboat and MidCamp made significant one-time investments that helped us toward our new Drupal 9 launch. I’d like to formally recognize Centarro and The Drupal Association for their current and previous ongoing contributions. I never imagined we would be this successful with our sponsorship program and want to send an enormous “thank you” to all of you.

Today, I’m proud to announce that any individual, group, or business who joins SimplyTest.me at a sponsor level or higher ($100+/month, ongoing) will be featured on our website and recognized during our livestreams.

Development Partners

Volunteerism is the community spirit of SimplyTest.me. We have had some individuals and companies step up with in-kind work they pay for. This has made a major impact toward the support and future goals of the project. I want to specifically recognize Bluehorn Digital (Matt Glaman), QED42 (several members), AmyJune Hineline (Kanopi Studios), and previously Hook42 (who would let me spend some time on it during my time there).

Today, I am excited to announce our Development Partners program aimed at incentivizing ongoing contribution to the project. Development is tied to the development of Simplytest.me across the board. This is not exclusive to just software development. Companies or individuals that offer five hours a month of ongoing support toward approved project activities (development, live streams, documentation, marketing, etc) will be considered. Development Partners will also have the right of first refusal for sponsored work (a concept I learned from buying a few houses). This basically means I’m giving development partners first dibs on sponsored work for the project through the Open Collective (based on the amount of their in-kind sponsorship in the last thirty days).

Service Partners

When I took over the project, I was torn if I wanted to do this. There is conflict between our commitment to open source and use of services, some proprietary, offered by companies. In retrospect, partnering with specific, strategic service companies that have sponsored their services has allowed our project to be sustainable, scale faster, and focus on our application without maintaining the full stack. Plus, those we’ve partnered with are deeply committed to open source through both their words and actions. To that end, these decisions have been some of the best I’ve made to help drastically improve the service we offer.

I’m announcing our active service partnerships, currently Amazee/Lagoon and TugboatQA, will get their logo on our site and recognized through our livestreams.

Legacy Partners

Our project has evolved, and that sometimes means we no longer require the use of specific services. Both the technological landscape and community look drastically different than when the project was created. But we won’t forget those who helped us get here. In fact, we’re grateful they have supported the project as long as they have. We recognize our founding project lead, PatrickD, for creating the service. Companies like Maloon and Druid still continue to sponsor infrastructure of our current simplytest.me website and previously used worker backend. Linode sponsored all of the development infrastructure for Simplytest.me for almost two years. Most of these tools will no longer be required once our new site is launched, but our Legacy Partners are owed a huge amount of gratitude for their commitment to the project.

Legacy Partner criteria will be determined on an as-needed basis. Their logos will be shown indefinitely on our website and recognized during our livestreams.

Disclaimer

This is where we are starting our partnerships to try to tighten our definitions of those participating today and incentivize those who support our project. With time, I hope to evolve it further, especially if people have ideas on how we can offer better or additional incentives to our partners. I also need to have the sole discretion to add or remove partners, which will hopefully encourage people to think of creative ways they can help or allow me to remove a partner if something changes.

This partnership is gradually being rolled out, especially as we launch the new Simplytest.me. And, again, I want to thank those involved to date. I can’t imagine where Simplytest.me would be without all of these amazing individuals, groups, and companies helping out. Also, thank you to AmyJune who edited this blog.

admin Sun, 04/18/2021 - 11:33

Tags

Drupal, Identity, and the Road Ahead

admin — Wed, 14 Apr 2021 22:41:04 +0000

Drupal, Identity, and the Road Ahead

In the wake of the poor leadership demonstrated by the FSF, there was a sharp contrast displayed today at DrupalCon. Passion, interest, and innovation around open source software seems to be at an all-time high. One of the most prevailing open source projects, Drupal, just turned twenty years old. You can't help but recognize Dries and other long time community leaders for choosing open source before it became cool and helping to push the boundaries of what a large, open source community is capable of doing. Today's Driesnote was an inspiring message fitting for now and the road ahead.

While twenty years is a celebratory milestone, what about the next twenty? Will Drupal be around to see it? It's of no surprise that Drupal faces competition in a number of forms. WordPress continues to see strong adoption. Proprietary tools, both headless and conventional CMS tools, continue to pump investment to compete with Drupal's largely volunteer led community. But, to their surprise, Drupal persists and, arguably, is stronger than ever. For there to be more certainty, Drupal needs to evolve and more clearly define it's identity.

One may wonder why after twenty years that the identity of the project is in question. Well, simply put, this is because Drupal has evolved with time. In my opinion, it's solved key problems at the right time to remain relevant. While starting as one of the first database driven CMS systems, it moved into one of a no-code site building platform. In Drupal 6, 7, and 8, it then drove major new features and made major strides in it's developer framework. Drupal 9 continues more of an investment in decoupled API-based features and underlying dependency modernization. Today, Drupal needs to position itself through an identity and vision that helps sustain itself. Dries is taking the project back to its roots and for good reason.

When interviewing Drupal candidates during my agency time, I would ask every candidate how they solved problems when creating Drupal applications. The best candidates responded with the same message. You would leverage both out-of-the-box and contributed Drupal features to build as much as possible before diving into code. I used to call it the 80/20 rule. 80% would be site building and 20% would be tweaking what was configured to match customer-specific requirements. As the Drupal framework matured, the community invested more features into core and other features were made in the contributed space. Modules were created that solved more problems or even opened up new, easier to use APIs to simplify the development. Now, outside of the specific visual branding and theming work, users readily can create a Drupal application that is even closer to 100%. Drupal remains fully qualified to be customized and extended through code, should you need it. Today, we find Drupal not only offering a robust development framework but it also has readily configurable features can compete with anything. It's time to get back to what put Drupal on the map: recommit to the experience of low/no-code tools that help a non-technical persona.

Many Drupal community members came for this originally. Structured content could readily be modeled through CCK. Field types could readily be added through core-sponsored modules or extended with contrib options. Content displays could readily be created through View Modes or Views. Much of this possible without adding any code. This pathway helps non-coders get into code when they need more. Individuals readily understand the capabilities of the system and the potential problems solved before ever writing a line of code to customize it. Then, figuring out how to do this customization is a logical next step and one people can use specific experiences that extend their Drupal knowledge. These experiences and the corresponding code are often great things to contribute back. The community is fantastic and at the ready to help make these outcomes happen. This is the path many of us went down both using and contributing back to Drupal, one that inevitably grows the space of relevant first-hand problems we solve, and one that doesn't require a Comp Sci degree through it's organic growth.

Dries demonstrated bravery and was refreshingly honest during his keynote. It can be difficult to stand in front of a large audience and admit where the project you've spent twenty years creating is falling short. He was forthcoming that the current experience of Drupal was too technically minded and that we needed to shift the tide to one of an easier, more native experience those in other open source communities are used to. He presented a Project Catalog feature as one of the more straightforward ideas that could help enhance Drupal. It's a cool ideal. Non-technical users could avoid Composer and work around some of the Drupal-specific jargon that can be a barrier of entry. An investment in the Drupal Association will be made to help continue to modernize and build tooling that aide in the experience of contributors through Gitlab, bots, and more. In a previous DrupalCon, the experience of installing Drupal was a major focus, too. I fundamentally believe this shift in focus can help Drupal become significantly more accessible and appealing to a wider audience. I believe this can open doors for more people to see the value in Drupal, help the community grow, and allow more people to have professional opportunities with Drupal.

For those reasons, I left the keynote inspired and grateful for the chances I've had. Much like my motivation for simplytest.me, I want to open doors to see others have this same experience. I see the path forward now for Drupal itself and fundamentally believe Drupal is and will more readily be competing with Contentful, Wix, WordPress, SquareSpace, and all other enterprise, proprietary CMS systems at the same time. Drupal can and should be aggressive in positioning itself as the open source, low/no-code solution for all of the modern, backend digital systems. The features are there. The development extensibility and modern framework is there. The shift toward a site building, no-code focus will help Drupal shine. Let's dive in to help Drupal continue to be a leader for the next twenty years.

admin Wed, 04/14/2021 - 18:41

Tags

Site Building

SimplyTest.me Welcomes Matt Glaman

admin — Sat, 02 Jan 2021 19:28:08 +0000

SimplyTest.me Welcomes Matt Glaman

SimplyTest.me is a labor of love but it has been one of the most unique, satisfying contributions I've made to the community. Most of that labor has been dedicated toward maintaining the Drupal 7 version. Our maintenance was massively improved with the introduction of Tugboat.QA, but this year found major changes in the Drupal community with the launch of Drupal 9, the major changes to Composer workflows, and the Gitlab integration. All of these things are of high impact for Drupal and required major changes to SimplyTest. This has been especially hard to keep up with for me. Our latest incident showed the limitations of the current system, where SimplyTest.me was blocked from the Gitlab infrastructure due to updates in Drupal.org's patching workflow. Much of this pulled my attention away from our aspirations to launch a new version. Until very recently, that is.

On a whim, I had asked Matt Glaman if he could help. He had a little bit of time over the holiday season to pitch in and this rapidly changed the course of our new implementation. Matt stands out for his deep knowledge of React combined with his knowledge of Drupal itself. Several people have pitched in on the React frontend, but it was incomplete. The backend was also only partially completed, difficult to know what was left given it wasn't yet integrated, and was largely based on Drupal 7 code with only nominal improvement. Since we implemented Drupal 7 last year, Tugboat itself made some nice improvements that also were not implemented yet. In SimplyTest, we had the chance to simplify the architecture by more direct API calls and removal of the repository-based approach we used. React itself had an opportunity to invoke Tugboat APIs in a more straight forward way for logs, progress updates, and more. In short: we needed Matt.

Matt graciously agreed to help and at a community rate. We will be sponsoring his time through the Open Collective. Any contributions to SimplyTest's Open Collective will help us finish this effort up faster.

Matt is an expert. He knew every part of this stack. We needed someone to come in, sort things out, and get the basics of things in place to help move this effort forward. I was able to provide answers on what needed to happen, but I wanted Matt to have the full autonomy to implement it properly. This investment now delivers brand new long requested features, sets up future contribution in new ways, helps us make huge strides toward shutting down our Drupal 7 current system, and is overwhelmingly simple.

I want to thank Matt for making this possible. His contributions have brought a much needed jolt of energy into these new efforts. I can't wait to share this work with the community. Thanks for helping the cause, Matt!

admin Sat, 01/02/2021 - 14:28

Tags

Drupal CI/CD with TugboatQA and Github Actions

admin — Tue, 29 Dec 2020 23:54:38 +0000

Drupal CI/CD with TugboatQA and Github Actions

Vacation this year has been amazing. I've caught up on some of my long-standing to do list, like launching this new nerdstein site and digging into some of the newer technology I've wanted to explore. SimplyTest has some great new contribution I am excited about. I've spent a ton of time with the kids coloring, playing, and just enjoying these moments while they are young. It is shocking how quickly they have grown. I've cooked a lot and those close know how much I enjoy doing that. I've blogged more - finally - after a long hiatus and lack of motivation. I am currently enjoying an Eight & Sand Brewing - Loco Mo Sim DDH and listening to the Gravity album from Our Lady Peace. The kids are currently asleep. I wanted to share some things I've explored today.

Automation is important for consistency and for ease of use. It's one of the tenets of DevOps. Automation is the cornerstone of creating a great experience with SimplyTest.me. I've spent years creating continuous integration solutions for customers to help them be more effective. Yet, I never did that for my personal website... until now.

Building off of my new website launch, I wanted to keep the momentum going. Recall from my blog post yesterday, I set up the basics of TugboatQA to replace my development server with something more modern. I also set up a new Linode for my production server. I wanted to learn Github Actions for deployment automation, as I had never used it. I desired to have an end-to-end CI/CD pipeline built completely with GitOps. And, I wanted as much of this automated as possible.

I was pleasantly surprised with how smoothly things went. Maybe I shouldn't be, as I'm basically building a pipeline for a simple website. Let me share a bit more about this experience should you find it beneficial.

Pipeline

This pipeline basically happens in the following workflow:

I work locally and push changes to a branch to Github (Composer, custom code, config, etc)
I make a pull request for this change off of the branch
Pull requests are subsequently deployed into their own Tugboat environment (executes a fresh environment that pulls production databases and files with automated deployment)
I review the code for anomalies or missing things like config
Manual testing occurs on the Tugboat environment (note: I need to work on automated testing; I plan to implement the visual regression test of TugboatQA in the future)
The pull request is merged after it passes my thorough review ;)
A production deployment happens once the code is merged

For the sake of what I consider novel, I'm going to focus on two main areas of this pipeline: TugboatQA and Github Actions. I assume a production server exists, but I will describe what is needed to manage assets from production (the source of truth for content in Drupal). And, I assume people are good with the well-documented pull request workflow methods. Please reach out if any further details would be helpful.

Commentary: Drupal Assets

My production site is a basic LAMP stack with some specifics for Drupal, like Composer and Drush (site local, of course). Any true Drupal development workflow needs to readily be able to get databases and files from production as the source of truth. Files are relatively easy with the Stage File Proxy module in Drupal, which can replace local files with those served remotely. Drush Aliases are a great way to do the database backups. But, I wanted to avoid putting credentialed data that into a public repository (note: these features are often offered by Drupal PaaS providers and you should use it). I opted to generate a script that could be invoked upon deploy and used mysqldump to create a gzip'd SQL file on-demand. Easy peasy bash script-ezy (sorry, I'm watching too much Food Network during this pandemic hell).

TugboatQA

TugboatQA replaced my development environments with automated environments per change (pull request). TugboatQA natively has Github integration and the Tugboat repository settings allow for new environments to be provisioned upon pull request.

Tugboat's infrastructure-as-code capabilities resemble Docker Compose (I denote this as the services layer), but Tugboat has specific hooks that allow for automation scripts to run at specific events within the lifecycle of an environment. The offering is catered for building great environments in a variety of platforms. As such, the services layer is readily configurable, allowing it to have parity with the Linode server tied to a set of Docker-based images. I'll probably try this out for a NodeJS-based workflow in the future.

I was able to add in the basic Drupal deployment steps into these hooks for the desired automation. This can and should be specific for your project. Mine did the basics: Composer install, drush config import, drush update database, and drush cache clear.

Finally, TugboatQA generates a public and private key for every project. I was able to create a locked-down, Tugboat-specific user on my production server where I copied the TugboatQA public key into the authorized_keys for that user. This allowed me to explicitly control what Tugboat could and could not do within the server. This allowed me to only have Tugboat run a script on production that made a database backup and leveraged scp to retrieve the generated backup into the Tugboat environment.

Example

You can see how I've configured the TugboatQA behavior through its config.yml directive:

Github Actions

I wanted something to kick off a production deployment. Much like AWS Lambda, this type of capability only needs to execute a script which is in sharp contrast to a more persistent, permanent server like production. This deployment automation only needed to happen after I reviewed a change in Tugboat and after I merged a pull request. Github Actions had just what was needed to do this.

Secrets Capability

One of the "secret" sauces of Github Actions is the integration of their secrets feature. Think of this as a private, secure key value store. Instead of committing scripts with a bunch of private information (keys, server IPs, usernames, passwords, etc), you can store your secrets in the repository settings and pull them within committed, ever changing scripts. Very cool.

Events

I only need my production deployment to happen after a pull request is merged into master. This signifies that a change has been reviewed, tested on Tugboat, and it is not expected to break a bunch of stuff. Github does not explicitly have a pull request creation or merge event in Github Actions. However, on further thought, what I really care about is when I push code to master. Suppose I have a hotfix, like a security update in Drupal. Yes, I should push this through normal channels. But, time is of the essence. So, I may want the opportunity to commit code directly to master. Yes, this can break things but I can't rule out the possibility of needing to do this if I feel like it needs to be done (process for the sake of process is not effective). Pushing any code to master actually covers me for any deployment I care about - a hotfix or a pull request. I focused on this code push event for the basis of a production deployment, which was supported by Github Actions.

Automation

Much like Jenkins is commonly leveraged as a CI tool to automate remote deployments, I didn't want Github Actions to do much more than serve as a proxy to my production server. In a similar fashion to Tugboat, a Docker image can be leveraged in each step of a Github Action "used" to execute steps of your workflow within a specific runtime. I chose a simple "SSH Action" image that allowed me to run commands remotely with a clean abstraction to SSH into my production server. I was able to readily embed my secrets into this script thanks to this abstraction, which had parameters for the SSH credentials that I embedded the secrets into.

Like what I did with Tugboat, I added deployment commands for the basics of a Drupal deployment. I updated Composer and leveraged Drush to update the database schema, import the config, and clear the cache. One notable difference was pulling in the most up-to-date code from the master branch. If I had something more complex, this could have accounted for environment-specific differences with tools like Config Split.

Example

You can see how I've implemented the Github Actions configuration through it's provided interface in Github:

Conclusion

It is astonishing that people routinely accept the norm when there are better options available. How do you choose to invest your time? Personally speaking, I have better things to do than manually deploying code when I want to update my website and subsequently scrambling to fix things that break when my QE process was to blame. Imagine those that have to deal with this type of thing frequently and in their professional career. These "manual" approaches add up in terms of technical debt and required investment. As technologists, we need to be better and push to make the systems we build serve us too. Ultimately, it benefits those we're trying to serve by freeing us up to do better with the time and opportunity we have.

admin Tue, 12/29/2020 - 18:54

Tags

Finally! A website refresh

admin — Tue, 29 Dec 2020 03:43:46 +0000

Finally! A website refresh

Let me welcome you to the new nerdstein.net. I'd like to thank Ana Laura Coto for help with the design. I'd like also thank Jonathan Daggerhart for being there when I needed an assist. I am really happy to finally share this project with the world.

This has been a long time coming. Three years. Yes, you read that correctly. Three years. Why? I prioritized learning. And, I am slow and methodical. This website is a culmination of many things I learned over a three year span.

But, three years?!? Yep. I have a rewarding and challenging full time job at Acquia. I have a family with two young kids. This project was all done in my spare time and at my convenience. Most of my time and learning is invested in SimplyTest.me. But, this project gave me a high degree of freedom on my own timeline. I wanted to learn things well and understand things properly. I did it piece by piece. Drupal evolved a lot in three years, as well. There was a lot to learn. And, then 2020 happened (I'll hopefully blog more on that soon).

For the rest of this blog post, I'd like to reflect on these efforts and learning.

From Drupal 7 to Drupal 8 and then Drupal 9

Drupal evolved significantly from Drupal 7 to Drupal 9. My original goal was to launch this with Drupal 8. Then life happened. Then Drupal rolled more features and made it even easier and better to launch my site. I'll share some specifics below. Regardless, Drupal has established itself as a great tool for progressive enhancements.

One notable change on this journey is how the community adopted Composer. I recall the very basic support when Drupal 8 was launched. Major changes were made when I upgraded the site to Drupal 8.7, which totally revamped the Composer work. I did the same when Drupal 9 came out. The community made some significant progress, but I'd love to see this stabilize now. I made heavy use of Composer and it's DevOps capabilities to script some of the integrations with my design system. This area of work was not well documented, especially in moving between versions and resolving issues.

New server

I was long overdue for a tech refresh. I had the same VPS running my Drupal 7 site for over seven years. It served me well. I spun up a VPS for a few Drupal 8 sites I hosted for local non-profit orgs that couldn't afford it. My Drupal 8 development site ran there for several years. The non-profits moved on due to grant funding and poor technical support (hint: if you can't do something well, don't do it). And, that Drupal 8 server rapidly dated itself.

I was able to shut down both VPS servers and create a brand new Ubuntu 20.04 on Linode. Linode has been a sponsor of SimplyTest.me, helping offset the cost of it's development infrastructure. I'd hardly call the experience of Ubuntu 20.04 learning; it was a breeze setting up a Drupal 9 environment. These systems have come a long way even in seven years. Shutting down the VPS servers is bittersweet. I've removed some significant tech debt but those servers were rock solid. No regerts.

Design Systems and Drupal Integrations

The biggest emphasis of learning was the front-end work of the design system. I am still so far from an expert. But, I definitely understand it now. I started with Pattern Lab. I broke down Ana Laura's design into a series of atomic components. I developed them. I learned more about SCSS and building of front-end assets. I mocked up these patterns with JSON data objects and finally built out representative pages with the pattern.

Once the design system was done, I started on the Drupal integration. My goal was to pull as much as possible from the design system (no cheating!). Composer made it easy for me to keep the design system and theme separated. I leveraged the Components module and proceeded to site build and theme simultaneously. Some of this was challenging. It was a fight between properly structuring content, overriding Twig themes, leveraging the Components module to include pattern markup, and parsing Drupal-related data objects.

I blogged about this several times, both in terms of the concepts I used and the architecture I leveraged. Please feel free to read more about this if you are interested.

Twig. All the Twig.

Developing Twig was hands-down the most time consuming part of this project unquestionably. I spent countless hours digging through Drupal rendered objects, raw data, attributes of that data, and much more. I tweaked the display settings, created new view modes, did more tweaks, changed more Twig, and this went on endlessly. Data objects passed to Twig were massive and nearly impossible to debug without printing keys, refreshing, and traversing deeply nested objects. The syntax changed with every different entity and then even more with Views. Yes, Drupal is incredibly powerful and extensible. But, I continue to be surprised by the developer experience around Twig. I just wish this was simpler. I know the community has developed several utility modules. I need to dig into those more.

Media System: image links

I had aspirations of contributing a composite field type module back to Drupal core. Developing this module, which never got complete, was a huge rabbit hole. I thought it would be relatively straight forward to inherit the core-provided image and link field types into one new field type. This was significantly more complex, especially when dealing with cardinality, managing data storage/schemas, and dealing with field widgets that were built atomically. This approach was rapidly becoming complex and it didn't seem like it needed to be. Then, help was on the way...

Daggerhart shared with me the new Media entity delivered as part of the Media system in Drupal 8. I was able to create an Image Link media type that was composed of an image field and a link field. This was super easy. From this, I got all of the expected benefits: Views support, easy integration with other entities, and the perks of the new media features in Drupal. Lesson learned: spend some time figuring out what parts of Drupal can be used before diving into code.

Migration from Drupal 7

My website is quite simple. It's a basic blog. I wanted a simple way to migrate the content. Drupal offered that with it's native Drupal to Drupal migrate UI.

Set up was simple. I was able to set up a secondary database within settings.php for my Drupal 7 database. I archived to the files directory on Drupal 7, extracted them in a specific file path, and entered that path in the UI.

When I ran it, I got a nice confirmation page of potential issues with the Drupal 7 configuration, modules, and structure. I worked through it, ran the migration, and it basically worked. I had a few nodes that did not properly map their type. I cleaned this up through the database by manually editing the node type in the node and node revisions tables, followed up with a cache clear. I also had a few nodes that did not display the body field content. I simply re-saved the node and it worked.

I had to run this migration multiple times over three years as I refreshed the content on my current site. The UI didn't offer a rollback (this would be a nice feature through the UI) and had a big red note of caution when running multiple migrations. I did it anyways and it seemed to work fine for me (again, with my simple use case). Buyer beware.

To learn what happened behind the scenes, I audited all of the migration classes and configuration that were created. Kudos to those who worked on making the migration experience a positive one. I was really surprised how much was automated, how insightful it was, how smooth it went, and how easy it would have been to override the underlying config it created.

TugboatQA

As I previously shared, I wanted a tech refresh. I thought about spinning up a development server, but this isn't really a modern CI/CD workflow. Having such a positive experience with TugboatQA on SimplyTest.me, I wanted to rapidly see changes before posting them live. And, I wanted something that didn't require me to mess around with another server. TugboatQA for the win.

Set up was straightforward. This may be potentially because I understood most of the concepts from SimplyTest.me, even though the use case couldn't be more different for my personal website. I followed the documentation and configured it within a few hours (love their IaC set up). I actually found a bug in how I implemented Composer paths, which I subsequently fixed.

Ported Block Type Templates module to Drupal 9

Again, I spend a lot of my personal time on SimplyTest.me. I still moonlight with some module maintenance, but I do a pretty poor job at this if I am being honest. I did use the Block Type Templates module I developed to have more fine grain control of block Twig. This was immensely helpful with the design system integration. But, I had to port it to Drupal 9. I also cleaned up the issue queue and added some nice features. I hope this helps others, too.

Future Goals

This website is definitely not done. I have some open issues I've logged. I need to clean up some content, fix even more styling, and finish the Tugboat implementation now that I've launched. It's done enough for me to not maintain two websites any longer. Please feel free to let me know if you find any issues.

I also want to add more DevOps. When a PR gets merged, I want to set up a GitHub action to trigger the deployment on prod: pull updates from Git, load the config, run the database updates, and clear the cache. My confidence is a lot higher with Tugboat and my CI/CD workflow in the mix. This should be fun.

I'll be finally adding SSL support for my site, but I'd like to do this by learning more about the edge layer. I need more research but leaning towards using CloudFlare for this.

Pattern Lab has evolved majorly since I first set up the design system. I'll be upgrading this with time and I have the Drupal integration versioned to allow for changes like this to be done in the future.

Final Thoughts

I'm glad to finally be able to launch this thing. I learned a lot doing this. Drupal is still a fantastic option for digital experiences. It does so much. Drupal 9 brings all of the previous years of learnings, new features, great performance, modernized dev workflows, and continues to deliver a highly extensible framework. I thought a lot about developing this in something like Gatsby, but would have still wanted a FOSS backend like Drupal. It did everything I needed natively.

admin Mon, 12/28/2020 - 22:43

Tags

Getting Started with Drupal Rector Development

admin — Tue, 05 May 2020 16:53:14 +0000

Getting Started with Drupal Rector Development

Drupal 8 introduced a lot of changes. Its usage of best-of-breed dependencies, like Symfony, represented a major shift for Drupal. Drupal 8 also moved to a more nimble release cycle with its major and minor releases, allowing a major version of core to get new features in minor releases. Between dependencies releasing updates and changes to core being more common, Drupal needed to evolve to manage change. One way this happens is through deprecations. This provides a way for Drupal to evolve, identify old code as deprecated, and offer guidance on a replacement. Deprecations were especially common as Drupal evolved from a largely procedural approach to one leveraging more object orientation and some of the design patterns Symfony uses, like controllers, services, and more. But, the great thing about this approach for deprecations is that deprecations do not get removed until the next major release of Drupal. This buys the community time to progressively fix deprecations within their code and is somewhat expected between major releases. But, what if addressing deprecations could be automated?

Rector, in its simplest format, is an automated, fancier "find and replace" tool for deprecations. It tries to identify the correct symbols and conditions to perform substitution within a library of rules. Each rule has two primary parts: what it is seeking to replace (statement, method, function, argument, and more, represented as a class) and a processing method to perform the replacement. Each rule returns the object with the proper replacement. This processing is great for nuances tied to deprecations, like optional arguments. Rector’s underlying tooling has fine-grained symbolic control that allows for the highest degree of tuning around deprecations.

Did you know that Drupal is able to automate updating deprecated code? Did you know that these updates represent the bulk of the code development work required to upgrade from Drupal 8 and 9? Did you know that this approach works for core, contributed projects, and for custom code? And your help is needed.

This blog post demonstrates how to create and run Rector rules, with some tips along the way. If we all paused from our hectic lives and made just one Rector rule, we could hit a really high percentage of refactoring (note: it may be impossible today to do this kind of automation and hit a flawless 100%). The future goal of this should be upfront time savings with a follow-up manual review and testing to ensure the automation worked.

Background

In my undergrad, we learned about compilers, particularly Lex and Yacc. In grad school, we leveraged symbolic execution for vulnerability analysis. I didn’t find either experience all that satisfying. Both represent a broader umbrella of symbolic computing, with different intended purposes. In short, the code in programming languages can be broken down into its smallest, atomic parts, line by line, part by part.

Let’s break down a simple statement, $number = 8;. A variable in PHP starts with a "$" character and the context of the variable can change based on the location of a variable. The "=" sign refers to the assignment operator, where the variable set is to the left of the equals sign. "8" represents a literal value, not generated like a function. All of this is considered a statement, which is terminated with a ";" character.

The key takeaway is that even a line of code that is trivial to type is a series of symbols with specific semantic meaning tied to the program language itself. Now, imagine expanding this into conditions, functions, objects, and much more.

Getting Started with Drupal Rector Development

These steps should serve as a high-level walkthrough to getting started. Development best practices are still being established, and I encourage joining the #rector Slack channel on drupal.slack.com to get help, offer feedback, and coordinate contribution.

Step 1: Getting setup

The Palantir.net team has set up a sandbox project with instructions on how to rapidly set up an environment for Drupal Rector development. The development instructions follow most Github standards, where a fork of the Drupal Rector project is created to observe the standard pull request workflow.

To identify a deprecation to work on, check the consolidated list of deprecation notices in public modules here (filter by category "not covered by rector" and click on the "total occurrences" column for a sense of impact). Mention the deprecation on the rector channel on Drupal slack for discussion and check that someone hasn’t already filed the issue on the drupal.org issue queue. If no one has worked on it, file an issue in the issue queue and assign it to yourself for the unassigned deprecation you wish to work on.

Step 2: Mock up code and analyze

It is important for you to mock up code examples for all variations that demonstrate both the old (has deprecations) and the new (remediated) code. Yes, you should do both. Why? Drupal Rector dependencies ship with an analysis tool that shows you how statements are composed. It breaks down a statement into a hierarchy of parts. Running the analysis tool against the old and new code helps you identify differences.

A specific example file for Drupal::url can be found here, found in a file named DrupalURLStatic.php. To run the analysis tool against that file, as an example:

vendor/bin/php-parse web/modules/custom/rector_examples/src/DrupalURLStatic.php

Step 3: Develop the Rector Rule

3.a. Creating the Rule

Create a new rector rule class within this directory. Check existing base classes for some helpful starting points that will simplify the logic within your rule. When possible, extend a base class, otherwise, extend the AbstractRector class from the Rector utility. Please bear in mind that if a base class exists, this likely automates a lot of the processing. You may not need to follow every step defined below, but I capture the basic steps you need without a base class.

Begin with a getDefinition() method that provides a human readable description and simple before and after code sample.

Next, create a getNodeTypes() method. Running the analysis tool in step 2 against both the old and new code samples offer guidance on how to create the remediated code returned from the processing in the rule. The generated output of the analysis tool will help highlight exactly what development changes are required to get an old code sample to become the new one. For efficiency and best practice, your starting point should be the highest order difference between the old and new code. Are you replacing a whole statement? Are you replacing a function or just an argument? Within this function, return an array of matching class types tied to the highest order class. This will send all instances of this class as an argument to your processing function when the Rector engine executes. Classes are represented as one or more PHPParser node class types. Please note, this is not a Drupal node, but a PHPParser base class representing the breakdown of the PHP language (e.g. functions, objects, statements, etc).

Finally, create the processor by creating a refactor(Node $node) method. It’s common in this method to further refine the conditions of the passed argument. For instance, if you pass a deprecated class method like getEntity, the argument will receive a class of type ClassMethod. A simple condition to check the name attribute of this instance will refine the processing further.

Proceed to create the new desired code hierarchy in the refactor method from the differences between the code samples. As an example, if you only need to change the name of a method, replace the name attribute in the passed argument and return the object at the end of the processing. Processing differences can be drastically more complex, but encouraging the use of base classes and patterns should lower the complexity over time.

An example of a Rector rule

3.b. Register the Rule

Rules should be associated with a deprecation. A deprecation associates to an issue that identifies what major/minor version of core that introduced the deprecation. Any rules that are created from the deprecation need to be registered in the correct config file found in this directory. If there is not an associated config file for the major/minor version, create a new YAML file with the class name for the rule. Add this new YAML file to the project’s YAML file and the new YAML file referenced in the 'all deprecations' YAML file.

The rector.yml configuration file

An example configuration file that registers a Rector rule

Step 4: Running and Validating

Double check your YAML configuration to ensure the rules are properly registered.

To see a dry run of the rector engine processing, use the following to process all of the rector examples:

vendor/bin/rector process web/modules/custom/rector_examples --dry-run

This will help to debug and iterate on your new rector rule. Running this command will display code that matches Rector rules and code that does not. Hopefully the matches are the old code that needs to be updated to the new code. The new code should come back clean.

A partial example of a log output

Remove the --dry-run flag and replace the path to actual code to have Drupal’s rector engine perform code refactoring.

Summary

Automating deprecations can be complex but it is high impact work. It should become our new muscle memory as we continue to deprecate code in the future. Imagine handing developers a tool capable of automatically performing maintenance to code indefinitely. We can get there.

I want to thank the following people for reviewing and contributing to this blog post: Dan Montgomery, Ofer Shaal, Ken Rickard, Dries Buytaert, Gabor Hojtsy.

admin Tue, 05/05/2020 - 12:53

Tags

Drupal Community Care Packages

admin — Thu, 30 Apr 2020 20:33:00 +0000

Drupal Community Care Packages

Our community has always meant more than just code. These last several months have been difficult to make the same kind of connection we have come to expect from things like in-person events. And, during this time, many of us are having to juggle new challenges, may have sick loved ones, face professional or financial uncertainty, and more. I’m choosing to do something about it.

I am announcing free community care packages for Drupal. I care about our community and I care about the wellbeing of all of you. I recognize this is basically nothing at a time when people are dealing with much larger issues, but I hope that even a small gesture can help to remind you that you matter.

I’m extending the concept of the coffee exchange. What will be included? One-half pound of coffee (thanks to my friends at Standing Stone for help with the coffee), some stickers, and some local chocolate (thanks to my friends at MarCia's Chocolates for suggestions and help with shipping). Shipped to your door. For free. This is my way of saying thanks and recognizing what I miss the most from our pandemic times: each of you.

For financial reasons, I need to keep this within the United States and to the first 30 participants. I will try to do more, if possible. I encourage others to steal this idea, especially for their own country or area. And, I would gladly accept donations to expand to a greater number of people.

What do you need to do? Nothing. However, I’d love to hear your story, if you are inclined to share. I’ll release people’s stories, for those who opt-in, in a series of community spotlights on my blog to help promote the kind of connection our community affords. I believe we need these types of messages to balance the difficult and challenging news we see each day.

How do you sign up? Simply fill out the form here. I’ll remove people’s personal data once the packages get sent, which will hopefully be within two weeks.

admin Thu, 04/30/2020 - 16:33

Tags

SimplyTest.me OpenCollective Update

admin — Mon, 13 Apr 2020 17:28:15 +0000

SimplyTest.me OpenCollective Update

An update from SimplyTest maintainers AmyJune and Adam:

In late 2019, simplytest.me joined OpenCollective (https://opencollective.com/simplytestme), allowing transparency around accepting donations and creating expenses. The Open Collective Foundation (https://opencollective.com/) is a 501(c)(3) organization collecting these contributions on our behalf. Because of this, contributions to simplytest.me through OpenCollective are tax-deductible for US taxpayers.

Supporting our project through the collective allows us to make strategic investments and maintain our critical infrastructure. It also allows us to fund community members who contribute to design, code, and marketing.

Since November 2019, through the support of 16 individuals, 4 DrupalCamps and 3 organizations, we raised $3605.00. The Organizations include The Drupal Association (https://www.drupal.org/association), Tugboat/Lullabot (https://www.tugboat.qa), and Centarro (https://www.centarro.io/).

Thanks to the efforts of AmyJune Hineline (volkswagenchick (https://www.drupal.org/u/volkswagenchick)), the Community Ambassador for Kanopi Studios (https://kanopi.com/), several North American Drupal Camps have adopted Contribution Day Sponsor packages. These packages not only fund a room for contributions but a portion of the money goes toward the tools that folks use while contributing. This enables the collaboration and participation in issue queues and the First Time Contributor Workshops. Specifically, donations are sent to simplytest.me and the Contrib Kanban (https://opencollective.com/contribkanban).

Through that effort, BADCamp (https://2020.badcamp.org/), Midcamp (https://www.midcamp.org/), DrupalCamp Asheville (https://www.drupalasheville.com/), and Florida DrupalCamp (https://www.fldrupal.camp/) have all made contributions totaling $625.00. Kanopi Studios and Acquia (https://www.acquia.com/) picked up those sponsorship packages which ultimately made the donations possible.

The following is a breakdown of the funds collected:

$505 - Individual sponsorships
$2475 - Organization sponsorships
$625 - Camp sponsorships

With the funds collected, we were able to offset maintenance costs. We also funded Community developers for their efforts of porting the project to Drupal 9 and redesign the User Interface.

Some numbers:

$2325 - Benji Fisher (https://www.drupal.org/u/benjifisher) (porting SimplyTest Tugboat to Drupal 8)
$150 - Rahul Baisane (https://www.drupal.org/u/rahulbaisanemca) (porting the Tugboat dependency to Drupal 8)
$40.85 - Domain renewal
$104.99 - SSL certificate
$24.74 - Host fees
$179 - Open Collective fees
$171.89 - Payment processor fees

Please consider supporting our project at https://opencollective.com/simplytest if you like what we do. Simplytest.me is fully volunteer and has no personal profit. All funds will be used to further the project in one form or another.

admin Mon, 04/13/2020 - 13:28

Tags