SEED FEED

We are very happy to announce that after several months of combined work with Concern Worldwide and Apple we now support Apple Pay via desktop, iPhone, iPad and Apple Watch @ Concern.net!

This was a fascinating endeavour for our team with many requirements spanning both hardware and software.

We now have tools in place for Concern.net donation forms to enable existing donors to make a donation, or increase their regular donations by following a marketing link and press a single button on the form before using their fingerprint to authenticate payment.

There is a famous saying that “The best GUI is no GUI” This ideal is now a tangible possibility.

Stay tuned for further developments as to how you can donate without fuss to one of the world’s leading charities.

Our many thanks to all the teams at SystemSeed, Concern and Apple that helped facilitate this work.

Late last year we blogged about the SystemSeed company trip to Minsk in order to work, bond and be merry. Each were achieved in equal degrees and we came away with revitalised enthusiasm for our work and a shift in what exactly that work would contain.

I’m happy to announce today a turning point at SystemSeed where we will begin to offer service beyond solely Drupal development. For the past 7 years+ we have branded ourselves as Drupal Enthusiasts™ but times change and we must all keep up, not with trends but an ever-moving landscape.

Drupal+

From Nov 2016 we have been developing with ReactJS and NodeJS as well as Drupal backend micro-services on internal projects. From Feb 2017 we starting rolling our this new stack to client projects that will benefit from it.

We aim to provide much of this work back the open source communities through Drupal.org and through our SystemSeed Github account in order to help support others who wish to benefit from this code and allow others to support us in our move to embrace the latest, greatest technologies.

Our first client project to embrace this change will include:

New and exciting payment methods! :O

API-first micro-services across the backend.

Public accessible API design as standard, for public consumption as the client permits.

Fully decoupled ReactJS & NodeJS frontend GUIs.

API versioning. Eg, the ability to turn on site upgrades per micro-service between separate sites running the same distribution (note - not distro-wide upgrades, but a custom mix of individual micro-service upgrades) 

Health Monitoring dashboards as standard checking:

All micro-services.

All regression and unit tests (live and multi-dev)

Admin UX discovery to drive intuitive CRUD of systems data.

Enhanced Devops (per multi-dev build)

Automated high % test coverage of all code written

Automated documentation for code

Automated security checks within CI 

Automated open source upgrade checks within CI

Automated performance checks within CI

High sensitivity alerts to cover downtime or performance issues

This really is just the tip of the iceberg and as we open source our new toolset we’ll give a deeper insight into what strategy was followed and how everyone may benefit from this work.

Startups and products can move faster than agencies that serve clients as there is no feedback loops and manual QA steps by an external authority that can halt a build going live.

One of the roundtable discussions that popped up this week while we’re all in Minsk is that agencies which practice Agile transparently as SystemSeed do see a common trade-off. CI/CD (Continuous Integration / Continuous Deployment) isn’t quite possible as long as you have manual QA and that lead time baked-in.

Non-Agile (or “Waterfall”) agencies can potentially supply work faster but without any insight by the client, inevitably then needing change requests which I’ve always visualised as the false economy of Waterfall as demonstrated here: 

Would the client prefer Waterfall+change requests and being kept in the dark throughout the development but all work is potentially delivered faster (and never in the final state), or would they prefer full transparency, having to check all story details, QA and sign off as well as multi-stakeholder oversight... in short - it can get complicated.

CI and CD isn’t truly possible when a manual review step is mandatory. Today we maintain a thorough manual QA by ourselves and our clients before deploy using a “standard” (feature branch -> dev -> stage -> production) devops process, where manual QA and automated test suites occur both at the feature branch level and just before deployment (Stage). Pantheon provides this hosting infrastructure and makes this simple as visualised below:

This week we brainstormed Blue & Green live environments which may allow for full Continuous Integration whereby deploys are automated whenever scripted tests pass, specifically without manual client sign off. What this does is add a fully live clone of the Production environment to the chain whereby new changes are always deployed out to the clone of live and at any time the system can be switched from pointing at the “Green” production environment, to the “Blue” clone or back again.

Assuming typical rollbacks are simple and databases are either in sync or both Green and Blue codebases link to a single DB, then this theory is well supported and could well be the future of devops. Especially when deploys are best made “immediately” and not the next morning or in times of low traffic.

In this case clients would be approving work already deployed to a production-ready environment which will be switched to as soon as their manual QA step is completed.

If you haven’t noticed from our Twitter feed this week we’ve flown the team to Minsk in Belarus to socialise, eat, drink and be merry while maybe taking in a little culture and even some work(!)

One of the first things that we all notice when the team get together is you can’t hug someone over Skype... you can’t make the other person a cup of tea, or complain about the same weather.

While distributed teams can pick the world’s finest global talent as far as timezones and personal or client flexibility allows, meeting in person is a necessary task to undertake on a regular basis. It’s not essential that everyday is spent this way and removing the ability to choose from only your local talent, or those willing to relocate is not the most sensible choice in our modern era of collaborative tools and communication methods. We’d still much rather be distributed but greatly appreciate these times together.

We’ll continue to blog through the week and Tweet some extras as they are happening.

From all of us in our temporary Minsk HQ - have a fun and productive day and if you are sat next to a colleague give them a hug or make them a cup of tea. Not all teams can enjoy this luxury every day of their work life.

Handling clients with more than one site involves lots of decisions. And yet, it can sometimes seem like ultimately all that doesn't matter a hill of beans to the end-user, the site visitor. They won't care whether you use Domain module, multi-site, separate sites with common codebase, and so on. Because most people don't notice what's in their URL bar. They want ease of login, and ease of navigation. That translates into things such as the single sign-on that drupal.org uses, and common menus and headers, and also site search: they don’t care that it’s actually sites search, plural, they just want to find stuff.

For the University of North Carolina, who have a network of sites running on a range of different platforms, a unified search system was a key way of giving visitors the experience of a cohesive whole. The hub site, an existing Drupal 7 installation, needed to provide search results from across the whole family of sites.

This presented a few challenges. Naturally, we turned to Apache Solr. Hitherto, I've always considered Solr to be some sort of black magic, from the way in which it requires its own separate server (http not good enough for you?) to the mysteries of its configuration (both Drupal modules that integrate with it require you to dump a bunch of configuration files into your Solr installation). But Solr excels at what it sets out to do, and the Drupal modules around it are now mature enough that things just work out of the box. Even better, Search API module allows you to plug in a different search back-end, so you can develop locally using Drupal's own database as your search provider, with the intention of plugging it all into Solr when you deploy to servers.

One possible setup would have been to have the various sites each send their data into Solr directly. However, with the Pantheon platform this didn't look to be possible: in order to achieve close integration between Drupal and Solr, Pantheon locks down your Solr instance.  That left talking to Solr via Drupal.

SearchAPI lets you define different datasources for your search data, and comes with one for each entity type on your site. In a datasource handler class, you can define how the datasource gets a list of IDs of things to index, and how it gets the content. So writing a custom datasource was one possibility.

Enter the next problem: the external sites we needed to index only exposed their content to us in one format: RSS. In theory, you could have a Search API datasource which pulls in data from an RSS feed. But then you need to write a SearchAPI datasource class which knows how to parse RSS and extract the fields from it.  That sounded like we’d be reinventing Feeds, so we turned to that to see what we could do with it. Feeds normally saves data into Drupal entities, but maybe (we thought) there was a way to have the data be passed into SearchAPI for indexing, by writing a custom Feeds plugin?  However, we found we had a funny problem of the sort that you don’t consider the existence of until you stumble on it: Feeds works on cron runs, pulling in data from a remote source and saving it into Drupal somehow. But SearchAPI also works on cron runs, pulling data in, usually entities. How do you get two processes to communicate when they both want to be the active participant?

With time pressing, we took the simple option: we defined a custom entity type for Feeds to put its data into, and SearchAPI to read its data from. (We could have just used a node type, but then there would have been an ongoing burden of needing to ensure that type was excluded from any kind of interaction with nodes.)

Essentially, this custom entity type acted like a bucket: Feeds dumps data in, SearchAPI picks data out. As solutions go, not the most massively elegant, at first glance. But if you think about it, if we had gone down the route of SearchAPI fetching from RSS directly, then re-indexing would have been a really lengthy process, and could have had consequences for the performance of the sites whose content was being slurped up. A sensible approach would then have been to implement some sort of caching on our server, either of the RSS feeds as files, or the processed RSS data. And suddenly our custom entity bucket system doesn’t look so inelegant after all: it’s basically a cache that both Feeds and SearchAPI can talk to easily.

There were a few pitfalls. With Search API, our search index needed to work on two entity types (nodes and the custom bucket entities), and while Search API on Drupal 7 allows this, its multiple entity type datasource handler had a few issues we needed to iron out or learn to live with.

The good news though is that the Drupal 8 version of Search API has the concept of multi-entity type search indexes at its core, rather than as a side feature: every index can handle multiple entity types, and there’s no such thing as a datasource for a single entity type.  With Feeds, we found that not all the configuration is exportable to Features for easy deployment. Everything about parsing the RSS feed into entities can be exported, except the actual URL, which is a separate piece of setup and not exportable. So we had to add a hook_updateN() to take care of setting that up.

The end result though was a site search that seamlessly returns results from multiple sites, allowing users to work with a network of disparate sites built on different technologies as if they were all the same thing. Which is what they were probably thinking they were all along anyway.

Here’s our quick overview of the second day at DrupalCon Barcelona.

KeyNote Designers and developers learn plenty of best practices and techniques to get the most out of their websites. From A/B testing to Heat Maps we constantly progress through a course of combined understanding as to how to build the best possible site.

We have come to know more than just basic layout strategies in combination with good information architecture. We now know that the users of the web are affected by basic, general psychology just as in the real world.

Yesterday’s keynote from Nathalie Nahai explained just this.

Firstly, we are more primal than we acknowledge. Sex sells and we all know it. The use of strong colours such as red, taps into important parts of the brain that initiate fight, flight, or arousal. Designers need to research appropriate use of colour from people like Karen Haller.

Faces, body language, positive affirmation and storytelling all engage users successfully also. This is due to emotional responses rather than rational ones.

Although there are users that want to be rational, however unnatural that is for us as emotionally led creatures. This audience want to be given hard facts, feature lists backed up with tick symbols, and an array of details uninteresting to the purely emotive audience. That audience often uses social affirmation to confirm and feel good about decision making (asking experts in your personal network for advice). A practical plan for this expected behaviour is to show personal recommendations in the way that Google Maps shows your friends ratings first.

Here are the slides from the session: http://t.co/t8FyyBUtal

Dev Sessions

It’s pretty hard to do objective мodules comparison but we all love it. Webform vs. Entityform is a very well done comparison of form building modules in Drupal. In some cases, Webform is the only choice, but the Entityform module is definitely the future.

“Making Drupal fly” was one of the most awaited Wednesday sessions. Drupal 8 has brand new cache layer with its contexts, tags and cache keys. During the session, Fabian and Wim explained how Drupal 8 cache works, compared it to Drupal 7 and mentioned a couple of pitfalls we should be aware of.

What we really love about Drupalcon is that it's not limited to Drupal itself. You can learn about dozens of new technologies from one session. “Drupal Extreme Scaling” by Zequi Vazquez is a good example. Apache Mesos, Marathon, Zookeeper, Chronos, Docker,  Ansible, Amazon S3/EC2, Node.JS, PostMark, NewRelic... and Drupal. It's an incomplete list of tools used to run 100k-sites multisite Drupal installation. It's real extreme!

Another great non-Drupal session was given by Andreu Balius,  a type designer from Barcelona. Fonts are important. Even if you're a total geek you should know that the code written in Courier is very different from the code written in Consolas. Seriously, typography is considered to be one of the most important parts of web design. Andreu used a lot of great metaphors to explain aesthetic and emotional values of different fonts. “What's your type?” video is already online.

Agile Estimating & Planning

Bluespark’s own Ashleigh Thevenet spoke to the client management portion of DrupalCon attendees about Agile. This is such a common way to develop recently,  with the facts firmly in support of Agile when compared to waterfall. However, clients may still see it as vague, risky or too involved. The truth does not reflect these worries but it’s important to explain why.

Firstly, you will have to expect that not all client will want to work this way. If you are not at all open to working in a waterfall way and the client cannot agree to the terms of Agile, then the relationship will not work. It’s important to set your own expectations in this way.

Budgets are often run through several stages internally and have a rationale of their own. This may not be something you can challenge and so if a fixed cap of an Agile project is given, this must result in a flexible scope.

As is common at SystemSeed this is best handled by regular sprint planning calls where we:

Report on the status of the budget burn vs story points burn in the project as a whole (knowing that we have an all-important fixed cap budget to fall within by the close)

Constantly check the client priorities in the Product Backlog, having them decide what to move to the top of the list or out to a future phase. Create “buy in” from the client.

Review the projections. How much is still possible within the fixed budget? On reflection, sometimes the budget can be extended after all!

Client management is key so be transparent and help explain where uncertainties lie early on. It should be understood that any estimations (also to be called “fortune telling!”) should be taken with a healthy pinch of salt. +/- 40% is reasonable before the picture becomes clearer.

At SystemSeed we tend to offer deep dive investigations to help gather details and clarify this for our clients. This usually slims down margins to +/- 20 or 30% and by beginning of the development you should aim to be around +/- 10-15% certainty. This will obviously still change according to any scope creep if that happens throughout the project.

One great suggestion in this talk was the suggestion that in the initial planning phase sketches be drawn up by a UX expert. These shouldn’t be full wireframes but just the basics. Having UX talent on staff allows you to listen, convey options and risks while helping manage expectations from the beginning.

When doesn’t this work?

Client providing the UX

Time & Materials projects don’t need every step like this.

Disadvantages:

Needs client buy in

Planning meetings can be hard to schedule. Clients can be disinterested in the process.

Watch the session here:

Here’s our quick overview of the first day at DrupalCon Barcelona.

PreNote & KeyNote

We didn’t make it to the PreNote as it was crazy early for the laid back city to accept, but the KeyNote Dries gave was very honest about Drupal’s current obstacles.

“We should talk about that”

Was the mantra for the issues the community will face in the upcoming Drupal 8 adoption and subsequent migrations. It’s refreshing to have such critical reflection on our own projects. We shouldn’t pat ourselves for our successes but instead focus on where we need to improve.

Catch the KeyNote slides here: http://acquia.slides.com/drupalcon/driesnote2015/fullscreen#/

Sessions

Our team hit up the coffee stands and then got straight into the sessions.

The variety of DrupalCon sessions is such that every level of experience can gain value. This also applies to varying disciplines - developers, managers and salespeople alike can all take something away.

Agile Several sessions today focused on Agile development, planning and sales. This has become such a hotbed for delivering projects with greater success there is no surprise that it features largely here at DrupalCon.

Scrum is the big methodology discussed. Keep It Simple Stupid (KISS) is the standard when starting off or talking to “classical” clients. Introduce those clients to Agile slowly and build on it.

Also discussed was RFPs and how to get new business when selling an alternative to the classical approach. The main answer is to explain the major pitfalls of Waterfall (inevitable changes, change requests and added costs, project delivery is disappointing eyc), then counter with how Agile aims to solve each of these. You may not be able to submit proposals to very strict RFPs, but those clients that agree to an initial, paid “deep dive investigation” will allow to sort those clients that you will enjoy working with from those you may not. Drupal & CDNs Drupal 8 can do some pretty interesting things with media handling and page loading using cache tags and cloudflare.

I’ll let the video walkthrough speak for itself (note: this is from an advanced session):

https://www.youtube.com/watch?v=AAcChiYo0q8&feature=youtu.be Drupal 8 Drupal 8 is mentioned literally at every session. If you are new to Drupal 8, we recommend a session ”Altering, Extending, and Enhancing Drupal 8” as an architectural overview of the system for developers. After watching a session video you will have a good understanding of plugins, services, events and hooks in Drupal 8. Next, you can check out more specific sessions for any taste from Dependency Injection to Rules to Twig.

Drupal in 2020

SystemSeed have donned our sunglasses and headed to the wonderful city of #Barcelona along with a few thousand other Drupal enthusiasts for DrupalCon 2015.

Coinciding with the conference’s dates is the city’s incredible La Merce (or “Fiesta Major”) festival - a huge event that spans all neighbourhoods (or ”barrios”) where you can expect the whole city to be celebrating.

If you are going to be in the city for DrupalCon or for La Merce, check out our guide on how to get around the city and what do while you’re here.

#Transport

Arriving at El Prat? Outside the Airport terminal is the Aerobus. This will take you from the terminal to Placa Catalunya. This bus will cost €5 and from the placa you can get a taxi to your hotel for about €5-10 more. This is much cheaper than getting a €30-35 taxi from the airport.

The city is well connected by a metro system as well as taxis. Metros are the easiest and cheapest way to travel. You can buy a metro pass "T10" which will give you 10 trips for less than €10. These are available at any metro station. Metro trains arrive at the platform every 5mins so there is never a long wait.

From Sunday to Thursday the Metro closes at midnight. After this we’d advise getting a taxi if you are going through a rough area.

Friday night the metro closes at 3am. Saturday it runs 24hrs.

Taxis generally cost €10-15 to get almost anywhere in the city and the costs go up slightly at night.

#Safety

Barcelona is a very safe city. There is very low violent crime although the central tourist areas and the central beaches have a lot of pickpockets.

It's advised to stay with at least one person after midnight in the central neighbourhoods such as Gotic or Raval. When going to the beach do not take anything valuable unless you can look after it at all times.

#Beaches

The city centre beaches are nice to check out the city's tourists and vibrant locals coming together enjoying lots of beach bars ("chiringuitos"), and lots of activities.

If you are hiring a bike we recommend cycling along the beach and getting a sense of geography as well as taking in the sights. Don’t forgot to check out Frank Gehry’s whale at Port Olimpic.

The quality of the sea in the central beaches is not great. There is usually some rubbish in it. If you specifically want a "beach day" we recommend going north just past Port Olympic. After this the beaches are less crowded and the sea a little cleaner.

Also, if you get a train (rather than a metro) you can get to some great, quiet beaches up the cost in just ~30mins. The train runs all the way up the coast.

#Weather

Spring and summer is HOT in Spain, and Barcelona is no exception. The weather the past week has been 20-30 degrees each day. The weeks of Drupalcon are expected to be the same.

Remember your sun cream if you go out for a long day as not everywhere is shaded. People do get heat stroke or become dehydrated. There are many free water fountains in the city and around the beaches and forest trails if you need to keep topped up.

#Attire

Summer weather requires summer clothing. You can leave all your sweaters and hoodies at home - or maybe just bring a single warm item if you are going out all night as the temperatures can drop to a chilly 10-12 degrees at that time.

Bring whatever you feel comfortable wearing for the trip but bear in mind that some nicer establishments will refuse entry if you are in Bermuda shorts and baseball caps. It is also illegal to be topless off the beach (that is for both boys and girls).

Loose fitting cotton clothes are likely best. Also short trousers / short sleeve shirts, or skirts and dresses for the ladies.

The city is very bohemian and the fashion is best described as a scale of “dirty hippy up to posh hippies”. The city’s people are very stylish. It’s not Milan, but it’s not far off!

#Activities

Boat trips, cycling, Sagrada Familia, La Merce, Castellers - the city has a lot to offer.

If you want to see Sagrada Familia, book online and avoid the inevitable 2-3hr queue outside the ticket office. Turn up at your correct time and walk straight in.

La Merce is expected to gather the city’s 2 million people together with all the extra tourists that come to witness the event. Every Barrio will be doing something, there will be stages set up in some placas and there will be a selection of things to see and do.

The Castellers (human castles) are a Catalan tradition and amazing to see. You will be praying they don’t fall when you see the children climbing to the top while their parents are at the bottom supporting them.

#Eating+Drinking

“Menu del Dia” = The daily menu, is 3 courses (starter, main and dessert) and is available at lunch time from most restaurants for around €10-15. This usually comes with beer, wine or water and sometimes coffee as well.

Cafes or cheaper restaurants cost from €8-15 for a cheap meal or to take away.

Menu del Dia is not available in the evening and the prices are higher than in the day. Some restaurants don’t allow you to book, others do. Expect to pay €12-25 per main dish depending on how posh the restaurant is.

Drinks can also be from €1-2 for a basic small beer, to €12-15 for a posh whisky or cocktail in a nice bar/hotel terrace.

People sell “street beers” at night in the tourist areas. They are always a euro for a can, but they get stored in the sewers to avoid the police seeing them!

#Wining+Dining

Because the city is so fun there will be a lot of wining and dining to be done. Here is our favourites shortlist of generally great places:

Restaurants

El Asador De Aranda (Lamb restaurant, Avenida Tibidabo, 31)

Bangkok cafe (Les Corts, near Camp Nou)

Samsara (Gracia)

Da Greco (Posh-but-cheap Italian in Gracia)

La Bodegueta de Provença (Eixample)

Xemei (Poble Sec)

Lolita (Between Poble-sec & Raval)

Doble Zero (Born)

La Paradeta Fish Market (Born)

One Ocean (Barceloneta port)

Bestial (Port Olympic)

El Pescadors (Poble Nou)

Can Recasens (Poble Nou)

Bars

Old Fashioned (Lower Gracia)

Gatsby (Upper Eixample)

Boca Chica (Eixample)

Chéri (Upper Eixample)

BierCaB (Lower Eixample)

Belchica (Lower Eixample)

Milano Cocktail Bar (P/ Cat)

Mandarin Oriental (Passeig de Gracia)

Moritz factory (Sant Antoni)

Mau Mau (Poble Sec)

Ocana (Gotic)

Sub Rosa Cocktail bar (Gotic)

Pipa Bar - aka “Secret bar” (Gotic)

Llamba (Born)

Can Paixano (Barceloneta / Born / Gotic)

Tapas & Cafes

Quimet Quimet (Poble Sec)

Vaso del Oro (Barceloneta)

Manso Cafe (Raval / Poble Sec)

El Nacional (Passeig de Gracia)

Gatsby (late bar / burlesque / “pico”)

Kiosko Burgers (Lower Born / Barceloneta)

Roof bars

Hotel Royal (Passeig de Gracia)

Majestic Hotel (Passeig de Gracia)

Cotton House (Eixample)

Hotel Omm (Eixample)

Pulitzer Hotel (P/ Cat)

1898 (Las Ramblas)

Museu d'Història de Catalunya (Barceloneta)

A special note:

SystemSeed, a multinational Drupal agency is once again growing! Because this role is so critical to the team, we would like to leave no stone unturned. Also, because every one of our team members is critical to the success of the team as a whole, we are doing something different.

At SystemSeed, we have always been a completely distributed team - enabling our teammates to do their best work from anywhere in the world. We've found that sort of flexibility helps people explore their ambitions, whether that be career development, personal development, or simply seeing the world without letting their "job" get in the way.

That is why we have decided to literally pay our staff to move to that dream destination that they always wanted to live in. We are making this financial commitment because the type of loyalty we want to build with our team requires trust and it requires a give and take relationship. We have simply decided to go first in the giving department.

Starting with our Senior Drupal Developer position outlined below, we are now offering to pay a relocation allowance so that they can pursue personal growth along with career growth. Is there a caveat to the offer? Yes, the relocation needs to be within +/-2 hours of Greenwich Mean Time (GMT). This is important to ensure there is ample overlap with the entire team to enable us to best serve our clients. But hopefully joining SystemSeed will now become a significant opportunity for more reason than one.

Now onto the opportunity:

We are currently looking for a rock star full stack Drupal developer with frontend specialist skillsets.

In summary, we are seeking:

GMT(+2hrs max) based

Fluent English speaking

Senior Drupal developer talent (5+ years)

with a focus on front-end, UX, theming

who is familiar with Grunt, LESS, SASS, CSS, HTML, JavaScript

We would like someone with:

backend knowledge to a reasonable level for seamless handoff and integration with the broader range of component parts

experience in Drupal Commerce

a portfolio of greyscaling, wireframing, Photoshop and concept work using standard grids

conscientious of responsive web design, cross-browser development and performance

We can help train you in the following (wherever necessary):

Scrum / Agile development methodology

Pantheon, CircleCI, Drush, etc.

Drupal distribution creation and maintenance

Continuous Integration methods and practice

{insert your desired skillset or technology} - Yes, we will help continue your personal growth. Understanding your personal career goals is important to SystemSeed, and we make it our goal to help you build your own personal value.

If any of this has piqued your interest, read on - what else can we offer you..?

Become part of a genuinely vibrant, energetic and friendly team.

Paid vacation and public holiday recognition.

Competitive compensation.

Fully distributed team. Work wherever. Make that move to your dream destination! (AND GET PAID TO DO IT!)

A puppy (edit: I've been informed I cannot give away puppies)

Please note: We currently only have openings for in-house staff. We appreciate the interest by recruiting agencies, but we are not accepting resumes/cv's from recruiters at this time. Also, we must hire within the GMT timezone (+/- 2hrs). Far eastern and US candidates need not apply for this particular role, but that could change in the future.

Check out our case studies and what we have committed back to the community.

Do these household names belong on your personal portfolio too?

We're a distributed development agency so our staff are located across the globe, each bringing their unique skills and culture together culminating in our excellent team.

We rely on tools that help make our communication as easy and pleasant as possible, as that communication is paramount to a successful distributed team.

For the past few years we have used Campfire as a central chatroom (mainly internal) along with Skype when we talk to clients and most recentlyHangouts for all our Scrum events. We like to see each other's faces on Hangouts and it helps us to sense how a conversation is being received by a client when using video rather than just audio or written text.

Basically Campfire was our rock. We spent all day every day logged in and through a single, central chatroom we could observe notifications from all integrated services (Github, Pivotal Tracker, Zendesk, Selenium, CircleCI etc etc) as well as have transparent exposure to the chatter amongst the team whether it was work-related or how their new offspring were developing (congratulations again Jacinto & Rob!)

We were happy using Campfire but we'd have certain issues with it too.

Campfire is primarily web-based and didn't have the best interface. Switching between chatrooms felt clunky and so we'd have a tab open for each room, and it was unusable on a mobile using a browser. The desktop notifications were pretty shoddy and unreliable for those in the team using the Chrome extension. Any attempts to overcome these hurdles were met with demands for payment either for OSX widgets or mobile apps. We weren't satisfied.

Our distributed team got together last week in Amsterdam for the DrupalCon and with that bonding came free and open discussion about what we could change within the business to help the devs do their job or better an aspect to the company workflow where it was not yet perfected. After numerous mentions of Slack and how dev teams always experiment with new tools that come about we thought it was worth playing with and seeing what it could do.

And - as the phrase goes:

"So yeah, we tried Slack..."

And that was it. We tried it. We liked it. We showed our devs how the combo of client project chatrooms and private DMs were great for letting us cover all communication in one place rather than searching separately for Skype chats or Campfire chats to no avail…

It integrates with all the tools we used and the setup of each was trivial - a completely no brainer yours truly accomplished within a morning and with time for a 2nd coffee.

So that was it. We'd set it up, shown our guys, they loved it as much as us. The familiar phrases from Amsterdam became programmed into the SlackBot and the team agreed we could shut the Campfire tabs. Later the same day we had imported our Campfire history and were ready to shut it down. It was that simple a decision.

The web interface, the OSX app and the mobile app are all equally great and with a very simple and intuitive UI.

As another blogger mentioned - the notifications system is "intelligent" in that it will give you a pop up on the desktop (with / without a noise as you define) and if you don't see it within a certain amount of time it will email to tell you about it. Likewise if you see the notification your mobile instead of your desktop then it will no longer display on the desktop.

The integration tools also allow for specific detail to come through as well. You can drag and drop files to upload them (which Slack will index the content of to help with your searches later) and if you start integrating certain tools you can access them using the slash (/) commands. We can now type /hangout and a Google Hangout will start for us. Bliss!

I could go on, but to really understand and appreciate it's greatness you just have to try it. It's free and if you have any sort of chatroom / IRC / DM setup currently, just have 1 person start it up and invite the others, I am guess that like us, you'll just start using it straight away. By the end of the day you'll be asking "What was that other tool again? Meh - delete it."

The world can often seem to rush by and if you don’t stop to smell the roses you can miss it.

In the coming months we at SystemSeed will be “going back to our roots” so to speak and attending DrupalCon Amsterdam from September 29th to Oct 3rd.

We hope to meet like-minded techies (and possibly the next SystemSeed employee), the next incredible minds on stage giving presentations and the busy bees working away in the Birds of a Feather groups.

When working for clients you love, the primary objective is to go above and beyond, enrich the relationship and deliver something you are both truly proud of.

Well we love working with Concern Worldwide and have just launched the latest iteration of their website we built in Drupal 7 just a short time ago.

Concern have a strict budget to stick to as they know donors want as much of their donation to reach the people in those most disastrous situations around the world. They currently manage to do all of their amazing work with only 9.1% of income to cover staff costs, marketing, IT, legal and accounting needs and much more. Without the investment in these areas they simply could not do what they strive to achieve - making the world a better place.

Everyone and their grandad now has a smartphone and we love them to bits. People feel genuinely attached to their digital devices and lost without them. That is why it was so essential for Concern to tap into the mobile user experience. It was a simple choice to invest a small amount of resources to aid in raising the most amount of money possible for the charity, giving them a very positive Return On Investment in the process.

As the site had already been built with Drupal and used a flexible parent theme at the core of it’s frontend, we knew this was a great premise to achieve an enhanced mobile user experience and allow Concern to engage with their audience wherever and whenever they had their devices with them.

Their site now supports both tablet and mobile users in their own unique ways, has a revised signup process for joining fundraising events on Show Your Concern.

If you are interested in this case study please head over to Drupal.org where this has been published. You can also download a copy from us here.

You may have heard the saying, "Surround yourself with the best people you can find." It's a quote from President Reagan in 1986, which is fairly intuitive until you dissect those words. Having founded and co-founded a few businesses, I find myself constantly challenging the idea of who the best are that I can surround myself with as our teams take on real business needs.

As I sit back and evaluate those individuals I have surrounded myself with in the past, the one constant with those who I consider "the best" is high character. It may seem like a no-brainer to insinuate that high character is important, but unfortunately many don't seem to put as much weight on character as they do other measuring sticks. Give me a high character, hard-working teammate who is eager to learn and wants to create value all day long. You'd be surprised how few and far between these types of individuals are. When you find them, you fight for them.

You can learn how to write clean code, build flawless API integration, or target and convert contextual consumers in social media... You CANNOT learn character. You either have it or you don't - and only those who have it can build on that character through the experiences they are afforded and willingly learn from.

"Be more concerned with your character than your reputation, because your character is what you really are, while your reputation is merely what others think you are." - John Wooden

If you hadn't heard on Twitter or our Facebook page, our very own Tom Kirkpatrick (SystemSeed's co-founder and rockstar developer) will be appearing on the Modules Unraveled podcast today at 4pm GMT.

Expect straight forward talking about what Panopoly is, Q&A (which you are welcome to participate in) and a few case studies with some light banter thrown in for good measure.

Panopoly is a Drupal base distribution that provides a solid and robust starting point for those wanting to build their own Drupal websites and distributions. The Panopoly project was started by Pantheon's Matt Cheney and its really beginning to taking off. There are many major distributions moving to it (such as OpenAcademy and OpenAtrium) and more new ones picking it up all the time. The idea of a distribution to build distributions has clearly struck a chord!

As maintainers of Open Academy we have been pretty heavily involved with Panopoly. After a while it became apparent that one of the main roadblocks to building off of Panopoly was the the rate of development and how quickly patches were being reviewed and integrated upstream. It had been almost 4 months since the last release candidate (RC5). Lots of people were using the code, submitting patches, and even (to a lesser degree) reviewing -- but those patches were just sitting in the queue, waiting to be committed. Our make files for Open Academy had some 12 patches applied against Panopoly, and the same was true for Open Atrium. Maintaining that number of patches is a burden to say the least.

Luckily, the Drupal community is never far away and when David Snopek reached out to me suggesting that I become a co-maintainer for the Panopoly project I was both flattered and extremely happy to oblige. We discussed this for a while in the Drupal.org issue queues before Matt, David and I met in a Google Hangout to talk things through in person. Since then David and I have both been granted official co-maintainer status on the Panopoly project and have been working hard to get the backlog of patches tested and committed. Additionally, we have set up a Panopoly group on groups.drupal.org where people interested in Panopoly can get together to discuss things related to the project.

Our plan now is to try and get an initial 1.0 release out of the door before Christmas. There is a discussion on the Panopoly group about what exactly a 1.0 release should include, but the thinking at this point is to focus our efforts on getting the backlog cleared and getting things as current and stable as possible...