Front End Performance Strategy: Image Handling

May 21, 2015 at 7:33pm

Javascript code

Business is keenly aware of the importance of page-load time, and its impact on conversion and search engine optimization. It’s now a priority at companies like Wal-Mart, Amazon, and Mozilla.

At Acquia, we hear about it from virtually every customer. They all want to know how our platform and services can improve the performance of their websites. How much can we speed up the responsiveness of the digital experience they are offering their users and customers.

Performance is often considered to be primarily a back-end problem, but frankly what we find after we dig through back-end code: often poor front-end optimization is the culprit and not Drupal itself.

While internet users don't have a page-load value in mind — they’re not counting seconds — they do want their content now. A content owner’s fear is that with a finger hovering over the back button, a user's brain is doing an automatic cost-benefit analysis on whether the loading content is worth the wait. If the site is too slow, they are impatiently wondering if they can get what they’re looking for somewhere else, somewhere quicker.

Its important for business to understand the impact of design and feature-level decisions on performance, and the importance of balancing a sophisticated and elegant user experience with nimble performance. As Engagement Managers, Architects, and Developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and to implement in smart and responsible ways. Regardless of the heroic efforts we are asked to make at the code level, we should all be able to agree on this:

Faster Page Loads = Happier Users

This article kicks off a series about optimizing the requests made by a Drupal site after the DOM loads. The goal of the series is to give site and product owners a new set of tools to evaluate their internal performance and to provide architects and developers specific recommendations. Today we’ll tackle image handling. Subsequent posts will cover JavaScript and CSS optimization, Content Delivery Networks (CDN), semantic HTML and better content selection. We’ll start with image handling because it’s low-hanging fruit and a front end swing-and-miss we often see.

Our first post is divided in two: Theme Images, the images comprised in your design, and Content Images, the images chosen and uploaded by authors, editors, and producers.

In Theme Images we cover sprites: why you should use them, how we employ them at Acquia, and some resources to get you going. In Content Images we explore how to deliver high quality images, optimized using compression and size adjustments, and how we accomplish this at Acquia. Finally, we’ll link to some additional resources.

IMAGE HANDLING

Your images need to be optimized. Full stop. Apply some lossy compression to that 50 image gallery. Dump all your theme images into one sprite file. Don’t serve a retina-quality image to an outdated smartphone. All of these impact page-load times, and we’ll touch on each one here.

Theme Images

We have the most control over theme images because the end users who create content on a site rarely need to manipulate them. Theme images don’t change much after the designer has created them. That makes them ideal for combining into CSS sprite files. A sprite works by combining all theme images into one file and using the x and y positioning values of the “background” CSS property to control which portion of the image is visible.

Sprites hold the advantage of existing in a singular file that is almost always smaller than the sum of its would-be piecemeal parts, plus it can be downloaded with a single HTTP request and cached for reuse. While nothing new, if you’re unfamiliar or need a refresher on sprites, CSS Tricks has a great introduction.

There are a lot of ways to create sprites, including manually in Photoshop. Various Ruby gems and Grunt/Gulp plugins make the process easier. Here at Acquia, we tend to rely on Compass to do the heavy lifting for our Professional Services builds. When creating sprites with Compass, you can use directories to group images that will form separate sprites. So, instead of creating one enormous sprite for all of my styles, I'll break them up into logically grouped images based on their use. These almost always end up being PNGs. When employing icons, I try to use a font-icon or an SVG icon if possible. And if you’re considering SVGs because they look great at different resolutions and screen sizes, you can sprite those too.

Content Images

Content images differ from theme images in that we as designers don’t have full control. We’re shackled to the whims of a writer or a content producer with a burning desire for that full-window 50-image slideshow. Nevertheless, we need to make sure those 50 images hit a sweet spot for size and compression. That means we’re applying an acceptable amount of lossy compression on our JPGs and sizing them to correspond with viewport size and device resolution.

We see a lot of designers and developers getting around responsive challenges by simply loading a larger image then necessary, not declaring dimensions on the image, and scaling the image using styles.

Instead, we should use our current best option, Drupal’s Picture Module. The picture module uses the (soon to be accepted) HTML5 picture element and is a backport of Drupal 8's Responsive Image module which is a part of core Drupal 8. For many, the current preferred solution is to use an image tag with “srcset” and, yes, I am aware of the ongoing conversation around Drupal 8 image handling. Presently, however, the picture element and a polyfill is Acquia’s go-to solution for responsive images. It uses the Breakpoints Module to load the correct image according to viewport size and pixel density, and adopts our defined image styles to create derivatives for different viewports.

This solution takes care of both image size and compression, doing the math to find that optimized sweet spot so you don’t have to.

CONCLUSION

Drupal can be a speedy back-end workhorse, but sloppy front-end implementations can quickly undo all your hard work. Employing the strategies I’ve outlined here can decrease your page-load times by a significant amount. Using sprites for theme images reduces the number of HTTP requests, and enables caching for future use. Drupal’s Picture Module takes the guesswork out of image delivery, optimizing with appropriate compression and size manipulation.

And this is just a start towards your faster Drupal website. In the next post in this series, I’ll show you how to optimize your javascript and cascading style sheets -- two more ways you can improve your site’s front end to create faster page loads, and happier customers.

Tags:  acquia drupal planet
Categories: Planet Drupal

Karma and the journey from consumption to contribution - Drupal in India

May 20, 2015 at 11:04pm
Language Undefined

At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.

Categories: Planet Drupal

How to Select Drupal Modules: Part 3 - Evaluation Tips

May 18, 2015 at 8:26pm

choosing a module

In the previous posts we’ve focused on defining your requirements and the basics of searching for modules. Once you’ve found a Drupal project you’re interested in, now you can make a quick evaluation of the project to determine if you should dig deeper before you test it out.

Evaluation Criteria

Each module you select and install on your site must be maintained. There will be security updates, feature improvements and bug fixes offered on a rolling basis. The update manager within Drupal will notify you when new releases are available. This means you will never miss a key security release.

If a module is actively maintained it will mean that one aspect of your site is more likely to be secure and bug-free. One less thing to worry about! Take a “maintenance first” approach to module selection to limit potential issues arising from compatibility issues or security issues that might arise.

An initial evaluation is something an experienced Drupal developer might do in about one to two minutes, simply to compare two modules to decide which to download and try first. However, let’s tease this apart. There are three useful criteria for evaluating a module.

  1. Reputation: How many maintainers? What other contributions have the maintainers made? Is the individual or company a member of the Drupal Association?
  2. Reach: Is there a community around the module? Are there related modules which integrate with it? What is the total number of installations? Checking the usage over time is there a stable arc?
  3. Currency: Have there been recent commits? Are issues being added by users? Is the maintainer responding? Is there a stable (green/not alpha or beta) release available?

These criteria can give you some indication of the level of effort that is being invested in maintaining the software, and help you interpret information on the project page.

The Project Page

You can determine how a project scores against those criteria based on the information available on the project page itself. A wealth of information is available.

example drupal project page

  1. Description: This should provide some basic information about the project and you should be able to tell what requirements the module has.
  2. Project information: Maintenance status and how many reported installations. Just because only two others use a project, doesn’t mean it’s not a good start for a solution for your team.
  3. Downloads: Is there a compatible version available? If it's not recently updated it might be a warning sign, or it might just be a stable, well-used module that just works.
  4. Maintainers: Is there an active team of maintainers? You can look at their profiles which also list other contributions and activities.
  5. What are current issues? The graphs indicate recent activity and also a brief analysis of how responsive the maintenance team is. Keep in mind most of this work is done on a voluntary basis, so if you’re willing to help out, you can often get a better response.
  6. Is documentation available? This will help you in the next step of testing and exploring the module.

The project information provided should be considered in relation to the other information. For example, you might see a project like Bean doesn’t have a Drupal 8 version. This might make you wonder if the solution is future-friendly. In this case, similar functionality has been incorporated into Drupal 8, so it actually makes this module unnecessary.

To give another example, a project with few installations could be just that unique solution you need to connect your Drupal site to an obscure third party application. And as another example, a project managed by a Drupal newcomer who has few contributions could be a great sign that someone is bringing in new skills and experience to the community.

I would never disparage or dismiss a project based on just one of the criteria. Make sure you look at each aspect of the project and balance it with the rest of the information available.

How can I help?

OK, now we’ve whittled down our choices and found a module or two we’d like to try out. In the next blog post, we’ll actually install and test out a module. After that, I’ll show you how to explore and “learn” a new module.

In our Drupal Site Building course we focus on the essential building blocks of Drupal and contributed modules. In fact, some of the contributed modules we use in the Drupal 7 course have become core in Drupal 8, which is a good sign that the community has convened around specific requirements and solutions.

If you’re stuck trying to find a module for X, please leave a comment and I’ll help you find the module you’re looking for.

Tags:  modules drupal 7 site building training learning functionality acquia drupal planet
Categories: Planet Drupal

Web Accessibility for Developers -- Part 2

May 14, 2015 at 8:15pm

access

We’re at the halfway point of what hopefully has been a helpful guide for developers to make a website accessible for all visitors. (If you missed the first part of this two-part series, please click here.)

In this blog, we’ll review how instructional text, navigation, and other parts of development can allow those with blindness and low vision, deafness, and other disabilities to make full use of a website.

There’s a Proper Place for Instructional Text

When providing an example that will help the user fill out a field, place it after the label of the field and before the field itself. This will let the screen reader pinpoint the instructional text and leave no doubt to the user that they’re hearing an example of what’s required. For instance, an example of how to enter the country code and remaining digits of a telephone number should come just before the field.

A Search that Searches When Instructed

Many people love filters that are dynamic — offering results after each selection is made — but it’s not the best thing for a text reader. Dynamic searches cause the page to constantly refresh, leaving a visitor who’s using a text reader to wonder what’s going on. A page shouldn’t reload until the user hits a button. That means all filters and search functionality should have “submit,” “go,” and “apply” buttons.

Jump Directly to Main Content

Readers without disabilities probably take it for granted that they can jump directly to the main content on a webpage. But for those using a screen reader, they first have to listen to a long list of navigation links, icons and other elements before reaching the main content. That’s where a “skip to main content” link comes in handy. It allows a user to skip everything at the top of the page.

The good news for developers using Drupal is that the “skip to main content” link is beginning to come right out of the box and is already included in some themes. If it’s not included, don’t worry. The code in your template should look similar to:

<a id="skip-link" href="#main-content" class="element-invisible element-focusable">Skip to main content</a>.

The CSS code should make the link invisible to a sighted user but will allow a screen reader to focus on the link.

An Easier Way to Zoom and Shrink

Visually impaired people who don’t need a screen reader still may need to manipulate the size of text. They don’t always know how to use keyboard shortcuts and need a user-friendly aid. In a matter of minutes, a site administrator can plop a text-resizing module onto a Drupal webpage. Here’s a handy helper on how to do it. Just keep in mind that it doesn’t always work for menu items, but it usually does resize static text.

Know What to Show; What to Hide

CSS allows developers to change the style of a webpage and make content sparkle. But some text-based screen readers or older screen readers need to read the page with all of the styles disabled. It’s important to make sure that if the stylesheets are turned off, the screen reader will still be able to read the order of the content correctly and be able to access all functionality.

Most of the responsive Drupal themes are already providing this functionality out of the box, but this standard is important to think about, and test when choosing how you will lay out your pages.

In order to test, disable your stylesheets — as seen in this screenshot of a White House page, for instance — and scroll down the page to ensure that the content order is the same as you originally intended.

white house screenshot

These are only a few steps that can help developers make a website accessible to all visitors. If you’d like to see more ideas — or perhaps even gain a greater understanding of Web accessibility itself — here are two resources worth checking out:

The first is a checklist of standards from Section 508 of the federal Rehabilitation Act that government agencies must follow to provide full and fair Internet access to people with disabilities. Even though only federal agencies are required to follow them, the standards serve as a thorough and detailed source of steps for businesses and organizations to use.

Another useful resource are the Web Content Accessibility Guidelines offered by the World Wide Web Consortium (WC3). The guidelines are comprehensive and should also help you on the way to creating an accessible website.

Thanks for reading. Please leave a comment below if you have other suggestions you’d like to share.

Down the road, we’ll post a companion, two-part series on accessibility for clients – stay tuned.

Tags:  acquia drupal planet
Categories: Planet Drupal

Build Your Drupal 8 Team: Technical Roles and Required Skills

May 14, 2015 at 1:38pm

Last time, we discussed some big themes your Drupal 8 team should be synched up with, like object-oriented programming. Now we're going to drill down into more specifics on the technical side.

Is your tech team full of generalists, or do all your developers have special skill sets and focus on specific kinds of functionality, like databases or communications? Either way, someone on your team will have to fill each of these technical roles for a successful Drupal 8 project.

Drupal 8 Architect

More than anyone else on the project, the Drupal 8 architect needs to understand Drupal 8 in depth. The architect needs to make the decisions about the project's overall architecture, which requires envisioning how the system works as a whole. This is bigger than just the Drupal 8 application, because the project needs to fit into your company's entire software environment. It may need to be integrated with other corporate back-end systems, so this role needs to understand the full technical environment, not just the tech stack that comes with Drupal 8. As much as possible, this individual needs to have a strong understanding of front-end and back-end development tools in addition to a thorough understanding of how Drupal 8 works.

UI Designer

The UI designer needs to understand what the technology is capable of and how to use it to create the best experience for end users. To work with Drupal 8, the UI designer should keep building HTML, CSS and Javascript knowledge, but also develop a Drupal 8-specific understanding of how to create themes and build sites. Learning the capabilities of Twig is needed because Twig replaces PHPTemplate in the new version of Drupal. Instead of .tpl.php files, .html.twig files are needed.

Front-End Developer

All that stuff the UI designer promised the business? It's the front-end developer's job to turn that hypothetical design into a functioning interface. Like the UI designer, front end developers should enhance their knowledge of HTML, CSS and Javascript, and pick up knowledge of Twig. PHP knowledge will help also; so will knowing MySQL. The front-end developer will also want a Drupal 8-specific understanding of how to create themes and build sites, as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Back-End Developer

Clicking on website front-end elements does nothing until you implement the functionality in the back-end. You need to be able to write new functionality from scratch, building on existing components when possible. When the application needs to integrate with other systems, the back-end developer writes the code that hooks it all together into a system that functions seamlessly. This role needs some knowledge of front-end tools like HTML, CSS and JavaScript, but it also requires understanding back-end tools like PHP and MySQL in depth. For Drupal 8 knowledge, the back-end developer should focus on architecture and planning topics as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Marketing Technical Lead

The marketing technical lead owns the content publishing process. She defines the procedure for publishing content and makes sure it adheres to site standards. Because content doesn't accomplish anything unless someone sees it, the marketing technical lead needs to make sure it follows good SEO and SEM practices. It's important that the marketing tech lead keeps current with ever-changing SEO practices, and focuses on learning Drupal 8 as a content management system. Learning about the administration functions, and the kinds of changes you can make that won't require a developer to write code, will be especially useful for this role.

Next time: Non-Technical Team Roles and Required Skills for a Drupal 8 Project.

Tags:  acquia drupal planet
Categories: Planet Drupal

Web Accessibility Tips for Developers

May 7, 2015 at 7:06pm

access

Creating the code that makes a website accessible to all visitors doesn’t have to be as time-consuming or resource-intensive as you might think. All you need to do is follow some simple steps that require a little extra time and effort. But these efforts will ensure that your Web content is at the fingertips of everyone — including those with blindness and low vision, deafness, and other disabilities.

It’s up to both the developer and the client to achieve site accessibility. Although they usually work together in the planning and later stages of website creation, a developer and client also have separate responsibilities in making a site accessible. This blog post, the first in a four-part series that offers website accessibility tips for developers, will make this important part of development easy to follow. And it comes just in time for Global Accessibility Awareness Day on May 21.

Reading More Shouldn’t Take More Effort

The visually impaired rely on screen readers to help them learn what’s on a page, and to navigate a site. But without the proper code in place, a screen reader that’s reading a short list of blog posts on a landing page that will direct users to a longer list of items, will only say “read more” over and over again.

Not knowing what the “more” is, a user will probably get frustrated and go somewhere else. Fortunately, all that’s needed to get a screen reader to articulate the details that accompany the “more” is just a few snippets of code — commands that accommodate disabled people while at the same time hiding text and not cluttering up the screen for non-disabled people.

A developer simply needs to include a small snippet of code similar to:

<a href="/">Read more <span class="readmore"> [site] Blogs</span></a>.

The “read more” CSS class should include code that makes the span class invisible to sighted users but can be heard by non-sighted users. Sighted users would still see “Read More” but non-sighted users would hear “Read More about [site] Blogs.”

Alt Text Should Paint a Clear Picture

Developers should stress to clients the necessity and importance of using alt text on a webpage. It helps visually impaired visitors know all there is to know about an image.

It’s easy to overlook when constructing a webpage, but it’s super easy to include alt text in an image’s markup code. A simple description of what the image is, and its title, are all that’s needed — as seen in this example of the markup box for a photo of Attorney General Eric Holder.

Spell Out What’s Required in a Required Field

Many websites use an asterisk as a cue for people to know what’s a required field of input on a form — but that’s not the best method to reach everyone. That sort of general warning doesn’t always work with screen readers; the user will be left guessing where the required field is. Not to mention, a colorblind visitor won’t see the red or green that’s typically used to highlight the field asterisk warning.

The solution is easy. First, the code behind the field should spell out the name of the required field, and the fact that inputting information there is required — so that people using screen readers will have no doubt about what they need to do. Also, the code should inform users that an asterisk is indeed the warning that’s denoting a required field; that way colorblind visitors who can’t see the red or green text that’s often used on websites as the only type of warning won’t have to second-guess and those using a screen reader will also will know what to do.

Don’t Bury Mistakes; Put the Error Message at Top

Another thing about website forms: A visitor who errs when completing an online form should be immediately informed on the refreshed page about where they’ve made a mistake. Otherwise, a screen reader will speak the entire page again and mention the errors only when it reaches the incorrect fields. The refreshed page should instead offer — at the very top — a basic box that lists what went wrong and what is required.

That’s it for now. Stay tuned for second part of this series, as we take you, the developer, down a true and easy path to website accessibility.

Tags:  acquia drupal planet
Categories: Planet Drupal

Building a great remote team, helping clients & giving back

May 7, 2015 at 4:26pm
Language Undefined

The European Acquia Client Advisory team had an onsite week in Reading the week after Drupal Camp London 2015. I got the chance to see a number of them there and sit down with two of my friends from "Supporta!"–Daniel Blomqvist and Henk Beld. We talked about remote teams and helping others succeed with Drupal, while also paying it back/forward by sharing and teaching what they learn and what they know.

Categories: Planet Drupal

Security in the Cloud: Why Open Source is the Best Choice

May 7, 2015 at 2:37pm

cloud locked
This is the first of a series of security-related postings, which Acquia will compile into a free ebook. In this entry, we’ll look at the perennial question: Is Open Source software inherently more secure than commercial closed-source software?

Securing applications is an ongoing process. It’s a continuum that requires vigilance.

Application security begins during the requirements analysis stage of the Software Development Lifecycle, and must be nurtured throughout the life of the application to be successful.

With Drupal properly configured and managed, it is as secure and reliable as any enterprise content management tool available. However, a Drupal application must be maintained and enhanced over the course of its existence. Acquia Cloud eases this management and maintenance burden on customers, and substantially reduces the risk that software vulnerabilities, external actors, or poor human choices will compromise the integrity of the application or the organization.

As requirements are gathered for a new project, and both open and closed systems are considered, evaluators often ask, Which solution is more secure?

This is frequently cast as a contest between the ideologies of open and closed source software.

It’s the wrong question. All software is susceptible to errors at every step of the lifecycle: from first release, through patches, and on through end-of-life support, when the provider no longer supports the code.

Repeated professional and academic assessments have demonstrated that coding errors are simply part of software development. The professionalism of closed-source commercial software development, which has continually improved its security reviews and practices, is matched by the professional commitment of open source engineers. The main difference between the two is the visibility of source code to all users.

Because most malicious users take the same approach to probing for and exploiting known vulnerabilities, by trying to enter systems on the Web, source code availability seldom plays an important role in discovering flaws in mistakenly unprotected servers, services, or protocols. Open source code, however, enjoys a greater flexibility and speed-to-solution when a vulnerability is discovered, which we will look at later.

Writing, testing, and shipping perfect code is the impossible dream that falsely creates the impression that some software is inherently more secure than others. All non-trivial software is imperfect, and the hardware it runs on can also carry vulnerabilities. In fact, the likelihood of security vulnerabilities is inherent in any application, because people often make mistakes in development or configuration of an application.

So, when we talk about “computer security,” we must recognize that we’re really talking about human security practices that can fail at any number of user-controlled points. Open source software makes those potential flaws a discussion among a group of coders, reviewers, and security professionals. In closed source software, a potential flaw is often regarded as a secret -- one that may impede the resolution time or increase the risk of a discovered vulnerability.

A race with intruders

At the time a vulnerability is discovered, the clock starts counting down to an increase in attacks against that vulnerability. The closed-source software world depends on “security through obscurity,” the assumption that hiding source code makes it harder to discover vulnerabilities. This means that a newly discovered vulnerability sets off a race between the developer and malicious users: who’s going to patch or exploit that vulnerability first?

The same race happens in the open-source software field, but there are many more people familiar with the open source code, so the dynamics are very different. Sometimes projects even collaborate with each other to increase the number of developers working on the same fix, as was the case in August, 2014 for the XML-RPC Denial of Service affecting both WordPress and Drupal.

By comparison, in proprietary software only the commercial software company’s employees can work to fix an error in the closed code.

Indeed, many commercial software security vulnerabilities are discovered by outside consultants and security professionals, who inform the company that built the application. These outside discoverers may bring a solution to the problem along with their vulnerability report, but ultimately the vulnerability will only be patched when the company decides to respond, when it is able.

In some situations, this vulnerability becomes an open secret held closely by an ever-expanding circle of people in the know, all hoping the Bad Guys don’t find out before they deliver a patch. By contrast, commercial companies with a vested interest in the security and capabilities of certain open source systems are now frequently joining together to fund development or security remediations out in the open. Thus, open source actually adds another dimension of security through this community approach to development: it provides a constructive outlet for coders whose passion is searching for vulnerabilities.

Open source code software allows many hands to work towards the mission of identifying and fixing vulnerabilities. The same race to patch a vulnerability exists, but the open source community has a more distributed approach to responding to a known issue. This is generally understood to be an advantage. In a 2009 University of Washington paper, Is Open Source Software More Secure?, researchers, including a Microsoft contributor, concluded:

“...Open source does not pose any significant barriers to security, but rather reinforces sound security practices by involving many people that expose bugs quickly, and offers side-effects that provide customers and the community with concrete examples of reusable, secure, and working code.”

It’s worth mentioning, by the way, that in late 2014 Microsoft itself, once the paragon of the closed software model, announced that it will make its server-side .NET stack and core runtime frameworks available as open source code. Acquia’s Christopher Stone said it was the software equivalent of the falling of the Berlin Wall.

So the real operational security challenges come after a vulnerability is discovered, in the time between a patch becoming available and the time that customers patch their software. Most successful attacks occur in that window. Any system left unpatched is likely to be targeted at some point.

This is why Acquia Cloud's managed platform includes patching and maintaining of all server components, prepares security updates for their customers with Remote Administration, and recommends security best practices and configuration hardening for Drupal applications.

With Acquia, customers can count on rapid responses to vulnerabilities and a quick delivery of patches when available.

The intractable problems in computer security remain: open or closed, people write imperfect code; many are lazy about patching or upgrading to the latest version to close newly discovered vulnerabilities.

The challenge is bigger than open source versus closed software.

That’s why we’re confident that the Acquia approach is the best hybrid response to the threat of imperfect software. We leverage professional practice, the open source community, and a tightly managed continuous-deployment workflow to quickly patch vulnerabilities on our platform, while providing the tools to customers to stay up to date with regards to patching their Drupal applications.

We’ll get into the details of Acquia’s approach to patch management in one of our next posts.

Tags:  acquia drupal planet
Categories: Planet Drupal

Four Final Questions You Should Ask Your Drupal Cloud Host

May 5, 2015 at 4:48pm

You know how when you're buying a car, and the questions just keep on coming? And the salesperson keeps making roundtrips to the manager's desk?

It's kind of like that when you're considering where to host your website. There's always time for more questions. It's one less surprise later on.

That's why I keep adding to my list.

It started, you may recall, with just five questions. A week later, I added five more. Now, before closing out this series, I've got a final four.

Ask now, avoid unpleasant surprises later. That's my motto, and it should be yours.

1. What is your level of Drupal expertise?

Acquia offers the industry's highest level of technical Drupal expertise. Our support organization is larger than most hosting companies––over 60 professionals worldwide with over 250 years of combined experience. And Acquia’s overall level of in-house Drupal expertise is unparalleled with over 150 Drupalists, including core owners, security team members, and module contributors. Furthermore, Acquia’s wealth of Drupal knowledge is being expanded continuously. Closed loop processes between our support and engineering organizations help to drive new tools and add to our Help Center, which we then share with the Drupal community.

2. If my site turns into a volcano of errors, will you proactively notify me?

Acquia monitors the health of customers’ servers, and we proactively notify customers of the nature of any issues we detect. When the problem is server-side, we mitigate it, and when the issue is caused by something on the application side, we provide recommended steps to resolve the issue (though we do not usually implement them ourselves unless the customer cannot for some reason).

Acquia also gives customers access to advanced monitoring at the application level, via partners like New Relic or features like our Uptime Monitoring tool—both of which can be used to alert customers in a self-service fashion whenever the application is suffering. If the root cause is server-related, we will notify the customer proactively, but some issues are application-only (meaning they do not trigger server health alerts on our end), so that is why we recommend that customers utilize application-level monitoring whenever possible.

3. Do you offer advanced platform analysis tools to help ensure that my application is running at its best?

Every Acquia Cloud Subscription comes with a suite of tools that make managing your Drupal sites easier than ever before. Drupal site developers, administrators, and site owners can quickly identify problems, eliminate costly mistakes, simplify processes, and improve overall site performance. Acquia’s monitoring tools analyze and measure the quality of your site based on security and performance parameters. Dozens of tests ensure your site’s conformance with best practices for security, performance, and general Drupal and web application development. Monitoring over 50 settings, these tools provide real-time analysis and proactive alerts for issues with your Drupal code and configuration. You can identify code issues and modifications fast, easily download patch files, and view needed updates at-a-glance. You’ll receive a site score to help you improve the quality of your site. You’ll get clear, actionable recommendations to help solve problems and expand your Drupal knowledge.

Acquia provides several additional tools that help you quickly troubleshoot problems with your application. The Uptime Monitoring tool monitors your site’s uptime and responsiveness. It checks your site every minute to see if it’s online and serving pages. For a developer looking to quickly and easily get visibility into a problem, log streaming is a solution that allows for easy access to information without having to download a full day’s log file. It provides real-time access to server logs from within the UI—making troubleshooting more efficient.

4. What is your uptime Service Level Agreement (SLA), and how do you ensure that you meet it?

Acquia commits to 99.95 percent platform, infrastructure, and application uptime. To ensure this, we operate monitoring services 24x7. Acquia uses the Nagios monitoring platform to provide instant access to over 50 vital real-time and historical metrics. We also maintain robust home-grown monitoring tools to ensure performance. Our team of Cloud Operations professionals is always standing by—proactively monitoring your environment and responding to critical issue alerts. With coverage in all time zones and fluency in five languages, the team is available 24x7 for critical, site-impacting issue response.

Tags:  acquia drupal planet
Categories: Planet Drupal

Build Your Drupal 8 Team - Skills for Tech, Non-Tech, and "Bridge" Members

May 4, 2015 at 5:12pm

Getting your hands on new technology is the best part of being a developer -- playing around with it, and trying out cutting-edge concepts is challenging.

But trying to meet deadlines with new tech, especially if you don't understand it fully? That can mean lots of late nights and weekend work when you'd rather be doing something else.

Fortunately, working with Drupal 8 builds on core skills your team already has. Augmenting their existing knowledge with additional skills to use the new functionality of Drupal 8 will help your team deliver that first project successfully.

The new release of Drupal integrates technology that's become industry-standard, so developing skills in these areas will have benefits beyond the Drupal ecosystem.

drupal8teams.pngHow to think about your Drupal 8 team: Tech, Non-Tech, and "Bridge."

Skills for the Tech Team Members

Even if you've worked with Drupal previously, upcoming architectural changes in Drupal 8 mean you'll need to spend some time to get up to speed.

For the tech folks, here's the bulletin: bone up on PHP, Symfony, and object-oriented development.

PHP underlies Drupal 8's event-listener, which is what makes its functionality work. Understanding PHP namespaces is important to coming up with a clean way of organizing your code modules and sub-modules.

Symfony is a PHP framework that's being incorporated into Drupal 8. It will help provide the routing, sessions and services container functionality. Features like dependency injection will help you develop reusable code.

Drupal 8 implements its fields, views, entities and nodes in an object-oriented fashion. This brings the benefits of object-oriented development, like inheritance and encapsulating functionality, but means you need to understand concepts like polymorphism. Focus on understanding key design patterns like dependency injection -- you'll want to leverage those patterns in speed-building your site.

That sounds like a lot of learning, but you don't need to become experts in all of it -- you just need to get a deep enough understanding of the concepts and how to use them to speed your Drupal 8 development.

Skills for the Non-Tech Team Members

The non-tech members of the team don't get a free pass while developers hit the books.

Everyone on the team should understand the capabilities of Drupal 8 so they know what they can reasonably ask you to develop.

Finally, your team needs a "bridge member" -- a team lead or project manager who understands both the technical capability of Drupal 8 and the needs and wants of the business to mediate when there is a conflict between them.

A bridge member who is fluent in technology and business is key to making sure project commitments are realistic and achievable, allowing you to get the project done while having weekends to yourself.

Next: We'll drill down into the technical roles and required skills your team needs for Drupal 8.

Sources:

https://www.drupal.org/drupal-8.0

http://buytaert.net/why-the-big-architectural-changes-in-drupal-8

http://www.sitepoint.com/symfony-drupal-8/

http://stackoverflow.com/questions/1068556/how-drupal-works

Tags:  acquia drupal planet
Categories: Planet Drupal

Jumpstart Your Drupal Project with a Technical Project Manager

May 4, 2015 at 3:46pm

istock_000035083202_double.jpg
Is your Drupal project stalled?

Perhaps you don't know exactly what's wrong, but for some reason the project is just stuck.

You're eager to take the next step -- if only you knew what that was. If you find yourself in this situation often enough, you might want to consider hiring a technical project manager.

What is a Technical Project Manager?

Simply put, a technical project manager is your liaison between your technical team and the non-technical people you are working with. Technical managers are familiar with technical jargon and processes, and most importantly, they understand the culture of IT professionals. Thus, they can communicate well and help motivate members of the IT team that aren't performing at their maximum capacity, help managers delegate work appropriately and jump-start project leadership.

Technical project managers do a whole host of things on any given day to help move projects into the next stage of completion. For example, they might:

  • Write emails to members of the IT team to assign tasks, check in on project completion or resolve problems.
  • Discuss the project one-on-one with technicians to make sure they are staying on track and are moving towards project completion.
  • Write status reports
  • Lead IT team meetings
  • Help technicians brainstorm solutions to severe technical problems.
How to Work With a Technical Project Manager

The key to working with a technical project manager is to communicate often about the project. Here's some specifics to keep in mind:

  • Share your vision for the project. Technical project managers are as prone to assumptions about what the project entails as other IT team members are. It's important to begin by ensuring everyone's on the same page. When the technical project manager is brought on board, have a team meeting where everybody shares what they think the project is meant to accomplish and what their role is. That way, the technical project manager understands what's needed and can make sure that everybody on the team knows what they are supposed to be doing.
  • Collaborate on a timeline. One of the biggest problems with IT projects involves timelines. It can be tempting to get sucked into side projects when researching or working on the main project, and this can push deadlines back -- especially if those deadlines aren't clear to begin with. Sit down with the technical project manager to discuss the timeline for the project, including deadlines for each step. Together, the team can come up with a timeline that feels comfortable for everybody and the technical project manager can more easily help everybody stay on task.
  • Have regular check-ins. Now that there's a technical project manager on board, IT team members can talk about technical difficulties or problems with completing their tasks as scheduled because the project manager will understand what they're talking about. Team members should get in the habit of checking in regularly with the technical project manager and sharing any concerns or technical problems that are interfering with progress.
  • Use technology for check-ins and discussion. Reporting tools should be updated, and internal social media, instant messaging and conference calls should be utilized to quickly provide status updates for each member of the team.

Bringing a technical project manager on board can help bridge the gap between IT professionals and management.

Technical project managers have an IT background as well as a management background, so they are in a unique position to help projects get off the ground and moving towards completion.

Tags:  acquia drupal planet
Categories: Planet Drupal

PHP Reset, PHP Renaissance: Unify everything in PHP with Composer

April 30, 2015 at 6:20am
Language Undefined

It was great to get the chance to sit down and talk with Jordi Boggiano at SymfonyCon Madrid 2014. Jordi is responsible for Composer, one of the most important pieces of technology that is driving PHP interoperability and the PHP "renaissance" of the last couple of years. He's also on the Symfony2 core team, "and bad about telling things about myself."

Categories: Planet Drupal

Yhteisöllisyys and global Drupal: "Friendships beyond business"

April 23, 2015 at 9:31pm
Language Undefined

If only non-Finns could easily pronounce it, I think "yhteisöllisyys" would be a perfect motto for Drupal. To explain what it means, I dragged Lauri Eskola, Drupal Craftsman from Druid.fi, away from the contribution sprints at DrupalCamp Brighton 2015 long enough for him to fill me in on that, as well as his trip to Drupal Camp Delhi 2015, what he's excited about in Drupal 8, and how doing business in the Drupal world–based on values like sharing and openness–must seem strange and different to outsiders.

Categories: Planet Drupal

Sites that Cannot Fail -- Forecasting the Big Storm

April 16, 2015 at 7:04pm

storm.jpg

Sometimes we can’t plan for it. Sometimes we have a moment’s notice. Other times it’s our most anticipated day of the year. No matter the situation, every organization has experienced a time when their digital properties could not fail—or the business impact would be devastating.

In this blog series, we’re showcasing what it meant for three of our largest customers to have a site that could not fail. We’ll highlight both business and technical preparation, continuous improvements, platform insights, and the importance of always listening to those providing feedback on the experience.

The Story

The Weather Channel’s weather.com, one of the top 20 most trafficked sites in the US, provides millions of people every day with the world's best weather forecasts, content, and data. On average, it serves 15 million page views per day to 30 million unique visitors per month. But when major weather events loom, like a hurricane or nor’easter, the site will serve up to a billion requests a week.

These requests include delivering hundreds of dynamic maps and streaming video to users in over three million forecast locations. The site has to remain stable with instantaneous page loads and 100 percent uptime, despite these bad weather traffic bumps of up to 300 percent.

The Weather Channel’s legacy platform was groaning under this pressure. It was using approximately 144 servers across three data centers to deliver more than 17,000 articles updated on a minute-by-minute basis.
So in November 2014, weather.com moved its entire website, which serves more than 20 million pages of content, to Drupal and the Acquia Platform, facilitated by the experts at Acquia partner MediaCurrent.

Within weeks, one of the nastiest winters on record began moving into the Midwest and Northeastern part of the US. Prodigious web traffic followed.

The new site, now the busiest Drupal site in the world, never buckled. In fact, it thrived, delivering faster, more efficiently cached pages to customers.

“weather.com is thinking ahead to a future where up-to-the-minute weather information requires an open delivery platform that adapts to fast changes in technology,” Tom Erickson, CEO, Acquia, said at the time. “The Weather Channel is leading the transformation of how we interact with weather news; people expect accurate weather forecasts on-demand, and they want to be alerted to events that may impact their life, work, travel, and leisure. weather.com is gaining the agility to deliver on customers’ increasing expectations. It’s leading the charge with contextual weather insight that anticipates every user’s needs.”

A recent global survey of more than 500 businesses for the Reducing Customer Struggle report found that companies are losing nearly a quarter of their annual online revenue due to a bad website experience. That’s billions of dollars lost and customers who won’t come back because of a digital experience that left a bad impression.

Whether you’re a weather site watching traffic rise with the barometric pressure, an enterprise facing transformation in an industry where digital transformation is lacking, or a smaller brand on the cusp of breaking into a new market, your digital presence can’t fail.

Dave Terry, co-founder and partner of client services at Mediacurrent, said, “Acquia opens up all kinds of opportunities for weather.com. The site relies heavily on the ability to quickly create and distribute massive amounts of content, and with Drupal, weather.com gains editorial agility and the ability to innovate and bring the latest applications and features to the user experience.”

Behind the Scenes

When it comes to capacity planning, some organizations plan for a worst-case scenario. They purchase larger-than-necessary capacity to be permanently available. But this is wasted money. Conversely, some organizations under-plan for traffic. Without the means to increase capacity on demand, they suffer outages and, ultimately, loss of revenue.

With Acquia Cloud, the guesswork is eliminated. You only pay for what you need. Acquia Cloud scales with burstable and elastic resources, which can be added quickly and easily on demand. Our operations team can scale up resources for any period of time, and then return resources back to normal levels when traffic subsides.

We know that scaling is complex, so we do the work for you. We add resources in real time to address changing traffic conditions seamlessly when a site needs it most. Scaling on Acquia Cloud does not require risky architectural changes like migrations and resizing. But we do scale the ecosystem, not just the hardware. We scale across all layers of the environment––web servers, file systems, databases, and load balancers. The architecture scales across the MySQL database layer using data replication and the file system layer utilizing GlusterFS to ensure syncing. The web server layer is scaled up by running active web servers in multiple availability zones. We run dedicated Memcached servers for sites with high workloads and multiple load balancers to ensure traffic is distributed. This level of Drupal-aware customization doesn't exist outside of Acquia.

scaling-image.png

As part of the scaling enablement strategy, it is important for customers to have a site insulation strategy so that visitors are not aware of traffic increases. Acquia uses Varnish caching in front of all traffic to speed up sites. Additional features such as geolocation, mobile redirection, and CDN implementation can be enabled. Acquia has over 25 personnel across our Professional Services, Technical Account Management, and Support organizations who specialize in performance, focusing load testing, database query rewriting, stack tracing, and more.

At Acquia, our passion is customer success. Because of that, your site doesn’t become the next headline. Your best day doesn’t become your worst; your biggest events are uneventful behind the scenes. In essence, we don’t sleep, so you can. Our team of experts is on hand 24 hours a day, seven days a week, 365 days a year so that you don’t fail. You get a true partnership with Acquia.

No matter the time of day, or the size of the traffic spike, we have your back. So instead of downtime, your traffic spikes yield growth and success.

photo: NASA Goddard Space Flight Center

Tags:  web platform drupal acquia drupal planet
Categories: Planet Drupal

Drupal is fun to use - meet Karen Grey

April 16, 2015 at 4:49pm
Language Undefined Drupal is more fun - meet Karen Grey

I sat down with Karen Grey at Drupal Camp Brighton 2015 to find out more about who she is and what she does with Drupal. I apologize for taking her out of the code sprints for that time! Since we spoke, Karen has taken on a position as Senior Drupal Developer at i-KOS in their Brighton office.

Categories: Planet Drupal

PHP: The entire world is your development team – Beth Tucker Long

April 8, 2015 at 4:31pm
Language Undefined PHP: The entire world is your development team – Beth Tucker Long

Categories: Planet Drupal

Streamline your local Drupal workflow with Acquia Dev Desktop 2

April 5, 2015 at 11:50pm

Since we introduced the original version of Acquia Dev Desktop, thousands of people have used it to quickly create local Drupal sites on their Mac or Windows PCs. Over the years we have received a lot of great feedback, and so we redesigned Dev Desktop 2 from the ground up, incorporating the most requested improvements. Thousands of users have tried the beta version, and now it's ready for prime time. If you haven't upgraded to the latest Dev Desktop 2, download it now and give it a try. It's free!

What's new in Dev Desktop 2?

  • A streamlined UI makes it easy to work with all your local Drupal sites and their code, database or files from the GUI or the command line.
  • A welcome wizard makes it easy to get started with any Drupal sites including:
  • Built-in Acquia Cloud integration lets you host any of your local sites for free, or sync locally with any of your Acquia Cloud sites. More on this below.
  • The latest xAMP stack components are included including Apache 2.4, MySQL 5.5, as well as PHP 5.6, 5.5, 5.4 and 5.3 so you can easily test your site with multiple PHP versions.
  • Drush 7 is configured to manage all of your Drupal sites via the command line. Click Dev Desktop's terminal icon to start a command line pre-configured with Drush aliases for all your sites.
  • Browse, query and edit your local site's database using phpMyAdmin.
  • Take advantage of Dev Desktop's deep integration with Acquia Cloud to:
    • Host your local sites on Acquia Cloud for free. Dev Desktop takes care of packaging up your Drupal site and importing it. Once there leverage Acquia Cloud's scalability, dev and stage team environments, Git workflow, site tests and more.
    • Synchronize any code, database, or file changes between your sites on Acquia Cloud and your local sites. Easily pull or push your code, database or files between Acquia Cloud and the local site running in Dev Desktop.
    • Add modules to your local file system and then click Push code to add those modules to your Acquia Cloud site and git repository without using Git. Use Git directly for more complex operations.
    • SSH in to your Acquia Cloud environment by clicking the terminal icon. Use drush commands to manage it.
    • When pulling an Acquia Cloud site database locally, use the sanitize checkbox to scrub the local database's user emails and passwords to keep it secure and prevent accidental email blasts while working on your site.
    • Already using Acquia Cloud? Clone any of your Acquia Cloud sites locally to work on them in Dev Desktop and your local toolchain.

And much more

  • Keep up to date with the newest Dev Desktop features and fixes by selecting the Check for updates menu. This is also done automatically when Dev Desktop starts.
  • Take advantage of the command-line installer to script the installation on multiple machines, or embed it as part of another installer that includes your custom Drupal distrobution.
  • Create multiple sites sharing the same codebase using Drupal multi-site.
  • Easily report feature suggestions or issues via the menu Help > Report an issue.

See it in action!

With these improvements Dev Desktop 2 is the fastest way to create Drupal sites on your Mac or Windows PC, and optionally sync them at any time with Acquia Cloud. Download it now, and try it out! There are more great things in the works so be sure to check for updates regularly.

Tags:  dev desktop acquia drupal planet
Categories: Planet Drupal

From Content Strategy to Drupal Site Building: Connecting The Dots with Ronald Ashri

April 1, 2015 at 5:45pm
Language Undefined

Ronald Ashri, former CTO at BlueSpark is now a Founder at Roomify - a Drupal-centric startup focusing on online reservations. Here, Ronald presents an enjoyable and valuable session about content strategy and Drupal, full of practical and actionable advice – worth watching in full for all strategists, site builders, and anyone who wants to know how to build a better content-oriented site.

Categories: Planet Drupal

2014 greatest hits - 30 Awesome Drupal 8 API Functions you Should Already Know - Fredric Mitchell

March 26, 2015 at 9:02pm
Language Undefined

Looking back on 2014, it was a great year of events and conversations with people in and around Acquia, open source, government, and business. I think I could happily repost at least 75% of the podcasts I published in 2014 as "greatest hits," but then we'd never get on to all the cool stuff I have been up to so far in 2015!

Nonetheless, here's one of my favorite recordings from 2014: a terrific session that will help you wrap your head around developing for Drupal 8 and a great conversation with Frederic Mitchell that covered the use of Drupal and open source in government, government decision-making versus corporate decision-making, designing Drupal 7 sites with Drupal 8 in mind, designing sites for the end users and where the maximum business value comes from in your organization, and more!

Categories: Planet Drupal

Behat & BDD: "Deploying better software with confidence" - meet John Bickar

March 18, 2015 at 10:21pm
Language Undefined

While speaking with Melissa Anderson about behavior driven development (BDD) at BADCamp 2014, she suggested I get John Bickar from Stanford Web Services in front of my cameras to talk about his experience during last year's "Drupalgeddon" security vulnerability. The result is this podcast and some great insight into how this kind of testing can significantly improve initial, ongoing, and emergency delivery of software. As John puts it, using BDD means: "delivering better software, delivering it faster, and knowing that it is delivering the value that we have promised to our partners." I would have named this episode of the Acquia Podcast more in the spirit of Dr. Strangelove: "Behat tests mean death to Linky-Clicky or how BDD helped Stanford Web Services recover fast during Drupalgeddon," but reason won out.

Categories: Planet Drupal

Pages