 I just want to prefix this with this is my first DribbleCon and I feel like I'm in social heaven. It is amazing. So thank you all for being here and for attending my session. So we're going to talk back to the basics of front-end development. It's not going to be a lot of code stuff. It's going to be a lot of things that we don't think about because we're too busy writing code. So let's just get started. So my name is Tessa. I am an agency and community engineer at Pantheon. I am also an instructor for Girl Development as well as an instructor and director for Code of Tomorrow which is a non-profit organization that teaches kids to code. And I also love dogs. I feel like that's really important to mention. So I have 25 minutes to tell you everything and that's not going to happen. So I've pulled out the things that have felt very near and dear to my heart in front of development and the things that I've started to learn working with agencies and different companies that have helped us become successful. There's so many things. All of the libraries. How do you keep up? I definitely do not keep up. So beyond all of these things, like what can we do to make sure that our projects are actually successful? First off, designer and developer collaboration. It's really easy as developers to see designers as our anti-friends. And if we want to be successful, we need to see them as our very close friends. So it's a very important thing to consider. So I actually implemented this process at an agency that I worked at and it ended up being insanely successful, saved us a lot of time, saved us a lot on budgets. So I wanted to share it. So we started a design review process. And what that process was is that the developers actually reviewed any wireframes and design concepts before they went to the client as well as before they went to the creative director. That allowed us to find things that were essentially un-codeable. Or at least we can code everything, but do we want to code it like that? So we would discuss these wireframes and we'd also compare them to the scope of work. So we had a budget that we were all trying to stay within. And looking at that budget and being able to say, hey, is this inside of budget or is this outside of budget? And be able to recognize that before the client saw something. And essentially at that point, we had to do it. And then we also reviewed our coding decisions with them. I know that sounds brutal, but if you're creating transitions or animations or anything that has to do with the aesthetic of the site, they feel super important if you actually involve them in that decision and that helps build that relationship. So let's all be friends. Outside of that, like have social hours. I know it's easy to go have a happy hour with your fellow developer friends, but try to include your designer team as well. Offer to do a lunch and learn on dev topics. I actually did a lunch and learn from my team on Git because they didn't understand like, oh, why can't you just push it where it needs to go? That's not really that easy. But in the return, they actually did a lunch and learn for us on some design aesthetics on buttons that they really enjoyed. And like if they were codeable and how we could set up an actual process or like a library that they could essentially pick from when they were working on designs. So an after hour or after work happy hour solves all problems, right? I feel like this one is really tedious and I don't even know if I should mention it, but yet it is super important because there's so many sites that are not responsive. So there's lots of devices and they're all changing. So we need to make sure that we're not just hitting those certain breakpoints, but that we're actually like making them responsive so that they are good for all breakpoints and all of those crazy devices. Doesn't always have to look the same, but it needs to function. And this also plays into the designer piece. Like lay that out with your designers. Let them know that it's like we might not be able to perfectly match that design that you have, but as long as this functions and that we can agree on this meeting place, then it's a safe place to be. Installing Twitter Bootstrap is not going to make your site responsive. Version control, this is an important one. Have you ever had this where you created or made some changes to a file and then you uploaded it via FTP and you broke your entire site and then you're like, I don't actually know what I did to that file? Has happened to me more than I'd like to admit. So Git, this is a buzzword and I'm trying to stay away from buzzwords, but this is an important one. It's a free and open source distributed version control system that allows you to handle everything that has to do with your large projects with speed and efficiency. So if you're new to Git, this is a super great tool and I actually used this for that lunch and learn that I did with my designers. We went through and they literally were writing commands based on what Git was this Git tutorial was telling him to do. And it's super great because it actually walks you through all the different processes and it's inside of command line. So it also kind of gives you that comfort level with the command line. And this is kind of an example of what it would look like in source tree if you're not a command line person. So you can see like in the bottom corner, whatever is green is what was added to that file. So instead of changing the file and uploading it via FTP, you can control it in Git and actually see what was changed and know like, oh, that broke my site, I should revert that piece of code. So there's GitHub, there's Bitbucket and there's Pantheon. These are all places that you can store your Git repositories while we are on the topic of Pantheon. I can't be up here and not do a little bit of self-marketing. It's important to find a DevOps workflow that works for you. You know, you might have servers that are set up and you might have staging environments and you're cloning all these things all over the place and having to replace databases, there's a better way. And my friends down at the Pantheon booth can tell you all about that. So has anyone done this? Like you've copied over a file and put it like from the server onto your computer and then renamed it. Yep, show of hands. Come on, don't be bashful and use that as your backup. It's not a good way to do it. So this is a super obvious one, write good code. Actually, we should take some time to read this picture. And if you can't read it, I can read it for you, but I don't have them on my screen. Basically, you should write code with the intention that the next person that's going to use it is a psychopath and they know where you live. Avoid technical debt. Again, this kind of lays into the psychopath thing. Any code that is written in a manner that is difficult to work on in the future is technical debt. So ensure that you are not being lazy the first time. Code reviews. You can ensure everyone is following proper internal code standards. Code reviews is something that I don't think enough people are actually doing. Have another developer review your code. You have no idea you might have been putting something in a weird place and they're going to be like, hey, this doesn't make sense or maybe you could do this. And it's not even, like, don't be shameful. Like, just allow them to give you that feedback. We all make mistakes. Let's find them before the client does. And what a better way to learn new techniques than by reviewing others' code. I actually really enjoyed that at a previous position of mine because I would review ways that they were writing the code that I would not even imagine of doing them. And it was really great to see different techniques for writing that code. Some really great tools for code reviews is GitHub. The pull request process is super smooth, probably my favorite way to do them. There's also Code Break, Collaborate, and GitLab if you're looking for other tools for that. Comment your code. I think this is a super obvious one. When you have to come back to your code like two years later and you're like, I know I made this custom slider, but what did I do? If you comment that, that process will be so much easier. And just acknowledge that we don't know it all. There's always someone that can help you grow and become a better developer. And for me, especially at the beginning, I didn't want to admit that I didn't know something because I didn't want to look stupid. I didn't want to look like the developer that didn't know what I was doing. But I've come to realize that other developers are super great and they want all of us to be super great developers together. So share that, talk to other developers and acknowledge that I don't know how to do this. I'm willing to figure out or listen to what you have to say. And if you're a team leader, encourage your team to go to things like DrupalCon or other continuing education places to help them grow as well. It'll just be an overall good fit for your team. I'm not a wizard accessibility, but we should definitely be considering this when we're building websites. You have no idea what kind of disabilities your end user are going to have and make sure that you are considering these things when writing code. So this comes back to the lazy thing. I've had this happen. Don't be lazy because the next time you come back to that code you might be even lazier or busier, one of the two. I like this picture, it's pretty fun. Testing. There is so much that I could mention with testing. So I'm really just gonna kind of cover the basics here, but testing is super important. It's more important that you find any issues before your clients actually find them. So there's nothing worse than building this super great feature and having Internet Explorer literally smack you in the face. I built this super awesome responsive mega menu with Twitter Bootstrap, which if you use Bootstrap it's actually quite difficult to edit their menu structure. And it was awesome. I opened it in Internet Explorer and it was non-functional, not even working. So that was not fun. So you should definitely review your code as you dev. So there's lots of tools, and I'm sure some of you know lots of other great tools. BrowserStack, Chrome DevTools, BrowserShots, there's all lots of great services. Microsoft Edge, I'm not a Microsoft person but I was reading that Microsoft Edge actually has some pretty great tooling or testing inside of their platform. Xcode if you're testing Apple devices, and then the actual devices. For me, I find that to be a really good reason to need the iPad and the iPhone and the Macbook and the gigantic iPad. I have to test on all of them, right? You have to buy them for me. URL testing, I think this gets a lot of people and we don't even realize that it should be a thing. I found this super awesome tool called Integrity. It is for only Mac users, but it allows you to look, it browses your entire site and then brings back any URLs that are broken. Super slick tool. And Behat. I don't get into Behat and it is a little bit, or at least I haven't dug into it much yet. And it is a little bit deeper than front end development but I wanted to mention this because my fellow pantheor, Steve, is actually doing a session on this at 345, I think it's at 345. In room 315. So if you're interested in further testing, you should definitely attend this session. So after you've worked on a website for so long, you no longer see the issues. It's like when you're writing a blog post and you're like, keep reading it and you don't realize that you say like, what, what, twice? You just don't see it, it's just not there. So have others review your website. Client, it'll, okay, I got like four minutes so I'm gonna do this really quick. Sorry guys, I like to talk. So things to consider. You need to make anything that your client is ever going to want to edit actually editable. We do not want to deal with clients calling us like six months later saying, can you change my phone number? You can change it yourself if you make it client editable. I just love like this story from the oatmeal. Have you guys all read this? Where they like turn the site into like this horrible, kaboshed, like completely fluorescent colored website. This will happen if you don't allow your clients the correct amount of client editability. And documentation. Documentation is huge. Yes, this is a really great meme. Write the docs. Sometimes they suck. But if your client can review those documents and actually go into their website and change that phone number themselves without calling you, that's gonna save them time, it's gonna save you time. I know it's nice to have that client that is going to come back to you for that recurring income. But if you can alleviate some of those pain points for them, they're gonna have a more successful experience with you. Don't tell anyone, but I actually like writing documentation. There's some tools for documentation writing. Google Docs, that one's really great. If you insert like a table of contents and use the headers correctly, it's a super slick tool for that. Google Sites, Google Sites like just redid their platform and their new platform is pretty awesome. At last in Confluence, Wiggy Spaces or any type of wiki offerings are super great for client documentation. And I suggest that if you're getting into this, create like a template that you can copy. So create all of the Drupal basics, how to add all the different content and then allow that to be your copy point for any of your new client documentation. Your client will destroy your masterpiece. Allow them the information to wreck it correctly. That's all I have. Does anyone have any questions? We only have like two minutes, but thank you. Thank you everyone. Have a good DrupalCon.