 It must be three o'clock. Awesome, welcome everybody. I am Josh Simmons. I'm a recovering lamp developer, now a community manager for O'Reilly media. I cover open source and web technology there. So I cover Fluent Conference and OSCON. But I'm getting ahead of myself. I'm actually gonna talk about that in a little bit and I promise that will be relevant. So I spent 14 years as a web developer. I started with ASP before the whole .NET thing happened. I went to PHP because it looked like ASP. And after that, well I spent about 10 years using one set of tools. Few contract gigs, had me doing Ruby and Rails. Every once in a while I didn't counter a new language. But I spent most of my web development career doing PHP development with content management systems like Drupal or Joomla and WordPress. Well I realized when my freelance career fell apart and I do another talk that talks about how that happened. When my career fell apart I realized that I had spent the last 10 years investing in a tool set that was really quite limited. And I realized that I was defining myself as oh I'm a PHP developer or oh I'm a Drupal developer which was very limiting. And what I found is there were languages I wasn't familiar with but more importantly there were architectures I wasn't familiar with. So now that it worked for O'Reilly and we published on all of the things I have the advantage of seeing new technologies as they're coming out and seeing how the different languages are used. This meandering introduction is basically to tell you why I'm giving this talk. Because I've spent 14 years doing web development in the last two years that I've been working for O'Reilly. I've been learning a lot about what was going on outside of the PHP ecosystem I was in. So today we're gonna be covering a lot of ground. We're gonna start with web technology like the core, the languages related tools. We're gonna talk about web thinking. So we're gonna talk a little bit about where it came from, why it is the way it is and to borrow a phrase from Frank Camero we're gonna talk about the grain of the web because the web is a medium, wood is a medium. You wanna work with the grain of the web. We're gonna talk about tools and process. So how it actually happens, how it gets done. Excellent, welcome everybody, welcome. So we're gonna go through web tech, web thinking. We're gonna talk about tools and process. We're gonna talk about practical considerations, things that you'll run into when you're working as a web developer. We're gonna talk about stacks, so which language do you primarily use? And definitely you're gonna use a lot of them but you're probably gonna work with one primarily. We're gonna talk about gotchas, easy mistakes to make, things that go wrong on the web all the time. And lastly we're gonna talk about next steps. So you've sat through a 90 minute presentation. What are you gonna do with it? So I'll say this. I'm writing a book for O'Reilly of the same title and this talk is based on that outline. Why I say that is that these slides are mostly very boring. There are gonna be slides that are just an outline and really most of the content's gonna be what I'm saying to you and what's in the speaker notes. So the slides will be available later. I'm gonna post them to SlideShare, gonna post them to Internet Archive. But all that said, I encourage you to take notes. Don't get too distracted with it but there is a lot of little details that'll fall out of this presentation. So feel free to stop me if I'm going too fast. Raise your hand if you have a question. I will try to take as many questions as I can. I may wait until the end of the slide to take that question. Okay, just a little more housekeeping and we'll get right back right into it. So if you've been in the industry, if you're an engineer or if you're a developer, some of this is gonna be basic for you, not gonna lie. But there are things that I cover here that you may not know. You may wanna stick it out. This is me getting you permission to vote with your feet. If you're not interested in this talk, if it's not valuable for you, like there's the door, it's okay. Try not to be disruptive. But please feel welcome to go elsewhere if this isn't the talk for you. Lastly, of course, I work for O'Reilly. That means at the end of this presentation, there's a free ebook waiting for you out of a set of 12 that I've chosen that are relevant. And there's also discount codes for Fluent and Oscon. More about all that at the very end. Okay, what an intro. Y'all ready? Seriously? Y'all ready? Okay, thank you, thank you. All right, let's dive in. Web technology, what is the web platform? The web platform is not really a platform, to be honest. There are lots of platforms, right? Your phone has a web platform on it. Your browser is a web platform. Really what I mean when I say web platform is there is a set of technologies that you expect to be available to you and they come together in a way that, they're designed such that they work together. The web ultimately, designed by Tim Berners-Lee Cern, it was built in such a way that it was easy to use. It was meant to be used by scientists who, raise your hand if you've seen a scientist's lab notebook. They're not really trying to compose things. They're just trying to get the information out there so that they can share it. So, Tim Berners-Lee designed this to be forgiving for it to be easy to learn. And what I mean by forgiving is that if you screw up, oftentimes a browser will fix the problem, the mistake for you. This allowed HTML to take off because it was easy to use and it didn't penalize the user for making silly mistakes, most of the time. There are other technologies that HTML and other, and CSS and JavaScript overtook HTML just one by default. And this is something that we see happen a lot on the web and generally in technology, right? We have standards bodies and that's great, but the bottom line is what are people using? And people started using HTML, so here we are. HTML, CSS, and JavaScript are like the three main things on the web platform. This is probably most of us know this. HTML is for your content. It's a markup language, right? So you're just describing all the stuff that you want your user to see on that page. CSS is the styling, right? So for a long time, if you ever did web development in the late 90s or before, even the early 2000s, we were using tables to build layouts. We were using font tags to shove font weights and font faces. I mean, it was repulsive. It was really, really bad times. And frankly, because the style of the website was embedded in the HTML back in the day, that made maintenance very difficult. So think about if you have a website with say, even if it's just 10 pages, but say you have 50 or 100, say you want to change the font or the color on all of these pages, what you want to run a find and search operation on like a whole directory of things, that's not gonna create problems. So what CSS did is it decoupled presentation from the content. And so by decoupling the presentation from the content, each can specialize in what it's good at. And it makes it easier to maintain. So you end up updating one CSS file and the whole website changes instead of having to update each individual HTML file. Then there's JavaScript. JavaScript is crazy. It is blown up. It used to be this like a language that people didn't take seriously. And some people still don't. That's probably a mistake though. Because at this point, JavaScript is everywhere. It's not just in the browser. It's in robotics. I mean, you can use it to do a lot of different things. JavaScript is about the interaction. So you've got your content, the content of your web page with HTML. You've got the CSS to make it look nice. And then you've got the JavaScript to sort of animate it or to bring it to life. Now, I wanna make something clear here that interaction sort of comes baked into the web. You've got hyperlinks. You've got buttons. You've got forms. So there are things that these web languages give you to do interaction without JavaScript. JavaScript is that extra layer of interaction. That extra, say you wanna build a single page app or a Toby Photoshop in the browser for some reason. Well, that's what you would be doing. Or something like that. But to be clear, there's only one of those three languages that you can rely on at any given time when you're doing web development. And that's HTML. So HTML, CSS, JavaScript, these are all sent over HTTP, Hypertext Transfer Protocol. All you can count on is HTML and HTTP. Someone might have JavaScript disabled. Someone might have CSS disabled. Hell, they might be using a line mode browser. I mean, those things are still out there. And for some people, those are really important. Also consider that there are accessibility concerns. And so if there is interaction on your website that requires JavaScript, chances are some people are not gonna be able to use your website. I don't have the stats in front of me, but it's not an insignificant number of people who have JavaScript disabled or otherwise not available to them. So, for instance, you could have a form on a webpage and that form should have a button to submit that form. Don't make that button depend on JavaScript, right? Like if that form submission requires JavaScript and someone doesn't have it, well, then they're SOL and you just give someone a terrible UX and maybe you lost some money. So just know, and this will be a theme as I go on through the presentation, that all you can really rely on is HTML, CSS, and JavaScript are niceties. So there's a topic we'll get to called progressive enhancement that sort of frames all of this. Stacks. So there's all this talk about being a full stack developer. I think it's unrealistic, frankly. I think there are generalists, there are specialists, that's fantastic. A full stack developer is unlikely to be able to excel in any particular area. I'll say, as a freelance developer, I had to be a generalist. I had to be a full stack developer. I was the client's marketer, I was the designer, I was the developer. Hopefully you don't have to wear that many hats, but sometimes you do. So it is useful to understand the breadth of the web and all of the things that are associated with it so that you can work with other people or get the job done if you don't have any other people to rely on. So stacks really gets down to what language are you using? What tools and technologies are you using? There are different web servers, there are different operating systems, but for the purposes of this presentation, when I'm talking about stacks, I'm really talking about the languages that you're using. So one common stack is the LAMP stack. It's a Linux, Apache, MySQL, PHP. So again, in the context of this, when I talk about LAMP, I'm really just talking about PHP and why you would choose PHP. But we're gonna go over those languages later in the presentation. All right, servers. So the core of a website is a web server. You've always got Nginx or Apache or Express serving up these files for a web browser or other clients. But there are a lot of other servers that you have to deal with when you're doing web development. So first of all, name servers. Name servers, hopefully you don't have to run your own name server because it's kind of, DNS is like an archaic system. It's crazy. What you need to know is that you pick up a domain name from a registrar, right? We probably all know that by now. And what they're relying on are name servers. And in fact, your own local server, your server that you have your website on, you're gonna have some name servers on there too to manage routing with subdomains and things like that. But just know that somewhere out there is a name server that's pointing to your server, pointing to your IP address, resolving google.com to 10, 10, 10, whatever the IP address is. Name servers are complicated. Hopefully you don't have to deal with them. But you may have to if you end up on a virtual private server or you got your own box. Moving on, we have mail servers. Again, another type of server that you really don't wanna have to deal with, that you really don't wanna have to host. If you have your, say you have a WordPress install on your web server, the WordPress sends out email. It sends out forgot password requests. It sends out comment notifications. There are lots of things that it's gonna be emailing. If WordPress sends you an email and say that WordPress install is on a box that has dozens of other people on it, maybe one of those other people is a spammer. Maybe they have, or maybe it's just a WordPress install that got infected and it's being used by a spammer or by a botnet. And so suddenly your website is hosted on the same server with the same IP address as this other website that's doing terrible things. Okay, so when Google gets an email or when Gmail gets an email from that infected website and whatever it is, well, then it's keeping track. Google knows that that came from a certain IP address. And so over time, it can learn that, okay, just don't trust that IP address. I had a client once where they had their own mail server and it was not uncommon for us to have to call an ISP and say, hey, you blacklisted our IP address. We promise we're not spam. You don't wanna be in that position. So the way to avoid running a mail server is to use something like Syngrid or Mandrill or any of these services that will send the email for you. They're whitelisted a lot of times. They're more trustworthy and there's more controlled environments. So if you can, avoid running a mail server, rely on a third party for that. Okay, maybe I should have started with this one because it's really critical, but there are databases. And so you have your database server. So in the lamp stack, that's MySQL. And MySQL has a server running. And anytime someone hits your website, again, let's use WordPress as an example. WordPress knows, okay, they're going for this web, this post with this ID number. All right, let's query the database, let's find that post, let's pull all the data. And then what WordPress does is it injects that content into the HTML. So it generates the HTML and sends that to the client. There are lots of different types of databases. The most popular is MySQL. I really encourage people to explore beyond MySQL, not just because of its corporate governance, but because it does some things that are just weird. If you've ever worked in a language where it does something unexpected, maybe false triple equals there. I mean, sometimes things just don't make sense. And so MySQL will sometimes do something unexpected. And the last thing you want your database to do is something unexpected. You want it to follow exactly what you've come to expect of databases. So alternatives, MariaDB is often a drop-in replacement for MySQL. And Postgres is my personal favorite, but sometimes it's a challenge because so many tutorials, so many courses assume that you're using MySQL. So just know that you probably should explore other databases, but that when you do, the documentation may not be, documentation with that database is probably fine, but those web tutorials that you might use are not gonna be referencing it, and they may not be transferable. The last thing that I'll say about databases is that the databases I just talked about, those were all relational databases. What that means is you have entities, which are tables in a database. And so you have your users, you have your pages, you have your posts, and they all relate to each other somehow. This post belongs on that page and is created by this user. And so that's how these relational databases work, and there's not always the right thing for the job. For instance, if you're building a chat client, or if you're building a tool that is logging things, you want to use something that's called a NoSQL or a document store. So you might look at CouchDB, you might look at MongoDB, Cassandra. There are lots of options out there for NoSQL databases or document stores. The reason that the document stores are so nice is because they are often schema-less, which is to say you don't have to define ahead of time that every single entry in this document has to have an ID, a name, and a date. You can just throw data at it and it'll add it to the document. There are people who like to use NoSQL or document store databases for everything. Don't do it. Also don't use relational databases for everything. Now as with all crafts, there's a right tool for the right job. It's possible that you might be using a document store database as well as a relational database. Maybe I have a website that makes sense to use a relational database, but there's a part of it where I'm logging things. Okay, well then let's use the NoSQL, the document store for the logs. So in all of these cases, you can usually use these technologies together and you just want to make sure that you're using it for the right thing. I think I've said enough about databases. And just as I say that, I realize there's one other type of database. We're not going to cover it because it's less relevant, but it is important to know about. There are graph databases. So a graph database is what Facebook has, for instance. It relates things to each other, like a relational database, but in a different way that I can't really speak too well at the moment. You probably won't encounter those all that much, unless you're getting into data science or analysis. All right, question. So you're asking if I have names of which databases? You know I actually don't have one on the tip of my tongue. One thing that I noticed is when I was doing the research for this, the graph databases that are out there are highly dependent. The graph database that you use is highly dependent on the language that you're using. That's not typical with other types of databases, with document stores and relational databases. Usually you can use whatever language, as long as there's some sort of adapter or connector. But GraphDB is a little more language specific. Is that the question? Thank you, Neo4j is an excellent graph database. And I believe that one's fairly language agnostic. So that's an excellent counterpoint too, thank you. All right, any last questions before we move on? Say that again? So the question is what are some types of applications that no SQL database like Mongo would be appropriate for? I would say if you're building chat clients, if you're building, let's think of some use cases here. Does anybody here have some suggestions or thoughts about where you might use a no SQL database? I mean, to be perfectly honest, I haven't used a whole lot of them in my, yes sir. Right, right. So that's sort of the abstract answer, right? It's not a specific use case, but the point that he's making is when you don't really need to relate the data and you just have it and you just wanna put it up somewhere, that's when you would use a no SQL database. So again, if I wanna know that this user created this page on this date, well I want a relational database so that I can run that query and bring all that information together. But if I have a no SQL database, a document store, it's just gonna have a long list of things. And it's gonna be hard for me to interrelate that. Like, you know, I could have a user's document and a post document, but it would be, I can't just query them and connect them easily where you can with a relational database. You would have to run through each document completely and then find, or almost completely, then find the match. One last wrinkle here. A relational database is a really powerful thing and sometimes it's useful to have it on the backend, but you don't necessarily need it powering your website. So what you might have is you might have a database that gets rendered or rasterized or into a document store into a no SQL database. So that way you have all the power, thank you, of a relational database and you can run these queries, but you can also have the performance of a document store. So, and there's a lot of detail that I'm not able to cover here and there are database experts at scale who can really speak to these issues, but that's bad as far as my knowledge of the news. All right, moving right along, web thinking. We're gonna talk about the grain of the web. So we're gonna first talk about standards bodies here. Standards bodies are the arbiters between the browser manufacturers, the Microsoft, the Google, the Mozilla and the vendors, the, for instance, there are a lot of people who sit on these standards bodies that aren't necessarily the browser manufacturers. So in W3C, you might have Microsoft and Google involved. You might find Oracle at the table too. The standards bodies are also arbiters, not just between the browsers and the vendors, but also between the developers. And so really it's a group that all three of those parties come together at and hammer out a specification for how exactly a language should work or how exactly something should work. So with HTML, we have the W3C and the what WG. Those are the two standards bodies that are really responsible for HTML. The reason there are two bodies is because what WG was unhappy with the progress W3C was making, started on HTML5, while W3C was on HTML1.1. Eventually everybody made nice and we've got HTML5 is really the standard that's out there. CSS is also governed by the W3C. And JavaScript is governed by ECMA International, completely different organization. The interesting thing about JavaScript is Sun, excuse me, Oracle, owns the trademark for the name JavaScript. So when you see something called ECMA script, know that that's JavaScript. That's just the publicly available name for it. Unfortunately, Oracle hasn't licensed the name JavaScript for use and they haven't released it, which is a terribly confusing thing. Because now we're talking about ECMA script six and ECMA script seven or 2015 and 2016 that are coming out. And some people hear that and have, well, I don't do ECMA script, that's not relevant to me. So just know that ECMA script, JavaScript, ECMA International that's behind it. Because of the standards bodies, we're able to have, I'm not gonna lie, I mean the people who, the standards process is it takes someone with like an iron will and it takes someone with a stomach that can handle a lot because the standards bodies, the standards process is messy and sometimes it's really charged. If you think that a kernel developer's mailing list is bad, I mean just look at the standards bodies, it's not much better. But they're important because what they do is they help us hammer out the, help us hammer out competing interests, right? So while Microsoft used to be infamous for adding internet explorer specific capabilities that developers would start using, there are now standards for a lot of those things such that all of the browsers support them and you don't have to use the IE specific stuff. Okay, any questions on standards before moving on? Okay, excellent. Just so you know, I encourage people to get involved with the standards process, but it's really, really a pain. But it's a labor of love and it's good work and it's important work. Moving on, open source. Open source is really a key part of web thinking as well because for instance that lamp stack that I've kept referring to, Linux, Apache, MySQL, PHP, those are all open source tools and technologies. And because they're open source, they're free to use and so in the early 2000s, late 90s we had an explosion of web hosts and shared hosting providers and because these tools were free for them to install, they didn't need to pay in Microsoft any licenses, suddenly the standard became lamp. So open source has really fueled the growth of the web and I wanna make it clear that it's not just that open source is free, right? I mean, that it costs nothing is great but there's something much more fundamental and important about open source and that's the fact that it's a common good, it's a common asset. So I mean, I'm preaching to the choir with open source here, I hope, because we're at scale. But the point is that we're better together than we are apart and the more eyes you get on something, the better. So the web has open source as a movement to think. And let's just remember, acknowledge for a fact that open source free software was a radical idea. Like not radical in terms of like, oh, radical dude, but no, it was radical that you would invest your time in creating this thing and you would just give it away. You know, I mean, that didn't make sense with the business models of the time and business thinking of the time. That's new. Well, it's about 20, 30 years old but that's really only recently become the mainstream even though Linux has been on routers forever. So open source is an important part of the web and what you'll find is not only open source content management systems and frameworks and libraries and tools, the languages, the servers, most of it's open source. Hell, even Microsoft has gone open source with some of their stuff. Okay, web services. Think web 2.0, Ajax and Google Maps embedded on every website you see. One of the real beautiful things about working on the web is how you can bring together different services, right? We're standing on the shoulders of giants because I couldn't build Google Maps but I can certainly copy and paste that code and drop it in my website or install the Drupal module to generate a Google Map with the data I have. There are APIs out there for natural language parsing. It will give you the nouns. It'll give you relevant events. It'll pull out people that it recognizes. The web services that are out there allow you to build things that are very complex and very powerful. No one of us can build a giant mapping engine. No one of us can build a natural language parser. Maybe if there are a few like Savant among us probably can but it's just not realistic. And so by merit of having an API, an application programming interface which really all an API is is a way of talking with another service, another technology. So Twitter has an API, Google Maps has an API, Twilio has an API for working with phones. You can use all of those things to build an application that integrates a lot. This is one reason that I think the web has taken off is because you can build complex things without having to build it all from the ground up. And frankly, you're just able to accomplish a lot more with less. Okay that's the first official brain part of the presentation, bear with me here. So moving on from web services. The Uncertain Web and I'm borrowing the title of an O'Reilly book here. But the Uncertain Web is one of the things that it captures the way the web works. And so far as you don't know who's consuming your web service or your websites or your web app. It could be a browser, but what browser is it? And what operating system are they running? How much RAM do they have? How much processing power do they have? Hell do they have a screen? Maybe this is a Google's web crawler scraping your website. It doesn't have a screen. So just know and help, screen readers, right? There are all these circumstances in which your website's gonna operate that you're never gonna think of. And so what this means is we have to build websites in such a way that they work in all of these different places. That's a real challenge, certainly. And people who are experienced in software engineering who are used to having a little more control over the environment in which their software is running often bristle at the idea that your website could be anywhere. But that's also the beauty of the web. It can be anywhere, right? I can, using Apparataste, the open source project made by Cuban National, I can pull down a webpage via email because I don't have access to the internet through a web browser, but I have email. There are all these circumstances in which your website's gonna operate that you're not gonna predict. And so there are certain ways of building that. Now we're gonna get to that later. There's one example I wanna bring up here before we move on. And it's something that NPR did published on it in 2010 on Programmable Web. And it's called COPE. Create, once, publish everywhere. And the idea is that NPR has this massive body of content and media that they keep producing. And NPR knows that, okay, well, we've got desktop computers and laptop computers and smartphones now, well, what's next? We don't wanna build a new client every time. You don't have to build everything from the ground up every time there's a new device or a new variant on that device because the reality is there are so many different devices, you just can't do that. So what they did is they had a database, a highly normalized database. And normalized for those not familiar with database lingo means you take out, if I have a body of text, normalizing that body of text means pulling out the, it might mean pulling out the links or pulling out the hypertext. It might mean storing a date as a timestamp rather than as a string. I mean, that's kind of an absurd example, but a normalized database for NPR meant that they have this central core of content. And then as these new devices with different capabilities came out, they'd build filters and pipes. So, okay, we've got a smartphone that's accessing the NPR content through their app. Okay, well, what can their app do? Well, their app doesn't support links in the hypertext and maybe the app doesn't support rich text in general. So when the app makes a request to the central NPR database, the database is gonna say, okay, this is what they support, so we're gonna send it through those filters and the app is gonna have delivered exactly the type of content that works in that environment. Whereas when the website calls that central database, it does support rich text, it's a website. And so the filter is gonna go ahead and add that in there as it pulls it out. So the beauty of having a normalized database with filters is that it allows you to be very nimble as new devices come out. And just a reminder, not only are we talking about desktops and laptops and smartphones, we're talking about cars, watches, TVs, and virtual reality. It's everywhere. And I don't know if anybody here is familiar with Tesla, but Tesla allows you to write JavaScript to do robotics. I mean, it's microcontroller, so it's small, but you could build on that. So the uncertain web is why it's difficult, this is why it's difficult to be a web developer, but that's also why it's lucrative. The web is ubiquitous and the nature of it just allows you to get the broadest possible audience. Okay, questions? Say that again? So I mentioned, the question is, I mentioned a tool about accessing websites via email, and that tool is called Opera Taste. I'm sure I'm mangling the word. It's A-P-R-E-T-A-S-T-E. It's an open source project started by Salvi Pascual because a lot of Cubans don't have web browsers, but they do have email. It allows a person to email a specific address and request a URL. Or just to give it a search string. And then they will have that website or those search results emailed to them. And so they're basically browsing the web through email. Question is, would that bypass blacklisted sites? Yes, yes it would, and so that's one of the benefits. I don't know what Cuba does in terms of managing or censoring content on their internet, but certainly that's one way to get around it, and the reason again why I brought that up is you don't know what environment this code's gonna be running. And if you've ever dealt with HTML email, you know there are a lot of things you can't do in HTML and email that you can do on a website in your browser. So the question is, do I have any references for ways to find out if you're blacklisted? And I'm sorry to say that I don't have those that they're ready for you. All right, moving merely along. Okay, tools and processes. Your sword and shield as a web developer, you have your editor. Whether that's a plain text editor, a lot of, I mean, I started on Windows, so I started in Notepad. But an editor is something like Sublime Text or Notepad++ or Vim or Emacs. There are a lot of editors out there. Find the right one for you. Find ones that are well supported. But know that when you're looking at editors, there's a continuum. There's a continuum from your Spartan Notepad to Eclipse or Visual Studio even. And what that continuum is, is from the Spartan tool to the Integrated Development Environment, the IDE. So an IDE may have not just a way for you to code and edit files, but it may have built-in file transfers. So it will upload your files or as you make changes through SSH or SFTP. It may be that it has a built-in testing suite. So every time you save your code or you deploy your code, well, it tries running a series of tests first to let you know if they validate or it clears those hurdles. My one recommendation, I'm not gonna tell you what editor's right. My one recommendation is that if you are using an IDE, take advantage of the tools that the full feature set that's there. I mean, it's really incredible. If you're really not using the tools in an IDE, if you're just using it as a text editor, stop. Like, it's just power hungry, it's just taking up machine cycles you don't need. You can keep it simple. Okay. The last thing I wanna mention about editors is if you are using one of those really Spartan tools, if you are using notepad for, like don't actually use notepad. You can, but you shouldn't, because notepad doesn't have syntax highlighting. Anybody who's spent an appreciable amount of time doing any sort of coding will know that every once in a while, you're missing a semi-colon or you're missing a bracket. And if you don't have syntax highlighting to show you where that is, oh my gosh, you can waste so much time. It's really don't waste days or hours searching for an errand semi-colon or not knowing why something's broken just because you don't have syntax highlighting. Okay, so I'm gonna say about editors. Version control, aka source control. Version control is an excellent tool for allowing you to manage change, especially in a team environment. So, for instance, if I'm working on a website with a team of four other people and say I'm working on one set of features and they're working on different sets of features, well, we're all working on the same code base and maybe we get lucky with that setup and that if we're working on different areas, well, we can work with different parts of the file system so we're not stepping on each other's toes. But that's still playing with fire. Unless you're using version control, it's all too easy to overwrite someone else's changes, to have two different changes and to have two people make changes and then not know how to reconcile those things. Version control will capture the state of your code at any given moment. So, for instance, I might have a project and we have the central repository and all of the files are in that repository and it saves them at a certain state. Okay, so what I'm gonna do is I'm gonna check out that repository and have a local version of it and I'm gonna work on that local version of the software and then maybe I change just a couple files, a few things here and there and what I'll do is I will commit those changes and those changes, what the source control tool will do is it will see what's changed and it'll push the changes into the central repository when I run the push command. Now really, I'm clearly talking about Git here. There are other types of version control systems. There's Mercurial is the other really popular one with Git. Back in the day, CVS and SVN, they're still out there somewhere. Because I'm able to work on, because I'm able to work on files that someone else may be working on, we can bring those together, we can easily look at the differences and we can resolve that merge conflict. I'm not the best person to teach you about version control because the honest-to-goodness truth is that as a web developer who mostly used Drupal, there was not much that we were committing to version control and also as a freelancer who was working mostly for small businesses, they weren't paying me enough. I wasn't, anyhoo, don't make excuses for yourself like I have for myself. Use version control all the time, even if you're working alone and the best thing about version control is it gets you in a mindset of being focused on what you're building. So for instance, I may have an event management web app that I've built and I may have an event management web app that I've built. Okay, there we go. We're on to our second brain fart here. Version control. Ah, okay, so it gives you focus. So what I mean by that is, okay, so I have this system and maybe one part of it is the checkout process, you know, the e-commerce part where it handles payments and things like that. And maybe something's broken. Okay, or maybe there's a feature that I wanna add. Well, developer me of five, 10 years ago, I would just start hacking at those files. I would open them up, start making changes, try refreshing the page because I'm working in production because I'm insane. Also, don't work in production, I'll explain that later. And what I'll do is I'll change 10 things, I'll change a dozen things and it's suddenly broken and I don't know what one change broke it. So version control will support you being a disciplined developer and so far as saying, okay, I'm gonna fix this bug or I'm gonna create this feature and then you're gonna do that one thing and you're gonna commit those changes and then you're gonna do something else. Okay, so compilers and build process, you're not really using compilers on the web. Unless you're coding and go, you're not compiling. You might, however, be doing something like transpiling or backpiling, some people even say. And so what I mean by that is right now there's JavaScript, there's ECMAScript 2015, there's ECMAScript 2016 and not every browser supports all of those things. If you've done even a little web development, you know that support across browsers is inconsistent. So what you wanna do here is say you want to be able to write the latest and greatest version of JavaScript. Say you wanna use all the niceties of ECMAScript 7 but most browsers only support ECMAScript 5. Okay, so you can write ECMAScript 7 and you can use a tool called Babel from Google or Tracer, gosh, they may have changed it. Apologies, there's a tool out there that Google has released that will allow you to write in the latest version of JavaScript and then before you deploy that to your web server, it will backpile, it'll translate it to ECMAScript 5 so that you can be using the latest and greatest technology and the modern language features without having to cater to the lowest common denominator in terms of browser support. That's about it in terms of compilers on the web but the build process is something that I wanna speak to for a moment here. Now in software engineering, compilers and build processes are like, that's bread and butter, like that's really central. On the web, it hasn't been that way for a long time but now we're seeing a proliferation of tools and preprocessors and all this madness that's going on such that you want a build process. Now let's be clear, all along when doing web development, we should have had a build process that involved running tests against our code. That wasn't often common. So now, for instance, we have something called SAS and SAS is a superset of CSS and what I mean by that is, you can do things in SAS that you can't do in CSS but anything you can do in CSS, you can do in SAS. For instance, you can define variables in SAS so I can say my accent color is this blue and then I can have in the rest of the SAS, I can reference that again and again and again. Hell, SAS even allows for some basic formulas and stuff like that but the browser doesn't read SAS. The browser reads CSS. So what I do is I write SAS and then part of the build process is translating that SAS to CSS that's actually gonna be delivered to the browser. So the build process is relevant in terms of the preprocessing before you deploy something. The build process is also relevant in terms of testing. Build process is also relevant in terms of managing dependencies when you're doing crazy things in JavaScript land. I mean, if you looked at, okay, I'm gonna choose not to go down that rabbit hole because that would be a dangerous one here but definitely when you are working on anything that's more than brochure aware, if you've got more than a static website with HTML and CSS, consider implementing some sort of a build process even if it just includes testing. Okay, so moving merely along to project management. My number one piece of advice is choose a tool and stick to it. I made the mistake of in the 14 years that I was mostly doing freelance was I was always chasing the dragon, chasing the newest, shiniest tool that everybody else was talking about from base camp to Asana to Trello to God knows what. Pick a tool and stick with it because the reality is no tool is gonna be perfect for you and every tool comes with opinions. And so you just wanna find the one that has opinions that are best aligned with yours and then learn how to use that system. So I found now that I'm at O'Reilly and they tell me what tools to use. Okay, I'm now a pro at Asana. I spent six months in it and now I have habits that are built around it and it just works. So try to avoid falling into the trap of constantly searching for the next tool. So project management is more than just project management tools though. Not only are those the task management tools, there's JIRA and sort of the ticketing systems out there that you can also use as a project management tool. But there's the methodology. What methodology are you using to manage this project? We have on the two ends of the spectrum, we have iterative processes, agile, quote unquote, and the waterfall methodology. Now there are people who throw agile around like it's some sort of like miracle drug. Agile's not gonna fix your problem. No process is gonna fix your problem. No tool is gonna fix your problem. And really, there's almost no such, okay, well that's too bold. There's no such thing as like a pure waterfall system. I mean, in reality, you often have a combination of this waterfall methodology and this agile methodology. Okay, so I've thrown those words around. What the hell do they mean? Waterfall. Waterfall means that I am, say, I take the client's specification and let's rewind 10, 15 years and say we're working on a small business website. I take the client's specification. The designer puts together something beautiful in Photoshop. They throw it over a wall to me and I will code the front end and then I throw it over the wall to somebody else and they'll code the back end and then they throw it over the wall. They throw it over to the copy editors and then they throw it over to the marketers. So the whole point with waterfall methodology is that you have these critical bottlenecks, right? Where one person, one department is owning a project and working on that stage of the project and then throwing it to the next. The reason that this can be a problem is that information gets lost in translation, right? So the designer may have read the client's spec in one way and I might interpret it in an entirely different way. In reality, if all of us were sitting around the table with each other, we could probably hash out what the client really meant. And in fact, we could bring to bear our collective expertise to not only determine what they meant, but what they actually need, which is another thing entirely. So waterfall is this thing that happens especially in tightly controlled environments. Iterative, by contrast, is something where you say, okay, we're gonna work on this feature for two weeks. And we're going to just do the best we can and within that iterative process, there's gonna be some design, there's gonna be some development, there's gonna be some copywriting. But at the end of that, two weeks you're done. And maybe at the end of that, you say, okay, we didn't get as far as we wanted to, so we're gonna spend another two weeks working on that. And you just keep going around and around this iterative process until you end up somewhere. And so this is the, perhaps one of the things to watch out for with agile development is while it does allow you to change as the projects needs evolve, because projects will evolve, it's also, it doesn't work in con, like okay, NASA is not using iterative development, right? Like they know exactly what those rockets need, they know exactly what those satellites need, and so they're gonna write exactly to that. In other places, you know, you don't necessarily care about getting to that exact outcome, you really care about getting something that works for whatever definition of the word you're going for. Anywho, waterfall, iterative, agile, know that neither is a panacea, neither is the bee's knees, you're gonna have some combination of the two and just find what works for you given the type of project that you're working on. Distributed developments, so increasingly we're working remotely. How many people here work from home? Right? Yeah, same, couple days a week. And working from home or working in a distributed team is different, you're not there to bounce ideas off each other necessarily, you're not there to have a random brainstorming session. And so there are tools that you need to help with that, and there are disciplines that you need to help with that. And it's not just about you, it's about the company that you're working within too. You know, there are companies who do really well, they have a great remote work culture, others not so much. So with distributed development, you need to think about, okay, what tools are we using to make sure that we do have an opportunity for random brainstorming, that we are available to each other to ask questions and ask for support when we need it. And that could be saying, okay, well, we're gonna work whatever hours work for us because we're all over the world, but you know, every week we're gonna have a standup or we're gonna have a block of time where we're all available together and so that we can be available to each other. So just know that when you are working in a distributed development environment, communication is harder, you have to really put the effort into it. And testing becomes all the more important. Testing is always important, but especially when you're in a distributed team. There is a free book from O'Reilly, our CTO, Andrew Otawan wrote it, it's called the Distributed Field Guide to the Distributed Development Stack. And I'll have a link at the end of the presentation so when you get the slide deck, you can find that. It's really useful and it really just goes over a ton of different tools and ways that people are coping with remote work and distributed development. Okay, questions? All right, I had a feeling there wouldn't be many questions after this section. Moving along, the web and practice. Okay, I've talked about LAMP a little bit. If you wanna go from zero to employable in the quickest amount of time, LAMP is like the demand for LAMP work is everywhere. However, there are also a lot of LAMP developers. So they are kind of a dime a dozen, I'm one of them. So when you're looking to do web development, you're gonna hear a lot about LAMP, you're gonna hear a lot about WordPress. WordPress runs a god-awful amount of websites. Actually, it's fantastic, WordPress is an excellent tool. Ditto, Drupal, Joomla, these PHP-based content management systems run a lot of the internet, a lot of the web, and generally they're all running on Linux, Apache, MySQL, sometimes Engine X, different web server now. So my point with I Love LAMP is if you wanna get into web development and you want to be able to get started quickly and maybe then evolve as a web developer and find that next step, WordPress, Drupal, LAMP, PHP, this is a really good starting place. There's a ton of information out there about it, but remember that you don't wanna stick with LAMP. You wanna evolve beyond that because there are so many LAMP developers, the pay is not as great. Just gonna be perfectly honest, the pay is not as great as if you were, say, a Python or a Ruby developer, but you can start quickly and that's what's really nice about LAMP. Last little thing I'm gonna say about LAMP is that because it's been around for so long and because there are so many of us who are familiar with that stack, there's a lot of crappy information out there, right? Like give everything the smell test because there's a lot of bad advice, there's a lot of old advice, so make sure you're looking at what's the latest and greatest and a trustworthy source. One of the reasons people say PHP sucks is for the same reasons they say Perl sucks is because there's a lot of crappy code out there. That's not the language's fault, right? So just like engage your critical thinking when you're looking at the code tutorials and especially with LAMP. All right, frameworks and CMS. When you're doing web development, most of the time you're not writing something from the ground up. Unless you're building a one-off tool or a script for yourself, you're not writing something from the ground up. You're not opening a text file and starting from zero. What you're starting with is Symphony or Sylex or Rails or Sinatra and those are all frameworks that give you certain things. So Rails is an MVC framework, a model view controller framework and that means that you will define your data models in one part of the framework and then you will define how that webpage looks in another part and you'll define the logic in yet another part. So what a framework does is it comes with, usually comes with a standard library, right? So there are features or functions that are built into it that you're gonna need. But a framework will also come with, again, opinions. Okay, if you want to look, if you wanna see a good example of people not understanding that each framework has an opinion and you wanna use the right tool for the right job, just Google Angular and Ember, right? These are two JavaScript frameworks and one is far more opinionated than the other and they're both excellent. They're both fantastic, but one's right in some circumstances, one's right in others and it depends on you as a developer and what you're trying to build and what the rest of your team is familiar with. So when you're choosing tools, again, right tool for the right job. Frameworks are fantastic because you can get started very quickly. Like I said at the beginning of the presentation, there's the whole APIs, right? There are all these really sweet things that come bundled that you can tap into easily that other people are providing. Well, frameworks are another thing that give you power that you just, I mean, you can go from zero to 60. Rails, for instance, is used often Ruby, Rails is a Ruby framework. Rails, for instance, is often used for rapid application prototyping, right? So say you're part of a startup or you're working, contracting for a startup and they don't exactly know what they want and maybe they don't even need the most performant thing, they just need a proof of concept. Rails is great for that and Rails is good for other things too but this is just one use case. So CMS, CMS is a content management system. That's like a framework on steroids. It comes with a lot more. So for instance, when I install WordPress, not only am I getting this, you know, this system that allows me to add on functionality but it comes with the notion that I'm gonna have posts and pages and users and it has a templating system. It has a module ecosystem so I can just pick from a bunch of extra functionality and build really quickly. WordPress and Drupal and some people say Django is a CMS but really I think it's a framework. Whatever, it's all a continuum and when you hear CMS, just know that it's probably got a lot bundled in it. Now when you install a CMS, sometimes you're gonna have this big fatty package on your server and you have to use all of it but more often than not, it just comes with a lot and you can remove things, right? So with Drupal, Drupal has done a fantastic job of allowing you to peel back tons of features that you don't need. And so because of that, people use Drupal and WordPress, sometimes just as the backend for their website, right? So one of the nicest things about a good CMS is that it has a good authoring experience. What do I mean by that? Okay, so we're building the website but who's gonna maintain it? All right, like who is the person who writes the content for that website? If that's not a good experience for that person, then we probably haven't done our jobs very well. So this is why WordPress and Drupal are fantastic, specifically WordPress though. WordPress gets out of the box author experience, right? Like nobody else does. And this is why it's so pop, one of the reasons it's so popular. So what we have a lot happening more and more often now is because those have the best author experiences, someone might install WordPress to be sort of the back office solution, right? That's where they manage the content of their website. That's where they manage the users. But it could be that they have a node application that's actually consuming that database and rendering that to the client. So what I'm describing here is called the headless CMS, right? Because the CMS is now working fully on the back end. It's not even necessarily shipping CSS or content to the front end. You've got some intermediary that's pulling stuff out of the CMS and shipping it. This gives you more flexibility. Frankly, CMS are often not the most performant tool in your toolbox. And so being able to decouple that from the client end user experience can be a really powerful thing. All right, progressive enhancements. I told you we would get to this. Progressive enhancement is the notion that you build a foundation that will work for as many people as possible and then you layer on the extra features, right? So you build first your HTML website, your plain HTML website that works all right if you're using a line mode browser and a screen reader and it's very easily read by Google. But then you will add your CSS, right? Because maybe your designer has prepared some style tiles and so for all the people who have CSS supports, you want them to see a nicer looking version of your website, right? Okay, so say they not only have HTML and CSS but they've got JavaScript. Okay, great. Well, now you can layer on certain new types of functionality, okay? But do you have everything enabled in JavaScript, right? Because JavaScript will give you access to a microphone, to a webcam. It can make things go full screen. You could do local storage. There are a lot of things you can do with JavaScript and people can turn off bits of them, right? So it may not be that JavaScript is completely gone or completely enabled. It may be that you're in this quasi-state where some things work and some things don't. So progressive enhancement is the notion that you will build a foundation that works for the most people possible and you'll layer on these niceties. There are ways to do this. This is not the recommended way but one way of doing this is feature detection. Actually, some people say it is a recommended way. Feature detection. So I might have something, a JavaScript library in the browser that when it doesn't run, well, great, I know there's no JavaScript and so there we have it. It might also recognize that we're running an older browser that doesn't support using your webcam or your microphone. So if it has detected that those features aren't available, maybe I have a fallback. Maybe I have a fallback that's written in flash that that browser can use. Not that you should do that but that's an example. So progressive enhancement will give you the, it will give you the ubiquity that the web promises. That's really the sweet part of the web is you can get everywhere, right? And because you have built something that works when it's just HTML and just content, great, I can look it out on my phone. I can look it out on an email. Hell, even Apple, you know, you can even scroll through content on your, on your watch sometimes. But then, you know, people who have those, the extra capabilities can get the better experience. So that way, nobody's getting a crappy experience but some people are getting a better experience because they have machines that support that. Now progressive enhancement is not just about what language or features are enabled. Progressive enhancement is also about, I mean, let's just think for a moment like bandwidth, right? We're all lucky to be here in the states or at least in the LA area where it's pretty damn wired, right? We've got broadband in most of California and in the metro areas we have excellent broadband. Hell, there are other countries that have way better internet that we do. But most of the world doesn't. And where I'm from, Northern California, a lot of us are still on DSL or some of us on dial up or satellite for God's sake, right? And most of the world, frankly, still is. So what you have to think about is not just what features are available to me but how much bandwidth does this person have and not just how much bandwidth but what's their latency, right? So bandwidth is like how big is the pipe? Latency is how quick is the stuff moving through that pipe. So if I have a, let's say I've got a form and somebody clicks a button, well, the expectation is that something's gonna happen within about 200 milliseconds or less. If something doesn't happen within that time, someone thinks there's a problem, like, okay, what's going wrong here? So with that in mind, knowing that some of your users may not have the great internet connection that you do, you can say, okay, well, when it's taking longer than expected, I'll throw up a little loading gif, whatever it is, or you just decide not to use a five megabyte image as your background, right? This is one of the things that we're seeing happen more and more is just we've got so much goddamn JavaScript. We have so many images and it's way too easy to assume that everybody has the connections we do. So think about that. Think about the fact that you really only can rely on HTML and HTTP and think about the fact that not everybody has the connections or capabilities that we do. And just so you know, progressive enhancement isn't just gonna give you access to the widest possible audience, it just makes sense. It helps with accessibility, for instance. So moving on to accessibility. Accessibility is your user visually impaired. Are they hearing impaired? Maybe they don't have all four limbs or they don't have the same use of their digits as you do. So accessibility is how can these people use your websites? And this is important because 10% of the entire world population relies on some sort of assistive technology or they have some sort of disability that makes them rely on assistive technology. So for instance, for people who are blind or otherwise visually impaired, they use screen readers and a screen reader will read the screen. And so there are ways to build a website that makes that a really great experience or at least not a really bad one. And so this is things like using alt tags and title tags and ordering things in a reasonable way. This is having a back to top link or a skip navigation link that may not be visible to the user who is looking at your website but is read out to the person who's listening to your website so that they can skip over all the bullcrap in your header that they are, when they want to get straight to your footer or your content. Accessibility is not just about vision and hearing and touch though. Okay, well actually this is more about vision. There's color blindness too. A lot of people are color blind. And so you also have to think about the color palettes that you're using. Now I'm gonna heart back to something we were talking about earlier about iterative development. If everybody is sitting around the same table when something is being built, say you have an accessibility expert or say you just have a developer who understands accessibility and you have a designer who doesn't. Okay, well because you're all at the table when the designer puts forward a certain color palette, you might be able to say, hey you know what? I think people who can't really tell apart red and green are gonna have an issue with this. And there are tools for testing these things too. There are excellent tools out there and I'll add those in the links when I upload the talk. So accessibility, building your website in an accessible way, not only means that you have access, those, that 10% of the population that needs it has access to your website or web app, but it also means that you, you will have access to that website or web app because guess what? We're all gonna need assistive technology eventually, right? We're all gonna go blind, we're all gonna have, someone's gonna get thrown under a bus, like shit happens, right? So be kind to that 10% of the population that needs that stuff, realize that you want their money as a business person and also know that you, your future self is going to need it. So one thing, last thing I'm gonna say about accessibility is this. Some people say that accessibility is a feature, but personally I'm of the school of thought universal design where lack of accessibility is a bug, right? If your website's not accessible, it gives these, these, these are bad experience. That's a bug. It's something to be fixed. All right, security. You know, we web developers have it really good. We're working in high, high level languages with tons of abstractions beneath us that we don't have to worry about. Rarely are we gonna have to worry about garbage collection. You know, you don't necessarily need to worry about buffer overflows and all kinds of madness that you would have to worry about if you're doing, you know, C++ or anything below these web languages really. So that means there are some security things that we don't need to worry about as much. But that doesn't mean we don't have to worry about security. Security is a matter of protecting ourselves in our own business and also protecting your users and protecting their identities, right? I can't remember a month in the last couple years that I haven't heard about some giant data breach, right? That sucks. And our users should be able to rely on us. We should be able to rely on each other to build technology, to build applications that are gonna protect us from those things. So I'll talk about it a little later. This is, you know, at least one of the things that you can do for security. But just know that it's not something that you can ignore. Just because you've installed a framework and most of the stuff that you're using isn't written by you, it doesn't mean that you don't have security problems that you have to look after. The number one reason most applications, most websites get hacked is because they're not updated. So if you're using WordPress or Drupal, maybe you've heard of Drupal Get-In. Every once in a while, there's like a zero-day exploit where we realize, holy crap, somebody can run arbitrary code on my server if they do X, Y, and Z to my Drupal install. That's horrifying. Not only could they clean out, totally mess up your server, but they could steal the data that's on that and make a world of trouble for your end users. So when you are working with, you know, as a developer, there are best practices for the way you code that will help you with security, but just know that even if you're not coding, if you're installing WordPress or Drupal, whatever it is, update it and stay on top of those updates because they happen quickly and know especially if you're using WordPress that you really need to run those updates because guess what? There are bots all over the internet pinging every damn IP address and domain name, trying to figure out if that's a WordPress install that's a version that's exploitable. So you don't want your website, your out-of-date WordPress install to become part of the next botnet. I failed to update a Drupal install once on, once, only once I promise, on a media temple server and then I realized at the end of the month that I had just gotten billed for $400 and my server only cost me 50 a month normally, so I was like, okay, what happened? Clearly I wasn't paying attention. Sure enough, someone had used my out-of-date Drupal install to set up my machine as one of many nodes in their giant botnet and my machine had been working around the clock to send email and spoof pings and just all kinds of BS to who knows what that target was. So again, when you are writing code there are things to do to make sure that that code is as secure as possible but also when you're installing things, updating it, you have to do it, it keeps it secure. Last little bit about security, there's no such thing as perfect security. So we just have to keep trying and we have to stay on top of that game and ideally we will know experts who can help us with those things and yeah, security, it's really freaking important and web developers, we get it wrong way too often so please pay attention. Okay, SEO and shareability. The marketers love this stuff. You should too because when they're happy, often you're happy. SEO and shareability are really about search engine optimization so how well does your page, how well is your page understood by search engines, right? So when I have that HTML, am I using the header tag? Am I using the H1, H2, H3, et cetera in such a way that a search engine can realize that okay, this page is about domain names and okay the subsection over here is about running a running bind or whatever it is, it's a table of contents and not only is a good markup a table of contents but good markup with good writing will have key words in there. Now, search engines are much smarter than they used to be and we don't need the keyword stuff things and you certainly shouldn't because that's just, that's black hat marketing but you do wanna make sure that if you're writing about domain names, that domain name shows up somewhere on that page preferably in a title or a header tag. So SEO is about alt tags, title tags, using headers, using the H1 through seven tags well. SEO is also about yes, it still matters, your meta tags, that meta description is still what search engines show and if you don't define a meta tag then they're gonna show whatever the hell they pull up on your page and it may not be what you want. You may have seen a Google search result once or twice where they are, the description is a bunch of navigation links. That person failed to put a meta description. So use those tags, they're important. Shareability is related here. Shareability is how well does your website show up when somebody drops that URL into Facebook or Twitter or LinkedIn, whatever it is. Do you have open graph meta tags? Those are the meta tags that Facebook helped pioneer and do you have Twitter card meta tags? There's just a ton of stuff out there and really you only need to cater to a few social networks and you'll get most of them right. There's an important point here though and that's that progressive enhancement, accessibility, SEO and shareability all go hand in hand. If you build a website that's progressively enhanced, well it's gonna be search engine friendly and it's gonna be basically search engine friendly and then there are things you can do to make it especially search engine friendly and it's gonna be shareable. So when you build with those things in mind you're making it easier on yourself in all of those other areas. So when you do something the right way these other things get a little easier. Dealing with the uncertain web, it's a little easier. Catering to those users who need assistive tech will easier. Okay, so I'm running a little long so I'm gonna try to speed up here. Intellectual Property, we're an open source conference. I really don't think I need to talk to you all about that but let's just be really clear. Don't steal people's stuff and ask for permission to use it when it's not clearly public domain or when it's not a clear Creative Commons license. Intellectual Property is critical here especially if you're using a framework or CMS know that you're not selling your website your client a website or web app. You're selling them modifications on this code. So you can't sell Drupal, I can't give you a Drupal. That's a GPL code which means that's not something that I own and just because I'm building a Drupal based website for a client doesn't mean that suddenly they own all that code either. They might own the changes I've made. So just know that when you're writing contracts these are things that you might need to think about. A designer's contract for instance will say things like hey we're just licensing you the image or the graphics that we created. You can use them however you want but just know that we still own them. No there are wrinkles like that when it comes to intellectual property so it's something to look out for. Okay, questions? Yes please. Yes, so excellent points, thank you. It is all too often that a developer will go into something and see meta tags and stuff that they might think is fluff and they might tear that out. Don't do that. Don't just go in and nuke everything because you don't think it belongs. But the other point that he made which is really valuable is that oh my gosh brain fart number three, 90 minutes this is tough. What was the second thing you said there sir? Yes, writes. Miguel? Yes, so what Miguel and our friend over here have said is that if you are working as a federal contractor if you are working for a government agency in the US specifically, section 508 is a set of accessibility requirements that you are required to uphold. Now section 508 is a decent baseline but there's really a lot more that you can do in accessibility so look at that as a starting point. All right. Stacks, so like I said we're running a little long so I'm gonna have to speed through this and that's sad because this is one of my favorite sections. So what I'm gonna say is that JavaScript is everywhere and it's blowing up. Not only is JavaScript operating in your browser now and the client side but sometimes it's operating on the back end like in Node.js. Sometimes it's running robots. You know whatever it is, JavaScript is expanding into every little corner that other languages have been in. JavaScript is a increasingly modern language. It is a versatile language like many of them here where you can code in more or less functional styles or object oriented styles. You could code in procedural styles. Really most of these language support multiple paradigms of development but what's beautiful about JavaScript is it is available on the client side most of the time. And when you have the ability to also use it on the back end you can eliminate complexity from your project. Okay so software engineering, web development really what we're doing is I mean we're managing complexity and so when you can say I'm gonna define this data model once, okay. So here's what a user looks like. Here's what the user's fields are. You know the username can't be less than eight or more than 15 characters, things like that. If I can define that data model once, I can write that constraint once and have that apply everywhere then that saves me time as opposed to saying having that constraint in JavaScript in the browser and then on PHP in the back end. So when you use one language for these things you can share code which makes the whole thing simpler. That said and this by the way using JavaScript on the front end and back end is some people call it isomorphic JavaScript. Mathematicians seem upset about that so a lot of people are now calling it universal JavaScript. I think it's great using it on the front end and back end but I think the reality is most of us are still gonna be working with other languages. It's rare that you get to go into an environment and say alright these are the languages we're gonna use because it's the simplest cost effective thing. There's always gonna be legacy technology or other considerations. PHP, I've talked enough about PHP. It's ubiquitous and you know it's not running on the client side but because of shared web hosting and the explosion of lamp shared hosts it's everywhere and the thing to know about PHP is it's like JavaScript and so far it's a pigeon or a creole I can't remember. Anyhow basically these are like languages that are built and designed by programmers who wanted features that were in other languages. So you know C and C++ like these are early languages, green-filled, these are secondary tertiary generation languages that have features from lots of different places influences. That's nice because they're versatile. What's nice about that is that makes them versatile and often they have niceties that others won't. The challenge is that they can be inconsistent or quirky. Sometimes the syntax is a little weird, whatever it is. Okay, moving on from PHP. Python and Ruby I think are the two most lucrative, two of the three most lucrative languages for a web developer. PHP is great for starting but Python and Ruby and JavaScript are really where it's at for the long term is my belief. Go is blowing up but no one knows where it's going. Yeah, that was the thing. JavaScript, PHP, Perl and Go, those are all C-based languages. There's a syntax there that is familiar between all of them. You've got your curly braces and your semicolons and all that madness. Python and Ruby are more like basic insofar as it's, I mean you're reading it mostly and Python hell uses white space as opposed to brackets. So those are two things that set these languages apart but they're also just used in different ways in different contexts. I think that all of them are lucrative in one way or another but as if I were going into web development as a new developer I would focus on JavaScript, PHP, Python and Ruby and PHP only in the short term. PHP 7 is awesome but I still see Ruby and Python only blowing up. All right, if you have more questions about the specific languages I'm happy to talk about that after the presentation. Gotchas, rise of the expert beginner. It is easy to think that you know more than you know. As a skilled PHP developer who used Drupal a lot I had a lot of opinions that were totally bunk that I didn't realize until I started exploring what else was out there. If you Google rise of the expert beginner there is an excellent article, excellent article that I highly recommend and it really comes down to how you learn as a developer. If you're another thing in terms of learning look at Kathy Sierra making badass users as her book she also did a talk at Fluent. It's basically how to learn. Kathy Sierra, Kathy Sierra, yeah. Okay, just don't fall into the trap of being a beginner who thinks they're an expert. JavaScript required, we talked a lot about that. I don't think I need to belabor that. Photoshop first is not so much a problem these days but back in the day, back in the day when a designer would first get the project or a marketing agency would get a project well they'd give it to the designer and they'd build something beautiful and they'd ship it over to you. The reality is Photoshop isn't as multi-dimensional as the web is and you can, if you try to design a website in Photoshop and then go build it you're in for a world of pain what you really want to do is ask your designer to prepare style guides, style tiles, things like that that you can apply to the website or web app that you end up building. Bloat, we talked about that. Be careful with your image sizes, compress them, use the right image format for the right thing. PNG if it's low color and maybe you need alpha and JPEG if you have a photo. But also know that you don't want to use megabytes of JavaScript or for instance you don't need jQuery if all you want to do is have a very basic interaction on the site. So don't use a library when all you need is to write like five lines of code. Documentation, well these last three I have other slides for. I don't know how readable that is. This is a quote, Martin Golding. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Sometimes that violent psychopath is you, right? I mean you write something now and then a couple months later you go back to it and you're like what the hell was I doing? So document your code. Little Bobby Tables, this is input sanitization. Never, ever, ever trust inputs. So input sanitization is okay I've got a form that accepts username, password and email address. If I'm not doing input sanitization on those things and I'm for instance sending the results of those into an SQL query, oh my god, they can blow up my database if I'm not doing input sanitization. Reading comics isn't fun so I'm not gonna read that to you but Little Bobby Tables is an excellent XKCD comic about remembering to sanitize your inputs. The law of leaky abstractions, Joel Spolsky, another great person in the world of software who has a lot of valuable information. Remember as web developers we are working on high level languages and really high up the stack and so it's easy for us to make, if we don't understand what's happening below us in that stack it's easy to make mistakes. I learned about the law of leaky abstractions in terms of Drupal 8. So in Drupal 8 they were proposing having not just a rich text editor but a whizzy-wig editor, right? What you see is what you get editor. So that I, as the owner of bobsburgers.com, I can go in and I can go to the homepage and log in and I can say, okay, I just wanna click on this header and update the text. I wanna click on this body of content, update the text. Right, like me as Bob, I'm not going over into this admin area and then finding that page in a list of things, I'm just clicking on that page. And so the problem that was brought up with the Drupal community in terms of implementing a rich text whizzy-wig editor was that there are all manner of things that you're not gonna, that I, as Bob, I'm not gonna consider when I'm editing that page, right? I may not know how the content changes are gonna reflect in the meta tags. I may not know how that content is gonna look on a mobile device versus a desktop, you know. Just know that the higher we go and we're only going higher, I mean the more complex the things we build, the higher we need to go in terms of abstractions. Just know those abstractions leak. It's important to understand what's happening below you in that stack. The challenge now as a programmer, as Joel nails here, is that when we get to that point where we're doing web development, it's great. But to get there is harder than ever because you really need to learn a lot of things along the way. All right, what next? Yes, we are at the end. What next? Follow the web's best. Seriously, find amazing people. Some of them I've mentioned. Kathy Sierra, Joel Spolsky. Eric Meyer, Rachel Nabors. Eric Meyer has been a champion for web standards, especially within CSS. Rachel Nabors is like a queen of animation. She was a comic book artist and is now a web developer, sort of bringing the animation and web communities together to make sure there are APIs to do cool graphical stuff. Jacob Nielsen, forgot the name of his site. It's alert box or something like that. But Jacob Nielsen is a usability wonk. Not everything he says is 100% accurate, but that's true of all of us. He has a lot of good things to say, really useful stuff about guidelines of how quickly your website should respond and just tons of great usability information. Jen Simmons gave, great last name, right? She gave a great keynote at Fluent 2014, a love letter to HTML, one of my favorite keynotes that she's done. Jen Simmons is just another excellent person. She has a podcast she hosts called The Web Ahead. Kyle Simpson. Kyle Simpson is the JavaScript guy. Okay, well, there are lots of JavaScript people, but he's one of them. Kyle is fantastic. He wrote a whole series of books called You Don't Know JavaScript that really dives into the internals and looks at it. Those books are all, okay, O'Reilly sells those books, but if you go to his GitHub page, they're all there for free as well. Kyle Simpson is excellent. Leah Verrou, she was with Mozilla, she may be, but she is another person who has spent a lot of time making CSS awesome for the rest of us. She has a recording where she shows just how magical, something as simple as border radius can be in CSS. You have no idea what you can achieve with simple things like that, until you see what she does. Estelle Weil, she wrote O'Reilly's book on mobile HTML5, and something to know is that HTML5 isn't just about HTML, HTML5 is about JavaScript because suddenly you have these APIs for getting local storage or getting access to, all right, the brain parts are just gonna keep coming, but the bottom line is HTML5 is related to JavaScript. They're inextricable. Estelle Weil has a lot to say about that. And then Luke W, because I can never pronounce his last name, he was the guy, he was the person who helped us realize that, hey, responsive design is a thing, we really need to think about mobile devices, and sometimes we need to think about mobile first. Join the community. This is the meetup group that I founded up north. I'm preaching to the choir here. You're already a part of a community. You've come out to a community conference. Check out your local meetup scene, just get involved online and offline. There's, this industry moves so goddamn fast. The only way to stay abreast of it is to rely on a social network of other smart people. So be social and keep learning. Give back, open source, standards bodies, pro bono work. There are lots of ways to give back as a developer. Get the work. There's no better way to learn and then to make those choices about, okay, well what languages are gonna be best for me? There's no better way to find that out than to just start. And never stop learning. Books, blogs, videos, courses, boot camps. Conferences, both community and corporate. Conferences, both regional and national. There are so many opportunities to learn. Get out there. So there's one thing that I haven't talked about and that's when not to use the web. Like when is it not appropriate to bring web development skills to bear on a problem? Well, the way that I look at it is you can do just about anything with the web. But you probably don't want to. With the web, if the features you are using are cutting edge and they are not well supported by the browser, not well supported by the technology that your target market uses. So if my target market is people in Kenya, for instance, well then I'm really concerned about these things working on their mobile phones. And those may not be smartphones, those may be feature phones. And so just the technology selection is always a function of what the project is, what the market needs, and what legacy technologies are already there. And lastly, what the rest of your team is comfortable with. Don't use the web when the features are too cutting edge. So just because you can get to the mic or the webcam from JavaScript, if you have a user base that's not likely to have modern browsers, well then you probably don't want to use those. Sadly, you might want to use Flash or Silverlight or something, difference. Hell, you might want a native application. Last thing I'll say here is I like to think of native development, right? Like Riot coding in Swift or Java or like .NET. I like to think of native development as the testing ground for what we later blend to the web. Because we didn't used to be able to use webcams and microphones with websites. These are new features. We didn't use, we couldn't use to, it was not possible to render 3D in the browser. Now it is. All right, a question, last question. What the project is, what the technology your market has, the legacy technology that may be in place. And lastly, the technology that your team is familiar with. So those are all four things that you're gonna look at when you do technical decision making. Okay, I promise free eBooks. Here they are. So I know this is hard to read. O'Reilly, like bit.ly, but O'Reilly slash scale webdev. There are 12 books there I've picked that are all relevant to what we've talked about today. There are some that are really like nuts and bolts and some of them that are more heady pick a choice. Let me know what you think, write a review if you will. And the last thing is if you are interested in what O'Reilly has to offer in terms of these learning opportunities. We have O'Reilly Fluent, which is our web technology conference in San Francisco that is happening in March. You can get 20% off of Fluent with CM scale. I'm not gonna lie, these are not cheap events. I was never able to attend corporate conferences until I worked for a corporation. And the sad thing is that freelancers and independent contractors can't often afford these other conferences, which is why events like scale are so goddamn awesome. There, even if you can't make it to Fluent or OSCON, which is our open source conference, even if you can't make it to that, you've got scale. And then there's Drupal Camp and Sand Camp and Glad Camp and Word Camp and, look, there's a conference near you and there's probably one that you can afford. And I will say this, conferences are not just good for the learning, they're great for the networking. The first conference I went to, my God, I wish I'd gone to a conference way earlier in my career because it's like rocket fuel. It's inspiration, it's connection, it's learning. Yeah, so 20% off Fluent or OSCON with CM scale, free eBooks, if you have questions, feel free to ping me. I'm on Twitter and IRC. I think I've done enough talking. Thank you so much.