emGee Software Solutions Custom Database Applications

Share this

Drupal CMS

erdfisch: Drupalcon mentored core sprint - get that Friday feeling!

Drupal.org aggregator - Mon, 12/25/2017 - 10:00
Drupalcon mentored core sprint - get that Friday feeling! 25.12.2017 Michael Lenahan Body:  Drupalcon mentored core sprint - get that Friday feeling!

This is the first in a series of blog posts on a subject I'm very passionate about. So much so, that it's actually quite hard to put down in words the way I feel about it. That subject is the Friday Mentored Core Sprint at Drupalcon.

Call to action: If you are planning to go to Drupalcon Nashville, please be sure to extend your stay to cover the Sprint Day on Friday, April 13. You will not regret it!

TL;DR: participating at a large-scale mentoring event like this is an incredible experience. In fact, it is one of the most valuable learning opportunities you will have in your career.

Take advantage of this opportunity. Come along, first as a participant - and then, in future, once you have seen how it works, you can join this team of mentors:

The Drupalcon mentored core sprint is not just for developers.

I think that is worth repeating:

The Drupalcon mentored core sprint is not just for developers. It's for sales people, project managers, freelancers, site builders - in fact anybody in the Drupal world who wants to learn about contributing.

If you are a sales person or a project manager or a site builder - the Friday at Drupalcon is meant exactly for you, and you are welcome to come along and join in. Whatever your skill set is, Drupal needs you!

The Friday sprint at Drupalcon is brought to you by an amazing team of volunteers. Everything they do is centered around creating a friendly, non-intimidating atmosphere, so that everyone feels welcomed and productive.

So here it is. Your chance to make your first contribution to Drupal.

And - if that's not enough - you will simply meet great people, make new friends, and work together on Drupal Core with them. Friendships are made on this day which last for years.

So, what actually happens on Friday at Drupalcon?

I've been lucky enough in the past few years to have been supported by employer erdfisch so that I could go to Drupalcon.

If I didn't have a ticket for Drupalcon, I would travel there anyway, just to take part on the Friday, because it is the highlight of my professional year.

Three quick notes here:

  • You do not need a Drupalcon ticket to go to the Friday mentored core sprints.
  • If you are reading this and planning to be at Drupal Nashville then make sure you stay for the Friday!
  • Drupalcon Europe will, we hope, be replaced by a Drupal Europe event in 2018. We are certainly hoping that this will include a core mentored sprint as well.

So, what makes this day so special?

Well, here's what the Mentored Core Sprint Room looks like at 08:30 in the morning. If you look very closely you can see Sutharsan setting up his table.

After an hour or two, that very same room looks like this:

These photos make me feel hopeful and proud. They sum up for me what the Drupal community is about: people working together and helping each other to be successful.

I'd like you to take a moment and really look at these pictures for a while. The people you see in these photos have had a very long week, they are sleep deprived and very, very tired. (Last night was Trivia Night).

So what's going on? What's making them so engaged?

This is my favourite photo, because it describes perfectly the beautiful chaos of the sprint room on Friday.

Here's another thing: most of the people sitting next to each other did not even know each other a few hours before. That is beautiful. In my humble opinion, if you come to Drupalcon and miss out on this, you're missing out on something important, something potentially life-changing.

What are these people working on? How is this whole thing organized?

I'm glad you asked, because those will be the topics of the follow-up blog posts!

A final word in memory of J-P Stacey

While preparing this post, I saw this tweet.

Last year at Drupalcon Dublin, I asked J-P to be my "mentor mentor" because
I was so impressed by his gentle and unruffled style. He organized the team
at his table with exemplary grace and good humour. I was particularly struck
by how quickly he gathered a group of enthusiastic people around him. Bye J-P,
it was a true honour to have known you, if only once a year, in this particular
context.

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categories: Drupal CMS

Gizra.com: Selling an Item for $1.6M with Elm and Headless Drupal

Drupal.org aggregator - Sun, 12/24/2017 - 14:00

If you happen to know Brice - my colleague and Gizra’s CEO - you probably have picked up that he doesn’t get rattled too easily. While I find myself developing extremely annoying ticks during stressful situations, Brice is a role model for stoicism.

Combine that with the fact that he knows I dislike speaking on the phone, let alone at 6:53pm, almost two hours after my work day is over, you’d probably understand why I was surprised to get a call from him. “Surprised” as in, immediately getting a stomach ache.

The day I got that call from him was a Sale day. You see, we have this product we’ve developed called ״Circuit Auction״, which allows auction houses to manage their catalog and run live, real-time, auction sales - the “Going once, Going twice” type.

- “Listen Bruce,” (that’s how I call him) “I’m on my way to working out. Did something crash?” I don’t always think that the worst has happened, but you did just read the background.
- “No.”

I was expecting a long pause. In a way, I think he kind of enjoys those moments, where he knows I don’t know if it’s good or bad news. In a way, I think I actually do somehow enjoy them myself. But instead he said, “Are you next to a computer?”

- “No. I’m in the car. Should I turn back? What happened?”

I really hate to do this, but in order for his next sentence to make sense I have to go back exactly 95 years, to 1922 Tokyo, Japan.

Continue reading…

Categories: Drupal CMS

Agaric Collective: PHP and Symfony tracks merged for DrupalCon Nashville 2018

Drupal.org aggregator - Sat, 12/23/2017 - 12:51

The program for DrupalCon is evolving constantly. Among the changes for Nashville 2018 new tracks have been added and some have been merged. That is the case for the Symfony and PHP tracks.

Many topics clearly belong to a single track, but others could fit in more than one. When we had a dedicated Symfony track a session about Twig could be submitted to the Symfony or front end tracks. A session about Drupal Console could be submitted to the Symfony, the PHP, or back end tracks. In an effort to reduce confusion in the call for proposal process, the track team has agreed on the following:

  • The back end development track is for sessions focused on Drupal coding and development practices.
  • The PHP track is for sessions that cover the broader PHP ecosystem. These sessions can be related to Drupal, but focused on an external project/library like composer, or PHPUnit, Symfony components.
  • The Symfony track merged with the PHP track.

Undoubtedly Symfony plays a key role in Drupal. Symfony 4 has just been released and it would be great to learn about what the future looks like. We want to learn about what is new in the latest version and what benefits adopting it would bring. We are also interested in sessions that would allow developers to learn from each other. What does a Symfony developer need to know to write Drupal code? What does a Drupal developer needs to know about Symfony to become a better developer? In other words - how to make proper use of Symfony components and related best practices.

Other session ideas include best practices on using Composer, PHPUnit, and third party libraries; new features in PHP 7; functional, asynchronous, and reactive programming; machine learning; micro services; etc.

If you want to attend DrupalCon Nashville, but the cost of attending is too high there are some ways to reduce the expenses:

  • Getting a session selected gives you a DrupalCon ticket.
  • You can get a $350 stipend to help cover expenses if your session is selected and you identify yourself within at least one of the "Big Eight" Social Identifiers. This is part of an effort to increase diversity at DrupalCon.
  • If you volunteer as a mentor, you can get a free ticket. No need to be a speaker for this one.
  • There are grants and scholarships that can provide a ticket and/or money to cover expenses. No need to be a speaker for this one.

The track team for DrupalCon Nashville 2018 is here to help you during the session submission process. We can help review proposals, suggest topics, and clear any doubt you might have. For the PHP track, Chad Hester, Tim Millwood, and myself are ready to help.

For people who have not presented before and for those of underrepresented groups, the Drupal Diversity and Inclusion Initiative has created a channel in Slack to help them with the proposal project. Mentoring is available at drupal.org/slack? in the #ddi-session-help channel.

The call for proposals closes in less than a month on January 17. Do no leave things until the last minute. We look forward to your session submissions!

Categories: Drupal CMS

MidCamp - Midwest Drupal Camp: Buy a ticket, submit a session and sponsor MidCamp 2018!

Drupal.org aggregator - Sat, 12/23/2017 - 09:45
Buy a ticket, submit a session and sponsor MidCamp 2018! Session Submissions are now open

MidCamp is looking for folks just like you to speak to our Drupal audience! Experienced speakers are always welcome, but our camp is also a great place to start for first-time speakers.

MidCamp is soliciting sessions geared toward beginner through advanced Drupal users. Know someone who might be a new voice, but has something to say? Please suggest they submit a session.

Find out more at: Buy a Ticket

Tickets and Individual Sponsorships are available on the site for MidCamp 2018. Click here to get yours!

Schedule of Events
  • Thursday, March 8th, 2018 - Training and Sprints
  • Friday, March 9th, 2018 - Sessions and Social
  • Saturday, March 10th, 2018 - Sessions and Social
  • Sunday, March 11th, 2018 - Sprints
Sponsor MidCamp 2018!

Are you or your company interested in becoming a sponsor for the 2018 event? Sponsoring MidCamp is a great way to promote your company, organization, or product and to show your support for Drupal and the Midwest Drupal community. It also is a great opportunity to connect with potential customers and recruit talent.

Find out more at:

Thanks for reading this far!  We hope to see you at the camp!

Categories: Drupal CMS

Customized Building Stone

Drupal News - Thu, 12/21/2017 - 18:05
Material: marble
tiles: We can customize on request.
thickness: 1.8mm
contact us for a quote.Customized Building Stone
website:http://www.haoshuo-stones.com/building-stone/
Categories: Drupal CMS

mark.ie: Integrating a Simple Drupal Text Paragraph Bundle with Patternlab

Drupal.org aggregator - Thu, 12/21/2017 - 11:49
Integrating a Simple Drupal Text Paragraph Bundle with Patternlab

This is the first post in a series about how to integrate Drupal with PatternLab. In this first blog post, we'll look at a simple text paragraph bundle, which just has one field: text (formatted, long).

markconroy Thu, 12/21/2017 - 19:49

I see a lot of blog posts and talks around about the benefits of using component-based design, about how we should use design in the browser principles to present designs to our clients, about how styleguides are the best way to have sustainable frontends. I've even written some and given many presentations about it myself. What I don't see a lot of is blog posts about how to actually do it.

So, here's how to (or at least how I) integrate my PatternLab theme (it's based on the Phase 2 PatternLab Drupal theme) with a simple paragraph type.

PatternLab

Create a pattern - you can put it wherever your setup says it should go. Paragraph bundles are probably molecules, but I'm not sure how you set up yours. In my case, I have hacked PatternLab and created a folder called "Building Blocks" - this is where all my paragraph bundles go (and then I also have a "Building Blocks" field in each content type - more about my set up in another blog post.

Call the pattern something meaningful - in this case, I call mine "Text". Next, we write the Twig for the text pattern. This can be as simple as this:

{%
set classes = [
  "text"
]
%}


    {{ content }}

Then in my corresponding text.yml or text.json file, I put in some sample content, like so (I like yml):

content: 'This is a Level 2 Heading

This is a paragraph of text followed by a list. Sed posuere consectetur est at lobortis. This is strong while this is emphasised Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Aenean lacinia bibendum nulla sed consectetur. Curabitur blandit tempus porttitor. Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Vestibulum id ligula porta felis euismod semper.

  • A text item in a list
  • Another text item
    • A sub-item
    • Another sub-item
  • A third item in a list
This is a Level 3 Heading

Followed by some more text. This is a link sed posuere consectetur est at lobortis. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Aenean lacinia bibendum nulla sed consectetur. Curabitur blandit tempus porttitor. Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Vestibulum id ligula porta felis euismod semper.

'

Drupal

Finally, in my Drupal paragraph--text.html.twig file, I extend the above PatternLab file, like so:

{% extends "@building-blocks/text/text.twig" %}

Yes, there is only one line of code in that file.

Some Explanation

Why do I call my variable {{ content }}? Simple, I know that the default variable in Drupal's paragraph module to print the contents of the paragraph is {{ content }}, so if I give my pattern in PatternLab the same variable name, I won't have to worry about matching any variables. I do not need to do something like this:

{% include '@building-blocks/text/text.twig' with {
  content: text
  }
%}

This will become much clearer when we work with more complex paragraph types in later blog posts.

You can see an example of this pattern in PatternLab here, and the text you are currently reading is an example of it in use in a Drupal template. Simple, eh?

Categories: Drupal CMS

Zivtech: 5 Drupal Modules for Content Editors

Drupal.org aggregator - Thu, 12/21/2017 - 10:01

As a content management system, Drupal is designed to simplify the process for adding, modifying, and removing content, even for users without much technical expertise. 

Beyond its core functionality, Drupal has a number of modules that make life even easier for content writers and editors. Some of these modules, like Views and CKEditor, were added to core when Drupal 8 was released. 

These are some of our other favorite modules that can further simplify workflows for content editors. 

Real-time SEO for Drupal

Content writers always need to strike the right balance between user friendliness and search engine optimization in their work. Content should incorporate SEO strategies in order to appear in relevant searches while also remaining relevant and appealing to site users. 

Real-time SEO for Drupal promises to help “optimize content around keywords in a fast, natural, non-spam way.” The module analyzes elements of your content like page length, meta descriptions, keywords, and subheadings. This helps boost SEO without sacrificing readability, striking that careful balance. This module also requires the metatag module.

Pathauto

Drupal identifies every piece of content with a node ID, which is displayed in the URL. The Pathauto module uses tokens to automatically create URL aliases based on a specific patterned system that you establish. 

Read more
Categories: Drupal CMS

Chromatic: Principles of Test-Driven Development

Drupal.org aggregator - Thu, 12/21/2017 - 06:00

Summary: Test-driven development (TDD) keeps you focused, encourages critical thinking, and improves code confidence. Here are some basic principles that have helped me write effective tests and which have proven useful when introducing other developers to the practice.

Categories: Drupal CMS

DrupalEasy: DrupalEasy Podcast 201 - Jacob Rockowitz - Webform

Drupal.org aggregator - Thu, 12/21/2017 - 04:39

Direct .mp3 file download.

Jacob Rockowitz (jrockowitz), lead maintainer of the Webform module and builder and maintainer of the Memorial Sloan Kettering Cancer Center site joins Ted Bowman and Mike Anello to talk about the current state of the Drupal 8 Webform module and its path to Drupal 8 and beyond.

Interview DrupalEasy News Sponsors Upcoming Events Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Drupal CMS

Dries Buytaert: Evolving Acquia.com

Drupal.org aggregator - Thu, 12/21/2017 - 04:21

At Acquia, our mission is to deliver "the universal platform for the greatest digital experiences" and we want to lead by example. This year, Acquia's marketing team has been working hard to redesign Acquia.com. We launched the new Acquia.com last week. The new site is not only intuitive and engaging, but "practices what we preach", so to speak.

Over the course of our first decade, Acquia's website has seen a few iterations:

The new site places a greater emphasis on taking advantage of our own products. We wanted to show (not tell) the power of the Acquia Platform. For example, Acquia Lift delivers visitors personalized content throughout the site. It was also important to take advantage of Acquia's own resources and partner ecosystem. We worked in partnership with digital agency, HUGE, to create the new design and navigation.

In the spirit of sharing, the marketing team documented their challenges and insights along the way, and reported on everything from content migration to agile development.

The new site represents a bolder and more innovative Acquia, aligned with the evolution of our product strategy. The launch of our new site is a great way to round out a busy and transformative 2017. I'm also very happy to finally see Acquia.com on Drupal 8! Congratulations to every Acquian who helped make this project a success. Check out it out at https://www.acquia.com!

Categories: Drupal CMS

Freelock : Another Wednesday, another round of security updates

Drupal.org aggregator - Wed, 12/20/2017 - 16:10
back_door.jpeg

Drupal security updates generally come out on Wednesdays, to try to streamline everybody's time. WordPress security notices come out... well, whenever whichever feed you subscribe to bothers to announce something.

Today's notices showed some striking differences between the two communities.

maintenanceSecurityWordPressDrupalDrupal Planet
Categories: Drupal CMS

myDropWizard.com: Drupal 6 version of 'me aliases' module not affected by SA-CONTRIB-2017-097

Drupal.org aggregator - Wed, 12/20/2017 - 11:31

Today, there was a Highly Critical security advisory for a Remote Code Execution (RCE) vulnerability in the me aliases module for Drupal 7:

me aliases - Highly critical - Arbitrary code execution - SA-CONTRIB-2017-097

This module provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc.

It was incorrectly handling URL arguments that could allow an attacker to execute arbitrary PHP code.

However, the way the Drupal 6 version of the module handles URL arguments isn't vulnerable in the same way. So, Drupal 6 users can rest easy - your site isn't affected by this issue.

But if you do use it on Drupal 7, given the criticality of this issue, please update right away!

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Categories: Drupal CMS

Drupal.org blog: Developer Tools Initiative - Part 4: What's next?

Drupal.org aggregator - Wed, 12/20/2017 - 09:39

This is the fourth post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

With our plan to create modular integration points for our tooling options, we have a few clear steps for moving forward:

Phase 1: Prep work
  • Deprecation of password authentication for Git, since many external tooling services no longer support it.
  • Working with core to provide compatibility for semver versioning for contrib, both because this is needed for Composer, and because all of the third party developer toolsets we are considering have begun to standardize on semver.
Phase 2: Initial implementation, replacing current features
  • Replacement of custom, bespoke Twisted Git daemon with standard BitBucket repositories.
  • Replacement of unmaintained CGit with supported BitBucket code viewing.
Phase 3: New features
  • Integration of merge request 'hook' into issue queues, to allow contributors to use a pull request workflow instead of patches.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
  • Integration of code review 'hook' into issue queues, to give us powerful inline code commenting tools.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
Phase 4: Implement Hybrid Integrations for other toolsets
  • Updating project page integrations such that those projects which are already hosted on third party tools such as GitHub or GitLab (for example, Drush) can easily login with SSO, synchronize their repositories, and choose the canonical home of their issues.
On-going: Evaluation
  • Re-evaluate other tooling solutions as blocking issues are resolved and their feature-sets evolve.
So that's the update!

In short: after more than a year's evaluation of the current leaders in open source tooling solutions, including direct collaboration with several of those teams, we are going to focus on making Drupal.org modular to integrate with the best tooling solution as it develops. For now, we will be implementing key improvements for Drupal developers using BitBucket for our repository hosting, code viewing/review, inline editing, and merge requests - integrated with the existing project pages and issue queues.

We'd like to thank the following people for their involvement in this initiative at various times through the process:

Drupal Association Staff

The Technical Advisory Committee (TAC)

Members of the community

Categories: Drupal CMS

Drupal.org blog: Developer Tools Initiative - Part 3: Illustrating modular integration for Developer Tooling on Drupal.org

Drupal.org aggregator - Wed, 12/20/2017 - 09:37

This is the third post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

Below are some rough mockups of what a modular integration between Drupal.org's issue queues and a third party toolset could look like. For the sake of this example, I've used BitBucket as the tooling provider, as that is likely to be our interim toolset for the reasons outlined above. However, one can easily imagine these functions being substituted for their equivalents in other toolsets.

The following is only an early concept. These are by no means final designs for each of these integration points, but they will help to visualize how these tools will be integrated with Drupal.org.

Mockup: Workspaces in the issue summary

The biggest change for contributors would be the addition of a new place in the issue summary to contain these workspaces. For most issues we anticipate a single workspace, as most issues are resolved via collaboration on a single code path, however we would be able to generate multiple workspaces per issue for multiple solutions being proposed in parallel:

The key functions of the Proposed code workspace are: the ability to make a new workspace, the ability to clone an existing workspace, the ability to create/view/edit a workspace merge request. The latest test result and ad-hoc testing options for each workspace would be provided here as well.

Mockup: Propose new Code

The "Propose new code" button is very simply a way to automatically generate a new workspace. This would only be used when a contributor wants to propose an alternate solution to whatever is currently under development. When pressed, we would generate a new workspace with the back-end tooling provider (whether as a fork, branch, or Git namespace) and add it to the table to be cloned, viewed for comments/inline editing, or ultimately to create a new merge request.

The new workspace will be generated with a name based on the issue id, and will present its own test result, clone, and merge request features.

If a user wants to collaborate on an existing solution instead, they can simply clone that workspace locally, or view it to make inline edits. Because some issues can languish for months, or even years, we also want to automate the process of rebasing these workspaces from their parents.

Mockup: Automatic comments as workspaces are updated

Whenever a change is made within the third party toolset, we would use the API to call back to Drupal.org and leave a system message describing the change, as well as linking to the relevant part of the third party toolset UI.

This is what an automated issue comment for code review might look like:

This is what a comment for recently pushed changes would look like:

And this is what a comment for inline edits could look like:

Mockup: Clone

The clone button would simply provide a basic modal pop-up with instructions for collaborators to clone the workspace locally with Git. This is not the final url pattern (one of our goals is to avoid changes in canonical git urls where possible) but it could look something like this:

$ git clone ssh://git@bb.drupalcode.org/is/drupal.git

Mockup: Create Merge Request (in BitBucket)

Merge requests allow contributors to propose changes to projects they don't maintain, and provide maintainers an easy way to view proposed changes.

The create merge request button would allow the user to view the current workspace and request that it be merged into the canonical parent. Only a project maintainer would have the permissions to complete the merge.

Code in a workspace with an open pull request can continue to be iterated on by the contributors. Code comments, diffs, and reviews are summarized on the request.

Mockup: View Merge Request (in BitBucket)

View merge request, like 'create merge request' would allow any collaborator to view the current workspace. This could also be used to initiate inline code edits, or leave code comments.

Mockup: Inline editing

Inline editing allows a quick and easy way for people to propose "standalone" changes to e.g. documentation, markup, etc. without having to have an entire development stack.

We would rely on the third party tooling provider's inline editing functionality. In the example below, we can see how an inline edit is made using BitBucket:

Mockup: Code review

As with inline editing, we would rely on the third-party tooling provider's tools for code review. In the example below you can see the code review options provided by BitBucket:

As indicated above, these mockups are simply an illustration of what this integration could look like, not final designs. However, this has hopefully shown how we can introduce a hybrid model to integrate the best features of a third party tooling provider (pull requests, code review, inline editing), while retaining the essential nature of the drupal-flow.

In our next post:

We outline our roadmap for this initiative.

Categories: Drupal CMS

Drupal.org blog: Developer Tools Initiative - Part 2: Comparing our options

Drupal.org aggregator - Wed, 12/20/2017 - 09:33

This is the second post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

In this update we'll talk about the specific options we've been evaluating to improve the tools for developers on Drupal.org. For each of these options we've built prototype workflows, stood up test integrations, and opened a dialogue with the creators of these toolsets about any gaps we identified. You'll see a summary of how each tooling option does or does not live up to the criteria we outlined in our last post.

Issue Workspaces

At DrupalCon Los Angeles in 2015, Mixologic from the DA Engineering team proposed the concept of Issue Workspaces. While we've historically talked about this idea as a single concept, it actually breaks down into two key components:

  1. The definition of a modern, idealized workflow for the Drupal project.
  2. A technical implementation using a bespoke tooling solution built on Git Namespaces to implement this workflow.

Criteria (for a bespoke implementation):

  • Familiar workflow.
    • ❌/ While an implementation of workspaces based on a bespoke git-namespaces implementation has several technical advantages, it will not appear nearly as familiar to outside developers as a more standard 'pull request' implementation. (Though it would be functionally very similar).
  • Preserve the most valuable parts of Drupal's workflow.
    • By implementing a bespoke solution we could exactly tailor the solution to the needs of the Drupal community.
    • ❌ However, the needs of that community are great, and our capacity to build a 100% bespoke solution that meets all the community's needs is not clear.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ❌ Building issue workspaces using a bespoke git namespaces implementation would require us to continuously compete on features with major third party tooling providers that have much greater resources.

A purely bespoke implementation misses the mark on two of our three primary criteria. Fortunately, however, two years after the original proposal, it is no longer necessary to build a bespoke solution in order to implement an idealized workflow for the Drupal project. It is something that can be done by integrating the existing Drupal.org project pages and issue queues with third-party tooling solutions. Leveraging third party solutions provides several advantages including: familiarity to a wider audience of developers, a continually evolving featureset, and mitigation of the risks of maintaining a bespoke solution with a small team of engineers.

Here is the idealized 'Drupal-flow' visualized:

  • Every issue should be associated with one or more canonical workspaces (git repos+merge requests) which can be collaborated on by any contributor, and merged into the canonical parent by a project maintainer.
  • Contributors should be able to modify the code in these workspaces by:
    • Checking out the code and committing/pushing changes to the workspace.
    • Inline editing files within a workspace.
    • Legacy: uploading a patch.
    • Any contribution method should trigger the appropriate tests.
  • Workspaces should be rebased (manually or automatically) on any changes to the canonical parent.

This workflow is not dissimilar to the default GitHub flow, GitLab flow, or even the suggested BitBucket flow. These are all variations of the generic concept of 'Git flow' created by Vincent Driessen. However, the important difference comes in how each of these solutions tries to integrate a gitflow model into their issue/pull-request model.

The dominant model of these large third party tooling providers is not particularly collaborative. It encourages forks-of-forks, separates conversation about potential solutions onto multiple branch comments or merge requests threads, and generally caters to single developers working on individual proposed solutions, with one ultimately selected by the maintainer and the rest thrown away.

This is a key area in which the 'Drupal-flow' differs from the standard workflow that is implicitly enforced by these toolsets. Our ethos encourages collaboration of many developers on a single solution, and a single threaded conversation.

The gitflow behind the scenes may be identical, but the user experience wrapped around that flow makes very different assumptions about how people will collaborate.

GitHub

GitHub is of course the dominant player in the open-source tooling space. For many years though, their toolset was very much targeted at smaller open-source projects, and their default workflow highly encourages a many-to-many, forks-of-forks workflow, rather than the many-to-one single-threaded collaboration that is part of the Drupal community's ethos. More recently, GitHub has been improving their featureset, providing better issue management tools, more control over organization-level namespaces, and a new app marketplace that allows developers to extend GitHub's core featureset.

We reached out to GitHub and spoke with members of the technical and partnership teams, and while they were excited by the idea of bringing a project like Drupal to GitHub, we did run into some unresolvable blockers - most critically, by policy GitHub does not allow users of GitHub Enterprise to run their own public instances. This means we would have to migrate Drupal projects to GitHub.com, rather than self-hosting our instance.

Criteria:

  • Familiar workflow
    • ✔ GitHub is unquestionably the dominant platform for code collaboration on the web today.
  • Preserve the most valuable parts of Drupal's unique workflow
    • ❌ No way to enforce Drupal.org as the home of projects. While we can still keep project pages on Drupal.org there is nothing to encourage visitors who find the project on GitHub to treat the Drupal.org project page as canonical.
    • ❌ ;No way to enforce our workflow - forks of forks of forks of Drupal core into personal namespaces would be one click away.
    • ❌ Issue management tools are not setup for large, crowd-sourced teams.
      • Even for large community projects, it's more typical for only one or two developers to work on a single github issue at a time. Collaboration tends to be divided across issues, rather than within them.
    • Hard blocker Changing issue metadata requires maintainer permissions. (i.e: No way for non-maintainer collaborators to set an issue to RTBC)
    • ❌ Limited ability to manage project maintainers, especially in the case of abandoned or insecure projects.
  • Leverage a partner who will keep evolving their code collaboration featureset.

Other issues:

  • License/Source availability
    • ❌ GitHub is closed-source.
  • API availability
  • Hybrid integration
    • ✔ A hybrid integration between Drupal.org and GitHub is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitHub to one that does not.
    • ❌ Projects choosing to use the GitHub issues would not have access to DrupalCI
    • ⸗/❌ Projects using GitHub issues would not have access to contribution credit (though it may be possible to develop an app).
  • Data portability/vendor lock-in

    • ⸗/❌ GitHub's data migration feature is only available as part of GitHub enterprise.
    • ❌ GitHub policy will not allow us to self-host, which would allow us to work around some of the issues of preserving our Drupal-flow.
  • Developer support
    • ⸗ GitHub is well-funded and has a large team of developers improving the product. However, it is not open source, and so there is no capacity for the community to fill in the gaps on anything GitHub fails to provide.
    • ✔ GitHub has recently added a new 'apps' architecture, enabling deeper integration.
  • Maintainability for an engineering team of limited resources
    • ✔ Repositories hosted on GitHub would be easy to maintain, but we would have little access or control in the event of issues, and little ability to customize the workflow for the community's needs.
  • Cost
    • ✔ The GitHub team would be willing to provide the Drupal project an enterprise account.
  • Unintended consequences
    • ⸗/❌ Moving most of our developer traffic to hosted GitHub could have a significant impact on Drupal.org traffic, affecting everything from our search presence to revenue programs.

GitHub is a no-go.

GitLab

GitLab is the up-and-comer, and is becoming exceptionally popular in the open-source space - even beginning to be adopted by larger open source projects such as GNOME and Debian.

We've worked closely with the GitLab team as well. In contrast to GitHub, GitLab's terms would allow us to run our own instance of the service. GitLab's fundamental workflow is very much like GitHub's - a one-to-many model of forks of forks. After discussing our workflow with their engineers GitLab has begun implementing their new 'fork network' feature, allowing merge requests across forks. However, this doesn't quite achieve the goal of allowing our many-to-one collaboration model just yet.

GitLab is very close to being a good solution for an Open Source project of Drupal's scale, and the rate at which they are improving the service is impressive. GitLab is also already a favorite of many in our community for personal or professional projects. Given some more time, it may ultimately be able to tick all the boxes.

Criteria:

  • Familiar workflow
    • ✔ GitLab's workflow is very similar to GitHub's and it is the second most widely used code collaboration toolset.
  • Preserve the most valuable parts of Drupal's unique workflow
    • Hard Blocker - Maintainers cannot yet collaborate on downstream merge requests
    • ❌ Monolithic toolset - GitLab's featureset is designed to be used in an all or nothing way. There is no provision for using specific elements while disabling others.
      • For example, there is no way to disable GitLab project pages in order to keep the canonical project pages on Drupal.org.
    • No plugin architecture - changes must be accepted as merge requests upstream in GitLab, or re-rolled as patches with each release (aka, "hacking core").
      • No easy way to turn on or off elements of the GitLab UI.
      • No way to extend the GitLab featureset.
      • Very limited issue management states, and no ability to customize them.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ✔GitLab's roll-out of new features is the fastest paced of the tooling providers that exist today.

Other issues:

  • License/Source availability
    • ⸗ / ✔GitLab Community Edition is open source, but GitLab Enterprise Edition (which we would need for a project of our scale and with our workflow needs) is not open source, only source-available.
  • API availability
    • ⸗ GitLab has a fairly robust api, but in our evaluation we found that many api features were undocumented, and others were deprecated without notification between minor versions.
  • Hybrid integration
    • ✔A hybrid integration between Drupal.org and GitLab is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitLab to one that does not.
    • ❌ Projects choosing to use the GitLab issues would not have DrupalCI integration, or issue credits.
  • Data portability/vendor lock-in
    • ⸗ GitLab's API and documented data model should make it possible to migrate our data to another system should it become necessary.
  • Developer support
    • ✔ As an open-source project, GitLab has a growing community of contributors, as well as the support of a venture funded mothership organization.
  • Maintainability for an engineering team of limited resources
    • Hard Blocker - GitLab's current file-handling makes full copies of a repository for every fork. Taking the number of open core issues as a representative example, Drupal.org would need a new 200 TB+ redundant storage apparatus, just to accommodate Core. GitLab needs to transition to a shared git-object model, or an alternative like git namespaces.
  • Cost
    • ✔ The GitLab team is willing to provide the Enterprise Edition to the Drupal community for free.
  • Unintended consequences
    • n/a

GitLab: not-yet.

BitBucket

BitBucket was the dark horse candidate. Atlassian products are well known in software development circles, but they are often more tolerated than beloved. However, when we sat down at Midwest Drupal Summit in August and looked at the options we explored so far and found them to be not quite baked - BitBucket began to show some advantages as a solution.

For one thing, BitBucket has recently put a heavy focus on user experience and collaboration features. It also has the most flexible permissions model for control over branch permissions, forking, and automatic rebasing of any of the toolsets we evaluated. Finally, it can be implemented modularly - allowing us to use the components that serve our workflow and disable the ones that don't.

Criteria:

  • ✔/⸗ Familiar workflow
    • BitBucket implements a very standard pull request workflow. It is not as widely popular as GitHub or GitLab, but should be easily learned by developers familiar with either of those systems.
  • ✔ Preserve the most valuable parts of Drupal's unique workflow
    • Of all the options we prototyped, BitBucket is the only one which provides the flexibility needed to preserve key elements of our workflow - in particular the ability to cleanly use only the parts of BitBucket that we need (specifically, merge requests, inline editing, and code commenting) without having to use issues or project pages that are less sophisticated than our existing solutions.
  • ✔ Leverage a partner who will keep evolving their code collaboration featureset.
    • Though it's flown under the radar, Atlassian has been making some significant improvements to BitBucket from a feature and user experience point of view over the course of the past year.

Other issues:

  • License/Source availability
    • ⸗/❌ Bitbucket is not open-source, only source-available, though they have an open source licensing program.
  • API availability
  • Hybrid integration
    • ✔BitBucket is much more flexible in terms of choosing which features to use, and which to disable- allowing a fairly tight hybrid integration.
  • Data portability/vendor lock-in
    • ✔/ ⸗ BitBucket stores repositories as standard git objects on the file system, making it relatively straightforward in case of a future migration to another system.
  • Developer support
    • ⸗ BitBucket has the professional support of Atlassian, but does not have a robust open source community driving feature development.
  • Maintainability for an engineering team of limited resources
    • ✔ BitBucket is implemented with an api-first methodology, and is well documented, making it straightforward for a relatively small team to support a selective integration such as what we propose here.
  • Cost
  • Unintended consequences
    • n/a

BitBucket: the best tool in the current landscape given our community's needs.

To sum up, each of the toolsets we evaluated have advantages and disadvantages. However, if we want to move forward with making improvements for our developers TODAY, we have determined that the best way to do that is to create modular integration points, and use the toolset that currently meets our criteria: BitBucket. As these toolsets continue their rapid development, we will continue to periodically re-evaluate them.

In our next post:

An illustration of what the future of Drupal.org's developer tools could look like.

Categories: Drupal CMS

Drupal.org blog: An update on the Developer Tooling Initiative for Drupal.org - Part 1

Drupal.org aggregator - Wed, 12/20/2017 - 09:20

The initiative to improve Drupal.org's developer tools is part of a broader effort to broaden the reach of Drupal, not just to end-users and evaluators, but to a wider audience of developers as well. Improvements to our tools are an opportunity to remove friction to changes, increase the quality of changes, improve velocity of changes, and make contributing to Drupal delightful.

The initiative began in coordination with Drupal Association Staff, the Technical Advisory Committee, and a small group of volunteers from the community. We first announced the initiative in October of 2016, and provided our last update at the end of April of this year. Since that time a great deal of work has been underway to evaluate and prototype our options, collaborate with the vendors who supply these toolsets, and make some decisions about the direction we want to move in, with more data in hand.

Buckle up! Because this is such a large topic we've broken it into multiple posts:

Want a TLDR?

Where do we stand now?

Drupal is one of the longest-running open source projects on the web, and for more than 15 years (and many more to come), Drupal.org has been the home of the project. Over the years, we've built a developer toolset to serve the unique needs of the project. These tools have evolved as the open source environment changed. Right now, we use a combination of best-of-breed third party technologies, such as Git, Jenkins, Fastly, OpsGenie, integrated with our own bespoke tools, including issue queues, project pages, etc.

Right now, some of the third party and bespoke tools that we are using are market leading, whereas others have fallen behind. For example, CGIT (third party) and the patch workflow (bespoke) have both fallen behind compared to toolsets that can be found on other tooling providers. On the other hand, our issue crediting system (bespoke) is market leading, and a model for other projects to follow.

In the end, we will always be negotiating a balance between what we can do uniquely well with bespoke solutions, and integrating the latest and greatest of third party solutions as they coalesce around best practices that we want to adopt as well.

At DrupalCon Vienna it was decided that the Technical Advisory Committee had fulfilled their threefold mandate:

  • Helping the technical leadership transition on the DA engineering team after the downsizing in summer of 2016.
  • Helping manage the prioritization and scope of work.
  • Making recommendations to the board and DA staff on key initiatives, such as the project application process changes, and the direction to take with our developer tools.

We want to thank Angie Byron, Steve Francia, and Moshe Weitzman for serving on the committee. From here, DA engineering staff will carry the torch, though we will continue to rely on the individuals who were part of the TAC and other volunteers for feedback and help from time to time as we move forward.

Our evaluation

The most recent phase of this initiative was an evaluation of the leading contenders for open source tooling providers that Drupal.org could integrate with. These options were GitHub and GitLab, and after setting out to develop prototypes for these options, we added BitBucket to the list as well. For each of these options we built MVP prototypes, either as integrations with Drupal.org development environments, or with private organizations/repositories. Finally, we wanted to compare these options to the bespoke Issue Workspaces solution that we had proposed several years ago.

The Criteria

For the Developer Tools initiative to be successful we have to understand the criteria for improvement. From a user requirements point of view, contrib and core developers are unique stakeholders with unique requirements. Ideally we want a solution that increases velocity for both types of users, without fundamentally sacrificing the needs of one or the other.

  • Adopt a developer workflow that will be familiar to the millions of developers outside our community.
  • Preserve those unique elements of how we collaborate that have made the Drupal project so successful.
    • Many-to-one collaboration: that is to say, many developers collaborating on a single solution to a problem.
    • Issue workflow.
    • Picking up on long standing issues where other collaborators left off.
    • Contribution credit.
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve.

There are also some technical requirements that came out of our evaluation process.

  • Retention of our data/ability to migrate.
    • Where possible, retain existing Git remote urls for projects.
  • Maintainability for a small staff.
  • Project maintainer management: including abandoned project reassignment, fork control, security release management, etc.

In terms of features, we were looking for:

  • Merge/pull requests.
  • Code review.
  • Inline editing.
  • Branch permissioning to allow collaboration on merge/pull requests.
  • Administrative tools for managing project maintainership.
  • Project management tools that equal or exceed what we have with the issue queues.*
  • Extensibility, so that we can preserve areas where the Drupal project is a market leader, such as with our contribution credit system.

*Our tools for issues are very sophisticated on an individual issue level, however we are sorely lacking in tools for grouping and prioritizing sets of issues, ie: issue boards.

Finally, cost:

  • Given the care with which we must use our funding from the community, any option we consider must be cost neutral with the current cost of maintaining our tools.

It's difficult to condense the scope of our evaluation into a short blog series, but in the following posts we'll talk about how the options we considered measured up to these criteria, what implementing one of these options could look like for Drupal.org, and our suggested implementation roadmap.

In our next post:

Our tooling options, compared.

Categories: Drupal CMS

Platform.sh: A look back on 2017

Drupal.org aggregator - Wed, 12/20/2017 - 09:07
A look back on 2017 Crell Wed, 12/20/2017 - 17:07 Blog

Time flies. It's been quite a year for Platform.sh as our product continues to improve. One of the great things about a managed services product is that it can continually improve without you even realizing it. The sign of a successful product feature is that it feels like it's always been there. Who can imagine life without it?

Let's take a look at what we've improved just in the last 12 months...

January opened with support for HTTP/2 on all projects. HTTP/2 changes the way browsers and servers communicate, making it faster, more streamlined, and better tailored to modern, asset-heavy web sites. HTTP/2 "just works" automatically as long as you're using a reasonably modern browser and HTTPS.

And as of April, you're using HTTPS. Courtesy of Let's Encrypt, you now get a free, automatic SSL certificate provisioned for every environment. No one should have to think about HTTPS in 2017. It's just a part of the package.

April also saw the launch of our tiered CDN for Platform.sh Enterprise. The Global CDN combines a flexible, high-feature CDN for dynamic pages with a low-cost, high-bandwidth CDN for static assets. That offers the best of both worlds for sites that want the best performance for the least cost.

We've also continued to expand our available services. We kicked off the year with support for persistent Redis as a key/value store rather than just as a cache server. March saw the addition of InfluxDB, a popular time-series data service for recording time-based data. In June, we added support for Memcached in case Redis doesn't do it for you.

We also beefed up the functionality of our existing services, adding support for multiple-core Solr configurations and multi-database MySQL configurations. We even now support regular expressions in the router for more fine-grained cookie control.

And of course we've kept up with the latest releases of your favorite languages, be that Python, Ruby, NodeJS, or perennial favorite PHP 7.2. We even added preliminary support for Go and Java, both of which are in beta now. (Interested in trying them out? Please reach out to us!)

August included support for arbitrary worker processes in their own container. That allows an application to easily spin up a background task to handle queue processing, image generation, or other out-of-band tasks with just a few lines of YAML with no impact on production responsiveness.

As of October, we've added health notification support for all projects. At the moment they only cover disk usage, but in time will expand to other health notices. (If you haven't configured them on your project yet we strongly recommend you do so.)

We're also closing out the year with new support for GitLab, as well as more flexible control over TLS and Client TLS, plus a few other changes that line us up for even bigger things in the year to come.

Last but not least, all of that goodness is available down under as of July with our new Sydney region for Platform.sh Professional.

And that's all been just this year! What do we have coming in 2018 to further redefine "modern hosting"?

You'll just have to join us in 2018 to find out...

Larry Garfield 29 Dec, 2017
Categories: Drupal CMS

How Is React Different from Vue?

Lullabot - Wed, 12/20/2017 - 08:33

Recently I published an article about the usage of top front-end JavaScript frameworks. The two things that stood out were the dominance of React and the explosive growth of Vue. If current trends continue, it seems likely that by this time next year, Vue will have overtaken Angular as the second most used library or framework.

I've been using React for the last three years building websites for a client services company. Most of the time, the client comes to us specifying that they want to use React. However, it seems only a matter of time before Vue is a bigger part of those discussions. What follows is my first pass at better understanding the differences between these two libraries so I can give better advice to our clients.

Even though I’ve worked with React for three years and enjoy it, I will try to be as even-handed as possible in what follows, although some knowledge gaps with Vue may inadvertently arise.

Beginning at the End

I’ll start with my conclusions. React and Vue are similar, although there are some key differences which I’ll discuss shortly. This makes sense as Evan You, the developer of Vue, used React as one of his inspirations. They are much more like one another than they are to say, Angular or Ember. From the Vue documentation, we see that both:

  • utilize a virtual DOM
  • provide reactive and composable view components
  • maintain focus in the core library, with concerns such as routing and global state management handled by companion libraries

From the standpoint of a finished product, I don’t think clients (or product owners) would be able to tell much difference if their app was built using Vue or React. They are similar in performance and they are both capable of being used on projects large and small.

If you want to publish content across multiple platforms—web and mobile, for example—then React has the edge due to the excellent React Native. My colleagues have also used React to build embedded apps for TVs, which is an interesting example of another platform where you might use React. Vue does have a native mobile option in Weex, however, so perhaps it would work for your situation.

React also has a much larger ecosystem, which can potentially help accelerate development. If you need a key feature or behavior for your app, chances are someone in the React community has already made a solution for it. In fact, you’ll probably find several solutions.

Another consideration for the type of clients my company works with is the ability to find developers that are well-versed in the library/framework in which they are investing. React has the advantage here as well, although I think this is likely temporary.

The other differences are mostly developer preference. They involve paradigms that have trade-offs and I don’t see a clear right or wrong answer. I’ll discuss those in the next section.

Bottom line: If you have a team that is already familiar with React, there is no net advantage to switching to Vue (caveats below). If you have a team that is building front-end applications for the first time or are thinking of migrating away from a framework like Backbone or AngularJS, then you should consider Vue, although React retains the advantages I noted above. The other factors rest with developer preferences which I’ll discuss next.

The Differences

The best place to start looking at the differences between React and Vue comes from the Vue documentation (very good) which addresses the topic quite well. It’s particularly useful because it was written by Evan You in cooperation with Dan Abramov, a member of the React team. It also works as a nice counterbalance to any biases I may have.

Performance

Vue and React are similar in performance. The Vue docs say it has a slight advantage in most cases. However, recent benchmarks show React 16 having the edge over Vue 2.5. When optimizing performance, there are some differences:

In React, when a component’s state changes, it triggers the re-render of the entire component sub-tree, starting at that component as root. To avoid unnecessary re-renders of child components, you need to either use PureComponent or implement shouldComponentUpdate whenever you can…. In Vue, a component’s dependencies are automatically tracked during its render, so the system knows precisely which components actually need to re-render when state changes. Each component can be considered to have shouldComponentUpdate automatically implemented for you, without the nested component caveats. Overall this removes the need for a whole class of performance optimizations from the developer’s plate, and allows them to focus more on building the app itself as it scales. Templating vs. JSX

Another big difference comes with Vue’s use of templates vs. React’s JSX. Many developers don’t like templating languages. Vue’s response:

Some argue that you’d need to learn an extra DSL (Domain-Specific Language) to be able to write templates—we believe this difference is superficial at best. First, JSX doesn’t mean the user doesn’t need to learn anything—it’s additional syntax on top of plain JavaScript, so it can be easy for someone familiar with JavaScript to learn, but saying it’s essentially free is misleading. Similarly, a template is just additional syntax on top of plain HTML and thus has very low learning cost for those who are already familiar with HTML. With the DSL we are also able to help the user get more done with less code (e.g. v-on modifiers). The same task can involve a lot more code when using plain JSX or render functions.

My concern is that if you are mixing JSX and a templating language, your app has more complexity. It’s easier to stick with one paradigm to avoid the overhead of context switching as you go from one component to the next. But reasonable people can disagree on this point.

CSS

The way Vue handles CSS is quite nice. The Vue docs begin by noting that CSS-in-JS is a very popular way of scoping CSS in React. Then it goes on to say…

If you are a fan of CSS-in-JS, many of the popular CSS-in-JS libraries support Vue (e.g. styled-components-vue and vue-emotion). The main difference between React and Vue here is that the default method of styling in Vue is through more familiar style tags in single-file components.

The single-file components that include CSS are what looks good to me. Below is a screenshot of a sample component from the docs. Notice the <style> tag at the bottom.

undefined

By including that tag in the component file, you get component scoped CSS and syntax highlighting. It’s also a bit simpler to implement that the CSS-in-JS solutions for React. Nice.

Ecosystem

As noted earlier, the React ecosystem is much larger than Vue’s. This is a benefit of using React, but it can also make it overwhelming for newcomers. Vue leaves less up to the community, instead keeping important libraries in sync:

Vue’s companion libraries for state management and routing (among other concerns) are all officially supported and kept up-to-date with the core library. React instead chooses to leave these concerns to the community, creating a more fragmented ecosystem. Being more popular though, React’s ecosystem is considerably richer than Vue’s. State Management

For me, this is a key difference. One of the big paradigms in React is functional programming. If you use the popular Redux state management library alongside React, then you are largely working in a functional paradigm.

This is something that has been hugely influential within the larger JavaScript community in recent years. React didn’t invent functional programming—it’s quite an old concept. But it did popularize it with a new generation of programmers. It’s a powerful way of programming that has helped me write better code.

One of the tenets of functional programming is immutability. Here’s a recent talk that explains why immutability matters for reference, but the idea is to control what are called “side effects” and to make managing application state easier and more predictable.

Now, React itself is not a fully functional library by any means. There is also a popular state management library for React called MobX that has mutable state. From the Vue docs:

MobX has become quite popular in the React community and it actually uses a nearly identical reactivity system to Vue. To a limited extent, the React + MobX workflow can be thought of as a more verbose Vue, so if you’re using that combination and are enjoying it, jumping into Vue is probably the next logical step. MobX + React is basically... A more verbose Vue? — Evan You (@youyuxi) May 29, 2016

Another popular state management option with Vue is a library called Vuex. Here’s a quote from an article comparing Redux and Vuex that is helpful in illuminating the differences:

Similar to Redux, Vuex is also inspired by Flux. However, unlike Redux, Vuex mutates the state rather than making the state immutable and replacing it entirely like with Redux’s ‘reducer’ functions. This allows Vue.js to automatically know which directives need to be re-rendered when the state changes. Instead of breaking down state logic with specialized reducers, Vuex is able to organize its state logic with stores called modules.

Although this is a fairly technical argument, to many developers paradigms matter. If working in a functional programming paradigm matters to you, then React will likely have more appeal (with the possible exception of those using MobX). If not, then Vue may be more attractive.

Other Insights

There were a recent series of tweets from Dan Abramov - in reply to a tweet that compared React unfavorably to Vue - that I think are worth sharing. Dan is part of the React team and there is a slight bias to his comments here, but they nonetheless offer insight regarding differences between React and Vue…

Is this the simplest example of Reactivity using @reactjs??? Give me @vuejs any day. Loving v-model #laravel #javascript #vue #react pic.twitter.com/imUfJo9g2p — Wilbur Powery (@wilburpowery) November 14, 2017 React is focused on making your code understandable despite the growing complexity of your requirements. Not on making simple examples as short as possible — Dan Abramov (@dan_abramov) November 14, 2017 This can mean more typing in some cases. But there is also an argument that clear data flow produces code that is easier to follow and maintain in the longer term. — Dan Abramov (@dan_abramov) November 14, 2017 That is not to say that Vue is bad (lots of people enjoy its tradeoffs!) but that making judgements based on whose Hello World is smaller is missing the point in my opinion. — Dan Abramov (@dan_abramov) November 14, 2017

I end with a quote from Evan You. It’s taken from an interview he did with Vivian Cromwell. The question was about how Vue compares with other frameworks.

I think, in terms of all the frameworks out there, Vue is probably the most similar to React, but on a broader sense, among all the frameworks, the term that I coined myself is a progressive framework. The idea is that Vue is made up of this core which is just data binding and components, similar to React. It solves a very focused, limited set of problems. Compared to React, Vue puts a bit more focus on approachability. Making sure people who know basics such as: HTML, JavaScript, and CSS can pick it up as fast as possible. On a framework level, we tried to build it with a very lean and minimal core, but as you build more complex applications, you naturally need to solve additional problems. For example routing, or how you handle cross component communication, share states in a bigger application, and then you also need these build tools to modularize your code base. How do you organize styles, and the different assets of your app? Many of the more complete frameworks like Ember or Angular, they try to be opinionated on all the problems you are going to run into and try to make everything built into the framework. It’s a bit of a trade off. The more assumptions you make about the user’s use case then the less flexibility the framework will eventually be able to afford. Or leave everything to the ecosystem such as React — the React ecosystem is very, very vibrant. There are a lot of great ideas coming out, but there is also a lot of churn. Vue tries to pick the middle ground where the core is still exposed as a very minimal feature set, but we also offer these incrementally adoptable pieces, like a routing solution, a state management solution, a build toolchain, and the CLI. They are all officially maintained, well documented, designed to work together, but you don’t have to use them all. I think that’s probably the biggest thing that makes Vue as a framework, different from others.

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday.

Until next time, happy coding.

This post originally appeared on John's blog, JavaScript Report.

Categories: Drupal CMS

Dries Buytaert: Clean CSS with Stylelint

Drupal.org aggregator - Wed, 12/20/2017 - 07:29

Last night I was working on the album functionality for this website. CSS is not my strong suit, so I wanted to get some help from a CSS linter. A CSS lint tool parses your CSS code and flags signs of inefficiency, stylistic inconsistencies, and patterns that may be erroneous.

I tried Stylelint, an open source CSS linter written in JavaScript that is maintained as an npm package. It was quick and easy to install on my local development environment:

$ npm install -g stylelint stylelint-config-standard stylelint-no-browser-hacks

The -g attribute instructs npm to install the packages globally, the stylelint-config-standard is a standard configuration file (more about that in a second), and the stylelint-no-browser-hacks is an optional Stylelint plugin.

Stylelint has over 150 rules to catch invalid CSS syntax, duplicates, etc. What is interesting about Stylelint is that it is completely unopinionated; all the rules are disabled by default. Configuring all 150+ rules would be very time-consuming. Fortunately you can use the example stylelint-config-standard configuration file as a starting point. This configuration file is maintained as a separate npm package. Instead of having to configure all 150+ rules, you can start with the stylelint-config-standard configuration file and overwrite the standard configuration with your own configuration file. In my case, I created a configuration file called stylelint.js in my Drupal directory.

"use strict" module.exports = { "extends": "stylelint-config-standard", "plugins": [ "stylelint-no-browser-hacks/lib" ], "rules": { "block-closing-brace-newline-after": "always", "color-no-invalid-hex": true, "indentation": 2, "property-no-unknown": true, "plugin/no-browser-hacks": [true, { "browsers": [ "last 2 versions", "ie >=8" ] }], "max-empty-lines": 1, "value-keyword-case": "lower", "at-rule-empty-line-before": null, "rule-empty-line-before": null, }, }

As you can see, the configuration file is a JSON file. I've extended stylelint-config-standard and overwrote the indentation rule to be 2 spaces instead of tabs, for example.

To check your CSS file, you can run Stylelint from the command line:

$ stylelint --config stylelint.js --config-basedir /usr/local/lib/node_modules/ css/album.css

Stylelint will point out errors, automatically fix some stylistic violations, or highlight where your rules are violated. In my case it found an error that was easy to fix:

For fun, I googled "Stylelint Drupal" and found that Alex Pott has proposed adding a Stylelint configuration file to Drupal core. Seems useful to me!

Categories: Drupal CMS

Amazee Labs: Zurich Drupal Meetup January 2018

Drupal.org aggregator - Wed, 12/20/2017 - 03:49
Zurich Drupal Meetup January 2018

Join us on January 18th for the first edition of the Zurich Drupal Meetup, where we will discuss the possible future of  React, GraphQL and Drupal at the Amazee Labs Zürich office.

Vijay Dubb Wed, 12/20/2017 - 12:49

In the Meetup, Amazee Group CTO and Partner, Michael Schmid, will lead our discussion and address the following issue:

The idea of a decoupled Frontend and Backend has been around for a couple of years. Some teams tried them out, but nobody was entirely satisfied with it. Too many problems arose during development; bad or non-existing accessibility, no support for crawlers and bots, changing APIs and expensive refactorings. Even the simple task of displaying a menu on the frontend was problematic.

All these concerns retained us at Amazee Labs from actually trying it. We avoided the use of decoupled systems. That is until a couple of months ago. In summer 2016, we were able to connect React with Drupal via GraphQL for the first time, and felt comfortable using it in a project. To increase the stakes we applied it in a multiple hundred-thousand dollar projects. We wouldn't be Amazee if we didn't! 

What came out is a completely decoupled system built on React that powers 12 individual websites with a single Drupal Backend connected through GraphQL. All of it is completely tested as part of a continuous deployment workflow, is hosted on Docker, has server-side rendering, and not a single line of content or menu on the frontend.

As one of the leading Drupal and React agencies, we always look towards the future. We would like to take the opportunity to plan community activities for 2018 and beyond. Here is a list of topics we are looking to address:

- Define overall goals for Drupal in Switzerland 2018
- Fix dates & contents for meetups for the Zurich Drupal Community
- Pre-discuss planning for the next Drupal Mountain Camp

Come for great talks, people and networking. Sign up here at meetup.com

 
Categories: Drupal CMS

Pages