Queues are a wonderful way of separating different parts of a system. Once you have separated those parts you can do lots of interesting things, like be more fault tolerant or have a more responsive front end for your users. For example, lets suppose that we have a website on which we can book a holiday. We can choose lots of different options and at the end of the process when we've booked the holiday...
I'm at Drupalcamp London 2015 today, I'm planning to attend: 1. Applying domain driven design when building Drupal modules using Symfony components - Should hopefully be a nice session about getting 'off the island'. 2. Uk (and European) user groups - a BOF session that's close to my heart, as I've been a previous group organiser and have attempted to get the different groups to get together before. 3. Drupal.org in 2015: What's coming next?...
Much has been said about last month's highly critical Drupal security issue 'SA-CORE-2014-005', otherwise known as 'Drupalgeddon'. It was covered by mainstream international media, even if the reaction needs addressing. Drupal's security team take a responsible approach to security issues - being open & honest in disclosing them with fixes, in keeping with the community values. Security issues should always be expected in any software, it's how they are dealt with that speaks far more. We patched all the sites that we had access to immediately fix, and informed all our clients of the issue as soon as possible. If you host a Drupal site, and haven't yet, run through the Drupalgeddon workflow right now.
To complete my series on multilingual Drupal, here are some mini-lessons I've learnt. Some of them are are to improve the experience for administrators & translators, others cover obscure corners of code. The first few don't require any knowledge of code, but the later ones will be much more technical.
So at DrupalCon Austin I had a great time at the contribution sprints. I worked on some issues affecting Drupal.org, it was great fun! The issues we worked on over the week range from simple things through to some pretty difficult issues. Although Drupal core can always use more contributors, I would suggest that Drupal.org is also desperately short of contributors too. One of the issues I worked on related to the [tracker page for...
##Part 8: CasperJS debugging tips You're getting desperate. Your CoffeeScript / Javascript syntax looks OK, but CasperJS doesn't like what you're giving it. Try going through this checklist for a selection of sensible sanity checks and more: 1. Is all your syntax actually correct? If you're using CoffeeScript, are your indents all correct? Like, all of them? 2. Is the page actually there? Is the content actually published? Have a look in a real browser...
##Part 7: When this.mouse.click doesn't work mouse.click and mouse.move are a really helpfuls function in CasperJS, but we have at times found that they just don't work. Mostly, that's been because the element isn't there to click on. Do make sure that it's actually there! Make sure you're using the right selector, too. Try a casper.capture() to see whether it's there, but be wary of timings to ensure that you get a capture for the...
##Part 6: Manually fail a test, but continue script execution We set up an event to take screenshots of failed test pages, by hooking into the onFail event. This made for a problem when we wanted to pass or fail a test based on whether there were entries in the Drupal Watchdog table. Failing a test also would normally stop script execution, but we explicitly need our post script to finish its work! CasperJS fortunately...
##Part 5: Fun with viewports, and THEN some As I described previously, we nicely externalised our list of viewport sizes, making it really easy to set our viewports for mobile, tablet and desktop tests. Our content appearance tests put this to good use, taking screenshots of the content at mobile, tablet and desktop resolutions. The problem we very quickly ran into was that we frequently ended up with empty screenshots, or sometimes no screenshot at...