Gender balance in tech sales through data-driven, objective hiring

July 17, 2015 at 4:48pm
Language Undefined

At a recent Acquia all-company meeting, I was glad to hear that half of the current group of Acquia U students and 7 out of 12 of the latest "BDR" hires in Sales were women. Acquia's CEO, Tom Erickson added that this was the result of some "objective, data-driven" hiring practices. I had to know more. I got Acquia Senior Manager of Business Development and Sales, Chris Hemberger on the line to talk about all of this.

Categories: Planet Drupal

Start Developing Sites on Drupal 8 with Acquia

July 14, 2015 at 9:34pm

This is a part of our Drupal 8 Ready series of blog posts. Read what Dries has to say on buytaert.net. This post will be focused on our push toward Drupal 8 for Drupalists.

If you have been wondering when the right time is to start new projects with Drupal 8, you are not alone. We are approached with this question from partners and clients on a daily basis and have built up a many faceted decision tree for determining which way a project should go. Some of the questions we ask include:

  • When will you start UAT?
  • When do you plan to launch?
  • What authoring and integration functionality will you need at launch?
  • What is the category of the site you will be launching: Campaign, Brand, Intranet, Portal, Community etc.
  • Do you have developers proficient in Drupal 8?
  • Do you have Symfony developers on your team?
  • Do you intend to use modules outside of the top 50?

We have been recommending Drupal 7, but are now at the watershed moment where we can with great certainty recommend that users of our platform start building Drupal 8 sites for launch later this year. There are some projects that won’t be a fit, but if you are still trying to make this decision, it just got a whole lot easier.

Why should we use Drupal 8?
Most reading this post will know the major architectural changes baked into Drupal 8, if not I recomend a visit to this page: https://www.drupal.org/drupal-8.0. These on their own should give you some good reasons to make the move, but digging a little deeper, back-end developers should read about:

According to Morten DK, front-end developers should also be getting very excited about Twig.
In general, Drupal developers are loving Drupal 8, just ask core committer Alex Pott or the teams from Phase2, Amazee Labs and Chapter Three.

The Decision
Acquia has made a company-wide commitment to upgrade Acquia Platform and enable our Customer Success team for Drupal 8. This will ensure our customers can reap the benefits of Drupal 8 while having support to overcome its current challenges.

    Starting your Drupal 8 project now means:
  • Working with a reduced and immature module eco-system
  • Upskilling Drupal developers for object oriented programming
  • Retraining site-builders on the new authoring tools
  • Updating your continual integration scripts

We have a four-pronged approach to supporting our customers in this endeavour:

  1. We have long supported Drupal 8 on our development platform, Acquia Free, but as of this week, customers will be able to develop Drupal 8 sites on Acquia Cloud Enterprise and as of Drupal 8 RC1 we will be offering full production support. This will give customers the ability to leverage the full power of our 50 person, expert-laden, follow-the-sun support team in development, launch and maintenance of Drupal 8 sites.
  2. We have an internal tracking system for active module development among our many projects, allowing our PS, TAM and support teams to give you up-to-date information on the likely release schedule for critical modules.
  3. We have Drupal 8 enablement and migration packages available to speed up your new site development and Drupal 6/7 migration.
  4. Shortly we will be launching our updated Drupal certification programme for developers and site builders for Drupal 8.

The future of Drupal 8 on Acquia
At Acquia we are always thinking about how we can better serve developers. We have put years of research effort into developing better tools Drupal 8 and we have some very exciting releases in our short term pipeline:

  • A new Drupal 8 version of our open source drupal distribution, Lightning. This will be released by the end of the year to give developers a standard architecture and starting point for developing amazing Drupal 8 sites for enterprise (Full Disclosure: This is a shameless plug, as I am the new product manager for Lightning).
  • Upgrades of our existing products Acquia Lift and Acquia Cloud Site Factory to Drupal 8.
  • A completely refreshed automated build system in Acquia Cloud Enterprise with both new APIs and a GUI to enhance your development velocity on Drupal 8.

Thanks @EclipseGc and @webchick for inspiration. I hope this post has helped you make your decision.

Acquia is going all in!

Tags:  drupal drupal 8 developer acquia drupal planet
Categories: Planet Drupal

Sustainable Energy in the Cloud - New AWS Wind Farms

July 14, 2015 at 6:25pm

Yesterday Amazon Web Services announced its largest sustainable energy initiative yet, and perhaps the most ambitious in the cloud industry: building a 208 megawatt wind farm called Amazon Wind Farm US East in North Carolina. In conjunction with the already launched Amazon Solar Farm US East this pushes AWS’s largest region towards being entirely powered by sustainable energy, and demonstrates AWS is actively meeting its lofty green goals.

AWS’s 2014 commitment to have 100% of its global infrastructure powered by sustainable energy is exactly the type of “Think Ahead” ambition that solidifies it as a key strategic partner for Acquia. AWS leads the public cloud pack by offering three completely carbon neutral regions including US-West (Oregon), EU (Frankfurt) and AWS GovCloud (US). Since Acquia Cloud runs in 7 AWS regions, and we are extensive users of the US-East region, we are thrilled to see advances in power generation for the region.

In the years since AWS’s original sustainable energy announcement they have been aggressively expanding their use of sustainable energy and pushing the cloud industry towards a brighter future. In May 2015 AWS passed 25% of global infrastructure consumption coming from sustainable energy sources and they are on track for making 40% by the end of 2016. With Gartner reporting that Amazon Web Services is 10x larger than its next 14 competitors combined it is evident that Amazon is pushing the industry in a big way towards sustainability.

Acquia shares AWS’s thinking that “the greenest power is that which is not consumed.” Acquia Cloud’s elastic scaling allows our customers to benefit from efficiently running their workloads in the cloud. According to analysis by AWS and others, cloud customers run 77% fewer servers, consume 84% less power, and reduce carbon emissions by 88%. The promise of the cloud is to efficiently and nimbly move around workloads, so we’re excited to see results such as these.

At Acquia we’re constantly striving to improve our own energy efficiency and sustainability. We’re thrilled that AWS is delivering on its promises. Wind power accelerates the cloud ecosystem and is important for all involved.

Tags:  cloud green sustainable energy aws acquia drupal planet
Categories: Planet Drupal

Drupal Modules Can Improve Site Performance

July 14, 2015 at 12:54pm

Drupal has modules for just about everything, including improving site performance. You can use these modules to see what's going on with a site and figure out the changes needed to increase Drupal's speed. As part of an ongoing series about ways to improve Drupal website performance, let’s take a closer look at the modules that can make your life a lot easier.

Find the Bottlenecks: Devel

Before trying to improve a Drupal site's performance, it's important to know where the bottlenecks are in order to avoid making random changes. The Devel module provides sharp insight by showing information such as how many queries ran to build a page, how long execution took, and how much memory was used. This information is especially helpful for assessing the impact of changes such as installing and disabling modules. Even if you don't understand all the detailed information the Devel module provides, seeing trends in the numbers will, over time, be useful.

Improve Caching: Entity Cache, Views Content Cache, Panels Hash Cache, and Panels Content Cache

Changing Drupal caching behavior can have a big impact on performance. When applications have a large amount of entity data (information on things like users and content), using Entity Cache can lead to large performance gains with almost no configuration. It's less useful if there's only a small amount of entity data.

To control other cache settings, Block Cache Alter lets settings for each block be configured individually. This allows for more fine-grained control than the settings on the Performance page.

Another change that can improve performance is using a cache based on content-driven expiration, rather than discarding cached data after a specified amount of time passes. The Views Content Cache, Panels Hash Cache, and Panels Content Cache modules provide this functionality.

Improve Database Usage: Views Litepager and Memcached

For sites that use the recommended InnoDB MySQL storage engine, Views Litepager speeds up the creation of pages for views. Rather than creating links to every single page, it provides just “next” and “previous” links. It's incredibly simple and beneficial. The drawback is that site visitors can move only one page at a time through a long list.

Another great addition is Memcache, which lets you integrate Drupal with Memcached, a free and open source, high-performance, distributed memory object caching system that is available on Acquia Cloud. The combination lets Drupal use the database only for large, heavy content, and caches other information elsewhere. To get the best performance from Drupal, it's really important to move as much work – caching and logging – off the database so it can focus on providing the content.

Standard Tools for Performance

There's so much benefit from some of these modules that they're practically standard at many companies, including here at Acquia. Almost everyone uses Devel. Acquia uses Memcache in its cloud platform.

But every organization is different, so find the tools and configuration settings that work for your needs and make them standard across all your development projects. That'll free up time for developing instead of tuning performance.

Tags:  acquia drupal planet
Categories: Planet Drupal

Front End Performance Strategy: Scripts

July 9, 2015 at 7:31pm

In the last installment of this series, we considered CSS optimization. This time we’re going to look at the impact of scripts.

Remember, as architects and developers, it’s up to us to inform stakeholders about the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

So, picking up on our last post, most everything about the way Drupal handles CSS holds true for JavaScript, with a few notable exceptions.

CSS aggregation removes whitespace, but JavaScript aggregation done using Drupal core's aggregation system doesn't do that or any other form of minification or uglification. It simply concatenates our scripts.

Like CSS, JavaScript also has three groups:

  • Library - Libraries, via drupal_add_library
  • Default - Modules
  • Themes - Your theme

Drupal creates aggregates for each of these three groups in the head, but can also deploy to the footer when the scope is set to ‘footer.’

When and where to load your JS

Drupal_add_js features a great option in the options array called scope that allows us to load JavaScript in the footer. This helps decrease our visual page load times by moving render-blocking JavaScript out of the way to a place where it won't impede the loading of other assets (like images, styles, other scripts).

The options array also provides an option called type which defaults to ‘file.’ When using the default option of ‘file,’ it tells Drupal that this is a script hosted on our site, so it's eligible to be aggregated. Combined with the every_page flag set to ‘true,’ just like with our CSS, these scripts get aggregated with the scripts added using ‘.info’ files into the big site-wide aggregates. If the every_page option is left out, or it is set to ‘false,’ then these scripts are aggregated as one-offs outside of our main three site-wide JavaScript aggregate files, again, just like with our CSS.

The type option can also be used to create inline scripts, which can be handy in a couple of ways. It will print our JavaScript directly into our header or footer depending on scope, but it's also useful for dynamically loading external scripts so they become asynchronous. Going forward, the async_js module is probably the way to go. I personally haven't had the opportunity to try it out, but I look forward to the chance. If you've used it, let us know in the comments how it worked out for you.

The third 'type' is the one we use for loading external scripts, which we seem to do often these days. Using an asynchronous method, mentioned above, is important because of the additional round-trip time to get the script. However, a slightly less effective way to handle it without using the older method of an inline script, or an additional module, is simply scoping the script to the footer and setting the type option to external (which prevents it from being aggregated).

Unlike with CSS, I'm less inclined to add JavaScript on every page because I like to scope JavaScript to the footer whenever possible. Since it isn't blocking render down there, the additional HTTP request doesn't really bother me. Generally, if it's on most pages, or a page visited by most users, go ahead and add it to every page. If it isn't and it's scoped to the footer, then only add it when it is needed. If it has to be in the header, and on an obscure page that isn't frequently visited by users, you're probably going to need to do some A/B testing to compare the performance hit on the obscure page by not including it on all pages vs. the performance hit on all the other pages by including it on all pages. I like to err on the side of the majority, meaning, I tend to only include the JavaScript on the obscure pages.

JavaScript: Know when to say when

You can do almost anything with JavaScript, and leveraging a framework like jQuery makes it easier to want to do everything with JavaScript. However, in addition to blocking page render and increasing the size of the page that has to be processed by the browser, there are other performance considerations with JavaScript.

It runs locally, in the browser, which means it uses a visitor's memory and processor. Poorly written or heavy use of JavaScript can lead to a poor user experience in the form of everything from delayed and choppy animations to browsers becoming unresponsive and/or crashing. For simple animations, consider using CSS3 animations, benchmark them using a tool like Chrome's dev tools or Firebug, and go with the least expensive performance option (these usually end up being the smoothest animations as well).

These script performance problems are often magnified on mobile devices where the hardware resources are more scarce and we often resort to using more JavaScript to solve challenges presented by the smaller viewport. This should reinforce the importance of a mobile first strategy, not only for design but also for development. It also highlights the need for open communication between the product owners, the design team, and the development team.

Conclusion

Scripts, like styles, contribute front-end implementations that can seriously hamper Drupal’s back-end magic. By favoring stylesheet aggregation and reigning in exuberant preprocessing, we can save the browser a lot of work. Applying the same principles to JavaScript, while properly placing scripts in the header or footer-based on function, can also improve our page-load times.

Next time, in our final post of the series, we’ll take a grab-bag look at some subtle, more specialized techniques that just might shave off those last few milliseconds. Stay tuned for a post covering Content Delivery Networks (CDN), semantic HTML, and how to encourage improved client-side content selection.

Tags:  acquia drupal planet
Categories: Planet Drupal

Quick Tips for Writing Object Oriented Code in PHP

July 9, 2015 at 7:15pm

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

PSR-4 Autoloading: How to set up your files to be loaded

First things first, how do you include OO code in your project? In D7 you had to add the files to a .info file for a module or do module_load_include. In D8 all you have to do is follow PSR-4 namespacing. If you follow the PSR-4 folder and namespace structure your classes will be auto-detected. No more need to add them to a .info file! If you are writing code for D8 then it’s done. Great. In D7 you can use the XAutoload module to get PSR-4 autoloading in D7 today!

Namespacing In PHP: Loading your files

Namespacing in PHP can be confusing and misleading. In Java or .NET, in a file you first import other namespaces you intend to use. In the example below we use the “using” keyword. Then you declare the namespace wrapper for the code that is being implemented.

using System;
using Microsoft.VisualBasic.Devices;
namespace SampleNamespace
{
    class SampleClass
    {
    }
}

PHP is VERY different. It’s actually the opposite. First you declare the namespace then inside the namespace you have your “includes.” In PHP including the use statements outside of the namespace would contaminate the global-scope.

namespace SampleNamespace
use GuzzleHttp;
use GuzzleHttp\Subscriber;

class SampleClass
{
}

Now this is where things get tricky. If there is a class called Client inside GuzzleHttp then you would expect that you could use it by writing the following.

namespace SampleNamespace
use GuzzleHttp;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
      }
}

And you would be wrong. The way that PHP interprets classes are RELATIVE to the current file’s namespace. So it actually sees “$myClient = new Client();” as “ $myClient = new SampleNamespace\Client();” which does not exist so the declaration fails. To work around this you can reference the actual class in the use statement. If you have multiple classes you must have an include for each one. It’s more verbose than what you might expect coming from .Net or Java e.g.:

namespace SampleNamespace
use GuzzleHttp\Client;
use GuzzleHttp\Subscriber\Mock;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
   $mock = new Mock();
      }
}
Dynamic Typing: A variable can be anything!

PHP is a dynamically typed language. It provides great flexibility and velocity when coding, especially procedural code. However, this can be a nightmare when you are writing OO code. It means that you cannot make assumptions about the type being passed into an object. If you make assumptions and those assumptions are invalid your code can behave unpredictably. What are you to do?

Type Hint ALL THE THINGS:

You might be surprised to know that PHP allows you to apply and enforce function param types. PHP 5 introduced the concept of type hinting. With type hinting you can set type on objects. e.g
function sampleFunction(MySampleClass $a){

If a type hint is violated, an InvalidArgumentException is thrown. There is a catch to type-hinting in PHP, it doesn’t work for scalar types e.g (string, int, bool). There is also no type hinting on return types. You’ll have to wait for PHP 7 for both. In order to work around the scalar limitation in PHP5 you’ll need to write your own functions.

Setting up your code for an IDE

One of the advantages to writing Object Oriented code is that it works really nicely with an IDE like PHPStorm. If you have written type hinted code PHPStorm will pick up on it and help you with auto completion as you work. For the things that aren’t explicitly hinted you can use PHPDoc comments. e.g

/**
* Gets a specific setting by its name/ID.
*
* @param string $id
*   The name/ID of the setting to retrieve.
*
* @return ZoneSettingBase
*   The setting object given the ID passed in.
*/
public function getSettingById($id) {
return $this->settings[$id];
}

PHPDoc comments are actually mandatory as part of drupal-coding standards. Their omission causes coder’s code sniffer to fail.

You can also type-hint variables:

/* @var GuzzleHttp\Client $client/*
private $client;

While these hints are comments and not syntax they make the developer experience a lot more pleasant. No Enums :(

PHP still doesn’t have a formal enumeration type so you will have to get creative and roll your own.

I often create CONST arrays and throw an exception if a function param is not in that array. It’s a poor-man’s enum. There is currently a proposal to add enums to PHP7. We’ll see if it makes the cut!

Associative Arrays

Associative arrays reflect the dynamic typed heritage of PHP. They are incredibly flexible and a quick and easy way to move data from one point of your app to another that being said the lack of structure requires a developer to know everything about the underlying implementation of the array. Also without a debugger they have no way to determine what is actually in an array. The dynamic nature of these arrays makes them undocumentable. That makes coding with someone else’s array hard. The idea of OO is that you have structured data and layers of abstraction so that a dev doesn’t need to know the low-level implementation details. When going OO you should try to convert arrays into structured, documentable classes that hide the underlying implementation. If you need to accept an array as input parse it and break it out into objects as soon as possible. Developers will praise you for it!

No Function Overloading

PHP does not natively support function overloading. Since PHP is dynamic it’s possible to come up with some Frankenstein solutions to get around this. However, Frankenstein code often confuses other developers interacting with your code and is to be avoided. For better or worse you need to accept this constraint.

Dusting off the design cobwebs. How to assign responsibility to classes.

The lack of overloading can actually be beneficial especially in the context of class constructors. Like normal functions you cannot have multiple constructors in PHP (You can technically write a static class method to work around this constraint). This sounds like a pain. However, it forces you to articulate the single responsibility of a class. Often overloaded class constructors can be a sign that a class is taking on too many responsibilities. For example if you have a constructor that take params and another for parsing an array you might ask why should my class know about another representation. Maybe it's a break in tiered architecture and violating a separation of responsibilities. In this case something that might be perceived as a limitation is actually supportive and liberating.

Go Forth and Write OO Code

As we transition into D8 writing solid PHP OO code is more important than ever. D8 is built around OO classes. Even in Drupal 7 we can start to strive towards an OO world. Obviously in Drupal 7 most problems don’t lend themselves to an OO approach. However, even having that option gives you new tools to solve problems in Drupal! The resulting code has a clarity and aesthetic that most procedural code just can’t match.

Finding those opportunities to apply an OO solution keeps you sharp and ready to hit the ground running on Drupal 8.

Tags:  acquia drupal planet
Categories: Planet Drupal

Sustainable contribution 2/2 - Giving back is the same as making money.

July 9, 2015 at 4:35pm
Language Undefined

Part 2 of 2 - I spoke with John Faber, Managing Partner with Chapter Three, on March 17th, 2015.

In part 1 to talk about the business advantages of contribution and sustainability when basing your business on open source software. We also touch on Drupal 8's potential power as a toolset and for attracting new developers, doing business in an open source context, and more!

Categories: Planet Drupal

How to Evaluate Drupal Modules for Performance Optimization

July 7, 2015 at 5:58pm

Drupal was designed from the ground-up to be modular. Once you install Drupal core, you can add any number of modules to enhance Drupal's basic functions.

Unfortunately, contributed modules can also impede performance. For example, it's common to find contributed third-party modules that are incompatible with newer versions of Drupal, or other modules. Besides being a security hassle, this can often curb performance.

Evaluating Drupal modules for such issues is thus essential for a smooth Drupal experience. As part of this ongoing blog series on ways to improve Drupal website performance, let’s review how you can evaluate modules.

General module evaluation

The first step in module evaluation is to consider general usage reports, statistics, and maintainer reputation. One by one, go through the following:

  • Does the module officially support your version of Drupal?
  • Good maintainers write good code. If you see the same maintainer's name crop up on a number of well-regarded modules, you know you will at least get quality code.
  • A high maintainer activity level (i.e. commits to a module) indicates a proactive maintainer who takes care of issues quickly.
  • Higher total module usage generally means it's a well-regarded module with fewer performance issues.
  • A large number of stagnant, open issues can point to poor code quality and maintenance.
  • Sudden changes in usage patterns over a short period of time can be indicative of performance issues. For example, if people suddenly stop using a popular module, it could mean that users encountered performance or security problems.

Once you've gone through these steps, you can undertake a performance evaluation.

Module performance evaluation

Now you need to analyze the module performance on your own site.

  • Record site performance before installing any modules. This should include page load time, server load, and user scenario completion time.
  • Record site performance immediately after installing the module.
  • Monitor memory usage continuously to correlate the performance before and after module installation.
  • Perform the same steps for every module individually over time.

These actions will give you quantifiable results on each module's performance as it relates to your site. You might find that highly rated, widely used modules sometimes don't play well with your version of Drupal, while less used modules work perfectly well.

Final questions

Besides evaluating performance, you also need to ask a few questions before using a module.

  • Does the module scale? A module that works perfectly well for a small enterprise website might break when used on a large community-powered platform. Scale is difficult to measure but it is one of the biggest performance bottlenecks in any website.
  • Is performance a top priority? While performance is important, it is by no means necessary for certain types of websites. For example, a small corporate website visited mostly by internal team members may not need top-notch performance.
  • What happens if the module fails? This is an important question. If your module stops working, does it break the site completely, or can the users at least access parts of the site? For example, if the module that controls the login system fails, your users won't be able to use their accounts at all.
  • Do I really need the module? Far too many websites use more modules than necessary. This leads to "module bloat." Ask yourself: “Do I really need this module? Is there a simple manual workaround to enable this function?” If "yes," try to avoid using a module. Keep in mind that the fewer modules you use, the smaller chance of failure.

Modules are crucial for running a Drupal website, but they are also one of the leading causes of website performance issues. Evaluating and understanding modules is essential for running a fast and secure Drupal website.

Tags:  acquia drupal planet
Categories: Planet Drupal

Front End Performance Strategy: Styles

July 2, 2015 at 6:38pm

The quest for improved page-load speed and website performance is constant. And it should be. The speed and responsiveness of a website have a significant impact on conversion, search engine optimization, and the digital experience in general.

In part one of this series, we established the importance of front-end optimization on performance, and discussed how properly-handled images can provide a significant boost toward that goal. In this second installment, we’ll continue our enhancements, this time by tackling CSS optimization.

We’ll consider general best practices from both a front-end developer’s and a themer’s point of view. Remember, as architects and developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

Styles

Before we dive into optimizing our CSS, we need to understand how Drupal’s performance settings for aggregation work. We see developers treating this feature like a black box, turning it on without fully grokking its voodoo. Doing so misses two important strategic opportunities: 1. Controlling where styles are added in the head of our document, and 2. Regulating how many different aggregates are created.

Styles can belong to one of three groups:

  • System - Drupal core
  • Default - Styles added by modules
  • Theme - Styles added in your theme

Drupal aggregates styles from each group into a single sheet for that group, meaning you’ll see at minimum three CSS files being used for your page. Style sheets added by inclusion in a theme’s ‘.info’ file or a module’s ‘.info’ file automatically receive a ‘true’ value for the every_page flag in the options array, which wraps them into our big three aggregates.

Styles added using drupal_add_css automatically have the every_page flag set to ‘false.’ These style sheets are then combined separately, by group, forming special one-off aggregate style sheets for each page.

When using drupal_add_css, you can use the optional ‘options’ array to explicitly set the every_page flag to ‘true.’ You can also set the group it belongs to and give it a weight to move it up or down within a group.

<?php
drupal_add_css(drupal_get_path('module', 'custom-module') . '/css/custom-module.css', array('group' => CSS_DEFAULT, 'every_page' => TRUE));
?>

Style sheets added using Drupal’s attached property aren’t aggregated unless they have the every_page flag set to ‘true.’

Favoring every_page: true

Styles added with the every_page flag set to ‘false’ (CSS added via drupal_add_css without the true option, or without the option set at all, or added using the attached property) will only load on the pages that use the function that attaches, or adds, that style sheet to the page, so you have a smaller payload to build the page. However, on pages that do use the function that adds or attaches the style sheet with every_page: ‘false’, an additional HTTP request is required to build that page. The additional requests are for the one-off aggregates per group, per page.

In more cases than not, I prefer loading an additional 3kb of styling in my main aggregates that will be downloaded once and then cached locally, rather than create a new aggregate that triggers a separate HTTP request to make up for what’s not in the main aggregates.

Additionally, turning on aggregation causes Drupal to compress our style sheets, serving them Gzipped to the browser. Gzipped assets are 70%–90% smaller than their uncompressed counterparts. That’s a 500kb CSS file being transferred in a 100kb package to the browser.

Preprocessing isn’t a license for inefficiency

I love preprocessing my CSS. I use SASS, written in SCSS syntax, and often utilize Compass for its set of mixins and for compiling. But widespread adoption of preprocessing has led to compiled CSS files that tip the 1Mb limit (which is way over the average), or break the IE selector limit of 4095. Some of this can be attributed to Drupal’s notorious nesting of divs (ugly mark-up often leads to ugly CSS), but a lot of it is just really poor coding habits.

The number one culprit I’ve come across is over nesting of selectors in SASS files. People traverse the over nested DOM created by Drupal with SASS and spit out compiled CSS rules using descendant selectors that go five (sometimes even more) levels deep.

image00_2.png

I took the above example from the SASS inception page, linked above, and cleaned it up to what it should probably be:

image01_2.png

The result? It went from 755 bytes to 297 bytes, a 60% reduction in size. That came from just getting rid of the extra characters added by the excess selectors. Multiply the savings by the 30 partials or so, and it’s a pretty substantial savings in compiled CSS size.

Besides the size savings, the number and type of selectors directly impact the amount of time a browser takes to process your style rules. Browsers read styles from right to left, matching the rightmost “key” selector first, then working left, disqualifying items as it goes. Mozilla wrote a great efficient CSS reference years ago that is still relevant.

Conclusion

Once again we’ve demonstrated how sloppy front-end implementations can seriously hamper Drupal’s back-end magic. By favoring style sheet aggregation and reining in exuberant preprocessing, we can save the browser a lot of work.

In our next, and final, installment in this series, we’ll expand our front-end optimization strategies even further, to include scripts.

Tags:  acquia drupal planet
Categories: Planet Drupal

Sustainable contribution, part 1 of 2: How Drupal has solved and evolved

July 2, 2015 at 3:05pm
Language Undefined

Part 1 of 2 - Drupal user number 5622, John Faber, has been involved with Drupal since late 2003. He is a Managing Partner with Chapter Three, a San Francisco-based digital agency. Their slogan sums up well what a lot of us think about Drupal: "We build a better internet with Drupal." John and I got on a Google Hangout to talk about the business advantages of contribution and sustainability when basing your business on open source software. We also touch on Drupal 8's potential power as a toolset and for attracting new developers, doing business in an open source context, and more!

Categories: Planet Drupal

Improve Your Site’s Security by Adding Two-Factor Authentication

July 1, 2015 at 7:42pm

Identity theft and site compromises are all-too-common occurrences -- it seems a day rarely goes by without a news story detailing the latest batch of user passwords which have been compromised and publicly posted.

Passwords were first used in the 1960s when computers were shared among multiple people via time-sharing methods. Allowing multiple users on a single system required a way for users to prove they were who they claimed to be. As computer systems have grown more complex over the last 50 years, the same password concept has been baked into them as the core authentication method. That includes today’s Web sites, including those built using Drupal.

Why Better Protection Is Needed

Today, great lengths are taken to both protect a user’s password, and to protect users from choosing poor passwords. Drupal 7, for example, provided a major security upgrade in how passwords are stored. It also provides a visual indicator as to how complex a password is, in an attempt to describe how secure it might be.

The password_policy module is also available to enforce a matrix of requirements when a user chooses a password.

Both of these methods have helped to increase password security, but there’s still a fundamental problem. A password is simply asking a user to provide a value they know. To make this easier, the vast majority of people reuse the same password across multiple sites.

That means that no matter how well a site protects a user’s password, any other site that does a poor job could provide an attacker all they need to comprise your users’ accounts.

How Multi-Factor Authentication Works

Multi-Factor authentication is one way of solving this problem. There are three ways for a person to prove he is who he claims to be. These are known as factors and are the following:

  • Something you know - typically a password or passphrase
  • Something you have - a physical device such as a phone, ID, or keyfob
  • Something you are - biometric characteristics of the individual

Multi-factor authentication requests two or more of these factors. It makes it much more difficult for someone to impersonate a valid user. With it, if a user’s username and password were to be compromised, the attacker still wouldn’t be able to provide the user’s second form of authentication.

Here, we’ll be focusing on the most common multi-factor solution, something you know (existing password) and something you have (a cell phone).

This is the easiest method of multi-factor authentication, and is also known as two-factor authentication (TFA) because it uses two out of three factors. It’s already used by a large number of financial institutions, as well as large social websites such as Google, Facebook, and Twitter. Acquia implemented TFA for it’s users in 2014 as discussed in this blog post: Secure Acquia accounts with two-step verification and strong passwords.

How To Do It

A suite of modules are available for Drupal for multi-factor authentication. The Two-Factor Authentication module provides integration into Drupal’s existing user- and password-based authentication system. The module is built to be the base framework of any TFA solution, and so does not provide a second factor method itself. Instead the TFA Basic plugins module provides three plugins which are Google Authenticator, Trusted Device, and SMS using Twilio. TFA Basic can also be used as a guide to follow when creating custom plugins. You can find the documentation here: TFA plugin development.

You’ll find that it’s easy to protect your site and its users with TFA, and given its benefits, it’s a good idea to start now.

But before you do, check out the TFA documentation. Acquia Cloud Site Factory users can find documentation for configuring two-factor authentication for their accounts here.

For more advice, check out TFA tips from Drupal.org.

Tags:  acquia drupal planet
Categories: Planet Drupal

Caching to Improve Drupal Performance: The Three Levels You Should Know

June 30, 2015 at 4:07pm

image that illustrates how caching to improve drupal performance

In our continuing mission (well, not a mission; it’s actually a blog series) to help you improve your Drupal website, let’s look at the power of caching.

In our previous post, we debunked some too common Drupal performance advice. This time we're going positive, with a simple, rock-solid strategy to get you started: caching is the single best way to improve Drupal performance without having to fiddle with code.

At the basic level, it is easy enough for a non-technical user to implement. Advanced caching techniques might require some coding experience, but for most users, basic caching alone will bring about drastic performance improvements.

Caching in Drupal happens at three separate levels: application, component, and page. Let’s review each level in detail.

Application-level caching

This is the caching capability baked right into Drupal. You won't see it in action unless you dig deep into Drupal's internal code. It is enabled by default and won't ever show older, cached pages.

With application-level caching, Drupal essentially stores cached pages separately from the site content (which goes into the database). You can't really configure this, except for telling Drupal where to save cached pages explicitly. You might see improved performance if you use Memcached on cached pages, but the effect is not big enough to warrant the effort.

Drupal stores many of its internal data and structures in efficient ways to improve frequent access when application-level caching. This isn’t information that a site visitor will see per se, but it is critical for constructing any page. Basically, the only enhancements that can be made at this level are improving where this cached information is stored, like using Memcached instead of the database.

You just need to install Drupal and let the software take care of caching at the application-level.

Component-level caching

This works on user-facing components such as blocks, panels, and views. For example, you might have a website with constantly changing content but a single block remains the same. In fact, you may have the same block spread across dozens of pages. Caching it can result in big performance improvements.

Component-level caching is usually disabled by default, though you can turn it on with some simple configuration changes. For the best results, identify blocks, panels, and views that remain the same across your site, and then cache them aggressively. You will see strong speedups for authenticated users.

Page-level caching

This is exactly what it sounds like: The entire page is cached, stored and delivered to a user. This is the most efficient type of caching. Instead of generating pages dynamically with Drupal bootstrap, your server can show static HTML pages to users instead. Site performance will improve almost immeasurably.

Page-level caching gives you a lot of room to customize. You can use any number of caching servers, including Varnish, which we use at Acquia Cloud. You can also use CDNs like Akamai, Fastly, or CloudFlare to deliver cached pages from servers close to the user's location. With CDNs, you are literally bringing your site closer to your users.

Keep in mind that forced, page-level caching works only for anonymous users by default. Fortunately, this forms the bulk of traffic to any website.

It bears repeating: Caching should be your top priority for boosting Drupal performance. By identifying and caching commonly repeated components and using a CDN at page-level, you’ll see site speed improvements that you can write home about.

Next time: How to Evaluate Drupal Modules for Performance Optimization.

Tags:  acquia drupal planet
Categories: Planet Drupal

Seamless Migration to Drupal 8: Make it Yours

June 30, 2015 at 3:26pm

wildebeests migrating

Hi there. I’m Adam from Acquia. And I want YOU to adopt Drupal 8!

I’ve been working on this for months. Last year, as an Acquia intern, I wrote the Drupal Module Upgrader to help people upgrade their code from Drupal 7 (D7) to Drupal 8 (D8). And now, again as an Acquia intern, I’m working to provide Drupal core with a robust migration path for your content and configuration from D6 and D7 to Drupal 8. I’m a full-service intern!

The good news is that Drupal core already includes the migration path from D6 to D8. The bad news is that the (arguably more important) migration path from D7 to D8 is quite incomplete, and Drupal 8 inches closer with each passing day. That’s why I want -- nay, need -- your help.

We need to get this upgrade path done.

If you want core commits with your name on them (and why wouldn’t you?), this a great way to get some, regardless of your experience level. Noob, greybeard, or somewhere in between, there is a way for you to help. (Besides, the greybeards are busy fixing critical issues.)

What’s this about?

Have you ever tried to make major changes to a Drupal site using update.php and a few update_N hooks? If you haven’t, consider yourself lucky; it’s a rapid descent into hell. Update hooks are hard to test, and any number of things can go wrong while running them. They’re not adaptable or flexible. There’s no configurability -- you just run update.php and hope for the best. And if you’ve got an enormous site with hundreds of thousands of nodes or users, you’ll be staring anxiously at that progress bar all night. So if the idea of upgrading an entire Drupal site in a single function terrifies you, congratulations: you’re sane.

No, when it comes to upgrading a full Drupal site, hook_update_N() is the wrong tool for the job. It’s only meant for making relatively minor modifications to the database. Greater complexity demands something a lot more powerful.

The Migrate API is that something. This well-known contrib module has everything you need to perform complex migrations. It can migrate content from virtually anything (WordPress, XML, CSV, or even a Drupal site) into Drupal. It’s flexible. It’s extensible. And it’s in Drupal 8 core. Okay, not quite -- the API layer has been ported into core, but the UI and extras provided by the Drupal 7 Migrate module are in a (currently sandboxed) contrib module called Migrate Plus.

Also in core is a new module called Migrate Drupal, which uses the Migrate API to provide upgrade paths from Drupal 6 and 7. This is the module that new Drupal 8 users will use to move their old content and configuration into Drupal 8.

At the time of this writing, Migrate Drupal contains a migration path for Drupal 6 to Drupal 8, and it’s robust and solid thanks to the hard work of many contributors. It was built before the Drupal 7 migration path because Drupal 6 security support will be dropped not long after Drupal 8 is released. It covers just about all bases -- it migrates your content into Drupal 8, along with your CCK fields (and their values). It also migrates your site’s configuration into Drupal 8, right down to configuration variables, field widget and formatter settings, and many other useful tidbits that together comprise a complete Drupal 6 site.

Here’s a (rather old) demo video by @benjy, one of the main developers of the Drupal 6 migration path:

Awesome, yes? I think so. Which brings me to what Migrate Drupal doesn’t yet have -- a complete upgrade path from Drupal 7 to Drupal 8. We’re absolutely going to need one. It’s critical if we’re going to get people onto Drupal 8!

This is where you come in. The Drupal 7 migration path is one of the best places to contribute to Drupal core, even at this late stage of the game. The D7 upgrade path has been mapped out in a meta-issue on drupal.org, and a large chunk of it is appropriate for novice contributors!

Working on the Migrate API involves writing migrations, which are YAML files (if you’re not familiar with YAML, the smart money says that you will pick it up in, honestly, thirty seconds flat). You’ll also write automated tests, and maybe a plugin or two -- a crucial skill when it comes to programming Drupal 8! If you’re a developer, contributing migrations is a gentle, very useful way to prepare for D8.

A very, very quick overview of how this works

Migrations are a lot simpler than they look. A migration is a piece of configuration, like a View or a site slogan. It lives in a YAML file.

Migrations have three parts: the source plugin, the processing pipeline, and the destination plugin. The source plugin is responsible for reading rows from some source, like a Drupal 7 database or a CSV file. The processing pipeline defines how each field in each row will be massaged, tweaked, and transformed into a value that is appropriate for the destination. Then the destination plugin takes the processed row and saves it somewhere -- for example, as a node or a user.

There’s more to it, of course, but that’s the gist. All migrations follow this source-process-destination flow.


id: d6_url_alias
label: Drupal 6 URL aliases
migration_tags:
  - Drupal 6

# The source plugin is an object which will read the Drupal 6
# database directly and return an iterator over the rows of the
# {url_alias} table.
source:
  plugin: d6_url_alias

# Define how each field in the source row is mapped into the destination.
# Each field can go through a “pipeline”, which is just a chain of plugins
# that transform the original value into the destination value, one step at
# a time. Source values can go through any number of transformations
# before being added to the destination row. In this case, there are no
# transformations -- it's just direct mapping.
process:
  source: src
  alias: dst
  langcode: language

# The destination row will be saved by the url_alias destination plugin, which
# knows how to create URL aliases. There are many other destination plugins,
# including ones to create content entities (nodes, users, terms, etc.) and
# configuration (fields, display settings, etc.)
destination:
  plugin: url_alias

# Migrations can depend on specific modules, configuration entities, or even
# other migrations. 
dependencies:
  module:
    - migrate_drupal
I <3 this, how can I help?

The first thing to look at is the Drupal 7 meta-issue. It divvies up the Drupal 7 upgrade path by module, and divides them further by priority. The low-priority ones are reasonably easy, so if you’re new, you should grab one of those and start hacking on it. (Hint: migrating variables to configuration is the easiest kind of migration to write, and there are plenty of examples.) The core Migrate API is well-documented too.

If you need help, we’ve got a dedicated IRC channel (#drupal-migrate). I’m phenaproxima, and I’m one of several nice people who will be happy to help you with any questions you’ve got.

If you’re not a developer, you can still contribute. Do you have a Drupal 6 site? Migrate it to Drupal 8, and see what happens! Then tell us how it went, and include any unexpected weirdness so we can bust bugs. As the Drupal 7 upgrade path shapes up, you can do the same thing on your Drupal 7 site.

If you want to learn about meatier, more complicated issues, the core Migrate team meets every week in a Google Hangout-on-air, to talk about larger problems and overarching goals. But if you’d rather focus on simpler things, don’t worry about it. :)

And with that, my fellow Drupalist(a)s, I invite you to step up to the plate. Drupal 8 is an amazing release, and everyone deserves it. Let’s make its adoption widespread. Upgrading has always been one of the major barriers to adopting a new version of Drupal, but the door is open for us to fix that for good. I know you can help.

Besides, core commits look really good with your name tattooed on ‘em. Join us!

Tags:  acquia drupal planet
Categories: Planet Drupal

From consumption to contribution - Drupal business in India, Part 2

June 26, 2015 at 3:46pm
Language Undefined

Ani Gupta, Drupal Mumbai community lead, StartupNext lead, formerly at Axelerant in India, and I got the chance to continue the conversation I began with Piyush Poddar at Drupal Camp London about the changing face of IT and open source in India. Under the heading "from consumption to contribution" we talk about India's move from being perceived as being good for cheap, outsourced code to being a place rich with brands and startups in their own right and the home to much open source contribution. We also talk about old versions of Drupal, the Drupal community and its mentoring culture, open source acceptance in business and government, and more!

Categories: Planet Drupal

Drupal: Helping NGOs & Civil Society in Myanmar and beyond

June 19, 2015 at 2:11pm
Language Undefined

When Tom Feichter told me he only gets to one Drupal event a year, I wanted to know why. When he told me it's because he runs a Drupal shop–mspiral creative media–in Yangon, Myanmar, I had to know more! We talked about Tom's history in Drupal, how Drupal's multilingual capabilities have helped him, how excited he is about Drupal 8's architecture, his history working with NGOs on the Thai/Burmese border and how that has flowed into ethical digital agency work, and more.

Categories: Planet Drupal

How Weather.com Improved Their Page Load Times

June 18, 2015 at 5:07pm

migrating weather.com to drupal

In November, 2014 Weather.com launched on Drupal and became one of the highest trafficked websites in the world to launch on an open-source content management system (CMS). Mediacurrent and Acquia are excited to announce a new, 3-part blog post series that will share insight around how Weather.com was migrated to Drupal. Our team of experts will share best practices and what lessons we learned during the project.

There's an old saying, “Everyone talks about the weather, but nobody does anything about it.” While we are a long way from controlling the weather, Weather.com has done a spectacular job of delivering accurate weather news, as rapidly as possible, to all kinds of devices.

This is a small miracle, especially when you consider Weather.com served up a billion requests during its busiest week. Even slow weeks require delivering hundreds of dynamic maps and streaming video to at least 30 million unique users in over three million forecast locations. The site has to remain stable with instantaneous page loads and 100 percent uptime, despite traffic bumps of up to 300 percent during bad weather.

Page load times are the key to their business and their growth. When The Weather Channel's legacy CMS showed signs of strain, they came to Drupal.

On their legacy platform, Weather.com was tethered to a 50 percent cache efficiency. Their app servers were taking on far too much of the work. The legacy platform ran on 144 origin servers across three data centers. It takes all that muscle to keep up with the number of changes that are constantly happening across the site.

Traditionally, when you have a highly trafficked site, you put a content delivery network (CDN) in front of it and call it a day. The very first time a page is requested, the CDN fetches it from the origin server and then caches it to serve to all future requestors.

Unfortunately, it doesn't work that way for a site like Weather.com.

Consider this: If a user in Austin visits a forecast page, they see a certain version of that page. A visitor from Houston sees a slightly different version of that page. Not only are there two different versions of the page, one for each location, but much of the information on the page is only valid for about five minutes.

At the scale of three million locations, that's a lot of pages that have to rebuild on an ongoing basis only to be cached for 5 minutes each. Couple this with the fact that the number of served locations kept increasing as developers worked on the site, and you can see that things are rapidly getting out of control.

The first thing we did was break up the page into pieces that have longer or shorter life spans based on the time-sensitivity of the content. That allowed us to identify the parts of the pages that were able to live longest and that we could serve to the majority of users. The parts that varied, we no longer change on the origin servers, but instead delegate to systems closer to the user where they actually vary.

To accomplish that trick, we switched to a service-oriented architecture and client side rendering, using Angular.js, ESI (Edge Side Includes), and some Drupal magic. The combination of these three components boosted cache efficiency, page performance, and reduced the required number of servers to deliver it.

The result? After launch, we showed Weather.com a 90 percent cache efficiency. In other words, in going from 50 to 90% cache efficiency they reduced the number of hits to the origin servers, which means that you need fewer of them. Post launch, we were able to increase cache efficiency even further.

This cache efficiency was also measured only at the edge. Varnish (a caching proxy) further reduced the amount of traffic, meaning that Drupal itself and the Varnish stack were serving less than 4 percent of their requested traffic. The benefits of the service-oriented architecture also mean that scaling is simpler, architectural changes are less painful, and the end user can experience a richer user experience.

Doing something about the weather is still way out on the horizon, but Weather.com can certainly claim that it has improved the delivery of weather news.

Tags:  acquia drupal planet
Categories: Planet Drupal

Build Your Drupal 8 Team: The Forrester Digital Maturity Model

June 15, 2015 at 2:46pm

In business, technology is a means to an end, and using it effectively to achieve that end requires planning and strategy.

The Capability Maturity Model, designed for assessing the formality of a software development process, was initially described back in 1989. The Forrester Digital Maturity Model is one of several models that update the CMM for modern software development in the age of e-commerce and mobile development, when digital capability isn't an add-on but rather is fundamental to business success. The model emphasizes communicating strategy while putting management and control processes into place.

Organizations that are further along within the maturity model are more likely to repeatedly achieve successful completion of their projects.

Let's take a look at the stages of this model, as the final post in our Build Your Drupal 8 Team series.

Here are the four stages:

Stage 1 is ad hoc development. When companies begin e-commerce development, there is no defined strategy, and the companies' products are not integrated with other systems. Most products are released in isolation and managed independently.

Stage 2 organizations follow a defined process model. The company is still reactive and managing projects individually, but the desired digital strategy has been identified.

Stage 3 is when the digital strategy and implementation is managed. An overall environment supportive for web and e-commerce development exists, and products are created within the context of that environment.

In Stage 4, the digital business needs are integrated. Products aren't defined in isolation, but rather are part of an overall strategic approach to online business. The company has a process for planning and developing the products and is focused on both deployment and ongoing support.

The final capability level, Stage 5, is when digital development is optimized. Cross-channel products are developed and do more than integrate: they are optimized for performance. The company is able to focus on optimizing the development team as well, with continuous improvement and agile development providing a competitive advantage.

Understanding where your company currently finds itself on the maturity scale can help you plan how you will integrate and adapt the new functionality of Drupal 8 into your development organization.

If you are an ad hoc development shop, adopting Drupal 8 and achieving its benefits may be very challenging for you. You may need to work with your team to move up at least one maturity level before you try to bring in the new technology.

In contrast, if your team is at stage 5, you can work on understanding how Drupal 8 will benefit not just your specific upcoming project, but also everything else that is going on within your organization.

Resources:

  • A comprehensive SlideShare presentation on Digital Maturity Models.
  • A blog post by Forrester's Martin Gill that mentions the Digital Maturity Model in the context of digital acceleration.
Tags:  acquia drupal planet
Categories: Planet Drupal

Migrating Content to Drupal: The Weather Channel

June 11, 2015 at 1:31pm

migrating drupal content truck

One of the major challenges facing every digital publisher is making sure its content will display properly up on every possible venue: desktop, tablet, and phone of course, but also in web services, and on the emerging display opportunities arriving with the Internet of Things, like wearables.

Acquia partner Mediacurrent recently tackled this challenge on an awesome scale: migrating the giant The Weather Channel site to Drupal in a way that worked with all the above venues, and then some. (Have you thought about how your content will look on gas station pumps? Mediacurrent and The Weather Channel have.)

Recently, Matt Davis, a senior Drupal developer at Mediacurrent, explained how the team approached this task, in the first blog post in a projected series on the topic: Migrating Weather.com To Drupal: Increased Content Portability.

If your goal is to "write once, use everywhere" (and it should be), this post is worth checking out.

Tags:  acquia drupal planet
Categories: Planet Drupal

Real world change with PHP and community: "The sky's the limit."

June 10, 2015 at 1:01pm
Language Undefined

Michelle Sanver–developer at Liip–and I sat down and talked at SymfonyCon 2014 in Madrid. Michelle and I have a number of interests in common (community, FTW!) and I really enjoyed getting to know her better in a conversation in front of my microphone and camera. We covered her long history in PHP, her SymfonyCon presentation (Life After Assetic: State of Art Symfony2 Frontend Dev) the PHP Renaissance bringing communities together, Michelle's "open source addiction", building PHP applications that touch the lives of almost everyone in Switzerland, and more.

Categories: Planet Drupal

Drupal 8 - 1st product of the PHP-FIG Era

June 5, 2015 at 3:45pm
Language Undefined

I was happy to talk with two major contributors to Drupal 8 at the same time at Drupal South 2015 in Melbourne Australia. At the time we recorded our conversation in March 2015, Hussain Abbas from Bangalore, India and Jibran Ijaz from Lahore Pakistan had both contributed well over 100 patches to D8. In this podcast we talk about their history in Drupal, open source software as a force for good in society, the benefits of contribution, Drupal as the 1st project of the PHP-FIG era, Drupal 8 for developers, the incredible energy and size of the Australasian Drupal community, and more.

Categories: Planet Drupal

Pages