 Let's get this done in five minutes, and then we've got loads of parts here. 1,000 behind the bars, we've got them in two seconds. I think, no, he lost about an hour last year, I think. There's some volume though, I don't know. Has he gone in green? Yep, hello. Can everyone hear me? Excellent. This is Learning Front-end Development as a back-ender. I'm Dave, I go by C for Thawney just about everywhere. So, I'm going to talk today a little bit about the purpose of this talk. I'm also going to tell you what I'm not going to be covering, because I have to squeeze everything in to half an hour, three quarters of an hour. I'm going to talk about how my journey started. This is an ongoing process. Toolkit that I've happened to choose. I'm going to give some honourable mentions for stuff I haven't used, or chose not to use, and look to the future and where we can go from here, because I see this very much as a process, and I want to try and help the community to become more in sync with each other. So, we have the back-enders helping the front-enders with various bits and pieces on d.oqs and vice versa. This slide comes with a health warning. If I cough and turn the colour of ribena, I'm probably all right as long as I'm still vaguely upright. Anyone who's been in any of the talks I have been today will know exactly what I mean. So, the purpose of this talk is to help back-end developers start their journey towards being more full-stack. The idea that these days you are a back-end developer, or a front-end developer, or a full-stack, I think everyone needs a little bit of everything these days, and I know that I've described myself as three-quarter stack for many years because I'm not that great at the front-end stuff. I want to start a conversation, as I've said, about how back-enders can help front-enders and vice versa, and I'm looking to do a boff tomorrow to try and continue the conversation as well. So, what I'm not covering, well, I'm hoping everyone here knows what CSS, JavaScript, and HTML at least are. I'm not really going to cover twig in any great depth. I'm not really going to cover things like atomic design in any real depth. This is a 10,000-foot overview, as it were. I'm not going to include details on how to set up or use pattern lab. Spoiler, that's the chosen toolkit. This is about overview only. I am, however, hoping to post blogs and video tutorials as and when I get to building stuff with my own site. Also, mostly talking about Drupal 8 here, the differences between Drupal 8 and Drupal 7 mean that, although you can use pattern lab with Drupal 7, it's not as easy. Google is your friend if you wish to look up that. So, how my journey started? I had a desire to be a more rounded developer outside of London and home counties. Most roles wanted full stack developers rather than specifically back-enders, and I don't want to do the London thing every day. So, basically, it was partly for better job opportunities. So, I then started looking into tools, techniques, relearning JavaScript, brushing up on my CSS, and even to a certain degree my HTML. So, to make sure this is what I wanted. I then started watching a lot of front-end inspired talks, particularly Mark Conroy's pattern lab stuff, but also quite a lot of the talks that came out at sort of Drupal Camp, Dublin, et cetera. They were a big source of inspiration for me in terms of both choosing pattern lab, but also going down that idea of, this is what I want to do, I like the idea behind atomic design, et cetera. As I say, I eventually chose pattern lab. Mostly because I liked the idea of atomic design. To me, its flow is more similar to a back-end orientated way of thinking in that we have atoms which become molecules, which become organisms, which generate templates and pages. Back-end development, lines of code, functions, classes, which might be interfaces, they might be through inheritance, we might have super classes, et cetera. The idea is similar at least to my way of thinking. That was one of the reasons that I particularly liked atomic design. As I've just explained, there were similarities in how I developed, how I break things down, matches the atomic design way of doing it, and pattern lab was the first thing I discovered, the first thing I looked at, and I happened to really, really like it. My choice of toolkit had nothing to do with the fact that I worked with Anatech. It just so happens that Anatech used a lot of pattern lab, and it kind of works in a synergy with what I was looking for. It is genuine coincidence. Patter Lab 101, if I say, this is a 10,000-foot overview. It's atomic design, the idea that everything is broken down to the smallest possible layer, and then you build up towards having full webpages. You've got your atoms, which might be your fonts, or your base elements. You then go to your organisms, which might be a div. You go through to sort of templates, which might be a header section, and obviously templates make up pages. I also quite like the fact that you've got a live automatic style guide. You build pattern lab in there is an automatic style guide, which allows you to, A, demonstrate to the client exactly what their design is going to look like. You can present it as a website. They are able to see it exactly as it is, so we don't have issues surrounding. Well, it was 16.25 pixel font in Photoshop, and we can't easily do that on the web, and a pixel is a different size on a Mac to Windows, let alone browser differences. This way, you have the ability to be able to say, right, this is what you're going to see, so my boss who sat there on a 2010 MacBook will see it exactly the same as my grandfather who's using a Windows XP machine and IE7. They will see what they see, and there will be consistency in that. Again, this is something that I like. It's consistency. It helps relate to back-end techniques and tools that I've been using all my life, and it makes my life easier to adjust towards being a front-end developer. As I've mentioned, it's the back-end mentality surrounding it. PatentLab is heavy on buzzword back-end JavaScript tools. You've got your NPMs, you've got your galt, you've got your yarns, et cetera. I'm not going to go into too much detail about what each of those are, but what I found when I was going away and learning all of these was, actually, if I related them to back-end equivalents, then they made a lot more sense to me. NPM, if you consider it to be similar to Composer in that it's a package manager, that, for me, worked. I could then completely understand how NPM worked and deal with the fact that known modules brings in 50 million files. Gulp was a task runner. Great. As a back-end developer, I completely understand that. Look at things like Fing, if you go back far enough, or using other language tools such as Ant Maven for building objects, running tasks, et cetera. Yn yarn is very much Composer with Prestisema installed. It's NPM on steroids, basically. There is a requirement for the Drupal module components to be used because we need namespacing within twig. This is the core functionality about how both atomic design and pattern lab work. Great. Another back-end thing. I'm able to understand this. I'm able to relate to this, particularly now with Drupal 8 using more modern object-orientated approaches. We're seeing similar things start to come through with front-end techniques. Particle, which is one of the base themes that pattern lab or Phase 2, who created pattern lab, came up with. I actually found it quite tricky to set up, so I am going to make sure that I blog and release a video series about this because, for starters, the base theme is called Particle, but the directory it's in and the file names are pattern lab. So you have patternlab.info.yaml. My advice to people who are wanting to look into this and look into pattern lab further, leave the theme name as pattern lab to begin with, otherwise you are going to have a couple of hours debugging trying to find which reference is looking for patternlab.info.yaml, which you have, of course, renamed David's Orn Theme or whatever. Unused alternatives. So I looked at all of these in some detail and chose not to use them. So why did I not use Bootstrap? Well, partly because it's Bootstrap, it is very much a bit of a Marmite framework, but I also found sites that are built in Bootstrap. I tend to find to have a visual smell. You know it's Bootstrap, and I appreciate the slightly oxymoronic with a visual smell, but you can see that it's Bootstrap and I didn't want to just be another Bootstrap person. I looked at it, took the techniques, loved the idea of a very simple grid system, great, and I can completely see why a lot of people, particularly using rapid application development tools and techniques, love it. But I personally thought this isn't for me, I had some difficulty trying to get menus to work nicely with it, within Drupal. I never did work out if that was me, the Bootstrap-based theme, Bootstrap itself, or Drupal, probably somewhere between the lot, but I basically decided that Bootstrap wasn't for me. Zerb Foundation, which is a rival, if you like, framework, I found that to be very front-end heavy, which is great if you're a front-end developer, but again, I'm trying to learn these techniques for the first time. I worked with it quite extensively at one of the previous companies I've worked with, because that was what they had decided was the right framework for them. So I had access to people who knew it and understood it well, and there are bits that I really, really like. For instance, they have some lovely JavaScript extension stuff that will allow you to do better client-side validation. But Zerb Foundation is also nice in that it is a component-based framework, so you can pull bits of it in without needing to pull the whole thing in. So I've taken the bits that I like, and I will use those such as its data-binding properties for validation, and I'll leave the rest for now. KSS Node, okay, that is more of a style guide building tool than necessarily a CSS framework and such. I started to look into this at the same sort of time when I discovered a pattern lab and ended up going down the pattern lab route because everything fell together nicely for me. So I've not hugely looked at KSS Node. I like the idea behind it. I will probably look at it again at some point, but the idea of when I'm starting out having to maintain something separate to give me my style guide and import everything in through Drupal didn't sit well with me. I want something as simple as possible for the first few times that I'm doing this. Therefore, KSS Node was pushed to the wayside for now. Why didn't I use Omega, Zen, or any other popular Drupal parent themes? Probably because I fell out with Omega when they went back from the Omega 4 to Omega 5, and they took a step away from being more backend-orientated. I wasn't after something that was pointy and clicky. I've not looked at Omega on Drupal 8, I will be honest, and I know Omega 5 has been out on 7 for a long time now. They may even be at 6, but it was, again, it was front-enders, it was site-builders. It wasn't quite what I was after. I'm trying to be more of a full-stack developer. I don't necessarily want to be reliant on point-and-click, although point-and-click is a very useful teaching tool. Zen, I got fed up with so much Ruby. Again, Zen's moved on. I've not looked at it for 8, but as far as I'm aware, Zen Grid is still a Ruby gem. I'd still need to work with Ruby tools and techniques. I don't necessarily want to have to throw in and install Ruby on my machine just to be able to compile on my code. Everything I need to run is already on there. I've got my PHP, I've got my JavaScript. I shouldn't have to look at installing Ruby in gems, et cetera, to be able to deal with that. Where can we go from here? How can I continue developing my skills further? How can I help you develop your skills further as back-end developers? As you move towards looking to be full-stack, let's have a discussion about it. Let's do it as a boff. As I say, I'm hoping to be able to organise one tomorrow. Failing that, we can talk down the pub when we go to the after-party. For me, the next steps are, I need to continue the process that I've started, so I need to continue researching. I need to look at exactly how pattern lab can assist me further. What front-end techniques do I still need to look at to be able to become that more full-stack developer? Do I need to brush up on my JavaScript? Definitely. Do I need to learn React? Probably not, or not yet at any rate. For me, it's very much a continuation of the process I've started, the research, the iteration, and treating my front-end development very much as I would back-end development. It's just more visual. The iterations are more obvious and they might be with back-end development where we're potentially looking at efficiency, we're potentially looking at getting the right data. I'd also like to push towards back-enders helping in the Drupal.org issue queues. It's something I'm trying to do as and when I have the time. Because time and time again, I see both on internal slacks and in Drupal Slack, in IRC, a front-end developer saying, can a back-ender have a look at this, please? I don't completely understand it. 99% of the time someone does step up, but it seems that it's something that doesn't happen often enough. There is too much time between that request for help. It might be a couple of days before a back-ender gets in and helps with certain bits and pieces and depending on time zones, particularly with something like Drupal, that can be a very, very long time. I want to push for back-enders helping the front-end colleagues more. I also want to see the reverse. I want to see front-end colleagues helping back-end people more, helping with things like the accessibility side of it. We have our part to play in making sure that things display correctly. You've got the right data. It's as accessible as possible. Front-enders are very good at getting the data to look right. Let them help us. Let us give them the best chance by getting them the right data in an accessible way as possible. So some contact details. As I say, I'm Sifa Thorny on just about everything. I hang around in IRC slack from time to time. I do respond as time allows. I'd be a bit remiss given my boss couldn't get over because of the snow. Anatech hiring a sport engineer. Come work with me. Come work with other front-end people like Mark Conroy, who's been doing an awful lot after the box initiative. Sport engineers at Anatech do get to work on exciting projects, but also they do get to deal with working with building new features. A support engineer is not just standard support tickets. Q&A and then the pub. So, do people have any questions? I've not looked in any way shape or format angular, so probably not. There is limited support for React. I believe they're working on better support. The version 10 of pattern lab, which is currently in, I'd say early beta, because it's about beta 2, beta 3, and I checked a few days ago, is very much at the moment a much more JavaScript-orientated and looks like it's going to work better with things like React. So it looks like they're working towards better support for that. Pattern lab, I believe, can work with other templating languages as well. I don't think it is limited twig. I've not seen anybody using it with things like Smarty, which is another templating language, but my understanding is it can be used with that. Any other questions? When you're running a grunt, and you're getting modules from the MVM, there's always tons of warnings like, this looks different, this isn't working, so we're just starting to work. I've used the Particle starting kit, which is near enough as plug-as-play as you're going to get with Pattern Lab and Drupal. Basically, it's a case of download it, NPM run, build Drupal or Drupal, build something like that, and it will run off NPM, get your 50 million warnings, and it's then near enough ready to go, particularly if you don't rename it. In terms of where do we start from, well, actually how much attention do we have to pay to warnings of deprecation, et cetera? On NPM, yeah, I basically learned to ignore those warnings because it seems that NPM iterates at such a rate and deprecates so much so quickly compared with certainly what I would see as a lifecycle within back-end development that a warning of deprecation is as common as anything. In terms of what can be done about that, I'm not a strong enough JavaScript developer to be able to go away and say, right, this is actually what it now needs to do and don't file a patch with relevant module maintainer for that particular NPM package. But, yeah, if you are developing your JavaScript skills and have the confidence to go and do that, then let's help others, let's contribute fixes that say, well, actually, I don't know, index of has been deprecated, we now need to use index for or something. So go away and help the module maintainers start to move towards that in terms of how you can improve your JavaScript or getting used to the huge changes in JavaScript that are happening. I've used Wasteboss's JavaScript 30 course, which is 30 roughly 20-minute episodes that's freely available online, and everything there is JavaScript or ECMAScript 2015. JavaScript and ECMAScript are mostly the same. I think what traditionally we would know as JavaScript was ECMAScript 6, and they've now gone to a yearly, so ECMAScript 2015, ECMAScript 2016, et cetera. It's pure JavaScript rather than React or jQuery, so I found that very useful for brushing up on my JavaScript. In terms of CSS, I treated that very much as I would learning a language. I just went away, okay, how do I do this? What is a transition? What is a class? Do I want to look at using things like SAS less, or do I want to just write raw CSS? Again, I went down the... Well, actually, everything seems to use SAS, so I will use SAS. Root. HTML, we write enough of that that I didn't have to worry too much about additional stuff there. So there's plenty of resources online. I found with Boss's stuff from the JavaScript side to be top-notch. He's got some very good free stuff, some very good pay-for stuff as well. Any other questions? Okay, well, in that case, I think we'll head to the pub early. There's a tab behind the bar sponsored by Funder.