Q. Let's jump straight in Rob, you have a namesake Robert Varkonyi who is a fairly well known American poker player (lifetime winnings of over $2m) ... ever tempted?
A. Lol, no. I do like a game of poker but any recognition I might get is more likely to come via a different route.
Q. With that mind, what's your background with Drupal - how long have you been working with it and how did you get into it?
A. It was eight years ago, 2006. I was introduced to it by a friend (an ex-classmate) who had been working with it. He's still working with it today as am I.
I saw a really good opportunity to produce websites I couldn't do before. Up to that point I'd done simple, static HTML sites but they always felt too simple, too limiting. Drupal offered a way out of that and at the same time into a new level of tech.
Q. What are some of the highlights from your 10yrs working with it?
A. The work I did with ITV - it was the most complex, difficult and beautiful. In short we built a web app framework that provided a centralised user data store for client Drupal sites, that had an SSO solution on top. It was a large development team (approx 30 people) that was part in-situ (@ ITV offices) and part distributed (all over the world). And it worked.
The other project that comes to mind was an Ericsson project, where we were responsible for replacing their global intranet solution with Drupal. It wasn't as complex as the ITV project but still involved file and document management, LDAP and ActiveDirectory (login recognition) and targetted content delivery across different business units and regions. And again it worked.
Q. ... and where it hasn't worked?
A. Where it doesn't work it's usually down to a mixture of reasons but comms and budget are usually the root of it.
Q. It feels like you've got a good take for what makes a good Drupal project?
A. The common factors with any project are good comms, proper planning, default project management tasks. They're all important.
Specific to Drupal I'd say it's that you shouldn't be afraid to write custom code. That doesn't necessarily mean writing new stuff from scratch all the time but if we decide to use a contrib module then we want to make sure we use the right one. The thing is, if there are several different contrib'ed modules that can do some or most of what we need (which is nearly always the case with Drupal), how do we know which is the right and best one?
That's answered by how closely a given contrib'ed module matches to the requirements, combined with an evaluation of its maturity and vitality.
So in addition to establishing how closely a contrib'ed module fits to the requirements, I always look at usage statistics and what is the issue queue like. Basically how active the module is and how many bugs it's got. That gives a good sense of the vitality of the module.
Also a lot of developers are just that - developers - but projects involve other components and skillsets, namely other people and this needs to be considered as well. What's the performance of the contrib'ed module like? Can it scale up and handle the level of demand I want it for? Are there a lot of potentially bloated processes being used that might adversely affect performance? What state is the UI in, can it be easily extended/ improved? Questions like that.
So think about what other benefits a module has or could add to your project (e.g. in terms of performance and usability). The result could be that the best contrib'ed module to use, is the one that requires you to write more code over another one that might seem at first glance to be the easier one to use and require little or no code. Don't be afraid of writing code to make sure you're using the best option.
Q. You're writing a book, probably THE book on Drupal 8 module development - handily called 'Drupal 8 Module Development' for PACKT publishers. That must be pretty cool and exciting. Can you tell us how that came about?
A. I think a large part of it was that I'd previously authored 'Drupal Rules How-to' back in 2012. There were 6-7 authors of the previous 'version' - 'Drupal 7 Module Development'. They were or still are all heavily involved in Drupal working on core - for example the db extraction layer; jscript integration and release managemet for Drupal 7). So it's a total honour to stepping in this role.
Q. And how is it going?
A. I've done about 30%, 4 of the 14 chapters. The release is due for August (2014) - about the same time when D8 core comes out.
Q. Can you give us an overview what the book is about?
A. It's the ultimate guide to writing Drupal 8 modules. It explains its architecture and the major architectural changes compared to previous versions. That includes a basic intro to Symfony2 and its components and the way they're used in Drupal 8.
It also includes an overview of Object Oriented PHP (OOP) - not a methodology used in previous verisons of Drupal. I've introduced it into the book as there will be a lot of readers who have no or little exposure to OOP.
Q. As you're part way through, I'd imagine you've got a good feel for where Drupal 8 is going. What do you think will be the biggest changes for Drupal developers - Symfony2 will be a nightmare, using Twig will be GREAT for everyone (developers, engineers, UX, designers)?
A. Well there was an initial shock at first that was felt elsewhere too. I think that was because I'm from a Drupal background and Drupal 8 is different from everything that's come before it. The level of changes are substantial.
But after familiarising myself with it, I understand why these changes are important. Basically, even Drupal 7 is an outdated framework compared to others - it's too tight, too self-contained in its own world and needs to be more open and that's exactly what's happening with Drupal 8. It's more open.
Q. We'll cover more of the book in the next session. Meanwhile, with what you know, when do you realistically think you'll be working on your first live Drupal 8 project?
A. In a way I'm already working on a Drupal 8 project just not a client facing one. As with D7, more is included in D8 core (for example Views, the WYS, REST API, Services) but there's still loads that isn't and will need to be ported (for example Panels). With D7 that process (to port the best, most used pieces) took about a year, this time I think that it'll be quicker. So I'm going to say about 6 months after Drupal 8 core is released and we'll be working on a Drupal 8 project.
Q. 6 Months - bearing in mind how 'these things go' is that optimistic or realistic?
A. Time will tell and readers can form their view on that one.
Ok thanks Rob, looking forward to our next session ...
