Drupal 8 and Composer can be friends

Introduction

10 years ago (at the end of 2006), Drush appeared to make it easy for Drupal developers to do some common tasks, it wasn’t immediately popular as it was a Command-LIne tool and a lot of people didn’t appreciate the idea, but year after year it’s popularity grew as did its functionality.

By the time Drupal 7 came out it was unimaginable for most developers to build a site without Drush because of the incredible boost they got in their development process and the option of generating a site from a makefile and avoiding the need to add in their project contrib code or risk of people hacking the behaviour of this module and unfortunately this was a common practice.

But Drush with the makefile wasn’t good enough, if they update some module the makefile won’t show any update, sometimes some releases breaks other modules and it wasn’t a clear way to say “I need up to this version of that module”, indeed the whole update process itself wasn’t very automated at all, and it was only useful for download a specific version of a module and with his dependencies (it gets the latest version of them without check if they are compatible)

Drupalcon Baltimore talk & slides

Two weeks ago, I presented our story of rebuilding rednoseday.com on Drupal 8 at DrupalCon Baltimore, Drupal’s largest gathering with an attendance of over 3000!

I talked about our journey of building a product to power all our editorial websites at Comic Relief (see my previous blog post), and focused on three topics: editor experience, automation & streamlining, and using decoupled services.

So far, our product ecosystem proudly powers www.rednoseday.com, and the upcoming Red Nose Day USA Campaign, and we are currently working hard to bring www.comicrelief.com on board as well!

Check out the video of my presentation (audio+slides),

The Power of Digital Storytelling – Part 1

Hey, I’m Leigh. I’m a digital designer at Comic Relief and this is my first post for the Comic Relief Tech Blog! I’ve just started working on a new digital storytelling product and thought it might be interesting to blog our journey, through our processes, what’s working, our challenges etc. In this first post I’ll start by giving a little context to the work.

The story so far

Digital storytelling is a technique we have been using to educate people about the issues that Comic Relief supports. Not only to raise awareness about the problems but also talk about where the money goes and celebrate the progress. We have delivered this through films, personal stories, editorial, case studies, photography, infographics, stats, maps, interactive stories and social media takeovers.

‘The general public’ – how to identify who your users are when your brand is a national treasure

Working at Comic Relief has challenges unlike any I’ve experienced in previous roles at startups or agencies. When working in other roles, I’ve known exactly who our ‘target market’ are, what traits our users have and what we believed their biggest needs were, but how do you identify your core user groups when your brand is a national treasure?

From Drupal 7 to standard PHP development

The pain

In the past we used a Drupal 7 multi-site powering at least 3 different sites at the same time with all our business logic bundled inside of various massive custom modules shared along all the sites and some of them with dependencies of external modules (like Message Broker) and each site was using a different version of these modules.

We were restricted to deploying the work of a large team every one or two weeks. When something broke because of the number of changes we’d just deployed together with everything, we were unable to immediately know the source of the issue and sometimes we had to wait till the next scheduled deployment in order to fix the problem.

We needed to undertake a sanity test of the whole site on every deployment because a simple core update could shut down the whole site or one change in the javascript could break all the apps in one go. Every time we felt like we were delivering a Pandora’s box.

Our first Redis Nose Day

We changed a few of the services that support our apps for Red Nose Day giving pages before the big day this year.

One of the more interesting processes was finding a good solution for all our caches and session data. In many cases, we found a Redis service worked well with our Cloud Foundry apps, especially when data has to be shared.

The move to Redis wasn’t entirely seamless, but it worked well for us on the night, and has taught us lots. This is a quick summary of what we’ve found so far.

Women in tech at Comic Relief

‘A lack of women in technology jobs is not just a problem for women, it’s a problem for the whole sector.’

That’s the conclusion reached by the Tech Partnership and Founders 4 Schools, who recently published research into diversity in the sector. Alarmingly, this research also found that only 17% of technology staff are female. Worse still, fewer than 10% of these women are in leadership positions.

Digital storytelling: The next generation

Kids are my favourite kind of user. I haven’t yet met a user with more honest feedback than a pre-teen. And there’s no shortage of it: they always seem to have a lot to say for themselves!

This year our tech team created Comic Relief’s third version of a digital interactive story for teachers to use in primary school classrooms – and it’s the best one yet (not that I’m a proud Product Manager or anything).

My team are my product: How to develop a high-performing team of product managers (or anyone else)

RND17_lenny_header_large_L_.jpg

In my role as Head of Product at Comic Relief I currently have one overarching goal: to embed Product as a way of working. This is in order for Product to provide value to the organisation and it is underpinned by developing a high-performing team.