字幕表 動画を再生する 英語字幕をプリント [Nick Pettit]: Paul, Thanks so much for being here. I really appreciate you coming out. >>[Paul Irish]: No problem. [Nick Pettit]: So, for people who don't know who you are, how would you describe yourself? Who are you, and what do you do? [Paul Irish]: I am a developer advocate on the Chrome team right now, and so I kind of focus on--that encompasses a lot, but I focus on everything I can do to make it better to create compelling content for the web. We've got a lot of great content inside of Chrome. I wanted to help educate people about that, help people understand how to use things like the Chrome DevTools better. I also come with a big history of front-end development and open-source projects that I work on to help developers learn what they need to know to do better front-end development, make better websites and web apps. [Nick Pettit]: That's awesome. You're involved in a million different projects. You're doing Modernizr, HTML5 Boilerplate, which I use all the time by the way. You've been on the jQuery team, and you've made all these really handy tools for front-end devs. This might seem obvious, but what's the motivation for working on all these different things? [Paul Irish]: I think part of it is basically that I feel a lot of satisfaction helping other people, and so part of it is just that. Also, the other thing--I think this is actually another part that's happened-- is that I have a really bad memory, and what that translates into is if I don't write something down, I'll forget it. So, this happened in front-end development where you learn this technique of using media queries or the viewport meta, and you need to keep track of this because this is the right way to do it in this situation. So, that eventually translated into what became the HTML5 Boilerplate project, where a lot of best practices were distributed all over on blogs and books and things like that, and I was just like we need to get this together just to keep track of it; so I can keep track of it and remember to use it on the next project. So, that's helped me a lot and has helped other people. The other thing for me that really drives me is that I want the web to be where people build great things. I'm just really excited about anything that I can do to help make the web be a stronger platform for making great, really cool stuff. [Nick Pettit]: So, you're very diligent in tracking all of these different things? [Paul Irish]: Because I can. [Nick Pettit]: How do you balance your time working on all those different projects? [Paul Irish]: I don't have a good mechanism for time management right now. I use a really cool tool called, 'WorkFlowy,' which is like a super-enhanced to-do method list app. It's really cool. I set up priorities for myself on a quarterly basis and try and get them. I think that's actually quite important, which is to have a longer-term view of what you want to attack, because it's so easy on a daily basis to be totally distracted and just be like, "I want to play with this new thing and get it done. Oh, wow, something," and then you totally forget that you have this much larger, higher-impact thing that you should be doing. So, it's hard, and I'm still really bad at time management, but I'm working on it. [Nick Pettit]: I know what you mean. With being involved with so many different projects, I guess you kind of have to keep a big-picture view as to what all those things are working towards. [Paul Irish]: Yep, and what the priorities are. Yeah. [Nick Pettit]: Cool. So, before we continue, I want to back way up and just get some of your history. Where did you grow up and what were you into? [Paul Irish]: Sure. I'm from Western Massachusetts and Connecticut. So, I'm from New England where we say, 'wicked,' 'It's wicked cool.' [Nick Pettit]: Wicked. [Paul Irish]: I was into music. I was in the marching band; I played the tuba. I was into drama. So, I was a band and drama kid in high school. I was really into music and, in fact, the first time that I really got going online was I created a music blog. This was in--I put it out in 2004, and I thought I was so late to the music blog scene, but it turned out that I was one of the first 50 or so. Having that environment where I had a website that had a lot of traffic, and I could play with the design and experiment and get a lot of feedback on how people liked it, that was one of the first times when I was really like, This front-end development thing is a lot of fun. [Nick Pettit]: That's when you first became interested in the web and technology? [Paul Irish]: That was when I was like, this could definitely be full time. I'd been playing with websites. Back when IE4 came out they did this really cool marketing campaign. This was when the DHTML term arrived, and so they had this marketing campaign where they rented out all these movie theaters across the U.S. and invited a bunch of developers, and I went and I got free popcorn and a free t-shirt and a free Windows 95 install CD, and they showed about what you could do in IE4, and it was amazing. So many great features came out then, and so that was when I was like, this interest of mine, there's cool stuff in here. Eventually, it quieted down. I went to college, but after that everything picked back up again. [Nick Pettit]: So, did you go to school for this stuff? [Paul Irish]: I went to school for-- I got a degree in technical communications. I don't actually know-- I really do wish that there was more university-level coverage for web development. Front-end development is hard, and it's a pain, and I wish that there was a more sophisticated education program for this. I got education in computer science and mathematics, and management and communication. [Nick Pettit]: With us being an education company, I'm interested to know if you feel like your degree really helped you in your career, or--? [Paul Irish]: Mine did, and I think these days having a computer science background has a very direct effect. I wouldn't say 5 years ago that computer science would help in web development, but nowadays, especially on the client side, there's so much logic there. You're writing jQuery, things are going good, you're translating, you're writing larger applications. [Nick Pettit]: It's getting complicated. >>[Paul Irish]: It's getting real complicated. A background in computer science lays a lot of the groundwork so that you're not making stupid mistakes and taking 4 months to learn how you should have done things. So, yeah, computer science has a big influence on where the trajectory of front-end development is going for sure. [Nick Pettit]: Cool. Well, I think a big challenge that's facing people coming out of college today is how to make the transition to a career and not just kind of hopping from job to job or being unemployed. How did you make that transition? Were you just kind of in an internship, and it was a really natural progression or did you--? [Paul Irish]: Yeah. I started out I was doing some marketing for a stationary company that made wedding invitations and birth announcements, and I wasn't even starting out with web stuff. I was creating a mail-merge Word document, and then we were using that to fax blast all of our customers, and I was customizing the mail merge to be depending on the customer, and it was all this logic inside Word. It was awesome. That transitioned, within that job, into working on their e-commerce presence, and so that was good. I think for most people having something you can develop on your own-- In my case I had my music blog, but I think having your own web presence, whether it's a blog; I think blogging is really good. Blogging what you're learning is extremely smart and having that place where you can iterate and play around. So, when you see a new feature come out, like you're reading a site and they talk about some new CSS3 feature or something, make a demo with it. Kind of explore it. Put it up on CodePen. There's a lot of communities now that are encouraging and let you explore things, get feedback. Having a social community that you can talk to and explore your own professional development with. I had one, and it's just been very-- It's a very smart way to go about things. [Nick Pettit]: So what first attracted you to front-end development, specifically? Because you were making a blog, did you do that in WordPress or something? [Paul Irish]: Yeah, it was WordPress. >>[Nick Pettit]: Okay. Why aren't you, say, like a Ruby or a PHP developer, for example? [Paul Irish]: For me, the thing that really rocks about front end is that you're building the interface, and not only are you building the interface, and you can make decisions around how the interactions are, but you're also getting feedback from its users and from the customers. The thing that they're touching, their cursor is going over what you've created, and you're in a position to where you can define the style of interaction and the quality of the user experience. Other people can work on how fast it responds and a really strong infrastructure, but the UI is just very sexy to me. [Nick Pettit]: So it's kind of about that instant gratification then? [Paul Irish]: The instant gratification and the feedback cycle of I'm creating the interface, they're using it, they can love it, they can be delighted by it. Or they can hate it when I apply a lot of text shadow to it and make it hard to read or something. [Nick Pettit]: Sure, sure. So, I want to talk about HTML5 Boilerplate for a little bit, because I'm personally interested in it. I think it's a really amazing project for people that are just starting out in web design and web development, and I think there's a lot more that goes into it than people might realize. >>[Paul Irish]: Yeah. [Nick Pettit]: So, first, how did that project start? [Paul Irish]: Before working for Google, I was at an agency in Boston making websites, web apps. We had a big team of front-end developers there, and when I was going from project to project, I was noticing that I was pulling lines of code from my markup and from my CSS from my last one into my new one, and then I was like, well, I should probably make a template just to keep track of this, and so I could start off with that template each time. That's the original genesis, was just that I needed to keep track of all this stuff and move it forward from project to project. Soon after, I got Divya Manian involved. We put out a 1.0 just to see what everyone else thought. Immediately it was really great because inside HTML5 Boilerplate is a bunch of techniques, right? One of the things that has continued up until a little bit ago is having inline documentation. You see a technique, and you can instantly see the website where that was birthed, and someone can justify exactly why this is important. So, it's kind of serving as an education tool. You've kind of got to understand why everything is in here. So, what happened is we put this out there, and immediately we got a lot of feedback over on GitHub where we open-sourced. A lot of people coming in and being like, Actually, I see what you're doing here, but if you tweak it, this is a much stronger position. It accounts for this edge-case bug in Opera 9.6 or something like that. Every character inside HTML5 Boilerplate has had a lot of discussion around it, and so everything that you see is the result of extensive conversations that have included some of the best front-end developers in the industry. You can go and look back at all those past conversations in the old issues on GitHub. The commits in the project, the log messages have very desciptive explanations of why we're doing this. It's very well-justified in why all these decisions are very strong as a baseline for starting your web project. [Nick Pettit]: Cool. I think when beginning developers look at HTML5 Boilerplate for the first time-- >>[Paul Irish]: We've got a lot. [Nick Pettit]: --they're just like, "Wow." "What's all this weird code?" Let's talk about that a little bit. From the top, what are all those IE conditional comments, because that's the first thing people see? [Paul Irish]: Yeah, so the IE conditional comments, they don't look great. They look kind of nasty. It's like sometimes you want your mark-up to look svelt and sexy and minimal, and I love doing that as well. Inevitably when you're developing-- So, this is not a problem for IE6 and IE7, which have no market share anymore. IE8's definitely still around, but it's been a case where they have actual CSS bugs in their implementation, and you can use CSS hacks, like syntax hacks, to target them and change the width or something, and change the padding to make your layout work and to fix those bugs. But using undocumented CSS hacks, it doesn't allow you to communicate well with your team, and when you're working in a group you want everyone to read the code and understand. So, the conditional comments provide a first-class way, that was provided by IE luckily, to specifically target these browsers with CSS styles that affect just IE7 and just IE8, or a combination thereof. It's tricky because that's provided for you for free in the Boilerplate, but I do think that you do want to try as hard as you can to avoid vendor-specific styles. A lot of times just setting explicit dimensions, width and height, on an element will let you avoid doing that, and so you should try and go as long as you can without specifying specific browsers. But it is there when you need it, and it helps a lot. [Nick Pettit]: There's plenty more in Boilerplate that we could talk about. There's--I've heard you talk about all the weirdness with carsets. >>[Paul Irish]: Yes. [Nick Pettit]: There's Chrome Frame, Modernizr, setting the viewport, and so on. What's your favorite feature, and what do you think is the most interesting thing that's there? [Paul Irish]: I found this on Ajaxian a long time ago, and now on Stack Overflow there's a great question called, 'The Hidden Features of HTML.' I submitted it a long time ago, and it's the highest voted, and it's in HTML Boilerplate, and this is the protocol-relative URLs. So, down at the bottom when we include jQuery, we pull it in from the Google CDN, but the script source is equal to //ajaxgoogleapis.com stuff stuff, and you're like, "I think you're--" We get pull requests and bug reports on a monthly basis. Like, "You got a typo, you missed the http:." And we're like, "Actually, we didn't." So, the protocol-relevant URL provides an ability to-- the browser will grab the HTTP version when the page is in HTTP and HTTPS when you're hosted in SSL. This is cool because it guarantees that the assets are requested securely only when it's required. There is a small overhead in requesting a secure asset when you're in regular HTTP. So, this is really cool and helps, although it is a little tricky on Windows when you're just developing, when you've loaded it up from the file system and then in your browser it says, "file:," it can be really slow. If you use a local development server however, you don't have that problem. So, I think the feature is really awesome, and that's probably one of my more favorite things. [Nick Pettit]: It's crazy you brought that up because I was just looking at that the other day trying to figure out what happened here. It's kind of amazing to me just how much goes into a, supposedly, vanilla webpage. I mean, it's called 'Boilerplate,' right? So, it seems like it should only be the most basic things that you need, but there's a lot there. Do you think the job of a front-end developer has become a lot more complicated in recent years? And is that a good or a bad thing? [Paul Irish]: Well, there's 2 things happening at the same time. One of which is that age-old legacy browsers are on the decline. IE6 is dead. If you look at market share numbers, IE6 is dead. IE7 has under--actually just about 1%. IE is really strong but still that's improving. A lot of front-end developers' pain has been the old browsers that haven't kept up with not only fixes, but features that we want to use. So, that part is getting easier. By the same point, the last 3 years have brought an enormous amount of features to browsers that we now get to incorporate and figure out the best way to incorporate. So, for instance, if you're using a CSS transition, do you use that CSS transition and just let it fall back if it's not supported by the browser? I recommend you do. But you could choose to feature detect it with Modernizr and then use jQuery to animate the same general transition. So, figuring out your fallback scenario is a little tough. A little bit ago, a few of us put out a site called, 'HTML5 Please,' which aims to provide a bit more guidance for all this stuff. So, basically, you get to look up for every feature, all the new stuff, you get to look up exactly what is probably the best way to handle this for a cross-browser scenario, where you might not have support everywhere. Should you use a polyfill script to enable that feature in an old browser or should you just let it fall back or is there some in-between state that is probably the best way? Finding that is tricky, but I think there's more and more resources out there that help. [Nick Pettit]: It seems like this is something that's unique to the nature of web development where you have to come up with these fallbacks for all of these different browsers coming out. Do you think it'll always be that way, or do you think we'll hit some point where things are pretty stable, and web development is just kind of a little bit more static? [Paul Irish]: Well, so if we got there, if we got to that point, that would essentially indicate that there's not any groundbreaking new features being added. I kind of don't want to be there. Right? At the same time, I don't like having to send a bunch of polyfills at older browsers and just testing and worrying about that. So,yeah, that's getting really complicated and messy, and managing the various states, like if you think about the old state of all browsers must look--the experience must look the same in all browsers to the new one which is we feature detect, we find out what we can provide, and there's a lot of combinations of how your site looks. Then you're like bringing responsive design, and it's changing. So, from a capability and future perspective, it's different from a viewport size; it's a different experience, and when you've built a site, and you're testing it to make sure that everything is right, there's a lot of combinations to look through. Here, the most important things are choosing features to use where the fallback scenario is you kind of forget about it. If a browser doesn't have border radius CSS transitions, that's probably okay. A lot of these just kind of enhance. The other part is that I think we could actually, as a community, do better to help encourage our users to be using browsers that we specifically want to support, and that helps our job, and it helps them. I know conversion rates improve significantly when the experience is faster. Helping your users be on the kind of browsers that you yourself enjoy actually has a good business support, and is a lot more fun for users and developers, of course. [Nick Pettit]: There's so many steps that are involved in front-end development at this point. This is something you were blogging about recently where you said the tool chain is a little bit overwhelming. There are so many steps and there are so many different tools and techniques to deal with each one of them. Do you think there's a need to simplify that and try to bundle all of that together? What are your thoughts on that? Because I feel like the barrier to entry is really high for somebody that's new to it. [Paul Irish]: Yeah, so, it's tricky. There's a lot going on, and, yeah, it's a lot to absorb. I've recently been working with Addy Osmani and some other people inside the web development community to put out a project called, 'Yeoman,' and this project is about putting together a lot of tools that help you build better web apps. Now, there's a lot going on in there, but it's using things like CSS pre-processors, live reload, even shipping a plug-in for Sublime text. So, there is like a baseline of features that most front-end developers use, and I don't think this is really listed anywhere. Maybe I should make a blog post out of this, but there's a few things that these days are pretty well accepted as these are fundamental to development. People don't talk enough to their colleagues, coworkers about what is their process for developing. How are they interacting with their text editor, their source control? I think there could be a bit more of a conversation around what we can do to make sure that when we're coming back to work on our projects it's not frustrating and instead it's fun, and I'm getting work done quickly. Every time I watch someone else do their work and I sit next to them and I'm like, "Whoa, whoa, whoa," "What did you just do? What was that keyboard shortcut?" [Nick Pettit]: Right. {Paul Irish]: I think we should do a lot more of that. [Nick Pettit]: Do you think it's okay for people to just use the stuff and maybe not totally understand it but just know that, "I need to do this thing for it to work?" At what point does it just become an abstraction? [Paul Irish]: I think it's--that's a great question. So, right now-- Nicolas Gallagher is the new project lead on HTML5 Boilerplate. He's kind of taken over, and he's doing a fantastic job. So, his perspective is that the Boilerplate project is aimed specifically as a baseline--this is a baseline for web apps, and it can be used for web apps and websites, and there's not really much to take away, and there's probably not much to add. In fact, it's a very stable project at this point because it's not trying to solve other problems. Now, let's say in jQuery, for instance, this has been a longtime question which is, "Should I learn JavaScript at the same time as I learn jQuery?" "Should I learn it first?" My answer to that has always been you learn them at the same time, especially things like math and strings and array methods. You want to learn those JavaScript methods fairly quickly, because there are not good answers for them in jQuery. At the same time, you don't want to have to learn how a lot of the intricacies of the DOM work very early on. So, I think it's a matter of learning the techniques as you're using the tools. So, in HTML5 Boilerplate, you kind of dig into some of the documentation, and at some point you'll just be like, "Why?" And you should be asking that question. That shouldn't preclude you from using the tool. At the end of the day, you want to enjoy what you're doing, and you want to do it fairly quickly, and you don't want to be frustrated. So, you use the tools that are available. I think it's important to understand how they work, and right now I'm trying to get a better understanding how browsers work, and those are really complicated. But I'm not going to tell everyone that every web developer needs to understand how all of the web browsers work. I think we're okay with that kind of working as a tool. It's a balance. Understanding the internals of any tool will help you be much stronger at using it, but you don't need to understand it to use it. [Nick Pettit]: So, wrapping up, what advice would you give to web designers and developers out there, just as a very general question? [Paul Irish]: Sure. [Nick Pettit]: What can they do to better themselves? [Paul Irish]: One of the things that happened to me a while ago was, I had joined the jQuery IRC channel. So, IRC is kind of, it seems nerdy. Yeah. Nick's like, "Yeah, definitely nerdy." But I joined that a long time ago, and I was just super active in it, and that's how I got involved in jQuery projects, started doing developer relations for jQuery, joined the jQuery team, was involved in the project for a long time, and it was all because I joined the IRC channel and just started talking to people and helping people. So, helping other people with front-end development you learn a lot, and I would recommend that. The same time that that happened, I found a group of people that were doing a bunch of jQuery, doing a bunch of JavaScript, and we just formed this kind of social group of 20 of us. It was also on IRC, and we would just talk all the time about what we were doing, and this led to--there was a little bit of competitiveness, but a lot of cooperation. We would work on projects together, things like MovetheWebForward.org and HTML5 Please, have come out of this group. So, having-- So you're not alone without a mentor. It's great to have a social group where you don't feel like completely inferior to everyone around you and can kind of support each other. The last part of this is really just to be able to have fun while you're learning. I think part of that is creating little demos and experiments for yourself. Doing that will give you more experience with cool features and things that you want to explore and help you feel more confident when you propose to your boss, "Really we should do it this way," "Why? Why?" And you'll be like, "Well, I've actually done some work with this, and it's not as bad or as scary as you think, and, I don't know, it'll all work out." [Nick Pettit]: That's the advice that I always give to people is just, "Do cool stuff and share it with other people." [Paul Irish]: Yeah, absolutely. [Nick Pettit]: Awesome. Well, thanks so much for being here. I really appreciate it. [Paul Irish]: Cool, thanks. [Treehouse FRIENDS] [♪music playing♪]
A2 初級 米 ポール・アイリッシュのインタビュー (Interview with Paul Irish) 149 8 Andrew に公開 2021 年 01 月 14 日 シェア シェア 保存 報告 動画の中の単語