Software

Wrapping up today, Drupalcon Amsterdam created a big buzz around Drupal 8. A crew of over 2,100 participated in sessions, sprints and keynotes, and celebrated the release of the Beta 1 version of Drupal 8.

Sadly all good things must come to an end.   Here at the CiviCRM 2014 Edale Sprint we've been working closely with members of the core team. As well as fixing bugs, working on integrating Google Summer of Code projects, and readying extensions for release, it's been an excellent opportunity for the Future First Software Developers to learn directly from the CiviCRM experts themselves.   In a presentation I showed something that the Future First Software Development Team made recently - a brand new contact screen. It went down a treat, so here's a blog article revealing how we did it!   Background:   Future First is a charity that helps state-funded schools and colleges mobilise their former students for the benefit of their current students. Former students can do this by attending in-school events to inspire current students, by offering mentoring or work experience opportunities, by assisting in fundraising, or even by appearing on a poster displayed in the school!   A key part of Future First's offering is a Teacher Dashboard that teachers can log into to engage with their former students. This mostly involves an extensive search system and a communal inbox. It is built from a combination of Drupal custom modules and CiviCRM custom extensions.   The legacy:   Future First's Teacher Dashboard is a legacy system. Initially a screen was created to allow teachers to view contacts, based off a profile (with a separate screen to edit). Then notes were attached, so that teachers could add, edit, and remove notes about the alumni. When our Mailbox was operational we added each mail send to and from that alumnus to the profile screen too. Afterwards we added the ability to record mobilisations, so they made their way onto the screen as well!   The result was not pretty: an overburdened, messy screen that didn't allow teachers to view or edit all of the information that was being stored by CiviCRM. It was very slow, as all the mobilisations and emails had to be loaded just to add or remove a note. And everything had to be loaded once to view the contact, then again to edit it, and then a third time to see the saved edit.   It was time to start over.    The requirements:   Our main requirements were:  - fast - have only one screen for both editing - neater - view and edit everything - maintainable. Our system is growing rapidly, and the screen should be ready to support that.   The plan:   With three members of staff to work on the project, it needed to be modular. The data was broken into logical categories, and an api and template file was created for each of these. This structure translated directly into the different tabs.   Only the data on the first tab is loaded. When other tabs are clicked AJAX calls the API function for that tab. This retrieves the relevant data, which some jQuery then puts into the appropriate place.   Inline editing was used for each field. This feature, provided by the CiviCRM core, allows our users to view and update data without needing to move between different screens. Sadly, this didn't let us update custom data, so we patched it and offered our patch to the core!   The results:     AttachmentSize contact_screen_1.png86.5 KB contact_screen_2.png69.15 KB contact_screen_3.png97.02 KB contact_screen_4.png65.94 KB

• Drupal
• Extensions

Drupal has immersed all our lives in the web, and the biggest conclusion we can draw from this DrupalCon is that Drupal in particular and we, as creators and consumers of Drupal, are all being rocked to the core by the fast pace of change in the industry. Changes in the development, scope, architecture, process and workforce dynamics prevalent in the development and acquisition of ever-more complex web applications and systems are rocking Drupal too, and the result is a scrambling for solid footing.

The footing we all find, and the journeys we take to find it, will determine our future.

First and foremost we need to come to grips with the debates, with what is shaping up. We need to learn a lot just to fathom the consensus on what the options are now. Then we must prick up courage and make choices.

But one truth is acknowledged by all: there is no simple and straightforward path forward, from here on in we mix and match, we build on an industry-wide workbench to common standards, or we build not at all. There is no more protective balloon, the big blue bubble has burst, or worse, is in the act of bursting now.

But this is not a bad thing. We just need to keep our heads, even if Drupal cannot. If we can drive @eaton's Promiscuous Drupal to its logical limit, if we can Keeping it Simple with @sdboyer we can "bring that knowledge back to the community" no matter what, as @crell guides us through Managing Complexity (be sure to check out his reading list) and the portals decouple, while beset with New Wave PHP, and at every turn: Drupal in the Hip Hop Virtual Machine with the @outlandishjosh.

That's the intoxication of sampling the key presentations from this historic DrupalCon Amsterdam 2014: let's find out what it's all about.

Of course, this is just my own shortlist (grouped by topics, of which, it is worth pointing out, headless is second only to Drupal 8 and way ahead of anything else as a concern), but whether or not I left out any well-deserving items from the list, it's more than enough to be able to say "Wow, we live in interesting times".

Keynote

• Keynote: Dries Buytaert

Drupal 8

• Drupal 8: The Crash Course
• Managing Complexity
• Drupal 8 CMI on Managed Workflow
• Twig and the new Drupal 8 Theme System
• Drupal 8 multilingual hands-on
• Drupal 8 Media

Headless Drupal

• Turbocharging Drupal syndication with Node.JS
• Decoupled Front-end and the Future
• Building Modern Web Applications with Ember.js and Headless Drupal
• A Decoupled Drupal with Silex
• BOF: Zariz & RESTful - We've got your headless covered
  • Video

PHP Renaissance

• Drupal in the Hip Hop Virtual Machine
• New Wave PHP
• OOP For Drupal Developers
• Drupal’s PHP Component Future

Web Dev Future

• Styleguide-Driven Development: The New Web Development
• Distributed Companies are the Future
• Open Source Enterprise Continuous Delivery with "Go"

Drupal 7

• Future-Proof your Drupal 7 site

Check some of these out, we need to talk about this over the next few days.

And in later articles and repos, I will be sharing concrete examples of how I am dealing with all of this, and how I am planning, well, my future.

read more

Episode Number: 171

The Drupal 7 Search Krumo Module extends the Devel module and makes it easier to debug PHP variables while developing Drupal modules or building Drupal themes. It adds a simple search box that allows you to quickly search through the Krumo output that is generated by the dpm function.

If you want to try it out quickly, simply download and install the module and run the following code on the variable you want to debug:

Tags: DrupalDrupal 7Module DevelopmentTheme DevelopmentDrupal PlanetTips and Tricks

Situation

Suppose you build a site, it works great, the client loves it, you launch it, and the client still loves it. Yay! Now life goes on, and six months later, the client comes back to you saying they see a red box when they are logged in, with a message about security updates. You look and see that Drupal core, ctools, rules, views, commerce, date, and a handful of other modules have updates availalbe. Some are security updates, and others are bugfix/feature updates.

So you want to update this code to resolve security issues and improve the functionality of the site. But how can you be sure that these code updates will not hurt or break any of the existing functionality? You could revisit all of your feature work from six months to a year ago and confirm that those features still work as intended. But that can be time consuming and disrupt your other work.

So how do you make updates, whether updating contrib code or doing new custom work, with confidence that you're not breaking essential funcionality and without wasting countless hours doing a bunch of manual testing?

A Better Solution: Automated Testing

Let a machine do it for you. There are several categories of automated testing:

• Unit testing. This tests that a small piece of code, a function, behaves as expected.
• Integration testing. These combine several Unit tests in logical groups, to ensure that they work together properly.
• System testing. This tests the system as a whole, and is mainly code oriented, but starts to touch how real people would use the system.
• Behavioral testing. Acceptance testing. Customer testing. This involves clickthroughs, user behavior. This is what we are mainly interested in, and what I am talking about today. You will also hear this referred to as BDD or Behavior Driven Development.

Enter Behat

Behat is an automated testing system. Its strength is in behavioral testing, so it fits perfectly in our use case.

Behat tests are written in plain English phrases which are then combined into human readable scenarios. This was inspired by Ruby's Cucumber project and Gherkin syntax. This is probably the most appealing aspect of Behat. Most tests are understandable by anyone, whether you're a developer, project manager, or business owner.

Behat is the core framework used for running tests. It is capabable of testing several types of systems: terminal commands, REST APIs, etc. To enable Behat to test web pages, you need to add Mink and a browser emulator to the mix. Mink functions as the connector between Behat and browser emulators, and provides a consistent testing API.

There are several commonly used browser emulators. Some, like Goutte, are very fast, but don't support JavaScript. Others, like Selenium and Firefox, are full-featured browsers, but will run more slowly.

So when you hear people talking about Behat, they're usually talking about all three components: Behat, Mink, and browser emulators.

Why Behat Versus Others?

Mainly becuase of popularity, which comes mainly from its human readability. There are certainly other contenders with other strengths, but we're focusing on Behat today because it is a popular PHP-based testing framework. Its tests are written as human readable scenarios, can be easily extended by writing additional PHP methods, and, as you'll see soon, getting set up is not too difficult.

Business Use

Even though this all seems like a good thing, it does take some time to write tests, set up a testing environment, and determine what the best tests are. We need to allocate time to do this, and it shouldn't just be a surprise at the end of the project. Automated testing should be considered in several phases of a web project. When writing custom code, it's a good practice to write unit tests, and time should be allocated for that. When developing custom features for a site, behavioral tests should be written to accompany them, and again, time should be allocated. It's good if clients know at the beginning of a project that test writing is part of the development process, and test running is part of deployment.

Things that are measured always get more attention than things that just happen. Clients should have a large say in what is measured and tested. As a result, project managers can gain a better insight into priorities of the client and project. By making behavior tests something that is intentionally done, project stakeholders must clarify and prioritize the most important aspects of the site.

Run Tests

Let's use the scenario where we're ensuring that the user login experience is correct. This will verify that the site is up & running, that valid users can log in, and that invalid credentials will not work. Here's a test run, using a local development site:

And it only takes a few seconds to run.

If you run this test after a code update and find that the test fails, you know immediately that something must be fixed before it can be deployed to the production environment.

Write Tests

Behat tests are written in "Feature" files. They're just text files with a .feature extension on the name, instead of .txt or .php. They are usually placed in a "features" directory inside your Behat directory. More on that in the next section.

In the test run above, I was in my project's Behat directory, and ran bin/behat features/loginout.feature. That launches Behat and tells it to run the tests that are in loginout.feature. Here are the entire contents of that file:

Feature: Log in and out of the site. In order to maintain an account As a site visitor I need to log in and out of the site. Scenario: Logs in to the site Given I am on "/" When I follow "Log In" And I fill in "Username" with "admin" And I fill in "Password" with "test" And I press "Log in" Then I should see "Log out" And I should see "My account" Scenario: Logs out of the site Given I am on "/" When I follow "Log In" And I fill in "Username" with "admin" And I fill in "Password" with "test" And I press "Log in" And I follow "Log out" Then I should see "Log in" And I should not see "My account" Scenario: Attempts login with wrong credentials. Given I am on "/" When I follow "Log In" And I fill in "Username" with "badusername" And I fill in "Password" with "boguspass" And I press "Log in" Then I should see "Sorry, unrecognized username or password." And I should not see "My account"

Indentation is only for readability, and has no impact on how the tests are run.

Now let's look at each line and see what each is doing. The first few lines are essentially comments.

Feature: Log in and out of the site.

^ Name of the feature.

In order to maintain an account

^ Benefit.

As a site visitor

^ Role.

I need to log in and out of the site.

^ Feature itself.

Behat tests are written in the form of scenarios, and they comprise the rest of the feature file.

Scenario: Logs in to the site

^ Description of the first scenario.

Given I am on "/"

^ The context. This is the first line that is actually executed. In this case, it will load "/" (the home page) in a browser.

This (a "Given") as well as the next things ("When" and "Then") are each called a "Step."

When I follow "Log In" And I fill in "Username" with "admin" And I fill in "Password" with "test" And I press "Log in"

^ The events that need to happen. When kicks it off. And adds more events. If Behat is unable to do any of these events, the test will fail. I follow "Log In" looks for a link with the text "Log In" and clicks it. I fill in "Username" with "admin" looks for a field with the label of "Username" and types "admin" into it. I press "Log in" looks for button with the text "Log in" and presses it. Pro tip: follow is for clicking links, and press is for buttons on forms.

Then I should see "Log out" And I should see "My account"

^ The desired outcome. Then starts it, and And adds more outcomes. These are the actual tests that need to pass. Other testing frameworks often call these "assertions". I should see "Log out" looks for the text "Log out" anywhere on the page.

The other two scenarios follow the same format, as well as using not to ensure that certain things do not happen.

That's the quick walkthrough of writing scenarios, but you can dig deeper at http://docs.behat.org/en/v2.5/quick_intro.html#define-your-feature and http://docs.behat.org/en/v2.5/guides/1.gherkin.html and find out about other aspects like Scenario Outlines, Backgrounds and Multiline Arguments.

Get Set Up

I've looked at several resources from behat.org and elsewhere, and ended up just having to piece things together to get something that will work. I've consolidated those notes to ease the setup in the future. Behat Installation and Use.

There are a number of dependencies, so the easiest way to handle them all is to let composer do it for you. So install composer if you haven't already. On a mac, using homebrew works great: brew install composer.

Make a Behat directory, either for a project you're working on, or in a generic location. Copy this composer.json file into it. Run composer install, which might take a while. It's installing Behat, Mink, several Mink extensions, and webdriver, which is for Selenium. Then run bin/behat to make sure that Behat is actually available and doing something. You should see something like No scenarios.

Install selenium. This part is optional, if you don't need to test Javascript. Download the latest version of selenium-server-standalone. You'll also need Firefox and a Java runtime installed. If you get output from java -version you should be good.

In your Behat directory, add a features folder if there's not one already, and add a something.feature file to it. You can use this loginout.feature as an example.

The last thing you need is a behat.yml file in your Behat directory. Use this behat.yml as an example, replacing the domain with the site you want to test. Also remove the selenium2 line if you're not using it.

At this point, running bin/behat in your Behat directory should run any tests located in the features directory.

Hopefully, that gets you started on your road to readable automated testing. The best resources I've found are on the behat site. You'll probably be redirected to something like http://docs.behat.org/en/v2.5/. Please leave a comment with your successes or other suggestions. Thanks for reading, and good luck!

Announcing the sprint cards! My team created these cards as a condensed version of the DrupalCon Autsin mentor training. They summraize the top tasks needed for new contributors and coders and can be printed at any local print shop (usually in 12-24h) because we formatted them to be printed on standard business cards. So they are cheap to print and ready when you need them.

These cards have been seen at many Drupal events now and they get a good response wherever they go. The first sprint where they appeared was at the Jersey Shore (thanks again to the NJ team for bringing us there!) and they have since been at camps across North America and now at DrupalCon Amsterdam.

You can find them on our DrupalGive page, or use this handy PDF link.

Printing Specifications

Take this information to your local print shop.

• Business card size (formatted for North America, so 3.5 × 2 inches... in metric that is 88.9 × 50.8mm [you may ask them to "scale" the PDF to your local size])
• cardstock (thick paper)
• matte (not glossy... sometimes people want to write on them)
• double-sided
• color
• "no bleed" (extra cropping not necessary)
• PDF file
• quantity $x (most print shops have a special rate for different quantity, good to ask)

Category: Drupal 8Drupal Planet

You will find often find the less you are allowed to do with a computer the more user friendly it seems. This is hardly a coincidence. You need to make your decisions on how much inconvenience you are willing to take for freedom in computing. The first and most important step is to make these decisions deliberate. Perhaps after the keynote this necessity is clear.

I will detail my choices and my rationale. As Doctorow said, I avoid everything Apple. They have made DRM'd computing mainstream and I do not really want anything to do with them. When work makes me use a Mac (happens) then I use a very old second hand Mac Mini but have plans to switch to a Hackintosh. The best is if you can find a free hand down piece to make sure you are not fueling the Apple ecosystem even indirectly. And, I run OS X 10.7.4 because 10.7.5 comes with Gatekeeper and that software is simply not acceptable because it can limit the computer to only run Apple sanctioned applications. Another possible choice is to refuse work that requires a Mac -- I never claimed to be perfect.

Alas, the above decision makes you use Linux as your primary OS. Mind you: there are no good choices in the OS space. The "classic" Linux problems of laptops not sleeping, wifi, projectors are gone by now. Buying printers need a little care but most work.

Probably you want a smartphone and with the iPhone ruled out that probably means an Android phone. Pick one with an unlockable bootloader and install a custom recovery and a custom ROM. Consider as you install each free app on what are you giving up. I decided that using Google Maps is worth it for me but that's something everyone needs to decide for themselves and that's one of the hardest decisions. Practice healthy paranoia by sniffing your own traffic with tPacketCapture or a similar tool from time to time to make sure you know what's happening on the phone.

Speaking of traffic, make sure you can trust your router: buy one that is compatible with open source firmware and flash one. I was much afraid to make this step because I feared I will get another maintenance and/or stability nightmare but nothing like that occured. These days you can find a few with preinstalled DD-WRT even. If you choose one of these, make sure to email the manufacturer saying you've choosen their device because of the open source firmware. This perhaps will spur them to make more of the same. There are companies that purport open source compatibility but at the same time the small print says installing such violates warranty. Ask them why.

In eReaders, avoid the Kindle. I had a Kindle once -- the Paperwhite screen made me waver -- but no longer. These days I have a Kobo Aura HD for the beautiful screen of it. Make sure your eReader radio is off. Another of those convenience vs freedom decisions -- I very strongly prefer my device and my books being controlled by me and in turn I can suffer plugging the reader in to download a book or four. I recommend buying books from Barnes & Noble because their DRM is super easy to remove. Don't forget to email them thanking for this -- it's understandable they don't have the choice to sell DRM free books but at least they don't use the vile Adobe system many places use. Also, tech books at O'Reilly are DRM free, yay!

Campbell and I presented our session, Coder vs. Themer, Thursday morning and it was a huge success! The gist of the session was this: Campbell and I are both martial artists in addition to Drupalists, and we drew comparisons between our respective martial arts (Ninjitsu and Kung fu) and our respective Drupal roles (coder and themer). Then we both attempted, in real time, to build a Drupal site from a markup. I could only use the theme layer and Campbell could only use the code/module layer. The 302 attendees were more than spectators, they were active participants, cheering us on when we found clever solutions and booing when we took hacky shortcuts! Who won?!

Watch the video (slides with audio) and decide for yourself!!

Later that afternoon we also led a BOF (Birds of a Feather) expanding on our earlier session. We dubbed this follow-up Coder vs. Themer: Fight Club, and in it the attendees are divided into small development teams, each containing at least one coder and one themer. We then challenged them to collaborate and build out mockups. We had the luxury of having Augustin Delaporte and Robert Douglass of Commerce Guys there to provide development servers on their platform.sh hosting platform. All the teams did well and more importantly everyone had fun.

Drupalcon Amsterdam’s closing session always has the big reveal of next year’s European Drupalcon venue, and we were all very excited when it was announced that the 2015 Drupalcon Europe would take place in beautiful Barcelona, Spain on September 21-25. Campbell and I cannot wait and are already planning several new, fun, energetic, and engaging sessions!

Our industry needs a new position. A person whose entire job is owning, directing and overseeing a website. We need a new title for them. I propose we call them Digital Experience Directors. 

The current landscape for smaller companies

At best, people who currently do this work are called Web Master, Site Administrator or Marketing Coordinator—all titles which are low on the political totem pole. At worst (and more commonly), it’s a task tacked on to someone’s job, often forgotten or ignored.

How this hurts companies

Businesses suffer because of this hierarchy. The lack of long-term strategic oversight devalues the investments companies make in websites. Relegating content upkeep to roles without director-level authority creates headless websites. This usually produces sites with:

The biggest news from DrupalCon Amsterdam is the announcement that Drupal 8 is now in Beta. One of the most anticipated features of D8 is the Configuration Management Initiative, which aims to solve the well-known problem of "how do I deploy changes I made in my admin interface?"

We've been involved in this work over the past few years. Our CTO David helped architect the solution, and he and Co-Founder Matt Cheney presented the results in one of the most packed presentations at the Con:

Check out the video of their presentation to see the shape of things to come.

If you want to skip to the magic, it starts at around minute 20 with a live demo.

If you'd like to try this yourself, you can spin up a D8 Beta Site today and see the future of Drupal site development. For those of us who have been watching and waiting on this for years, it's an exciting moment to see that this solution is really going to work.

Blog Categories: EducationEngineeringRelated posts: Pantheon Drupal 8 Development (for free) Tweet

We sold Drupal to the world

(Illustration by Colin Panetta)

Much of the world has standardized on Drupal as their solution for a Content Management System for over a million websites. This is not hard to see. For example, Drupal makes headlines when organizations like NYSE (before merging with ICE) decided to switch to it.

NYSE
“Once we had those sites up and running there was a huge pent up demand for other sites in the company, and we launched 37 more. It was a big task, as some of those websites hold tens of thousands of pages - being highly regulated we are required to post everything we do online.”
- Bob Kerner, NYSE SVP & Chief Digital Officer 2010

“The important thing for us is that we are able to keep a relatively small team of 60 developers”
- Bob Kerner, NYSE SVP & Chief Digital Officer 2010

“We have tons of work to do, but we will rely on Drupal to build our social community.”
- Bob Kerner, NYSE SVP & Chief Digital Officer 2010

- https://www.acquia.com/resources/case-study/nyse-euronext

Another example is NBC Universal.

NBC
“[NBC Universal has] 30 to 40 leading brands, such as Bravo, Syfy, Telemundo.”
- Christopher Herring, Director, Publishing Program, NBC Universal

“We continue to push Drupal as our standard across the company.”
- Rob Gill, Director, Operations, NBC Universal

- http://www.acquia.com/resources/acquia-tv/conference/nbc-universal

One of the most recent large scale pushes to Drupal is well underway at Pfizer. I asked Mike Lamb, Director of Marketing Technology at Pfizer, a few questions about it.

How many Drupal websites are currently in action at Pfizer?
Approx 500 - 

How many people would you say it takes to support these sites?
Easiest to calculate suggesting a core team of 12 and then approx 1 person for every 15 sites, so approx 45 people. That’s to keep the platform running – projects and enhancements is additional.

How many non-Drupal sites will become Drupal sites over the next few years?
I’d say approx 200 migrations per year. Drupal launches are a combination of site migrations and completely new sites.

This is a serious amount of Drupal for one, although a big one, company. I gave this info as a talk at a Drupal Camp in Connecticut, MA. In two years, it will take the total attendance of that camp to support Drupal at Pfizer.

A little closer to home, I asked Gary Parker, Systems Analyst at University of Massachusetts (my alma mater), about it.

How many Drupal websites are currently in action at UMASS?

OIT hosts around 120 production sites.  I believe there are probably another two dozen hosted by various departments managing their own servers.

How many will become Drupal over the next few years?

Given the number of sites currently in development and our rate of growth, I'd expect 30-50 additional Drupal sites within the next year.

These numbers are lower but this is still a lot of Drupal. The holy grail of this type of information, however, is perhaps the growing list of Drupal sites in government. The “list includes embassies, parliaments, governmental portals, police, research centers, ministries/departments, monarchies etc. in more than 150 countries.” Check it out if you haven’t yet. It is awe inspiring.

How did this happen?

A popular answer involves a long list of Drupal’s amazing feature set. But how did that happen? Drupal is not alone. It is just another shining example of a wildly successful open source project. Drupal is to the Content Management System what Linux was for the Operating System. So how do these things happen?

The reason, I think, takes the following points as its premise:

• Open Source software is inherently inclusive and collaborative.
• The vast majority of participation is driven by intrinsic motives for personal growth, relationships, and helping others.
• Participating is an endeavor that creates actual happiness, dedication, and community.
• Open Source thrives to the extent it is shared.

It is fairly straightforward to get involved in open source. Despite current issues with tech culture, the code is available, the tools are collaborative, and the standards are, for the most part, objective. Community develops from solving intrinsically interesting programming problems. This is rewarding not only to the individuals involved, but open source and the world benefits from this collaboration.

Drupal has fostered such a community for itself by being adequately inclusive and collaborative. It is trusted experts, from this community, that are being asked what they recommend be the solution to the Content Management System issue. Across the world, they are saying, “Drupal, hands down.”

It is in this sense that we have effectively sold Drupal to the world. Now, we must stand by our recommendation. We must support it.

With worldwide adoption at the rate and scale we are seeing, there are some challenges that are coming with it. Here are some:

• Are we supporting our solution efficiently?
• Seeming talent shortage
• Team retention
• Recruiting
• Community

Each of these challenges are not unique to Drupal and are painfully experienced across the entire IT industry. Solutions are many and vary significantly between each challenge. Taken one by one, each tell a familiar story.

Are we supporting our solution efficiently?

Drupal is a powerful system with a lot of complexity. It has an infamous learning curve with nearly every Drupal project needing access to an expert a few times in its existence. Are we able to provide the needed level of Drupal support at a sustainable and affordable rate? The number of new Drupal sites is quickly outpacing the number of new Drupal experts. Salaries and rates have been increasing dramatically over the years. Is there a supply and demand issue with supporting Drupal?

A popular response from Drupal experts, “Is this a problem? What’s wrong with being in demand and making a lot of money?” During my survey on this topic, I also got responses like this:

We are basically pretty unhappy about that migration - it almost killed
support for Drupal on this campus, and still might. If we could do it all
over again we'd probably still be on 6.
-Name Withheld - VIP, A Five College Institution

The move from Drupal 6 to Drupal 7 has been very painful for many. Affordable Drupal expertise is rare and in demand, but the show must go on even if it ends horribly at times. It is reasonable to believe that, if this experience were to continue, Drupal would be abandoned.

Seeming talent shortage

Facts on this are popular across the entire computing industry. This one is concise and popular:

Some 1.2 million computing jobs will be available in the US in 2022, yet United States universities will produce only 39 percent of the graduates needed to fill them.
-NCWIT “By the numbers”

With a couple hundred million people out of work worldwide, an industry with an apparent talent shortage should give us pause. If you are a professional in the IT industry, consider this question:

How did you get into your field?

Nearly all answers to this question involve an entertaining tale of happenstance abruptly ending in, “...and that’s how I got into IT.” A popular term for this is, “accidental techie.” Since no career path was chosen, nor specific degree given, the person’s resulting career was accidental. For example, it is not unusual to find an English or Math degree in a Senior Programmer position. To go even further, I don’t find it unreasonable to consider Computer Science degrees in a web developer position as “accidental” in this sense. There is no college course that teaches you how to optimize your local development stack or the importance of limiting rounds of revisions.

I don’t fully agree, however, with the widespread use of this term. I’m sure some people truly do accidentally fall into a career in IT, but the rest end up there by following their heart. The issue is that the paths to entry are confusing, intimidating, and just damn hard for seemingly no good reason. It is not so much that there is a talent shortage as much as the directions in are mostly undefined.

Drupal, it seems, is no exception.

Team retention

If there is a talent shortage, then retention will be a challenge. Many organizations are finding themselves a stepping stone for their employees to reach greener pastures. The big players, with deeper pockets and bigger promises, are harvesting talent from smaller players, leaving the latter’s quality of work inconsistent as they scramble to find and train new talent.

And then there are statistics like this:

56% percent of Women leave IT by mid career
-Harvard Business Review - #10094

Not only are we not producing enough talent to support this industry, but we are driving a staggering portion of it away.

Recruiting

On the question, “What is the biggest recruiting challenge your organization faces?” a Talent Technology 2012 recruitment survey found “Finding good candidates” way out ahead of the pack with, “Filling positions fast,” in close second. Not only can we not find good candidates, but we can’t find them fast enough. There is no surprise here given the discussion so far. 

Community

The last challenge to be considered is us; ourselves. What do we do about this? For challenges so closely related, our solutions tend to be astonishingly specific. What can we do?

Hack Talent Shortage? 

We can’t solve this by staying up late and building a website. And what good will it really do to find a way to pump more people into an industry where a substantial portion are going to leave mid career?

Buy more kegs for the office? 

The people who want more kegs aren’t missing from this equation. The issue is that we’ve hired all the people that are excited by this sort of thing.

Get recruiters access to some NSA backdoors?

Obviously no, but allowing recruiters to be more invasive won’t fix this.

“And, what did you do?” 
-Rita (Nana) Albrecht, My Grandmother (1914-2014)

When I was a kid, my grandmother used to do this thing when I would tell on my sister. I would come running to my grandmother, “She’s annoying me, she’s annoying me, make her stop.” My grandmother would always ask, “And, what did you do?” meaning, what had I done to my sister, which of course I would try to answer, “Nothing…”

She may have just been trying to get the full story but what always stuck with me was, if I just took a look at myself, I could see, I had a role to play in the situation.

So, community, we need to look at ourselves.

Talent Shortage - We need to look at ourselves

Find and support those working to ease entry into this field. Some example organizations (is there a good list somewhere?):

• NCWIT: http://www.ncwit.org/resources/careers
• Anyone doing anything with Scratch: http://scratch.mit.edu/

Here are two examples close to my home:

• CAITE: http://caite.cs.umass.edu/
• NERDs: https://nerdsummit.org

Groups are working hard on this already and they need our support and collaboration. Find and support organizations with goals of increasing student interest in, and preparation for, careers in STEM.

Retention - We need to look at ourselves

Here are some things we can do in our organizations to solve our retention issues:

Manager and Maker schedule distinction (see here)

I’ve seen this change IT company culture drastically for the better. This is a topic all its own, but the basic idea is in recognizing the value in giving your Makers uninterrupted time to complete their work. A Maker is someone who makes something. Writers, Craftsman, Musicians, Painters, and Programmers are examples of Makers. They need schedules with long stretches of uninterrupted time to focus on doing a good job. With this understanding, Managers work to be a distraction buffer, managing incoming issues in order to optimize the experience of the Makers, whose work quality then excels and personal enjoyment increases. Tasks deliver with higher quality resulting in Managers producing overall better projects. Teammates are much less likely to leave a team which works like this.

Consider who your policies and improvements benefit

Team retention means considering everyone. If your policies and improvements tend to focus on a subset of your team, other team members are at risk of increasingly feeling excluded. Not feeling like good fit, they will start to consider your team as a stepping stone to a better situation. A new ping pong table or keg in the office may seem a quick win for smaller homogenous teams but will foster fracturing in better evolved and more realistic situations.

Increase inner company dialog and communication

Have regular conversations about how things are going internally. Work to foster feelings of safety in sharing one’s pain points within the company. It is hard at first but invaluable once people become comfortable with sharing without fear of endangering their job and as people learn to listen without getting defensive. Increasing dialog, increases accountability and alleviates resentments that would otherwise lead to a breakdown in the team. 

Increase inner company transparency

This one is scary for many at first: Work to share more administrative details about the decisions that concern your team. Work to eliminate closed door meetings. Increasing transparency, increases trust, feelings of being trusted and feelings of true belonging to a group. It is also a way to share responsibility and, in that sense, ownership. Bad news is easier for a team to bear, and good news has a greater impact and is more intimate, when the decisions leading up to it were shared.

Make a Company Code of Conduct

Your team may be full of people that feel they don’t need something like this. They may think things like, “if people mistreat me, I’ll just tell them off” or, “we don’t need this because we don’t have a conduct problem.” There is nothing wrong with putting it in writing what is expected and what isn’t tolerated at your company. In fact, doing so means you take it seriously. It means you recognize that people are fallible, don’t always know how to act, and putting it in writing is the first step to actually making an effort to be considerate and accepting of each member of your team. You can be sure this is extremely important to at least a few people on your team, even if they haven’t found a way to express it. Do some research on other Codes of Conduct, it is very worthwhile.

Recruiting - We need to look at ourselves

We saw earlier that the biggest challenge recruiters face in an organization is finding good candidates, and fast enough. We can look at ourselves here and ask, “Who are we attracting?”

Does the organization prioritize things like:

• Beer outings
• Ping pong/Air hockey
• Long hours with big one-time rewards

The first two are examples of things that can feel exclusionary to a good candidate looking for a new team to call home. The last one doesn’t work at all for people with families, for example, and is really only a great thing for very specific individuals having certain responsibilities and not others, like children. Your organization may currently feel on top of the world with those example perks above, but your next great candidates are turning and running away.

We can also ask, “How are we attracting talent?” For example, is the classic intimidating job posting involved?

Consider replacing things like this:

If you think you have the drive and positivity to fill these shoes:

• One
• Million
• Bulletpoints

With things like this:

If you have skills in one of these and are excited by the rest:

• Fewer
• Bulletpoints

Adjustments to our hiring techniques that make them more inviting and less intimidating are essential changes to make. We must also take this further by asking ourselves, “How hard are we looking?”

Consider this fact:

26% of the computing workforce in 2013 were women. 
-NCWIT “By the numbers”

in the context of how you answered this question earlier:

How did you get into your field?

Most of us are having to find our way into IT accidentally, and many of us aren’t finding our way at all. The path to an IT career is currently pretty intimidating and rather obfuscated. It can be very hard to know whether or not you are going in the right direction or even just wasting your time trying.

 

Your next Drupal expert could be hiding beneath a rock of self doubt.

 

Community - We need to look at ourselves

Read the rest here.

Together with Fabian Franz & Marco Molinari from Tag1 Consulting, I had a talk about render caching in Drupal 7 and 8.

Slides: Render caching in Drupal 7 and 8Conference: DrupalCon AmsterdamLocation: Amsterdam, The NetherlandsDate: Oct 1 2014 - 10:45Duration: 45 minutesExtra information: 

See https://amsterdam2014.drupal.org/session/render-caching-drupal-7-and-8.

• WPO
• performance
• Drupal

When approaching new Drupal projects, I’m always excited to listen and learn about the project’s requirements. It’s an occasion to create just the right solution. With a recent project, I took the opportunity to rethink the use of Nodequeue to manage front page content, and instead used the Draggableviews and Custom Publishing Options projects. Before diving into that solution, let’s step through other solutions to manage front page content, so we can undestand the pros and cons of each.

Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!

Notable Documentation Updates

Here are some Community Documentation pages that were updated this past month:

• ruscoe updated several pages of documentation about the Drupal Commerce IATS module. We always love to see contributed module maintainers documenting their modules -- thanks Dan!
• andrisek updated several pages of documentation about the ERPAL CRM system contributed module. In this case, he's not even an official maintainer of the project -- we always love to see community members updating documentation too -- thanks Daniel!
• chrischinchilla went through the Installation Guide and made updates for Drupal 8. That was one of our "Priority" tasks -- thanks Chris!
• Many people updated documentation in preparation for code sprints in Amsterdam, to help new contributors get up to speed quickly. Always a good idea!
• And there were many more updates... see below.

See the DocWG home page for how to contact us, if you'd like to be listed here in our next post!

Thanks for contributing!

Since September 1 (our previous TMIDD post), 229 contributors have made 629 total Drupal.org documentation page revisions, including 2 people that made more than 20 edits (andrisek and realityloop) -- thanks everyone!

In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

Upcoming Events

https://amsterdam2014.drupal.org - DrupalCon Amsterdam - THIS FRIDAY, October 3 - sprint!

http://bogota2015.drupal.org/ - DrupalCon Latin America, Bogotá, Columbia, Feb 10-12, 2015

Report from the Working Group

We're pleased to announce that Antje Lorch (ifrik) has officially joined the Documentation Working Group. She's been a leader of documentation events and has been participating in WG meetings for a while, so it's great to have her officially on board. Welcome Antje!

In our last This Month post, we forgot to report on a couple of our "infrastructure and tools" projects that were completed in August:

• We updated the Documentation Management page (log in to see it): https://www.drupal.org/documentation/manage -- it is wider and has improved columns and filters. Use it to find a page you want to work on!
• We updated the tab navigation for the Community Documentation pages: https://www.drupal.org/documentation

We're currently working on a new project: integrating api.drupal.org results into the Drupal.org search box -- stay tuned for updates on that!

Finally, our next meeting will be October 22nd. We normally meet using Google Hangouts (although last month we met in IRC due to technical difficulties); if you'd like to join us, contact Boris (batigolix).

It has been an interesting week since I wrote part 1 of this blog series. For one, more people have been talking about the <picture> element and that is a good thing because the more we talk about it the more attention is brought to an issue that is due for best practices and standards.

The Problem

Deeson's MD, Tim Deeson, took to the stage at DrupalCon Amsterdam for the panel session 'Life in the fast lane - achieving sustainable growth'.

He was joined by Vesa Palmu from Wunderkraut, Paul Johnson from CTI Digital and Jeff Walpole of Phase2, while Robert Douglass from Commerce Guys expertly chaired it.

The hour-long session addressed a series of issues and challenges faced by Drupal agencies, shops and freelancers when trying to grow their businesses.

With questions from the packed audience and Twitter, there were plenty of interesting discussion points.

Here are our topline takeaways:

1. Why grow for the company?

There are many reasons to grow, but the key one is to deliver success.

But, equally, you need to be sure you want to grow. What's more, there are different kinds of growth: acquisition and organic growth are the two most obvious. But they come with additional risks. Acquisition can prove very disruptive internally and externally with huge organisational shifts that can reverberate for a long time. Organic growth, while more steady, may enable you to optimise but can take a long time with the potential to put a company into a rut while things shift faster around you.

2. Why grow for clients?

The main reason is is to deliver a broad range of services. Why? Because if your clients' businesses grow successfully, so will yours. There's a note of caution: you can hit a point of diminishing return, so as hard as it is, try to find your company's sweet spot. Also don't be an IT elephant. Be agile. This means be large enough to service your clients, but flexible enough to meet the changing demands of your clients' needs.

3. How do you differentiate your business in the market?

There are different approaches to this. One way could be to identify a defining moment which changed your business, for example, when you took on your first major client. Another is to highlight specialisms you have. Whatever your USPs might be, you must tailor them to the right market. Remember it's not always one size fits all.

4. Can you plan growth, or can it just happen?

There are a number of things that will help you grow, but you need to think about budgeting cycles, a defined growth path and a realistic recruitment strategy. Added into the mix are the basics such as making sure you know your products, and sell what you are good at. But before anything, carry out deal evaluation. Be good at turning down work that's not right for you. It takes nerves of steel, but you build credibility.

5. How do you sustain growth?

Be bold. Tell people where you're going and why - be open. You must show cultural leadership by reflecting your values and goals in everything you do. This way you lead from the front line each day, which is critical to maintain growth.

6. What is a risk to growth?

You can look at market influences, shifts in buying patterns and other such external challenges. If you start to lose your culture, then you also risk your growth. If your role as a leader becomes 'just a job', then the alarm bells should start ringing. And if you are failing, face them head-on. Failures are not expensive but hidden failures are.

In summary

• Surround yourself with talented, motivated, engaged people
• Be clear what you want to achieve and why
• Have long term vision, approached with small steps

You can see more on the session at Twitter with #drupalfastlane

Want to learn more?

Come and find us at DrupalCon Amsterdam - we're on Stand 203!

I organised a Birds of a Feather (BoF) session at DrupalCon Amsterdam yesterday to discuss people's experiences of integrating Customer Relation Management (CRM) systems with Drupal.

The draw

It seems like it was a pretty popular topic as 12 people joined in a lively discussion which covered a number of areas.

General integration issues

We shared our experiences about integrating Drupal with remote systems, such as a CRM.

We agreed that writing custom integration modules can be a laborious process and prefer using a module to help with the integration to reduce the effort.

Integration modules

If a specific integration module does not exist then the generic Web Services Client module can be used to integrate to web services and provide Drupal actions based on Rules. For a non-Rules based approach, which requires more development, there is the Web Services Integration Framework.

Edge cases

Integrations also require consideration of edge cases, such as what to do if the remote system is unavailable. For example, should a user still be able to update their details on a Drupal website if the CRM is down for maintenance? If they are, how do you go about synchronising data later?

Possible solutions

These are the solutions we debated:

1. The group was in general agreement that there should only be one repository of 'the truth' and data should not be contained in two systems. In the case of a CRM system, user information should live in the CRM and cache what is needed on the website.

2. If the CRM is down, we agreed on a simple simple solution. Firstly, detect the system is down, switch off the connection to the remote system and display helpful messages if talking to the remote system was required. For example, "Our database is unavailable at present, we are working to correct the problem. Please check back later". The Web Service Integration Framework module takes this approach and protects sites by preventing connections being generated to the remote service if it's unavailable, which in turn prevents slow page loads.

3. More complex strategies are needed if it's critical that the website must be operational if the CRM is down. These include time-stamping requests so the data can be correctly reintegrated when the CRM returns.

Integration platforms

The group then discussed integration platforms.

These are cloud-based solutions which allow a simple mechanism for connecting two systems, such as Mulesoft, bip.io, cloudwork.io and zapier.com.

By integrating your Drupal site with one of these, you can use plugins to pass data straight to your CRM. This means less integration work as many CRMs come with plugins for these platforms already. Also, if you change your CRM provider, it's a simple matter of changing the settings in the cloud interface instead of writing or installing a new integration module on your site.

One disadvantage of using integration platforms is the rather large issue around trust. Afterall, your data will be passing through a cloud-based solution. Also, you rely on the quality of the plugin provided by the platform and custom requirements will still need to be addressed.

You can also setup and run your own integration platform using the Apache Camel project.

API quality

When writing custom integrations, the quality of the CRM's API needs to be considered. Some in the group said SalesForce provides a good mechanism for integration. Salesforce also has a Drupal integration module to help, which is maintained by the helpful people at ThinkShout, one of whom was at the BOF.

CRMs differences

When it comes to CRMs, there is a wide choice of systems available.

Drupal-based products, such as CRM Core and RedHen were discussed. The flexibility of Drupal means these are good starting points for custom CRMs for specific requirements.

Other CRMs provide a reasonable out-of-the-box experience but were generally thought to be more work to customise.

We also discussed Erpal, a complete backend business management solution, combines a CRM and invoicing system aimed at small to medium sized businesses.

As an organisation increases in size, it might need to move its CRM into a separate system, rather than being contained within their website or backend system. If this was the case then the group said it was worth considering larger platforms, such as SalesForce or MS Dynamics.

Finishing up...

There are many options in the CRM space and the BoF group went though many of the benefits and pitfalls.

It's clear that care must be taken when thinking about CRM integration. I advise having a look at what others have done before and which integration modules exist to help you before starting a custom integration.

Category:

• Drupal

During the Q&A with Dries Buytaert at yesterdays keynote I referenced the many unsung heroes of the Drupal community. I would like to shine the spotlight towards one such individual. Serving as the Local Social Media Lead for DrupalCon is necessarily a behind the scenes role however it should not pass without recognition.

Meet Baris Wanschers. With impeccable integrity he has single handedly delivered the social media for DrupalCon Amsterdam. In doing so he has played a major role in the promotional, communication and support activity which has culminated in the largest European DrupalCon ever.

One should not underestimate the time and effort that Baris has poured into performing his role. As global social media lead for the conference I could not manage without bright and dependable volunteers like Baris. In Drupal we are fortunate to have bright people like him to help grow the success of the project.

Thanks Baris.

The BADCast

"Why should I come to BADCamp?" you may be asking. Well, if you can get to San Francisco, one of the biggest and free-est tech events on the calendar awaits you: free training, free food and drink, free summits, free sessions, amazing keynotes (free), a party (entry fee ... probably zero), "fancy coffee", and opportunities galore all await you!