Podcast appearances and mentions of steve souders

Andreas Taranetz is a software engineer and lecturer at the University of Vienna. He creates a lot of educational content around Web Performance Optimization. For the past seven years, he has also operated Wahlkabine, Austria's top website, for matching one's political views with the parties that are up for election.This episode was an amazing flashback - reminding us about the time when Steve Souders - the "godfather" of Web Performance Optimization - educated web developers about optimizing CSS, JavaScript, and server-side roundtrips.Tune in and learn why Web Performance is still such an important topic, how it relates to sustainability, why you should cache on every layer, and what the Static Site Paradox really is! Links we discussed in the episode:Andreas on LinkedIn: https://www.linkedin.com/in/andreas-taranetz/Personal Website: https://andreas.taranetz.com/We Are Developers Talk: https://www.youtube.com/live/KRemC82gsBkWahlkabine: https://wahlkabine.at/Steve Souders: https://stevesouders.com/

Like many frontend developers, Sergey Chernyshev was inspired in the late 2000 by Steve Souders to contribute to and grow the web performance community. Not only did he launch the Meed4SPEEDs as part of the New York Web Performance Meetup. He also worked for meetup.com helping them to improve web performance and user experience. Over the past years Sergey contributed to many projects such as WebPageTest.org, UX Capture Library, Jamstack and more.Tune in to this episode, learn what has and what hasn't changed in the quest for better user experience. Get a quick start on Core Web Vitals and current challenges. Most important: get inspired to contribute back to this community.Llinks we discussed during the podcast are here:Sergy on LinkedIn https://www.linkedin.com/in/sergeychernyshev/Steve Souders Page: https://stevesouders.com/NY Web Performance Meetup: https://www.meetup.com/Web-Performance-NY/WebPageTest: https://www.webpagetest.org/Github UX Capture: https://github.com/ux-capture/ux-captureJamstack: https://jamstack.org/WebVitals: https://web.dev/vitals/CrUX: https://developers.google.com/web/tools/chrome-user-experience-reportEdge Compute:CloudFlare Workers: https://workers.cloudflare.com/Fastly: https://www.fastly.com/products/edge-compute/serverlessPWA Stats: https://www.pwastats.com/Next.JS approach to SSR: https://nextjs.org/docs/basic-features/pages

(November 19, 2020) Rick meets with Steve Souders, who created the HTTP Archive project 10 years ago this month, to talk about its origins and reflect on it's growth. They're also joined by Patrick Meenan, creator of WebPageTest and maintainer of HTTP Archive, along with Paul Calvano, past State of the Web guest and also a maintainer of HTTP Archive. For links to everything we discussed → https://goo.gle/3nfhjfA

Sponsored By: Panelists Eric Berry | Justin Dorfman | Richard Littauer | Allen “Gunner” Gunn Guest Gareth Rushgrove (https://twitter.com/garethr) Snyk Show Notes In this episode, we talk with Gareth Rushgrove, from Cambridge, UK, Director of Project Management at a security software startup called Snyk. He has spoken at a number of international technology conferences over the past few years, including FOSDEM (http://www.slideshare.net/garethr/config-managament-for-development-environments-6836888), RAMP (https://speakerdeck.com/garethr/the-unavoidable-big-bang), BACON (https://speakerdeck.com/garethr/monitoring-sucks), QCon (https://speakerdeck.com/garethr/clouds-in-government-perils-of-portability), PuppetConf (https://speakerdeck.com/garethr/puppet-module-reusability), Monitorama (https://speakerdeck.com/garethr/security-monitoring-penetration-testing-meets-monitoring), GOTO (https://speakerdeck.com/garethr/if-government-can-do-it-dot-dot-dot) and Velocity. Security and Open Source don’t often go together, in this episode we explore the topic and more. 01:20 Gareth explains that Snyk provides tools for developers who use Open Source Software and help them stay secure. He also expands on vulnerability landscapes. 02:10 Justin asks Gareth at what point does he think the collective community decided that we need to start digging into security holes within our software and he answers the question. 04:00 One of the guys asks Gareth if security is a passion of his and if he joined the company because that’s what he loves or was it more for Open Source. 05:30 The guys talk about Guy Podjarney (a.k.a Guypod) and Steve Souders and how they started the web performance movement. 07:30 Richard states Snyk has 400,000 users on the website and three times more vulnerability than a public database. Gareth goes further in-depth about this and what his company does using Java, Ruby, or Python and how he does a bunch of propriety research and helps projects do profit disclosure. 11:10 Gareth discusses the Heartbleed attack & the Equifax data breach and its effect on the industry’s view on Open Source. Companies want Open Source ecosystem to be more secure, 17:50 Gunner chimes in with a question about if there is a list of things Gareth wishes Open Source projects would do to be better members of ecosystems visa the security and if there are checklists or places to go for best practices. Gareth expands on this. 23:49 Gareth talks about DevSecCon which is a conference that brings developers and security together in one place. There are eight conferences around the world this year. 24:33 One of the guys is curious about the effect of security and how people out there have packages that are used by millions of other users and how often they don’t know how many users are using it. Gareth explains. 26:44 Gunner asks about the role of threat modeling in the work Gareth does and what he recommends. 28:25 Gareth goes in-depth about the Helm Project and CNCF sponsoring. 37:31 Gareth gives advice on where people can go to find more information about security besides talking to Snyk. Spotlight 38:40 Justin’s spotlight this week is a blog post by Andrew Mason about Ruby on Rails Development with VS Code (ttps://andrewm.codes/posts/ruby-on-rails-development-with-vs-code-p1i/) 39:07 Eric suggests getting off Google Chrome and using Firefox (Developer Edition). 40:15 Gunner’s pick is guix.gnu.org (https://guix.gnu.org) 40:46 Richard’s pick is crubadan.org (https://crubadan.org) 41:34 Finally, Gareth’s pick is openpolicyagent.org (https://openpolicyagent.org) Links Snyk (https://snyk.io/) Gareth Rushgrove Twitter (https://twitter.com/garethr) Puppet (https://puppet.com/people/gareth-rushgrove/) Heartbleed (http://heartbleed.com/) CNCF (https://github.com/cncf/sig-security) DevSecCon (https://www.devseccon.com/) Helm (https://helm.sh/blog/2019-11-04-helm-security-audit-results/) HeavyBit (https://www.heavybit.com/library/podcasts/the-secure-developer/) Open Policy Agent GitHub (https://github.com/open-policy-agent/opa) Guy Podjarny Twitter (https://twitter.com/guypod?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Steve Souders Twitter (https://twitter.com/souders?lang=en) Andrew Mason - Ruby On Rails (https://andrewm.codes/posts/ruby-on-rails-development-with-vs-code-p1i/) Firefox (https://www.mozilla.org/en-US/firefox/) Guix (https://guix.gnu.org/) An Crúbadán (http://crubadan.org/) Open Policy (https://www.openpolicyagent.org/) Special Guest: Gareth Rushgrove.

Hello fellow Web Performance enthusiasts! Just like in the song, this podcast has been coming for some time. Quite some time. In fact, this first episode was recorded about a year ago. So please add 1 year to any time-sensitive bits you hear.The first guest is Steve Souders. I think Steve has done more than any other living person when it comes to raising awareness about Web Performance and how important it is to both users and companies. He also showed us the way to enlightenment with his books High-Performance Web Sites and its follow up Even Faster Web Sites. He was the brains behind the YSlow browser extension. Some of you younger folks may have not used YSlow, since you have all these powerful dev tools shipped with modern browsers. But in my opinion YSlow is right there after Firebug in terms of influence and showing the browser vendors what tools they should be providing.I'm lucky enough to have worked with Steve at Yahoo on YSlow and other stuff. He then moved on to do his magic at Google, and is now at SpeedCurve. We talk about all of this in the interview.One thing people may not know about Steve is that he plays ukulele. We jammed a bit after recording this podcast and then I thought I should cut up some of these sounds and mix them with the interview. Enjoy!

An interview with Steve Schoger, designer and creator or co-creator of many online tools like Tailwind and Refactoring UI and Heroicons and Zondicons. Refactoring UI book Refactoring UI website @SteveSchoger on Twitter Transcription sponsored by Larajobs Editing sponsored by Tighten Matt Stauffer: Welcome back to the Laravel podcast season three. Today, I'm going to be talking to Steve Schoger, co-creator of Refactoring UI and about 10,000 other products you probably already use. Matt Stauffer: Stay tuned. Matt Stauffer: All right, welcome back to Laravel podcast season three. It has been a minute. It's been a couple months since the last one, and we're going to roll up, finish up season three. And I let you all vote on who you wanted to hear from. So, we got three people who were at the end. And the first one is Steve Schoger, designer extraordinaire, Twitter fame, making books, and making dollars. Matt Stauffer: And Steve and I have known each other for a while. We work together at Titan for a while. I've also learned a lot about design from him. So, I'm really excited to hear not about Steve the designer quite so much, but about Steve the person. Matt Stauffer: So, first of all, Steve, the first thing I always ask everybody is first of all say hi to people, and then second of all, if you're meeting somebody in the grocery store and they ask what do you do? How do you answer that question of them? So, let's get started with that. Steve Schoger: Yeah. Sure. I usually introduce myself as my formal title. I usually say UI graphic designer. Even that's weird, because depending on where you work, my job title might be different. It's either UI graphic designer, visual designer, but I usually say like, yeah UI designer. And usually they have a clueless look on their face. I usually say I design websites. Is the easy answer. Matt Stauffer: It feels like it's a little bit of a lame answer. I say the same thing all the time. I'm like, "I make websites." Steve Schoger: I know [crosstalk 00:01:48] get all technical, but they won't get it. Matt Stauffer: Exactly. Steve Schoger: And then some people are just completely like, if I'm talking to someone older, they'll be like, "Oh, so you design books?" I'm just like, "Yeah, I do." Matt Stauffer: It's easier to say yeah and move on and by your tomatoes than actually have to answer it. Steve Schoger: Yeah this conversations over. Matt Stauffer: Yeah. My go to for a while has been I make websites, and I'm getting more and more dissatisfied with it, because I did it for a good reason. It's hard to have that conversation with those people, but then everyone's like, "oh, can you make my website for my Mom and Pop Sausage Shop." Or something like that in WordPress. And I'm like, "No. No, I'm sorry." I know some people who make websites. So, now I'm like, "I make web applications." I don't know anyway. Matt Stauffer: So, okay. So, you are right now coming off the heels of a successful launch of Refactoring UI and everybody in the entire internet heard about this thing and it's super exciting, but just a couple years ago, you were working a nine-to-five, and you had not achieved the level of Twitter fame. So, we're going to walk through that process. But before we go there, I want to learn a little bit about who makes the man who we know today. Matt Stauffer: So, where are you from originally? And when did you first get into design? Even in the earliest stages. Whether it was drawing on your wallet at age three or whatever. What are the steps you can remember that really got you to the point where you realized that design or art or creativity in general were things you might be interested in long-term? Steve Schoger: Yeah. So, to your first question. I'm from Ontario, Canada, and I'm from a city called Kitchner. Which is about a hundred kilometers outside of Toronto. And it's a population of 200,000, is the city of Kitchener, but it's this Tri-City thing. There's three cities next to each other to make one big city, which is about about half a million people. And I actually grew up on a small town outside of ... that's the city I live in now, which is Kitchener, which is a city, a small town of 200, 300 people. Matt Stauffer: Wow. Steve Schoger: Yeah and and I started getting into design, I guess, when ... kinda what you said, I started drawing when I was a little kid. I guess, my mom put this miniature horse in front of me when I was ... I can't even recall this, it was like when I was a baby almost and I'd draw it, but I could ... she acknowledged that I could draw depth. You know when people draw a horse or something, they draw a stick figure or something, but I actually drew the depth of it. Matt Stauffer: The angle of it. Steve Schoger: Yeah, exactly. And she saw, "Okay. There's Talent here." And, I guess, that's the earliest form of what I do. So, I've always been into art and when I was younger, I wanted to be an animator/ I'd watch a lot of cartoons cool stuff. And I didn't really ... when I was younger, the job I have now was not even a job. So, I never designed on the computers until I got to like ... Actually, the first time I used Photoshop was my first day of college. Matt Stauffer: Okay. Steve Schoger: Yeah. So, I'd be doing art and stuff and I'd take graphic design courses in high school, but they're not computer based graphic design. It's school, low-budget, you're working with pen and paper, and you're drawing letters and stuff. Matt Stauffer: Using rulers and all that stuff. Steve Schoger: Yeah, exactly. Matt Stauffer: Now, what was that, because your teacher said, "Oh, there's all this newfangled stuff. But we want you to know the basics." Or was it not even in the context of the newfangled stuff and they just said this is what graphic design is? Steve Schoger: Yeah. I mean, I didn't really ... I guess, that's what I thought graphic design was, and then when I got to college then I started using Photoshop, and everyone around me in the classroom got a handle on Photoshop. They already knew their way around a little bit, but the course I took, it wasn't graphic design. It was multimedia design production. So, that's everything from graphic design to to video, to a little bit of development, to even a little bit of music production, because I didn't know I wanted to do graphic design. So, I took a ... but I knew I wanted to do something in media. Matt Stauffer: Okay. So, when you went up to college, you just said, "I want to do something media-related." And you were still trying to figure out what exactly, so you just tried a lot of different classes or? Steve Schoger: Well, it was a course called multimedia design and production. All those things I just said. And yeah, I just wanted to get my hands wet with everything, and figure it out from there. I didn't know what I wanted to do when I went to college. I didn't know what I wanted my career to be, let's put it that way. Matt Stauffer: But you did have a sense that it was going to be creative and you were going to making ... So, basically was that class the full spectrum of potential careers you were thinking of that point? Steve Schoger: Yeah. Matt Stauffer: Okay it was a perfect all-in-one experience on all them. Did you come out of that class then knowing graphic design is it? Or did it still take some time to figure it out? Steve Schoger: No, no, because like, I guess, in high school, I wanted to be a rock star in high school. Matt Stauffer: Yeah. Tell me more about this. Let's pause college. Tell me more about this. Steve Schoger: Yeah, I play guitar. I picked up a Guitar when I was grade eight. So when I was 12, I guess. And I got really into it, I'd spend four hours a day. I'd come home from high school and play guitar until I went to bed. Matt Stauffer: That's amazing. All-electric or were you an acoustic as well? Steve Schoger: I started on acoustic. The way I got a guitar is my great grandma passed away and it was my inheritance. Matt Stauffer: Okay. Steve Schoger: She didn't have the guitar, but the inheritance money went towards a guitar. So, I started playing acoustic and then I always wanted an electric guitar. So, I picked one up maybe first year of high school or something like that. And that's all I did. And I played in the high school bands and stuff. I played bass guitar in the high school band and stuff. Steve Schoger: And, I mean, that was just an unrealistic dream. But when you're in high school you're just, "I'm gonna make it. I'll be ..."- Matt Stauffer: So, when you were in high school, you legitimately were interested enough in that dream that you thought, "I'm going to graduate from high school and I'm going to join a band or start a band. And I'm going to tour the world, and that's where my money's going to come from."? Steve Schoger: Yes. That's what I believed. Matt Stauffer: Because some people say that ... is kinda like the side dream. That was the dream. So, what dissuaded you from that dream? Steve Schoger: Well, my parents. They were like, "Well, you should consider going to school first, then maybe think about doing that." Matt Stauffer: Okay. Yeah. Yeah. So, they were and trying to weave them together a little. Steve Schoger: Yeah. So, even when I was in multimedia design, I still had this music industry dream in mind. So, I did the multimedia course. I graduated from that, finished it, and then there was this music industry arts program at the same college. I went to Fanshawe College in London, Ontario. And it was really hard to get into it. But I applied for it anyway, right after I graduated from multimedia, and they accepted me. So, and I'm thinking, "Well, I might not be a rock star, but I'd love to be in the music industry right? I'd love to show you music production." Steve Schoger: So, that course covered everything from music business, to just being in the studio and recording artists, and all that stuff . Still an unrealistic dream. Look at the music industry now, right? But I took that course and, I mean, that's still my hobby today. So, I don't regret taking that course. I learned a lot out of that course, but then when I finished that program, I was interning at small record labels. And they all saw the multimedia design on my resume, and that's what I ended up doing at those labels, right? I end up doing a lot of web stuff. A lot of designing little brochures and one sheets. A lot of stuff like that. Steve Schoger: So, I was doing that more and more, and I kinda enjoyed it at this point. Because I was kinda doing it for something I really enjoy doing. But I wasn't getting paid, it was all internships and stuff. Matt Stauffer: Oh. Got it. Steve Schoger: Right. And then I'm like, "Well, I got to get a job in this,." And I tried to follow my music industry path, but there was no money in it. So, I'm like, "Well, I just enjoy doing this anyway." So, this is in like 2009. So, right at the peak of the recession. It was impossible for me to get a job. I couldn't get a job anywhere, right? Steve Schoger: So, I'm thinking "Well, not a bad time for me to go back to school." And I already took multimedia, and I'm thinking "Well, what can leverage all these skills?" What can add to this? And I was thinking, maybe I'll take a look at marketing course or some kind of copywriting course. So, I took advertising and copy writing at Humber College. Steve Schoger: But, when I was in school, in that course, I spent way more time working ... I was making ads, and again in the course, I was making fake ads, right? But I spent way more time working on the creative, than actually the writing the copy. And that year I also spent a lot of time just learning web development. And I learned a little bit of this when I took multimedia, but I forgot everything I learned. So, I was real learning that stuff. And it was easy to pick up again. Matt Stauffer: Real quick. What were you learning? Was it mainly HTML and CSS? Steve Schoger: Html and CSS. Matt Stauffer: [crosstalk 00:11:20] did you get into a CMS or anything like that, or not at that point? Steve Schoger: Yeah, I learned about ... I knew about WordPress and stuff. But even that was ... it was a little too technical for me at that point too, because WordPress you can use the templates, but I really wanted to make something unique. WordPress is always just like, you got the header, the content area, and the sidebar. Ad I didn't want that. I don't want that constraint. So, I just started hand coding, and I learned about a few other CMS's at the time. I don't even know what they were called if you asked. But I tried them out, and I found one that worked for me, and I built a little blog for myself, and I would never write, at all. But that's everyone who starts a Blog and has the attention of write a post every week. And some people succeed at it and I did not. Matt Stauffer: I'm there with you buddy. Steve Schoger: Yeah. Steve Schoger: So, I was doing that. And then during this time in school, maybe in the second semester, it was a one year program, like a post grad program. And I took, in the second semester of that, I spent a lot of time ... I realized I wanted to do web design, at this point. And if I found a job before I finished school, I would have just dropped out of school, because I already had two diplomas at this point. So, it wouldn't phase me to drop out. But I couldn't find a job, but I was doing informational interviews, where I would contact the company and say "I'm not looking for a job. I just want to learn what you guys do day-to-day, and learn about the company." And I did a quite a few of those, and it was my way of networking. And you know what? I did do a little bit of like, "Oh this job. This place is hiring a designer. I'm going to ask if they want to do an informational interview." And I did it with a few companies. And one of my informational interviews turn into a job interview and they offered me a job the day later. So, that's how I got my first job. Matt Stauffer: So, tell me about the difference between an informational interview and a job interview when you know they're hiring? Was it, because you didn't think you would have the qualifications or do you think you're more likely to get in for the informational interview? What made you want to do this one type of interview versus just applying for the job? Steve Schoger: Well, if I did an informational interview, it's this ... my sister recommended that I just reach out and ask for informational interviews. And, I guess, I didn't think I was qualified for the job. So, I didn't apply for the job. And I feel like they're more likely going to have me in, if I have no intention of this Matt Stauffer: Ulterior motive. Steve Schoger: Exactly, exactly. Matt Stauffer: So, that's really interesting. Steve Schoger: I recommend anyone, I recommend to everyone does that. If you're a student in school, and you're just maybe not confident enough to go for that first job interview. Just shoot ... most people ... very few people turned me down, for an informational interview. Matt Stauffer: I mean, it makes sense. We've had a few people reach out for that. It seems so unique that I'm like "Yeah. Sure, I'll talk to you for a little bit. We can't always give you a full hour, but we'd love to chat with you a little bit about Titan." So, I hear that. That's really cool. Steve Schoger: Yeah, and I bring my portfolio in, and say "Hey, can you take a look at this and give me some feedback?" Matt Stauffer: I'm a student. I'm still learning and I'd eventually like to work at a company like this. That kind of thing? Steve Schoger: Yeah, exactly. And I was more thinking about, I was going for visual design jobs, but then I was interviewing with companies, and they're looking for UX designers, and I didn't even understand the role at that point. What the difference between a UX designer and a visual designer is. And sometimes I still don't understand the difference. Matt Stauffer: I think most people still don't get it. I still struggle. Steve Schoger: Yeah. Matt Stauffer: Okay. So that was what? 2010, 2011 at that point? Or was it- Steve Schoger: That sounds about right. So, I think, so. Yeah. Matt Stauffer: Were you married yet at that point? Steve Schoger: No, but I was dating my now wife at the time. I met her in high school. And she's my high school heartthrob, and she rejected me in high school. Matt Stauffer: Oh snap. Steve Schoger: Well, she liked me. She later confessed that she liked me, but friends and influence from that. Kind of like, "Oh no, he's gross." Matt Stauffer: He's a rock star, you don't want to be with that kind of a guy. Steve Schoger: Yeah, but then later on we connected after I graduated from Fanshawe. We were talking on MSN at the time. MSN messenger. And that's how we really started to get to know each other, and then she came to visit me a few times, then we started dating. And then I sat a year off between when I graduated from Fanshawe and Humber, and that's when I really, I also spent that year figuring out what I wanted to do, working on my web design skills. And I was just getting to know my now wife at the time. And then we moved into together when I moved to Toronto. Matt Stauffer: Okay. So, during those years in between, when you weren't in school, the reason I asked about her, I mean, first of all, I'm always curious, but also, were you living alone, working just side jobs while you figured this all out? Or what was your life situation during that time? Steve Schoger: The years between- Matt Stauffer: So, basically you got a you got a job in 2010. We're about to talk about what, I think, was the first design job that you got. So, prior to 2010, where you in school the whole time, or where there any years in there where you were - Steve Schoger: [crosstalk 00:16:52] going back and forth here, because I'm stressing out and forgetting things. There was that year between Fanshawe and Humber. And that was me just getting more familiar with Photoshop again, because I haven't touched it in a long time, getting more familiar with code. And I was living with her, but not living with her. She was still a student. And I was just living at her place. Like, I was still living with my parents, but I was just always over at her place. I brought my computer over there and we just pretty much lived together. Matt Stauffer: Were you doing freelance work at this point or? Steve Schoger: No, I was [crosstalk 00:17:26] I was just learning. I took one job that I just was not qualified to do. And I started doing it and I'm like "I can't do this." And I had to say like, "Yeah, I'm not ... sorry." Because you ... I think, the best way to like ... you just got to try, right? That's how I am with ... maybe this is a conversation for later on, but- Matt Stauffer: No no, lets do it. Steve Schoger: That's how I am with speaking. I am really uncomfortable doing public speaking, but I just force myself to do it, and now I'm doing a lot of talks this year, and I regret are doing every one of them, but it's like, "Well, I gotta do them." And I put myself in that situation, but it's like ... anyways. Steve Schoger: So, yeah. I was just working on my craft, I guess, in the in that time, right? With my girlfriend. And that's how I ... and I just bring a lot of blog posts, learning how to design. Matt Stauffer: So, in 2010, you got your first job, and it came out of an information interview. So, a couple questions around there. What was your actual job supposed to be? And at that point where you primarily thinking of yourself as a UI visual designer? Had you started thinking about any of the other aspects of design that you do today? Because today obviously you're doing interface design, but there's a lot of UX embedded in the stuff that you're working on as well. So, how did you think of yourself then? And what was the actual job that you got? Steve Schoger: So, the formal title of the role, and this is goes back to different places have different titles, but the formal title was "interactive designer." And that could be the same as UI designer at our company, visual designer at another company. So, the work I was doing there was more like ... it wasn't so much software design, which I mostly focus on now. It was more like doing websites. And just doing the creative, mostly. Matt Stauffer: So, you'd basically be the one who says "Hey, we're working for Joe's Plumbing. Here's the font that Joe likes." And you'd put together Photoshop documents. Would you also convert them or are you mainly delivering fat Photoshop documents to web developers, and then moving on? Steve Schoger: Yeah. I remember when ... So, going back to the informational interview I had. The moment it turned into a job interview, there's that transition in that part, and I got all excited. He asked if I code. And I knew a little bit of code. I coded enough to build my own personal website, and that's all he wanted to know. He saw my website. He saw that it's probably not the best code, but he made it. And and I didn't need to code for the job. But he liked that I coded, because it just made it easier to communicate my ideas to the developer. Matt Stauffer: And probably also, because you understood the constraints that the developers are under. One of the things I said, when we first started working with you one, of the reasons that we were excited to work with you, and we'll get to here eventually is, because you were a designer who understood that for example, you can't deliver something with an image that would theoretically have to go wider than the browser, but you didn't give us what the image should look when it goes wider than the browser, right? Like when the browser gets a little wider. It's so clear what it's like working with a print designer, who doesn't understand ... not even responsiveness necessarily, but just like, you literally can't curve a thing that way in HTML. It's literally not possible. Matt Stauffer: As someone who understands what it's like to implement something, your brain was set in a different space, I think. Steve Schoger: Yeah, I think so, because everything was print design back then. There was no responsive design. Yeah, that's for sure. And everything was ... even if you wanted to use a custom font, you embedded it as an image. So, I was a big font guy. I didn't like using just the web defaults. So, I always searched for new fonts, and I'd export that as an image. Steve Schoger: So, I did a lot of the exporting stuff. and, but then yeah, I'd usually hand that off to the front end developer. And I was, when I was working there, I was the only designer at the company. It was a small company. I think, there's eight or ten of us in total. Matt Stauffer: Was it a consultancy? That just took client work and did a design- Steve Schoger: Exactly. Matt Stauffer: Built the front end, maybe integrated CMS, deliver it, move on to the next client? Steve Schoger: Yeah, and they specialized ... they worked with a lot of media companies. So, television production companies, and I think, that was just as a result of ... they worked with one, and word of mouth and ... Matt Stauffer: Its who you know. Steve Schoger: It often works that way. Steve Schoger: Yeah. So, I was doing a lot of that stuff. Matt Stauffer: Okay. So, what was your next transition after that? I mean, did you stay at that job for a couple years and regardless, what made you want to move to something Different? Steve Schoger: Yeah. So, I was working in downtown Toronto at this point, at this company. And I worked there for two years, I think. And it was good. I liked being in a small company, but there's also part of me, "It's my first job. What else is out?" So, I was curious, and I interviewed at other companies, but then we also wanted to move back to our hometown, Kitchener, because Toronto is so expensive. By the way, I wish we bought a house in Toronto at that time, because it was- Matt Stauffer: Because now it's so different. Steve Schoger: We could have sold our house then and had no mortgage whatsoever and moved back here. But whatever. Matt Stauffer: [crosstalk 00:23:14] you could predict the future. Steve Schoger: Yeah, right. Steve Schoger: But I wanted to move back to Kitchener, Waterloo. First of all, Kitchener had this ... we have a little bit of a tech scene here. Blackberry, you know Blackberry? They put our name on the map, our city on the map. And we have at the University of Waterloo. So, a lot of trucks, a lot of engineering talent. And this created this little tech community. And I saw this from Toronto, and I was really interesting in it. But there was no design whatsoever. It was all engineers, right? And I'm thinking "I could have a huge competitive advantage if I go there. There's no designers whatsoever." And there was a company ... So, I was interviewing at a company called "Desire to learn." And they're an educational company. Matt Stauffer: I feel like I know somebody else who worked there, or did you- Steve Schoger: [crosstalk 00:24:19] it might be me. Matt Stauffer: Oh okay. Sorry. Keep going. Steve Schoger: And are you familiar with Blackboard? Matt Stauffer: Yeah. Yeah. Yeah Steve Schoger: The same kind of- Matt Stauffer: Can you give a real quick intro to anybody who hasn't heard before though? Steve Schoger: Yeah. It's e-learning software. When you go to school, it's your login portal, and that's where you can get your grades and your assignments and all that stuff. And I even used Desire to Learn when I was at Fanshawe. That was one of their first clients. And I had a friend working there and I was really interested in the company, but they never had any design either. I was their very first visual designer. Steve Schoger: But, to step back a little bit. My friend recommended I apply for this job. So, I applied for it. But at the same time, the company I was working at, we had a really low time, it was not good. And right when I got offered the job, the day later, my boss, before I even got to go into his office and say "I'm quitting." He basically said I gotta lay everyone off. We're closing the doors. Matt Stauffer: Wow. Steve Schoger: So, it was like the same day. I'm like, "Wow. Perfect." Matt Stauffer: Talk about timing. Geez. Steve Schoger: So, I had a little tweak break there, before I started my new job, because I basically I said "I have to put my two weeks notice in." Matt Stauffer: And then turns out you didn't. Steve Schoger: I think, I had a week. We were still wrapping things up and I had nothing to do. Matt Stauffer: Okay. So, you moved back, because you said Desire to Learn was in Kitchener. Steve Schoger: Yeah, moved back to Kitchener. But my wife was still working in Toronto. So, there's a little bit of ... I moved him back in with my parents that summer, is when I moved in. And Caitlin was still in Toronto, living at the place we were renting out. Steve Schoger: So, the summer we were living a little bit long distance, but I mean, we were an hour away from each other. So, I saw her on weekends and stuff. And she was interviewing locally at that time. And I started my job as Desire to Learn. And like I said, I was the first designer there, and UX was such a buzzword at this time. No company understood. They're like we need to invest in UX, but no one knew what it meant. And I worked at that company for two years. And in the two years I was there, I don't think anything I actually did saw the light of day. It was one of those situations. And it maybe has since I've left right? I've made these projects and they were sitting there, and you could work on them. But yeah. Matt Stauffer: That's tough. Steve Schoger: And right when I was leaving, they hired a ... I think, they have a good design team, now. They grew their design team since I have left them. Matt Stauffer: So, is that why you left? Because you just felt what you were doing wasn't actually- Steve Schoger: I was getting burnt out. And I was really passionate about what I was working on. Where I took my work home with me. And it was so frustrating to not have any of my work see the light of day. So, that just burnt me out. And plus, other factors were going on in my life where, we were renovating our house. And I'm not sure if you've been through a process like that, but never again. Matt Stauffer: It's definitely a second job. And it's a second, more stressful job. Steve Schoger: Yeah. So, it's just all these stressful things in my life, to the point where "Man, let's just get out of this city and let's go move to California." And I even went for a job interview in California. They flew me down and stuff, and that was kinda fun. And I didn't get the job. I think, the reason I applied for the job was because I was just depressed, and I just wanted something to change in my life. Matt Stauffer: Maybe some change will make everything better. Yeah. Steve Schoger: Yeah, right? But once I left my job at Desire to Learn, and the house was done, we finished renovating the house, everything settled down, and I felt good I didn't make that decision. Steve Schoger: So, when I left Desire to Learn, I went to an insurance company, a local insurance, well not a local, it's a Canadian insurance company. Well, do you guys have Sun Life in the states? Sun Life? Matt Stauffer: Sounds familiar, but I'm not sure. Steve Schoger: Maybe, because I've talked about it. Matt Stauffer: Probably. Steve Schoger: Yeah. So, it's an insurance company. And it's just a huge company, a huge Canadian company, thousands, tens of thousands of employees. Matt Stauffer: Are they based out of Kitchner as well? Steve Schoger: We have an office kitchener ... I say we as if I still work there. There's an office of Kitchner. I don't even know where the head office is. In Toronto, maybe. But there's offices all over Canada. Matt Stauffer: Got it. Okay. Steve Schoger: And I worked there for two years. And when I started that job, this is when I started freelancing with you guys, Titan. And it was around that same time and it's around the same time I met Adam. And I'm trying to think of a way to tell this story that has this nice, seamless, flow, but I'm trying to remember everything that happened. Matt Stauffer: So, let me let me turn it and maybe this will help you out. So, a lot of us, when we met you and Adam. So, Adam worked at Titan, I think, when I first heard about you. So, he would say "Yeah, I got these buddy that I'm working with, and we do these design things together blah blah blah." So, we just started hearing your name more and more often, and eventually he's like, "Yeah, why don't you guys, consider pulling him in for something?" So, we would and we're like "He's really great." Matt Stauffer: So, we had this idea, especially because, I actually meant to mention this to the listeners that this Kitchner, Waterloo, that whole triangle, is really weird, because there is an excessive amount of technological ... I don't know if I want to say excessive amount of talent, but I don't know. But there's an excessive number of people who do the type of work that I do in that one little space. Matt Stauffer: You're there, and Adams there, and Vehicle's there, and all these other folks are there, and every time we open up a job posting. It's a guaranteed that at least several of the qualified applicants come from this little tiny circle, out of the entire globe. This little tiny circle. Steve Schoger: Well, it's like I said, we do have this tech thing going on here, and I don't want to say it like ... people will say "Well, we're the Silicon Valley of the north." But everyone says we're the new Silicon Valley. But it's like "No, but there definitely is something going on here." Matt Stauffer: And I hear a lot of people say like, "Oh, we've got a nice little tech community." People say that about my local town here. And what they mean is "We have more than nothing." But that's not what it is where you are. There is seriously a lot of people all doing the same stuff there. Matt Stauffer: So, when I start hearing about you, what I figured was, Adam and Steve have known each other since high school, they grew up together, they live down the road from each other, they happen to be very talented, and when I've only learned pretty recently that that's not the case. So, why don't we- Steve Schoger: [crosstalk 00:31:13] no that's not true, yes. Matt Stauffer: Why don't we come at it from the angle of how did you meet Adam in the first place? Steve Schoger: Yeah. Steve Schoger: So, I met Adam, because ... I was always working on a lot of side projects. So, when I was working at Desire to Learn, I'd be working on my ... I'd spend a lot of time working with just startups, helping them out, and just getting my hands dirty, right? And a friend of mine that I went to high school with, his name's Chris Albrecht. And I always wanted to work on projects with him, but he was always busy. He had a kid at this point. He was always doing house renovations. He's one of those guys that's good at everything. He can build a house, and he's a developer, and he's just ... and you want to hate him for it. Matt Stauffer: You don't, because they're also good at being a wonderful person, but you want to hate them a little bit. Steve Schoger: And that's the problem. Yeah, you want to you want to hate him. Good at everything. But then he's just an awesome person, so you can't hate him. So, like "Well, God, man." Steve Schoger: But he took a a software development course at Conestoga College, which is a local college. And that's where I met Adam. And, I think, the two of them were the top of the class. So, Chris talked very highly of him, and he said Adam works on a lot of side projects like I do, I should connect with him. Steve Schoger: And I said, yes sure. And I just sent Adam a message on LinkedIn, and it's funny, I tweeted that recently, the the message I sent to him. It's funny when I re-read it, because I dug it up, and I re-read it. And it's not how I talk to him, at all. It's like, I'm really proper. Matt Stauffer: Yeah, I was gonna ask if it was was really formal. Steve Schoger: Yeah it was a really formal, "Hey, we should connect. I heard a lot of great things about you. I hear you're a good designer, and you're a good developer. It's a really rare combination." And now we just talk like bros. But it was funny reading that and I just said "We should meet up and grab coffee." And I just showed him some of the work I'm doing, and he showed me the stuff he's working on, and I said, "We should work on a project together, just to get a feel for each other and see what it's working with each other, and maybe about can turn into something else." Steve Schoger: And, I think, the very first thing we worked on was, he happened to be working on this Resume Builder app. Matt Stauffer: Yeah. I remember that. Steve Schoger: And I had this idea for a Resume Builder app, and I was designing one, but they're both separate projects. And we're like, "Well, we're working on the same thing. Why don't we build this together?" And we never took it seriously, right? We just wanted to get a feel of what it was like to work with each other. So, we did it, and we got it half done, and that will never see the light of day. Matt Stauffer: Right. That was enough. Steve Schoger: Yeah. Nut I did like working with them. That's what we learned about each other, right? I really like that he's got a really good sense of design, and I have that way of ... we talked about earlier that, I understand a little bit of code. So, I can communicate with him effectively. So, I think, we had that good dynamic that worked well together. Steve Schoger: And, I think, I met him ... I'm not sure if I met him when I was working at Desire to Learn or when I went to Sun Life, but ... no, I met him when I worked at Desire to Learn, because the reason I went to Sun Life, it's like I was going there because, A) it was a pay increase. So, that was nice. But I knew I was going into this big company, that was just a huge bureaucracy. Matt Stauffer: You're a cog. Steve Schoger: I'm going to be miserable there. But I went there, because this is around the same time I was talking to you guys. And I'm like, "Well, I can make this transition into freelance maybe." And you guys were my first starting point there, and what brought me to Sun Life is "Well, I'm going to work my nine to five, and when I get home from work, I'm going to turn that off. And then turning that off and then I can work on freelance projects." And that's what I was doing for you guys. Matt Stauffer: And that's the type of job you want to have, if you're going to start that transition to freelance, is the type of job where you can turn it off at the end of the day. Which, if it were your soul thing, it would be worse, because you want a job you love, but if it's the thing that's helping you transition, you actually want one that you don't love and you don't care about, that goes away. That's really interesting. Steve Schoger: I almost didn't care if I got fired. It's that kind of thing. I didn't want to get fired, because it paid the bills, but it's ... Matt Stauffer: You weren't emotionally or mentally tied to it, other than showing up and doing the things you should do to get the paycheck basically. Steve Schoger: Yeah exactly. Matt Stauffer: Huh. Okay. Steve Schoger: So, this is where you get more familiar with where I come into the picture. Matt Stauffer: Lets pretend like I don't know it. Steve Schoger: So, I'd work on a few projects with you guys, and I was also doing a few projects with Taylor. And, I think, the first thing I did for him was spark. I did the first Spark website. I did the website and I did a logo for him. And, I think, I did that before I started work with you guys, because Adam recommended me to Taylor, and then he recommended me to you guys. Steve Schoger: And I knew nothing about Laravel at this point. I only know about Laravel, because of Adam. Adam got Laravel famous. And I said, "Hey man, I come with you?" Matt Stauffer: Me too. That's hilarious. Matt Stauffer: Yeah. So, I remember that you were doing that transition stuff. When did you leave Sun Life? What was the the moment right? Steve Schoger: Because I was talking ... I did a few you projects with you guys. And then I'm not sure who suggested it first, but we basically had an arrangement. I think, it might have been you who suggested it. It doesn't matter. But you guys wanted a designer, because you never had a designer at your company. And Taylor just wanted an ongoing designer, but neither of you had enough work to fulfill a 40 hour week. Steve Schoger: So, the arrangement was, well, I do one week with Titan, one week with Taylor, and then I'd have an off week to go find any other freelance work. So, we had that arrangement worked out, and then you guys matched my salary at Sun Life. So, it felt easy going into, it was easy to convince my wife it all worked out. Steve Schoger: So, I made that leap. And that's what brought me to that thing, an I've been working with you guys for ... how long have been with you guys for now? Matt Stauffer: Has it been two years with this arrangement? Steve Schoger: It's funny. I've been with ... every job I've had has been two years. Matt Stauffer: That's it. That's your magic number. Steve Schoger: Yeah. Matt Stauffer: Yeah. I think, it's been two years. Because, I think, we did one year, and at the end of the year, we thought about it, and we re-upped it. So, it's probably been two years this way as well. Steve Schoger: Yeah, and, I mean, we're on pause right now, right? And that's ... we're talking about that shortly. Matt Stauffer: [crosstalk 00:38:17] story. Yeah. Steve Schoger: So, I was doing that, and I don't know ... next question, I guess. Matt Stauffer: Yeah. Matt Stauffer: So, I think, that worked really well, and, I think, it was really great for us. I mean, that's a curious business thing that anybody else can ask any of us more about, is that idea where Dan and I since ... Dan and I are both liberal arts Majors, with the design aesthetics, who are programmers. So, we always wanted a designer. From the earliest days of Titan, we wanted a designer, but it was hard for us to really justify at the beginning. Matt Stauffer: So, this was a really cool way to do this transition. And now we have a full-time designer, and have had Steve working with us for a while. But it took us this kind of experience to start building design into our workflows, and our ways of building. So, just anybody who's curious about that, it worked out really, really, really well, for us. Matt Stauffer: But the next part of the story was what you used in that third week. And that third week, was a combination of, I think, finding other clients, but also starting to become not just Laravel famous, but eventually just web development, broad internet famous, and then there's books and stuff like that. Matt Stauffer: So, where were you thinking? What was your approach? What was your attack? What was your mindset? What were the first steps you took to start using that time and start garnering a reputation? Steve Schoger: Yeah, I think, for the first year, I was doing a lot of ... I was just doing ... I was using the time for freelance, and I was finding new freelance clients. And I don't even remember any of the projects I did in that time, even though it was like a year ago, probably. Two years ago. But they're just a little one off things right? Steve Schoger: But it was still ... the tricky part about that thing. It's like, well, I work on a freelance project for a week, but there was more to do after working after that week ... For you and Taylor, we all had this understanding. Well, I'll be back with you in two or three weeks. But when I get a new client, it's like, well, I had to be ... Full disclosure. I have this [inaudible 00:00:28] going on, so I can work with you this week, but I won't be back with you 'til the following week. Steve Schoger: And they had a deadline, so it's like ... Well, I don't know how long I could do this for. I could only pick certain projects that last ... It was hard to find clients that worked that way. Matt Stauffer: [crosstalk 00:00:40] one week or less at any given moment. Steve Schoger: Yeah. So what I spent my time doing is just working on my personal brand, or working on little side projects, and the first project I did was Hero Patterns. That was a website for ... It's SVG background patterns. You can go on heropatterns.com and it's just a bunch of patterns that you can use for a hero background or whatever you want to use it for. I built that just as a fun project. I wanted to learn more about SVG, so that seemed like the right step, and I just wanted to add it to my portfolio and add to my personal brand. Steve Schoger: Then I released a bunch of icon sets. That's what I was doing in that time, just working on free, open-source projects. Matt Stauffer: Yeah. And those took off pretty quick. I remember seeing Hero Patterns, and I think [Zomicons 00:01:40] as well, on things like CSS Tricks. So it was pretty early on that you were releasing these things, and they were getting picked up pretty broadly. Steve Schoger: Yeah. Well, the Laravel community has certainly helped with growing my Twitter following, because it's such ... The whole community is really active on Twitter, first of all. Then I had Taylor and Adam retweeting my stuff and that really helped. Taylor had probably 50,000 followers at the time, so it all helped. I was growing my following there, and then Hero Patterns was getting posted on Product Hunt, and that really helped. Steve Schoger: From there, where does that bring us to? I was doing all these little open-source projects, and then I started doing the tips. Let's move up to that, 'cause I don't know what else ... Oh, I released another little project, Heroicons, which is like SVG icons, marketing icons ... They weren't meant for in-app experiences, but more if you go on a marketing page, and you're showing a features section. You can put the icons there and customize the colors. I thought it was a pretty interesting idea when I made it and it was a fun little thing, and I could make some money off of it. Steve Schoger: I released that and it did okay. I think I made $10,000 in the first few months, over that period. But Adam was launching his books and his courses, and they were doing insanely well. I saw him doing that and I'm thinking, at this point, I think I could maybe do a design book or something like that. I had all these ideas for what a design book could be for developers, and I was sharing these ideas with Adam. He encouraged me to build my following first. Matt Stauffer: Yeah, yeah. Steve Schoger: 'Cause that's what he did and that's what made his launches so successful. He proved that what he was making was worth it. Steve Schoger: I started doing the tips on Twitter to prove that I know what I'm talking about, and I can provide little ... Basically the tips, if you're not familiar with them, they're little bite-sized design tips. Here's a before of something that a developer might design, and here's an after of how you can improve it. It's like, take it, instant improvement, instant gratification, and they've evolved over time. Steve Schoger: The first tips, I was working on a project for you guys, let's say, and I'd take a screenshot of that project I was working on and post it and that was it. Immediately, they started doing well. People started seeing them and they were like, wow, these are pretty useful. Then they just grow and grow and grow. Steve Schoger: The tip idea, by the way, I stole the hot tip idea from Adam, 'cause he was doing hot code tips, and he stole it from Wes Bos, 'cause Wes Bos has been doing it for years. I talked to Wes Bos about that recently, and he said he stole that idea of a tip from someone else. Matt Stauffer: Really? Steve Schoger: Yeah. But he made it his own by adding the fire emoji. Matt Stauffer: Yeah, yeah. Steve Schoger: But now people think I created the fire tip and there's people copying me. It's all great. It all grows from there. Steve Schoger: Then, like I said, I was working on these projects, and I'd maybe work on something and I'd see, well, that's an interesting insight, and I'd take a screenshot of it. But then they became a higher quality thing. Well, in order to communicate this idea, I need to make this own little thing specific for this. Matt Stauffer: Compose the tweet with all the ... You made a little graphic side-by-side with all the bullet points and everything, right? Steve Schoger: Yeah, exactly. So the very first tips that I was doing, I'm just doing them and not thinking of it, and then Adam would bring in a lot of ideas. He'd share his ... This would be a cool tip for you. Matt Stauffer: Sure. Steve Schoger: Then we'd work on it together, and then they became ... with both of us working on them together, the quality went up and up and up. We'd try to make each tip better than the last, so they eventually just did really well. I think the biggest tip I posted got 13,000 likes and 3,000 retweets. Matt Stauffer: Holy crap. I knew they had gotten big but I didn't realize they'd gotten that big. Steve Schoger: That's by far the biggest one. At the beginning, they were getting ... The very first one I ever did, 40 likes. Then from there, it got 100 likes. Then it was 300 likes. I'm like, whoa. That's so big. Now today, it's like I can't post one without getting at least 2,000 likes and 300 retweets. Matt Stauffer: Geez. Go ahead. Steve Schoger: Yeah. They just spread so far. Matt Stauffer: That's awesome. Steve Schoger: The last tip I tweeted, people are hijacking the first comment, 'cause they know ... They see a little fire emoji in the tip, and they're like, first comment. Matt Stauffer: At least it's first comment, and not, do you see this? You should go to my course, blah blah blah. Steve Schoger: No, it was a friend of mine who's just joking, 'cause on the Kanye posts, people try to hijack it with their art. Matt Stauffer: Yeah. That's awesome. I wanted to point out something really quick here. I think one of the reasons that these spread so much is that, first of all, they're really high quality. You really know what you're doing. There's not a lot of people talking about it this way, and they're really easy to digest and apply. So there's one aspect. They're just really good tips, broadly, this is a really good idea. Matt Stauffer: But I think the other piece about this is that your tips ... You mentioned the fact that [inaudible 00:07:38], there was a lot of dev and not a lot of design. We have talked about this for a long time, about the Laravel community and other programming, especially back in programming communities. I have clients all the time that say, yeah, you can tell this was made by a developer, referring to something that they have that they're asking us to fix up. That means something. "You can tell this was made by a developer" means it doesn't look good, it's hard to understand. The information density is bad, the flow is not good. Matt Stauffer: There's this very big issue, with us as developers, knowing how to put stuff on the page, but not really knowing how to make it and such so that it's going to be ... not even just enjoyable, but understandable for the end user to really get the information out in a reasonable, pleasant way. Matt Stauffer: One of the things I love about your tips and a lot of your teaching is I think it reflects the fact that you do understand developers, and you do understand development, and you do know code, and you know enough developers and work with enough developers to know where our shortcomings are. You're not just putting out generic design tweets, but many of these tweets ... not all, but many of them ... are explicitly useful for people without a design background who are put in context, that because we're application developers, we need to build user interfaces. We don't know what you're doing. Matt Stauffer: I feel like a lot of basic design tips people give tend to be relatively useless to developers 'cause it's the same three things you've heard over and over again, but you really narrow in on practical design tips that help application developers. I wanted to point out that that is something I think probably comes intentionally, but also probably comes a little bit because of the specific background you do as a tech-adjacent designer, right? Steve Schoger: Yeah, and I think also, Adam's involvement too is a huge, huge- Matt Stauffer: Sure. Steve Schoger: I'm more or less the face of Refactoring UI, but it's honestly ... Adam and I are doing it ... Basically, the tips are ... From the birth of a tip idea, me and Adam will be ... Adam might point something out to me and say, this is an interesting little insight, and I'll have a sketch file of all my tips. I'll be able to either take a screenshot of something and I'll passively work on it until it best communicates the idea, and me and Adam are going back and forth at this point. Steve Schoger: Then there's the tip launch day, that we decide we're going to post ... That's a two-week process before we get ready to post it. Then me and Adam jump on a call and spend some time figuring out, how do we want to work this? How do we frame it in a way that communicates it? A lot of time gets put into these. Steve Schoger: But, yeah. Certainly, I have that kind of background that helps communicate to developers. But I don't want to discredit Adam whatsoever. Matt Stauffer: I love that. Steve Schoger: He's equally involved in that process, and he's coming with his developer point of view. Like I said, he's got a really good sense of design as well. And to be fair, some of the tips we've posted, I never even thought of them as tips, 'cause I'm so ... I have a designer mindset. Matt Stauffer: Sure, sure. But Adam was able to help you see- Steve Schoger: Yeah, exactly. Some of them ... It's like, one of the tips, for example, is offsetting a box shadow to make it appear like a light's coming from above to make it look more natural, right? Matt Stauffer: Right. Steve Schoger: And he suggested that tip, that was his idea, 'cause I never even thought of it as a tip. I'm like, I just do that. It's just second nature. I don't even think about it when I do it. Doesn't everyone do that? There's quite a few tips like that, where it's like, I never even thought of it as a tip before, as something insightful. Matt Stauffer: That's cool. One of the things that I pointed out to Adam that he does intentionally, but I don't know if everybody recognizes, is that he has a talent for ... We haven't actually said it. This is Adam Wathan, in case anybody happens to listen to this podcast and doesn't know who Adam is, which I kind of doubt. It's Adam Wathan. Matt Stauffer: He has a knack for recognizing what everybody in a particular community doesn't know, and everybody in another community might know, and then bringing the stuff that the other people know into the community where they don't know it. Refactoring to Collections, if you were to sell that book to someone in a community where they use collections pipelines for everything, they'd be like, why would I spend money for this book? But Adam understands how to bridge that information, so part of his talent, I think, is helping bridge the knowledge that you have as a talented designer and a tech-adjacent talented designer who does have a lot to offer. But he's also able to help you bridge that gap into developer mindset. So I love that you brought that point up. Steve Schoger: Yeah, I think that's very accurate. Adam's probably the best teacher I know. Him and Jeffrey Way are the really good teachers. Adam's probably one of the smartest people I know, and him and my other friend are the smartest people, I know, but the other guy that I'm speaking of is ... He was almost an astronaut. So that's who I compare Adam to. They're both completely different. He couldn't do what Adam does and Adam couldn't do what he does. Matt Stauffer: Well, you mentioned Refactoring UI. That's a perfect segue. So, hot tips was a big thing, and then you and Adam decided you guys were going to make Refactoring UI together. A lot of people have questions about that, you did just launch it. Before we talk about how it started, what did it end up being? If somebody's never gone, what is Refactoring UI right now that they can go purchase? Steve Schoger: Yeah. Refactoring UI is sort of a package. It was pitched as a book, but that takes all of the ... pitched it as a book to help developers get good at design. But we made this whole package, this whole resource for developers to help them make their designs better. So there's the book aspect, and that's probably the main component that everyone's familiar with. But then with that, we provide color palettes. So a big problem with developers is they don't know how to choose colors, so we just provide a bunch of color palettes for them. We provide a bunch of font recommendations, and there's an icon set. So it's this big package that you can go pick up. Matt Stauffer: Yeah. That totally makes sense, and it's good to know it's not just a book, 'cause I think that you guys said, what's the best way we can teach this? It's not just book, it's also resources that help you do the thing. And there's videos too, right? I think you mentioned that. Steve Schoger: Yeah, I didn't mention that. There's videos in the package. The videos are taking the ideas that are introduced in the book and applying them to a real-world example. Matt Stauffer: You tweeted out a couple of those, so if somebody wants to get a sample, they can see what that's like. I think you tweeted some. Steve Schoger: Yeah, there is a one video available you can watch. We emailed it out to the mailing list, so you can sign up and you can get that. You can also check out, if you're interested in that kind of thing, I also have a YouTube channel where I do UI breakdowns, and that's all part of it. Matt Stauffer: Okay. So we now know what it ended up being. And it just launched ... Right now, it's January 11, and it just launched a couple weeks ago- Steve Schoger: A month ago, December 11. Matt Stauffer: Okay, there you go. Steve Schoger: There you go. Matt Stauffer: When did it start, if you remember, and what were you originally thinking? Steve Schoger: Yeah. Like I said, I saw Adam get successful with all his courses and stuff, and I'm thinking, well, I could maybe do that with design for developers. So the original idea was, I was going to write a book. But I was bouncing my ideas back and forth with Adam, and it just made sense to get him involved in the project. And I think this was even before I started doing tips, I thought I was going to write a book. It only made sense to get him involved and make it a 50/50 partnership, 'cause he can bring his developer frame of mind to it, and to articulate the ideas that have much better than I could. Matt Stauffer: Yeah. At that point it was still a book. What thinking process did you guys go to when you were starting to write this book that made you realize it needed to be more than just that? Steve Schoger: Right. I think when we started working on the book, there was a few ideas in the book that ... It was too difficult to communicate in the way we were writing it, the style of writing it was. And there was a few ideas we wanted to communicate that just couldn't be communicated that way. That's when we realized we needed to make some videos attached to it. There's a few insights in the videos that you can't necessarily find in the book, 'cause maybe it's a little more hand-wavy. We like to make the book very- Matt Stauffer: Very concrete? Steve Schoger: Yeah, very concrete, where in the video, there's a few more ideas that are a little more hand-wavy. Matt Stauffer: What was the hardest part about writing this book, about this whole process for you? Steve Schoger: Making the book was a roller coaster of emotions. Matt Stauffer: Oh, yeah? Steve Schoger: Well, you've been through this, right? I think early on, we had all these ideas of what the book was going to be. We spent so much time planning, and not enough just doing it. What we realized is that we should've just started doing it and let it just unfold, right? Matt Stauffer: Right. Steve Schoger: What was the hardest part? The book is more or less a picture book. There's more pictures than there are words. I made about 300 images for the book. Matt Stauffer: Wow. Steve Schoger: And they're not just ... A lot of books will just take a real-world example, take a screenshot of it, and put it in their book. We had really specific points we wanted to communicate, so we thought the best way to do it is design a little UI for it. One of my goals with the images was to make it so ... First of all, I might design an entire UI just to communicate how to do a drop shadow. I thought it'd be cool if every image in the book is something you can go ahead and create yourself, challenge yourself to create that image in the book. And I wanted there to be a little bit of hidden gems within all the images. Steve Schoger: So it's like, oh, we're teaching you how to do a drop shadow here, or a box shadow, but I noticed in this little UI example, you had this, and I never would've thought to do that on my own. So there's a whole bunch of little hidden gems like that in images. That took a long time. Steve Schoger: The way we delegated work with the book was Adam wrote all the words. We worked on all the concepts together to figure out how we communicate these ideas, and Adam wrote all the words, and I did all the images. Matt Stauffer: Got it. Steve Schoger: Some chapters will be like ... There's 200 words, but then nine complex images. So I just couldn't do any of the writing with the amount of time I was spending on the images. Matt Stauffer: For sure. What you're saying is you did all the work and Adam just mailed it in, right? Steve Schoger: Yeah, exactly. Matt Stauffer: I'm just kidding, I'm just kidding. Steve Schoger: No, no. I couldn't have done it without ... Like I said, Adam is far better at articulating these concepts than I could've ever done. If I wrote the book myself, it would've been ... I don't want to say a failure, but it wouldn't be near as good. Matt Stauffer: Yeah. And I want to attest to the fact that I know both of these guys relatively well at this point, and they basically disappeared off the face of the planet for weeks at the end there, because they were both putting in such long days. Tell me a little bit about that time for you. Steve Schoger: Yeah. Just for the listeners, I had my thing, gig with you and Taylor, and I think I sent you guys a note at the end of September, maybe? Matt Stauffer: I think so, yeah. Steve Schoger: Is that about right? And Adam and I were passively working on the book at this point, but we realized it needed a full-time commitment. So I sent you guys a note saying, hey, I know you guys knew we were working on this book. We were getting towards ... gearing up launching this. So I sent you guys a note saying, hey, do you mind if I go on a leave, and you guys were fully understanding about it, and that was awesome. I feel like I'm in debt to you guys for that. Matt Stauffer: No, dude. Not at all. Steve Schoger: Then that was in September, and we already had a launch date in our head. We wanted to get it done before the new year. We already announced that we were going to get it launched by fall 2018, right? Matt Stauffer: Right. Steve Schoger: And then I just worked on ... We worked on the book for three months there. There was a break in between where we were both ... And you were there too ... invited to speak at Laracon Australia. Matt Stauffer: Yeah. Steve Schoger: Both Adam and I made a bit of a family vacation out of that too. We spoke at the conference, but it's like, well, going to Australia is a once in a lifetime opportunity, and our wives want to come, so we brought our whole family along. Matt Stauffer: I got to meet your families and I loved it. Steve Schoger: Yeah. That was a two-week break we had in there. Then when we got home, we realized ... We wanted to launch it at the end of November. That was the original goal. But we got back from Australia, we were like, that is impossible. There's no way to get this amount of work done in that amount of time, so we pushed it back a bit. We didn't actually have a date in mind, but we were thinking, we've gotta get it done before the new year, because if we don't get it done by ... If we didn't get it done in the week we got it done, then we probably would've postponed it to the new year. Matt Stauffer: Yeah, 'cause it was just too close to Christmas and everything's too crazy around then. Steve Schoger: Exactly, exactly. Even at the time we launched, it was a little bit ... I don't know. Yeah. And we were just ... Like you were saying, we disappeared, especially in the last week. That was ... I didn't sleep for three nights, the last three days before the launch. I was up for 72 hours. I got maybe two hours of sleep in that period. Matt Stauffer: Yeah. I saw you at the end of that period. Steve Schoger: Yeah. Matt Stauffer: [crosstalk 00:21:09] Steve Schoger: No, and I was just neglecting my family. My wife was incredible about it. She even said, hey. Would it be helpful if I go sleep at my parents' for the next few nights, just to get out of the house, and you have time to yourself? Matt Stauffer: Wow. Steve Schoger: She was incredible for that. Yeah. That was just ... I was trying to stay active on Twitter, 'cause I needed to keep promoting the book and make it look like I was still alive. But, yeah. Matt Stauffer: Because we're pretty short on time, I try to keep these under an hour and we're going to go a little bit over, I want to ask you a lot more questions, but I want to at least push on this one thing. What did it feel like to put out your first big product, and what were you doing after the launch? Now that it's been a couple weeks, how do you reflect on that experience about having done it, about the launch day ... Does this make you want to go do something like this again, or do you say never again? How do you feel about it right now? Steve Schoger: I don't think I'll ever work on a book again, for sure. But I'm all down for working on projects like this again, big product launches. They're fun. Steve Schoger: I know when Adam did his Refactoring to Collections book, it was like, he was working on that in the evenings and stuff while he was working for you guys, then he had this unexpected huge

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

This interview is part of our six-part series On Tour @ #perfnow. At the beginning of November, we attended a new conference in Amsterdam called performance.now(). performance.now() is put together by no-one less than Steve Souders and Tim Kadlec, two well known experts in the performance circus. And they teamed up with the people running […]

Descripcion del programa José Manuel es ingeniero de software, trabaja como desarrollador web en Estocolmo para Spotify. Especializado en web performance optimization, SEO y accesibilidad. Con él nos adentraremos en el mundo de las Progressive Web Apps, y veremos como gracias al nuevo Catálogo de Apis podemos realizar acciones tales como notificaciones push, almacenamiento local y ejecución offline entre muchas otras. ¡Esperamos que os guste el episodio y como siempre nos vemos al final! ¿Queréis participar? ¿Queréis participar y ayudarnos a decidir que grabar en WeCodeSign y proponer invitad@s? Aquí podéis participar en WeCodeSign. Recomendaciones Preguntas rápidas: José Manuel Quién me ha inspirado: Alberto Quién me ha inspirado: Davide Mendolia Quién me ha inspirado: Felipe Ribeiro Quién me ha inspirado: Steve Souders Quién me ha inspirado: Nicholas C. Zakas Quién me ha inspirado: Addy Osmani Quién me ha inspirado: Dan Abramov Quién me ha inspirado: Stoyan Stefanov Recomiéndanos un recurso: Frontend Focus Recomiéndanos un recurso: JavaScript Weekly Recomiéndanos un recurso: Chrome and Web at Google I/O 2017 Recomiéndanos un recurso: JS Conf Recomiéndanos un recurso: CSS-Tricks Recomiéndanos un recurso: Smashing Magazine Recomiéndanos un recurso: High Performance Browser Networking Recomiéndanos a un invitado o invitada: Jaume Sanchez Elias ¿Qué tema te gustaría que tratásemos?: Web Performance Contacta con: José Manuel Twitter de José Manuel Web de José Manuel Links del programa Hilo sobre cómo aparecieron las PWA, por Alex Russell Progressive Web Apps: Great Experiences Everywhere (Google I/O '17) Production Progressive Web Apps With JavaScript Frameworks (Google I/O '17) PWA Directory Progressive Web Apps La guía sin conexión by Jake Archibald The Service Worker Cookbook Service Worker Tools Service Worker Pre Cache Tu primera Progressive Web App by Pete LaPage Building Progressive Web Apps A big list of progressive web app tips and tricks The State of Progressive Web Apps Production Progressive Web Apps with JavaScript Frameworks Qué son las Aplicaciones Web Progresivas o "Progressive Web Apps" Progressive web apps PWA: Para Webs Asombrosas Recomendaciones de Ignacio Progressive Web App questions Progressive Web App Checklist The PWA Resource list Lighthouse Patrocinadores Fictizia.com Contacta con Ignacio Web de WeCodeSign Twitter de WeCodeSign eMail de WeCodeSign Web de Ignacio Villanueva Twitter de Ignacio Villanueva

In this episode, the crew talks about enterprise applications, scalability, and productivity. Transcription provided by https://twitter.com/wtoalabi Episode 53: Bigger & Better Music.... Intro: Alright welcome back to another episode of the Laravel Podcast, I am one of your hosts, Matt Stauffer, I have got two guys joining me...Can you introduce yourselves? JEFFREY WAY: I am Jeffery Way! TAYLOR OTWELL: And I am Taylor Otwell. MATT STAUFFER: It's been a little while but we are back with a little bit more to share and if you haven't gotten a chance to check out the Laravel New...News Podcast...all *laugh...*Check out the Laravel new Podcast where... Interjections MATT STAUFFER: Checkout the Laravel New..News Podcast...oh my gosh! Everytime now! News Podcast, where Jacob Bennett and Michael Dyrynda, basically being Australian and ' Illinoisian'  tell you all the greatest and latest news that is going on with Laravel, so, because they are covering that so well, we are going off the beaten track a little bit talking about a few kinda broader topics, so, what we did was, we put out some requests on the Twitter account and said "Hey folks, what do you want us to talk about?" And we picked a couple interesting ones and we just want to...just like the reader grab bag or... whatever you call it on your podcast Jeffery, so, the first one at the top of the queue is...something we hear about all the time, not just in this particular request, which is "Can Laravel be used for big apps?" And sometimes this comes in the same conversation of well you know if you want to do enterprise you should use this framework or if you just want to do a cute little thing, then use Laravel. You know, there are all this like statements and perceptions that people have and make about this, so before we go anywhere else, I would ask like, what is and do we know, what is the definition of an enterprise app, like if someone, and then again we are trying to give as much grace as possible to the person who actually thinks there is a distinction...what makes an enterprise app? Is it about lines of code? Is it about patents? Is it about security? Is it about traffic? Like what makes something a big app? And or an enterprise app? Do you guys have a sense for that? JEFFREY WAY: I really don't. So I basically have the same question. From afar, I will just say an enterprise app is something I imagine that is really really big...I don't know, it is an interesting distinction that people always make. I mean for as long as I can remember, even back in the Codeigniter days, you had this idea that Codeigniter is for these sorts of hobby projects but then if you are on the enterprise level, you are gonna reach for Zend or you are gonna reach for Symphony. And I feel like even after all those years, I can't quite figure out, what specific features or functionality do they have, that make them suitable  for enterprise or what would Codeigniter  not have or what does Laravel not have...hmm... is it related to the fact that Zend has a big company behind it? And whereas with Laravel, you know, like everyone is just gonna keep creating threads about ...what happens when Taylor dies? Is that the kind of idea? Like this is open source...it's kind of rickety...you are not sure what the state of it is, you are not sure if it's going to be abandoned? And with Zend, maybe if you have a big company behind it..maybe you can depend upon it more? Maybe? I don't know, I have the same question as everyone else. TAYLOR OTWELL Yeah, I think most people mean lots of classes I guess. You know, lots of code, lots of lines of code and I think the answers is, you know, obviously I am going to say yes it can be used for big apps, one because it has been used for big apps in the past, so we already know it's true basically. But then also, I think that, you know, Laravel is good for any app that PHP is good for, so, Laravel gives you a good routing system and a way to route request as classes and sort of beyond that is really up to you, you know, once you are past the controller, you basically have total freedom to do whatever you want to do, so, it's up to you in terms of if your app is going to be scalable in terms of complexity. And also I think Laravel is kind of uniquely qualified and better at making big apps than other PHP offerings right now, for a few reasons. One because when people start talking about big apps, a lot of time there is dependency complexity and Laravel Dependency Injection Container  is really good and it's really thoroughly baked in throughout the entire framework. When you talk about complicated apps, a lot of time you are also talking about needs like background job processing and Laravel has basically the only baked in queue system out of any major framework in PHP...hmmm...and then of course there is event broadcasting and other features that I would say are more kind of on the big app side of things, so, not only is it...can it be used for big apps, I think it's uniquely better for big apps than other alternatives out there in PHP right now  for those reasons. And I think it's just a little misleading because it is easy to get started with, and has a very simple starting point. And since that has a single route file you can kind of jump into it and start hacking around on, but it also scales up, you know with your needs and with your team's needs in terms of complexity...so yeah, that's kind of my take on it. Everyone kind of thinks that their app is a special snowflake you know, that has this, very unique requirements that have never been required in the history of web apps, but, the vast majority of applications don't have unique requirements and they don't really have unique needs and you know Laravel and many other frameworks really are going to be a good fit for them but I think Laravel is the best option in PHP right now for a big sophisticated application. JEFFREY WAY: And it is funny because, for whatever reason everyone thinks their project is going to be the one that really put Laravel to the test in terms of how many page views it can render in a single second...all that stuff like...if you need to worry about that, you are at such high level and you will know if you need to worry about that or not, but 90, I would say 99% of projects will never even get close to that point. So, it's almost like, to be frank, it's almost like a sense of vanity that you think the project you are working on right now is something that really needs to worry about that, because you probably are not even close. TAYLOR OTWELL Yeah, and we are assuming, developers don't approach projects in a rational way, even though we think they might. Like people don't choose frameworks in a rational way, they don't choose anything really laughs related to tech in rational way, a lot of time, as surprising as that is. There's a lot of things that go into it and some of it are sort of personality things, maybe they don't like a way that a certain framework is marketed or not marketed. You know some people are very turned off by active marketing around open source, so, maybe they don't like the style of Laravel sort of friendly, hey look at easy this is easy kind of marketing and they are turned off by that, and so they choose something that is more toned down, more sort of suite and tie like Zend because that fit's their personality better. It's not really a technical decision, it's more of just personality or subjective decision. And that happens a lot with tech in general, you know, some people don't use anything that is popular in general, just the kind of classic hipster type thing. I think a lot goes into it and rarely is it purely technical. Sometimes it is... they don't like me! You know, they don't like me personally. And so they don't like Laravel or use Laravel. JEFFREY WAY: I like you Taylor. Everyone laughs JEFFREY WAY: Right before we started recording, I guess RailsConf is going on and I was watching DHH give his presentation live...and he was kind of talking about this to some extent...the idea that it is important even for a tool like Rails or Laravel to have like their own culture and their own sense of values. And he was talking about how like a lot of people take this idea that you just learn all the different languages and then... you do...you are a programmer. So, if you need to work in this local language, you do it and you just apply everything over. And he was talking about how like while that is true, what is wrong with being part of the community that has a very specific culture, very specific views...he talked about like the  people that are still using Rails are doing it, maybe not just because it's better, but because they agree with the values that Rails represents. That is like the huge reason why people still use it to this day. And I think, that is very much true for Laravel as well. It is kind of interesting way to think about things. It's all personality, it's about what your values are. What you connect with and what you don't connect with. TAYLOR OTWELL Yeah...when I first started Laravel, that was a big part of how I wanted, how I thought Laravel could be successful, because I knew that in my own life, like there is sort of this ongoing desire to sort of connect with a group of people. Some sort of community or whatever around shared values. And you know that can be found like around many different things like music, or sport or religion, or whatever.  And I knew with programming like I wanted to connect with this group of people that has similar values about writing really clean code and having a good time doing it and making it enjoyable and sort of interesting, new and fresh. And that's kind of how I presented Laravel and I think it resonated with some people that were also looking for a group with those kinds of values. And that is still the kind of the values that we obviously try to share today, but yeah, it wasn't necessarily a purely  technical thing, it was building this group of people that sort of resonates around similar ideas  and working on it together. MATT STAUFFER: It's interesting 'cos I think that even in my question, I conflicted big and enterprise and I think that you guys kind of really drew out the difference between the two in some of your answers, I mean if we think about it, like Jeffery's first answer was, while enterprise might be really interested in having a company back it versus a person..like Taylor said, we get the question of what if Taylor gets hit by a bus all the time. And it makes sense right, like we have clients all the time coming to us like, say, you know well, you know the CEO or the board or the CFO of our multi-million dollar or multi-billion company are very worried that we are gonna invest a whole bunch of money and time in something and X ..and it's not always...and that Taylor might get run over  by a bus, but a lot of developers are getting non-developer input on decisions they make here and there are certain times where some IT persons have set up some rules that says like "You can only use projects like this and not [projects like that and I do wonder whether there are some constraints there like one of them being, that it must of be owned by a company, I know that when we worked with CraftCMS a lot of people said well, why would you, there's actually a business value of using CraftCMS over something Wordpress because Craft is making money and therefore it's a sustainable business model and therefore the business people are actually less worried about this thing disappearing. Right? So like maybe a more direct chain of profit to the people who are running the thing might actually make it clearer. I don't know if that exists maybe ZendCon would be something like that but I know it's Laracon too...I don't really know! But it's interesting that the requirements of ...like the true enterprise requirements...like because I work for a company, my company has these requirements...but I think people, including me when I ask these questions conflict that with big. And so I think there is a good place to take this next is, lets step away from enterprise a little bit...enterprise culture is a thing...you know whatever...let's talk about big, so the thing mentioned Taylor, and Jeffery both of you said a lot of people come along and say oh well mine is going to be the one that finally pushes those bounds right, I am gonna run into traffic issues and stuff like that, so, first of all, like I know that we can't say a lot of the names of big sites that are running on it but I feel like is there anything we can do to kind of like just ... I mean, I know several of them 'cos I am under NDA with several of them, you know, who have talked to us about doing some work with us but there's like multi- I mean milions of millions of hundreds of millions of page views sites running on Laravel...there is like Alexa top 500 sites running on Laravel, there's ...hummmm...what's the big group of all the businesses in the US? I can't remember the name of it...Fortune 500 companies running on Laravel...like multiple Fortune 500 companies whose websites are running on Laravel. Are there anything that you guys can share, like to say, hey look, this is the proof, like we've got big stuff running through here. TAYLOR OTWELL Trying to think some of them..I mean like the Vice Video, Log Swan, you know, various video games sites like FallOut 4 had their landing page on Laravel...other stuff like that, but you know, it's sort of never seems to be enough and it sorts of becomes this treadmill of, you know, I have to give one more proof that it sort of can work...and I just wonder like what's really underlining the question like, do they want to know that if I build my big app on Laravel will it be infinitely maintainable and clean...and no, Laravel won't automatically make your app amazing to maintain for 10 years, you know, I don't know if it's like trying to sort of scale responsibility for you also having to do a lot effort to like make your app enjoyable to maintain or what...but... MATT STAUFFER: Bad programmer, can write a bad app with any framework right? Like, nothing is going to rescue you from that..not saying that the person asking is necessarily bad..but I think that's a great point you made earlier Taylor, I wish we can further into it, is that with Laravel like yea ok, Laravel has it's own conveniences but at some point every single app is basically just you writing PHP... TAYLOR OTWELL: Yeah MATT STAUFFER: And especially at this level when you are talking about hundreds of thousands of lines of code, like the vast majority of the dependencies there is going to be just PHP code right? TAYLOR OTWELL: Yeah. Once you get...let's just take like a Laravel app...'laravel new'...whatever...once you are at the controller, method, in your controller class, everything else is up to you, so whether you use the validator or whether you even use Eloquent at all, or whether you use anything in Laravel, is entirely up you, so it was your choice to do whatever you did past that point. So, it's not Laravel making you do any one particular thing. So, that's sort of the point where you are gonna have to, you know turn your thinking cap on and really plan on how to do a big project, because as far as the framework is concerned, the framework is gonna be a much smaller concern than your actual code, you know the framework is gonna be routing session, some caching, some database calls, but you are the one that is gonna have to like, figure out the domain problems of your app, which is gonna be way more complicated I think, than any framework problems you are gonna have. Like, how is this app gonna work? How is it gonna provide value for our customers, or whatever, those are all like much bigger questions I think...than worrying about can Laravel be used for "Big" apps. MATT STAUFFER: One of the questions we got on Twitter was, how to build big sites with Laravel, scaling, deployment,  database structure, load balancing, so, lets say someone is on board right...yes, Laravel can be used for big apps period..it's good..so, what are some considerations that you would have, so if you were taking, you know, a default app out of the box and you "laravel new" it and you build some basic stuff and someone says alright, this app that you just built needs to be able to handle you know, a million hits a week next month..what are the first things you would look to, to start, kind of hardening it against that kind of traffic? TAYLOR OTWELL: Hmm, really simple things you could do is to make sure you are using a good cache or session driver, so probably you wanna use something like Memcache or Redis or something that you can centralize on one server or Elasticache if you are on AWS whatever, you know, you are also probably gonna use a load balancer...PHP is really easy to deploy this way you know, to put a LoadBalancer up and to make a few PHP servers and to alternate traffic between them. PHP makes it really simple to do that kind of scaling and then with Laravel, make sure you use config cache, make sure you are using the route cache, make sure you are doing composer dump autoload optimized, you know, really simple things you can do to sort of boost your application a little bit. MATT STAUFFER: Jeffery, I know Laracast is pretty huge, you kinda in there day in, day out, so I know you are super focused on making sure that it's performing, especially related to maybe, let's say, databases and deployment, can you give me any kind of tips that you have there for people who are building new kind of high traffic apps that you have learned from developing Laracast? JEFFREY WAY: Yeah, Laracast is surprisingly high traffic, if you look at the numbers. And I can tell you, not doing that much...just to be perfectly frank, beyond what Taylor said, a lot of that stuff is kind of the fundamentals...of using config cache...a lot of people will just deploy and stick with the file based cache driver...laughs..you will obviously have some issues with that...but, I am not doing anything that fancy. A lot of it becomes basic stuffs like, people completely ignoring the size of their images...like that is always the very first one I bring up and it's such a 101 tip, but if you go from site to site, you can see it being abused immensely. There is so many ways to work it into your build process...or if not, just dragging a bunch of images into..like a Mac app...I am trying to think of the one I use... TAYLOR OTWELL: Is it ImageOptim? JEFFREY WAY:  ImageOptim, yeah just, like when you deploy you can drag a bunch of images up there and it will automatically optimize them as best as it can. And you would be shocked how much benefit you can get from that...versus people who just take a 100kb image and they throw it into their project...you know it's funny that people will debate single quotes versus double quotes all day and then throw a 200kb image into their banner, you know, it makes no sense, people, are silly that way. TAYLOR OTWELL: I think another great thing to do is separate out your database from your web server. If you are building anything, you know, that you care about...like in a real way, it can be good to do that..and sort of, if you don't do it from the start, it can be kind of, you know, scary to make the transition, because now you've got to move your live database to another server...but, there are tools out there to make it pretty easy, there are even free packages out there to make it pretty easy to back up your database, so, that has always been really nice for me to have that on a separate server. So definitely if you are gonna have to start do that because it just makes it easier to do that scaling where if you wanna add a second server, you don't have this sort of funky situation where you have one webserver talking to another webserver because it has your database and all that other stuff where now if you want upgrade PHP you've got to upgrade PHP on the same server that your live database is running on...just scary situations like that...that, that would help you avoid. MATT STAUFFER: Are you guys using a lot of caching on your common Eloquent Queries? JEFFREY WAY: Yeah, I do quite a bit. TAYLOR OTWELL: I really don't on Forge. MATT STAUFFER: I wondered about Forge, because with Forge, each query is gonna be unique per user right? Versus with Jeffery where there might be like a page that lists out all of the episode and you might have 10, 000 people hit that same page. With Forge, it's more 10,000 people each seeing a totally different list right? TAYLOR OTWELL Yeah, it is very dynamic. The one thing I do cache is the list of invoices from stripe because there is a stripe API call we have to make, so we do cache that. JEFFREY WAY: Yeah me too. TAYLOR OTWELL: But other than that I don't think I really do any caching. So, Jeffrey probably has more insight on that...? JEFFREY WAY: Well I have a lot of the stuff on the Forum, because the forum just gets hammered...you will be surprised about how popular that forum is... MATT STAUFFER: I won't be surprised because it shows up on the top results of everything. JEFFREY WAY: I know and I do love finding my forum when am googling for my own ignorance. And I go to my own website to figure out how to do something which is a great feeling! But I do have some queries related to the forum that are pretty intense, a lot of like multiple joins, pulling in stuff, so I do cache that..even summary,  I cache that every 10 minutes at a time. Just to reduce the weight a little bit. I get a lot of use out of that stuff and then, yeah, of course, the type of stuff that doesn't just change like Categories or Channels or like Taylor was bringing up, there is no reason not to cache those things. And yes especially the invoices it's a great example, if you are making a network query every single time a page is hit, there is really no need to do that if it's going to be the exact same results...every single time give or take a change or two...so those are obvious cases where you want to cache it as long as you can. TAYLOR OTWELL: How do you burst your cache on Laracast? JEFFREY WAY: Whenever something cache bustable takes place...I guess... TAYLOR OTWELL: Ok so I guess like whenever a new category is out and stuff, you just ... JEFFREY WAY: When a new category is out yeah, as part of that I will just manually bust the cache...or no, I will automatically bust the cache...in other areas, it happens so rarely that I just boot up 'php artisan tinker' and do it myself....*laughs...*which is crappy, but no, anything more common like that, I will just automate it as part of the...whenever I update the database. MATT STAUFFER: We are working on an app right now that has Varnish sitting in front of it. And so literately the code that is behind our Skype window right now is me writing a job that just wipes the Varnish cache either for the whole thing or for specific routes in response to us notifying that the change happens and that's an interesting thing because the cache is outside of Laravel app, but it's cached based on its routes...and so I have the ability to say...well, these particular changes are gonna modify these routes and I built an intelligent Job that kinda get sent out anytime we need those things. So even when it is not within the app, even when it is not your Laravel cache, there is still a lot of ability to kind of put some heavy caches on. And in speaking of that kind of stuff cache busting, use the Version in mix all the time. I mean that is just, because then you can throw Varnish or whatever else and just do infinite cache on your assets. And if you all don't know what that is, it's essentially every single asset that gets built by Mix now has like a random string appended at the end of the file name. And every time it's changed, it gets a new random string on it. And so you can set a forever expires on your Javascript files, your CSS files or whatever else, because anytime it needs to change, it would actually be a different file name as your browser will get to request it and then Varnish will get re-request it or whatever is your cache is. JEFFREY WAY: But on that note, actually, I have been thinking about that, is there...can you guys tell me any real reason why when we are using Versioning, the file name itself needs to change? Because you are using that Mix helper function already to dynamically figure out what the version file is, so is there any reason why we can't just use a unique query string there, or not a unique query string but taking where we would change the file name to include the version, we just include it as part of the query string and then the file name always stays the same? MATT STAUFFER: I know that HTML5 boiler plate used to do just query strings and I hadn't even thought about that, but that might be possible, where the files always stay the same but your...what's that JSON file that has the .... JEFFREY WAY: JSON manifest... MATT STAUFFER: Maybe that just adds the id into the new id to pass? And it's just like authoring comment or something like that? JEFFREY WAY: Yeah, when you version the file, it creates, basically it gets like a Hash of the file that you just bundled up and then that gets included in the new file name...but every time you bundle if that changes, you will never know what that file name is called in your HTML so basically you can use this Mix helper function that Laravel provides that will dynamically read that JSON file and it will figure out, oh you want this file, well, here is the current hashed version and we return that...but yeah I have just been thinking lately like, is it kind of dumb that we keep creating a new file, when instead, the Mix manifest file can just have the relevant query string updated. MATT STAUFFER: So, I googled really quick and there is a thing from Steve Souders....who is the guy who originated the 13 rules of make your website faster or whatever they were...the whole like, you know less HTTP requests, and it's called in your files names don't use query strings...I havent read it yet...oh High Performant websites...I havent read it yet and it is 9 years old. My God! Now that I am seeing seen him talking about Squid, I have worked with Squid before which is like a pretty old cache, but a lot of stuff that works for Squid also works for Cloudflare so I am guessing Cloudflare is either using Squid or adopted Squids terminologies and I do think...and I also did a whole bunch of work with one of our clients who is writing custom Varnish rules right now. And I do remember that stripping query strings is a thing that happens sometimes especially when it doesn't matter, for example in the case of asset, I think it maybe a thing that he do by default, so he is digging through here and Squid and proxies and stuff like that, I think basically what he is saying is your proxy administrator could go and teach the  proxy to care about query strings but all then ignore them by default... JEFFREY WAY: Ok MATT STAUFFER: So by choosing to use it with query strings you are opening up a lot of job opportunities where it doesn't work the way you are expecting. TAYLOR OTWELL: I have been using Cloudflare quite a bit recently. The whole Laravel website is behind Cloudflare, heavy Cloudflare caching, very few requests actually hit the real server. Mainly because it's all static, you know documentation but am a big fan of that, especially when you are scaling out webservers, if you are using, you know, some kind of Cloudflare SSL. I think Amazon has a similar SSL service now, it makes so much easier to add a web server because you don't really have to think about your certificates as much, you know, putting your certificate on every server, especially because since you can just use like a self-signed certificate if you are using the Cloudflare edge certificate...so that's something to look into and it's free to get started with and it has some nice feature for scaling.  MATT STAUFFER: I helped some folks at this thing called the Resistance Manual, which is a Wiki about basically...huh......sorry to be mildly political for a second...all the negative impact of the Trump presidency and how to kind of resist against those things. And so they wanted me to help them gather their information together and I said well I can help out, I am a tech guy and they were like, do you know, you know, media wiki, which is the open source platform behind things like Wikipedia, and I said no, but you know, I can learn it. Turns out that it's like really old school janky procedure PHP and so I said yeah I can handle this but it is also just extremely dumb in terms of how it interacts with the database and so when you are getting you know millions of hits like they were on day one, we had a like a 8 core, you know, hundreds of hundreds of dollars a month Digital Ocean box and it was still just tanking. Like couple of times a day that the caches were getting overflowed and all that kind of stuff, so, I threw clouldflare on it, hoping it would be magical and the problem with that is it's not Cloudflare's fault it's because Cloudflare or Squid or Varnish needs to have some kind of reasonable rules knowing when things have changed and for anyone who has never dealt with them before there is a sort of complicated but hopefully not too complicated dance between your proxy and reading things like expires headers and E-Tags and all that kind of stuff from your website. And so if you throw something like Cloudflare or something like that on it and it is not working the way you expect, the first thing to look at is both the expires headers and the cache link headers that are coming off of your server pre-cloudflare and also what that same response looks like when it's coming back after going through cloudflare, and cloudflare or whoever else will add a couple of other ones like did it hit the cache or miss the cache and what's the expires headers and what's the Squids expires headers, so there are lots of headers that give you the ability when it just seems like it is not just working the way you want and there is only like 3 configuration options in cloudflare, then what do you do? Go look at your headers and I bet that you know, 15 minutes of googling about how cloudflare headers work and Squid headers work and then inspecting all your headers before and after they hit cloudflare and you will be able to source out the problem. Alright so, we talked databases, we talked loadbalancing a little bit, deployment, so, if anybody is not familiar with zero downtime deployment, just a quick introduction for how it works...if you use deployments on something like Forge the default response when you push something new to your github branch is that it hits 'git pull', 'composer install' 'php artisan migrate' or whatever, so your site could erratically be down for seconds while the whole process runs and so, if you are worried about that  you can run, 'php artisan down' beforehand and 'php artisan up' afterwards, so when it's down, instead of throwing an error, you just see like hey this site is temporary down kind of thing. But if you are in a circumstances where that is a problem, you might want to consider something like Capistrano style or Envoyer style zero downtime deploy, look somewhere else for a much longer explanation but essentially, every time a new release comes out, it's cloned into a new directory, the whole installation is processed and run there and only once that is done, then the public directory  that is getting served is symlinked into that new directory instead of the old one. So you end up with you know with the last 10 releases each in its own directory and you can go back and roll back into a previous directory and Taylor's service Envoyer is basically a really nice User Interface in front of that... For me that has always been the easiest way to handle deploys in a high kind of pressure high traffic high loads situations is just to use Envoyer or Capistrano. Are there any other experiences you've all had or tips or anything about how to handle deploys in high traffic settings when you are really worried about you know those 15 seconds or whatever...are there any other considerations we should be thinking about? or anything? TAYLOR OTWELL: That's the extent of my experience..I haven't had anything that is more demanding than using Envoyer. Am sure there is you know...if I were deploying to thousands of servers, but for me when I am just deploying to 4 or 5 servers Envoyer has been huh...pretty good bet. MATT STAUFFER: And hopefully if you are deploying to a thousand sites, then you've got a server person who is doing that. You know like we are talking dev'ops for developers here right,  like when you are running a minor server not when you are running a multi-billion dollar product and the clients I have been talking to were working with all these kind of Varnish stuff..I didnt setup Varnish you know, my client setup Varnish and took care of all these stuff and he just kinda asked me for an input in these kind of stuff and so I definitely would say like there is definitely a limit at which...you know...people often lament like how many responsibilities they are putting on developers these days. I don't think we all have to be IT people capable of running servers for you know, a one thousand server setup for some massive startup or something like that. But I think like this whole, you know, how do I handle a thing big enough that 15 seconds of down time where a  migration and composer run...I think that is often within our purview and I think something like Capistrano or Envoyer is for me at least it's being a good fix...the only situation I have not had to run into which I have heard people asked about online and I wanna see if you all have any experience there is, what if you do a roll out and it has a migration in it and then you need to roll back?  Is there an easy way to do the 'migrate:rollback' in an Envoyer rollback command or should you just go Envoyer rollback as you SSH in and then do 'php artisan migrate:rollback' TAYLOR OTWELL: Sort of my view on that recently like over the past year has been that you will just never roll back, ever. And you will always go forward. So, because I don't know how you rollback without losing customer data. So, it's, a lot of time not really visible to rollback. Lets just pretend you could, then yes, there is no real easy way to do it on Envoyer, you will just kind have to SSH in and do php artisan rollback like you said. But I think a lot of times, at least for like my own project like Forge and Envoyer, I can never really guarantee that I wasn't loosing data so I think if at all possible, what I would try to do is to write an entirely new migration that fixes whatever problem there is. And deploy that and it will just migrate forward, you know. And I will never really try to go backwards. MATT STAUFFER: You find yourself in that accidental situation where you deploy something that should never have been, then you then go 'php artisan down' real quick, run the fix, push it up and let it go through the deploy process and then 'php artisan up' after that one deployed. TAYLOR OTWELL: Yeah. That's what I would do. If it's, I mean, sometimes if it's low traffic and  you feel pretty certain no one's messed with the new database schema, then probably you can just roll back, but, I was just worried  in Forge's case that people are in there all day, I would lose data. So that's why I would every time possible to try and go forward. MATT STAUFFER: Yeah, that makes sense. TAYLOR OTWELL: I have actually stopped writing down methods in my migrations entirely recently...not that it's optional. JEFFREY WAY: I feel evil doing that! Like I very much get the argument...but, when I create a migration and I just ignore the down method, I feel like, I am just doing something wrong. I am still doing it right now. TAYLOR OTWELL: It's really mainly visible in Laravel 5.5 'cos you've got the new db:fresh method or db:fresh command, which just totally drops all the tables without running any down methods. MATT STAUFFER: I end up doing that manually all the time anyway because at least in development, the most often when I want to do refresh, it's often in context where I still feel comfortable modifying  old migrations..like basically, the moment I have run a migration in prod, I would never modify an old migration. The moment there is somebody else working on the project with me, I will never modify an old one unless I have to and it's just so important that I have to say hey, you know, lets go refresh. But often when I am just starting something out and I have got my first 6 migrations out, I will go back and  hack those things over and over again...I don't need to add a migration that has a single alter in it, when I can just go back and edit the thing. And in that context often, I change the migration and then I try to roll back, and sometimes I have changed it in such a way where the rollback doesn't work anymore. I rename the table or something like that... JEFFREY WAY: Right.... MATT STAUFFER: So fresh is definitely going to be a breath of fresh air. JEFFREY WAY: I do wish there was maybe a way to consolidate things, like when  you have a project that has been going on for a few years, you can end up in a situation where your migrations folder is huge...you just have so many. And it's like every time you need to boot it up, you are running through all of those and like you said sometimes, just the things you've done doesn't just quite work anymore and you can't rollback. It would be nice sometimes if you could just have like...like a reboot, like just consolidate all of these down to something very very simple. MATT STAUFFER: We did that with Karani I don't know if there is...there is a tool that we used that helps you generate Laravel migrations from Schema and we did it soon after we had migrated from Codeigniter to Laravel for our database access layer. Karani is a Codeigniter app where I eventually started bringing in Laravel components and then now, the actual core of the app is in Laravel and there is just like a third of the route that are still on Codeigniter that havent been moved over and once we got to the point where half of our migrations were Codeigniter and half of them were in Laravel it's just such a mess so we found this tool...whatever it was. We exported the whole thing down to a single migration, archived all the old ones,  I mean, we have them on git if we ever need them and now, there is just one..you know, one date from where you just get this massive thing, and then all of our migrations happen kind of, from that date. And for me, I actually feel more free to do that when it's in production because the moment it's in production, I have less concern about being able to speed it up through this specific process because like if something is from two months ago, I am sure it had already has been run in production and so I feel less worry about making sure the history of it still sticks around... JEFFREY WAY: Alright...right... MATT STAUFFER: Alright...so the next question we have coming up is, "I will like to hear about how you all stay productive." And we've talked on and off at various times about what we use..I know we've got us some Todoist love and I know we've got some WunderList  love...hummm... I've have some thoughts about Calendar versus Todo lists and I also saw something about Microsoft buying and potentially ruining Wunderlist..so what do y'all use and what happened with Wunderlist. TAYLOR OTWELL: Well, Todo lists are dead now that Wunderlist is dead. MATT STAUFFER: Yeah...So what happened? TAYLOR OTWELL: Wunderlist was my preferred todo list, I just thought it looked pretty good...and Microsoft bought them I think, that was actually little while back that they bought them but now they have finally announced what they are actually doing with it...they are basically shutting down Wunderlist and turning it into Microsoft Todo...which doesn't look a lot like the old Wunderlist and doesn't have some of the features of the old Wunderlist...but it looked ok..you know, it seems fun, so what I have done is migrated to Todoist rather reluctantly but it's working out ok. JEFFREY WAY: Please correct me...is this funny like, Wunderlist is gonna be around for a very long time but just the idea that they are shutting down it's almost like you feel compelled...we've talked about this with other things too...where it's like you suddenly feel like oh I need to migrate...we talked about it with Sublime, like if we find out tomorrow, Sublime is dead in the water. But you can still use it as long as you want. Even though, it would still work great, you would have this feeling like well, I gotta get over to Atom or I gotta start moving on...'cos this place is dead, even though Wunderlist is gonna work for a long time. TAYLOR OTWELL: Yes...laughs...as soon as it was announced, I basically deleted Wunderlist off my computer... All laugh.... TAYLOR OTWELL: Which makes no sense, but it's so true... MATT STAUFFER: I needed a new router and everyone told me, you use the Apple Routers 'cos they are the best...but I have heard they are 'end-of-life'd'....and I was like no way...no way I am gonna throw all my money there and someone say well, why does it matter...you know...you are gonna buy a router and you are gonna use it till it dies? And I said I don't care...I am gonna buy something else 'cos it just...I don't know...it's just like you are putting your energy and your effort after something that can't...you know can only be around for so long and you just want..you want be working with something that's gonna last I guess... JEFFREY WAY: Yeah...I am still on Wunderlist right now. I am hearing...humm..if you guys are familiar with "Things" that was like the big Todo app years ago...and then they have been working on Things 3 or third version for a year...it's been so long, that people joke about it..you know, it's almost like that...new version of..humm..what was it...there was hummm...some Duke Nukem game that.... TAYLOR OTWELL: Is it Duke Nukem Forever..? JEFFREY WAY: Yes! For like 10 or fifteen years and it finally came out! It's looking like next month, "Things 3" will be out and I am hearing it..like the prettiest ToDo app ever made I am hearing really good things. So, I was hoping to get in on the beta but, they skipped over me. So, I will experience it in May but I am excited about it. So, that's the next one..but you know what, I am never happy with Todo apps..I don't know why. It's kinda of weird addiction...if you say an item address basic need...even like a Microsoft Todo. Ok, your most basic need would be to like say...Go to the market on Thursday. You can't do that in Microsoft Todo. You have to manually like set the due date to Thursday. Rather than just using human speech. TAYLOR OTWELL: Have you tried Todoist? JEFFREY WAY: Todoist works that way. Huh I think Wunderlist works that way but now, Microsoft Todo doesn't. MATT STAUFFER: Oh ok..got it. You lost that ability right? JEFFREY WAY: Yeah, it's so weird like every task app would have something that's really great and then other basic things that are completely missing...and it's been that way for years. MATT STAUFFER: I always feel bad, I mean I bought things...thankfully I managed to skip...what was that thing...OminiFocus, I skipped OminiFocus which is good 'cos that is hundreds of dollars saved for me. And I tried...I tried all these different things and I finally figured out that  there is a reason why I keep jumping from one to the other, is because..for me...this is not true for everybody...and I think it might have to do with personality a little bit...and the industry a little bit, and what your roles are whatever, Todo lists are fundamentally flawed because they are not the way I approach the day...and they are not the place my brain is...so, I can force my brain into a new paradigm for even a week at a time but I have never been able to stick with it and it's not the app, I thought it was the app, I thought just once I get the right app, I will become a todolist person and I realized, I am not a Todolist person so I can try every app and it can be perfect and I will still just stop using it 'cos it's not what I think about. And when I discovered that I can't use and then later found some articles talking about how I am not the only person who come up with this...that validated me...'cos I put it on my calendar and so, if I need to do something, I put it on my calendar and then it gets done. And if I don't put it on my calendar, it doesn't get done. End of story. It's so effective for me that my wife knows at this point that if she asks me to do something and I don't immediately pick up my phone and put it on my calendar, she knows it's not gonna get done. Because that's..that's how things happen and so, it's amazing to me, that..laughs...she literarily, when she first started discovering this, she sent..and she's not not super technical..like she's smart, she just doesn't like computers all that much...but she knows how to use google..and so, she, when she first discovered this, she sent me a calendar invite that is "Matt Clean Toilet"...and it's for 8 hours every Sunday and so, I will be on a screenshare..'cos she's like that's how I am ever going to clean the toillet right?...so I will be on this screenshare with a client and I will pull up my calendar and to say hey when is it a good time for us to have this meeting? And I will be like..oh "Matt Clean Toilet" takes the 8 hours....laughs... But for me, my todo list is my calendar. And everyone kinda in the company knows what my calendar is completely for and Dan actually has asked me to start marking those things as not busy, so, Calendly, our appointment app will still allow people to book...like clients to book times with me during that time..but like essentially, if I need to get something done, like, I..I need to review a whole bunch of pull requests, like Daniel who works with me literarily just put meeting invite on my calendar for tomorrow 10:30 and it says "Code Review @ Daniel". And literarily after this podcast, there is an hour that says "Code Review with James" because they know that that's how they get it....and there is...500 hundred emails in my inbox and all these other things I have to do, but if it goes to the calendar,  it gets done.  So, have you guys ever tried that? Does it sound like something that will click with you or no? JEFFREY WAY: I think it makes good sense for you because it sounds like your days are scheduled like your day is full..humm...my day isn't quite as much like do this with so and so, I don't have as many meetings. So, most of my day is like: these are the things I wanna get done. And it doesn't matter whether I do it at 9:AM or 9:PM, so, Todo list works good for me but yeah..I can see how like if my day was very segmented and scheduled that would make far more sense than reaching for some todo app. TAYLOR OTWELL: Yeah..my days are usually pretty free-form outside of the kinda standard schedule where I always do emails and pull requests first thing in the morning but then after that lately it's been...you know..was work on Horizon..now it's work on the thing that comes after Horizon, and that's pretty much the rest of the day, you know, besides whatever Laracon stuff that I have to do recently, which is more of a seasonal thing you know. But I got lunch, all booked, that's done...but whatever we need, you know, furniture, catering or whatever. But yeah, then I pretty much just work on one thing throughout the day. So, I don't really switch context like that a lot. But I was so despondent at the Wunderlist announcement that all Friday afternoon I wrote a chrome extension that when you open  new tab, it opens "Discussing Todo List" that I wrote in VueJs and you know HTML and it uses the chrome sync to sync it across my chrome account to all my laptops whatever...so... every new tab has a todo list, but even that, I was still not happy with it and deleted it and the whole afternoon went with the todo list. Anyway, but I have forgotten about the Chrome extension thing. I need to open source it. MATT STAUFFER: Every developer has to make their own Todo list at some point in their lives. TAYLOR OTWELL: Yeah. That's interesting about the calendar though...I want to get Calendly because it looks like a really cool app and try some more calendar stuff 'cos I haven't really dug into that as much as I could. MATT STAUFFER: Yeah...I use basic Calfor my desktop app, I know that, I  think I use Fantastic Cal on the phone or something..a lot of people love that...the thing that we like about Calendly is that it gives me a public link that syncs up to my Google calendar and so when we need to schedule things like we are in the middle of hiring right now or client meetings, I just send them to my calendly link and I just say, go here and  schedule time with me and it syncs up with my Google calendar and it shows them all the times and I can say..go schedule a 60 minutes meeting and I give them the 60 minutes link or 5 minutes or whatever and you can put different rules around each. So I teach calendly when do I drop my son off at school and when do I ...you know drive from my home office to my work office all that kind of stuff...so that it knows when I am available and then..because we just wasted so much time between Dan and me trying to get our calendars in sync. So, that's what I love about Calendly. TAYLOR OTWELL: What really sold you on basic Cal over like you know just Apple Calendar or whatever? MATT STAUFFER: I wish I can tell you...I know that it handles multiple calendars better...but it's been so long since I made that choice that I couldn't even tell you. I know that Dan, my business partner hates calendars more than any person I have ever met and almost every time he complains about something, I am like oh yeah, you can do that with Basic Cal and he is like "I still use Apple Calendars" I know those things but I can't tell you what they are..so. Alright...so one last question before we go for the day. Saeb asked "It would be nice to hear why are guys are programmers. Is it just something you love and enjoy or is it just a way to put bread on the table? Is it passion what is it that makes you wanna be a programmers?" JEFFREY WAY: I will go first. I fell into it. I think we are being disingenuous if we don't say that to some extent...but  I know even from when I was a kid, I love the act of solving puzzles. I remember I had this Sherlock Holmes book and it's one of those things where every single page is some little such and such happens...somebody was murdered and then Sherlock comes, points to so and so and says you are the  person who did it. And the last sentence is always..."How did he know?!" And that was like my favorite book. I would go through it every day and try to figure out how  how did he figure out that this was the guy who...you know...robbed the bank or whatever it happened it be. So, between that or I play guitar for over a decade and I went to school for that. It's all still the same thing of like trying to solve puzzles trying to solve riddles trying to figure out how to connect these things. You may not know it with guitar but the same thing is true, like puzzles and you start learning about shapes on the guitar and how to transpose this to this. And how to play this scale in eight different ways...it's still like the same  thing to me it's figuring out how to solve these  little puzzles. And so for programming, I feel like it's the perfect mix of all of that. There needs to ne some level of creativity involved for me to be interested in it....I always worried I would end up in a job where I just did the same and only this thing every single day. And I would finish the day and come back tomorrow and I am gonna do the exact same thing all over again. So there needs to be some level of creativity there which programming does amazingly well or offers amazingly well. Although my mum would never know. I think she thinks I gave up on music and went to this like boring computer job...and even though when I explain to her like no there is huge amounts of creativity in this I don't think she quite makes the connection of how that is. So, yeah, between the creativity and solving puzzles, and making things, it's a perfect mix for my personality. TAYLOR OTWELL: I was always really into computers and games and stuffs growing up, so it was pretty natural for me to major you know in IT in college but I didn't really get exposed to the sort of the front side of programming and open source stuff until after college when I started poking around on side projects and stuff like that. So, I did kind of fall into this side of programming you know, where, you are programming for fun as a hobby and working on open source after I graduated but I was always kind of interested in looking back sort of things that are similar to programming so like into games like SimCity and stuff like that where you are planning out you know, your city and sort of...one of the similar things you do when you are building up big projects or whatever a big enterprise project you know was sort of planning and trying to get... just the right structure whatever, so I was kinda always into that thing. And just sort of naturally fall into that path later in life. MATT STAUFFER: I...my brother and I started a bulletin boards service...out of our spare bedroom, I mean we were in Elementary or middle school or something like that..and he is 3 and half years older than me and he is a little bit more kind of like intellectual  than I am, so, he learned how to code the things and he said why don't you be the designer. And that kind of trend just kept up. When he learned how to make websites, he be like well, I am gonna make websites and you be the designer. And so I kinda had this internalized idea that A...I was interested in tech..but B, I was the design mind. And the thing is, I am not a very good designer...like the only reason I kept getting into design is because I had like... I was creative, I was a musician and stuff but also because my brother already had the programming skills down and so he needs a designer right? And so, I think that I went off to college, by that point I already had a job as a programmer, I already had my own clients, doing you know frontend web developments and basic PHP, Wordpress that kind of stuff but I was like well I need to become a better designer so I went off to college for design and I just realized I am not a designer, so I left. And I went off and I did English and I worked with people and I worked for a non-profit having thought you know like oh that is not my thing and then I kinda did a turn round when I left the non-profit, my wife went back to school and I needed to pay the bills, so it was..there is an element of paying the bills..I say like well I know that web development pays well, so I will go back to that. And just discovered that I love web development...it is fulfilling and it is satisfying...it is creative...it's using your brain in all this really interesting ways...each one it's a little bit the same, a little bit unique, there is always really great things about it...I mean I remember one of the things that drove me nuts about my previous work..both in design and in working in the non-profit is that there is no sense like whether you did a good job or not. There is no sense of when something is done. You are just very kinda of vague and vacuous and with this, it's like there is a defined challenge...and you know when it's done. And you know whether you did a good job or not. And I was just like that was huge...that was so foundationally helpful for me. And so I think just kind of being able to approach it and realize that it's creative..like, it's creative and it is well defined..it's a little concrete..it's a challenge all those things together I think for me..and it turns out that it wasn't just a way to make money and I have also since discovered now that I run a company that I also have all the people aspects here..it's about relationship, it's about communities...I mean we have talked about that a lot in this episode and running a company is about  hiring and  company culture and all those kind of stuff... So I get to comment especially at the level of tech that I get to do day to day whether it's open source or running company I feel like it's all of the best together in one word. JEFFREY WAY: So Matt, how did you go from taking on smaller projects when you went back to web developments to suddenly running Tighten? Like how did you get there? What happened? Were you getting more projects than you can handle? MATT STAUFFER: The opposite. I...I had no work. I worked out of a co-working space in Chicago and I only had about 10 hours a day, fifteen hours day filled because I didnt know anybody. And I had not been doing anything in the industry for 6 years. So, I said, you know what? When I worked for non-profit there was this need I had and I still worked for those non-profit's per time at that point, so I just started building an app...I built an app by hand while I worked for the non-profit in PHP and it was terrible. And I was like oh, I have heard about this framework thing, and so I tried building it in CakePHP and it was terrible, and so, those experiences matured me a little bit...and so by the time I was now kinda going solo as a developer, every free moment I would have, outside of the you know, the contract work I had, I would go learn Codeigniter. You know my buddy Matt had learned ExpressionEngine and said hey, checkout Codeigniter I think you might like it. So I learned Codeigniter and I did all these work in Codeigniter and I built  this whole app which is Karani, the thing we are talking about today and I built Karani and I made it for myself and then my friends wanted it and so then I made it for my friends and then it was costing me money to upkeep, so I learned how to charge them money..and Stripe was brand new at that point, so I almost went with Stripe but I ended up going with BrainTree...I got into like big and software as a service app development through there...and right at that same time... I was teaching my buddy all about modern web development HTML5 boiler plate all that kind of stuff after work one day and this guy walked over...the one guy in my co-working space that I had never met, who was always in his closed office and he was like, are you a developer? Are you looking for work? I was like yeah..and he was like..I need you...would you consider working for me? I played it all cool but I was like YES..PLEASE I NEED WORK!!! I only have 10 hours of work a week right now. And it was Dan... And so, Dan and I worked together on this massive project for a year and the client took 6 months to actually get the work ready for us. And he already had me booked  and he already had me billed and he was why don't you just go learn become the best possible developer you can..I will throw you know, 30 hours a week jobs just off my various you know various projects...but in all your free time and even in those projects, just learn to become the absolute best, because we were working for, you know, this massive billion dollar international company at that point. And responsive was like  just a thought in people's minds. So, I wrote you know, articles and I created responsive libraries back in the early days of responsive and all those kind of stuff and I was like really up in the middle of it. And then we built this app. So, I had like a lot of kind of things that took me very quickly from like hey I haven't written any code or any professional code  in 6 years to like to the point where I was ready to build an app for this billion dollar company. JEFFREY WAY: That was amazing. That is how learn best too. MATT STAUFFER: It really is..and Dan and I loved working together so well that within 6 months we decided to go into business together and 6 months or a year later, we named it Tighten and the rest is history. MATT STAUFFER: And so, we are super late and Jeffery, you are the one who has to edit this all later, so I apologize for that..so Ok. Future Jeffery, editing this, I am going to do you a favor, call it a day for now so..guys...it's been a ton of fun..everyone who submitted questions to us on Twitter, the ones we didn't get to today, they are still on our trailer board, we will get to some of them next time... But keep sending us stuff for us to talk about and like I said, the Laravel news podcast is doing a fantastic job of keeping you up to date on regular basis with news so definitely tune in there for that...but we are gonna be talking about more long form stuffs  when you got questions for us, send them to us either to our personal accounts or twitter account..for the podcast and we will try to get to them whenever we can..so, until next time..it's Laravel Podcast thanks for listening. MUSIC fades out...

Are there new Web Performance Rules since Steve Souders started the WPO movement about 10 years ago? Do we still optimize on round trips or does HTTP/2 change the game? How do we deal with “mobile only” users we find in emerging geographies. How does Google itself optimize its search pages and what can we learn from it. In this session we really got to cover a lot of the presentation Pat Meenan (@patmeenan) did at Velocity this year.Related Links:* Scaling frontend performance - Velocity 2016***** https://www.youtube.com/watch?v=LdebARb8UJk * WEBPAGETEST***** https://www.webpagetest.org* Google AMP***** https://www.ampproject.org/***** https://github.com/ampproject/amphtml

Are there new Web Performance Rules since Steve Souders started the WPO movement about 10 years ago? Do we still optimize on round trips or does HTTP/2 change the game? How do we deal with “mobile only” users we find in emerging geographies. How does Google itself optimize its search pages and what can we learn from it. In this session we really got to cover a lot of the presentation Pat Meenan (@patmeenan) did at Velocity this year.Related Links:* Scaling frontend performance - Velocity 2016***** https://www.youtube.com/watch?v=LdebARb8UJk * WEBPAGETEST***** https://www.webpagetest.org* Google AMP***** https://www.ampproject.org/***** https://github.com/ampproject/amphtml

On today's episode we sit down with Steve Souders and Mark Zeman of SpeedCurve. We talk about the benefits that come from Developers and Designers working side by side, and how the users are often a key component in uniting these (and other) disciplines. Mark discusses “perceived performance”, and we talk more about flowing the user experience over time, and some techniques on how to do that. We also talk about the difficulty in determining which metrics you should be measuring for your website. We are sponsored this week by Catchpoint Systems. Sign up for a free trial at catchpoint.com/freetrial. Show Links: Steve Souders Mark Zeman SpeedCurve Vox Media Declaring Performance Bankruptcy The Mobile Web Sucks Episode 10 of Path to Performance with Tammy Everts Tammy Everts Time is Money Perf.email Newsletter #perfmatters t-shirt #perfmatters poster WebPageTest YSlow 14 Rules for Faster-Loading Web Sites Jason Grigsby Lara Hogan Designing for Performance Path to Performance presentation Design Decisions Through The Lens Of A Performance Budget presentation The Space Between presentation Ilya Grigorik

Steve and Andi discuss the importance of metrics, which ones we have right now and which ones Steve believes will become more important in the future.Twitter *Guests:****Steve Souders: @souders*PurePerformance:**Hosts ****Andi Grabner: @grabnerandi****Brian Wilson: @emperorwilson*Feedback: #PurePerformance @Dynatrace

Steve and Andi discuss the importance of metrics, which ones we have right now and which ones Steve believes will become more important in the future.Twitter *Guests:****Steve Souders: @souders*PurePerformance:**Hosts ****Andi Grabner: @grabnerandi****Brian Wilson: @emperorwilson*Feedback: #PurePerformance @Dynatrace

Wouldn't it be great if your browser anticipated what you wanted before you asked for it? Web pages could arrive before you finished typing the URL. Science fiction? Not at all. This talk uncovers several techniques available to browsers and web developers today to move us closer to an instantaneous web experience. Preresolve, prefetch, prerender, preload, and other predictors: What do they all mean? Which browsers support them? How do web developers take advantage of them, and make sure not to break them? More info at: https://fronteers.nl/congres/2013/sessions/pre-browsing

Wouldn't it be great if your browser anticipated what you wanted before you asked for it? Web pages could arrive before you finished typing the URL. Science fiction? Not at all. This talk uncovers several techniques available to browsers and web developers today to move us closer to an instantaneous web experience. Preresolve, prefetch, prerender, preload, and other predictors: What do they all mean? Which browsers support them? How do web developers take advantage of them, and make sure not to break them? More info at: https://fronteers.nl/congres/2013/sessions/pre-browsing

When does slow actually feel fast? And vice versa? Steve provided examples from the Web and the real world that show it's not all about metrics - sometimes altering the user's perception of speed is the best path to a better user experience. More info at: https://fronteers.nl/congres/2013/jam-session/the-perception-of-speed

When does slow actually feel fast? And vice versa? Steve provided examples from the Web and the real world that show it's not all about metrics - sometimes altering the user's perception of speed is the best path to a better user experience. More info at: https://fronteers.nl/congres/2013/jam-session/the-perception-of-speed

We tuned the databases - for scaling up and scaling out - grids and clouds and no-sql. We tuned the servers - for scaling up and scaling out - farms and clusters and automated deployment. We tuned the network - accelerations and caching and CDNs. What's next? Web Performance Optimization - appealing to developers and designers alike, we are focusing on that last (or maybe first) piece of the puzzle: the client-side. There's been an explosion of tools and techniques around browser optimization and performance analysis, since the first time Steve Souders released the first version of YSlow! Now we have a twitter hash tage #WPO, meetup groups from New York to Seattle, to Frankfurt and Beijing. Vendors are rampantly adding "web performance" capabilities in their existing tools - trying to catch-up with the myriad open-source utilities employed by engineers learning the #WPO craft. This episode of PerfBytes will jump into the party and pass around a wealth of advice and context to understand the Web Performance Optimization fad.Original Air Date: Tuesday, January 8th, 2013 8AM EST

We tuned the databases - for scaling up and scaling out - grids and clouds and no-sql. We tuned the servers - for scaling up and scaling out - farms and clusters and automated deployment. We tuned the network - accelerations and caching and CDNs. What's next? Web Performance Optimization - appealing to developers and designers alike, we are focusing on that last (or maybe first) piece of the puzzle: the client-side. There's been an explosion of tools and techniques around browser optimization and performance analysis, since the first time Steve Souders released the first version of YSlow! Now we have a twitter hash tage #WPO, meetup groups from New York to Seattle, to Frankfurt and Beijing. Vendors are rampantly adding "web performance" capabilities in their existing tools - trying to catch-up with the myriad open-source utilities employed by engineers learning the #WPO craft. This episode of PerfBytes will jump into the party and pass around a wealth of advice and context to understand the Web Performance Optimization fad.Original Air Date: Tuesday, January 8th, 2013 8AM EST

This week, Steve Souders comes on the show to talk about web performance. We talk about the the state of performance in general, how to create a performance culture at your company and the importance of thinking big.

The word is getting out. Great web site experiences require careful development and crafty execution in the front end. Squeezing every drop of performance out of your user's browser is tough, but Steve Souders and friends have mobilized an army, and we are all having a bloody good go. But there is a common threat to doing great work in the front-end. It lurks in the back-end and clients love it. It's the content management system, and more often than not, it stinks. More info at: https://fronteers.nl/congres/2012/sessions/i-can-smell-your-cms-phil-hawksworth

The word is getting out. Great web site experiences require careful development and crafty execution in the front end. Squeezing every drop of performance out of your user's browser is tough, but Steve Souders and friends have mobilized an army, and we are all having a bloody good go. But there is a common threat to doing great work in the front-end. It lurks in the back-end and clients love it. It's the content management system, and more often than not, it stinks. More info at: https://fronteers.nl/congres/2012/sessions/i-can-smell-your-cms-phil-hawksworth

Carl and Richard talk to Steve Souders about making mobile web apps run faster. Steve talks a bit about the general issues around web page performance, including how some of the new features of HTML 5 are improving performance. The conversation then turns to tools for testing mobile web performance. Steve gives us a huge list of web sites to test your mobile web performance - check 'em out in the show links!

Steve works at Google on web performance and open source initiatives. His book, Even Faster Web Sites, explains his best practices for performance. Steve is the creator of YSlow, one of the top 25 Firefox add-ons.

Web 2.0 is adding more and more content to our pages, especially features that are implemented in Ajax. But our web applications are evolving faster than the browsers that they run in. We don't have to rely on or wait for the release of new browsers to make our web applications faster. In this session, Steve Souders discusses web performance best practices from his second book, Even Faster Web Sites. These time-saving techniques are used by the world's most popular web sites to create a faster user experience, increase revenue, and reduce operating costs. Steve provides technical details about reducing the pain of JavaScript, as well as secrets for making your page load faster in emerging markets where network connectivity is a challenge. Steve works at Google on web performance and open source initiatives. He previously served as Chief Performance Yahoo!. Steve is the author of High Performance Web Sites and Even Faster Web Sites. He created YSlow, the performance analysis plug-in for Firefox. He serves as co-chair of Velocity, the web performance and operations conference from O’Reilly, and is co-founder of the Firebug Working Group. He recently taught CS193H: High Performance Web Sites at Stanford University. Follow Steve on Twitter: @souders Licensed as Creative Commons Attribution-Share Alike 3.0 (http://creativecommons.org/licenses/by-sa/3.0/).

Web 2.0 is adding more and more content to our pages, especially features that are implemented in Ajax. But our web applications are evolving faster than the browsers that they run in. We don’t have to rely on or wait for the release of new browsers to make our web applications faster. In this session, Steve Souders discusses web performance best practices from his second book, Even Faster Web Sites. These time-saving techniques are used by the world’s most popular web sites to create a faster user experience, increase revenue, and reduce operating costs. Steve provides technical details about reducing the pain of JavaScript, as well as secrets for making your page load faster in emerging markets where network connectivity is a challenge. Steve works at Google on web performance and open source initiatives. He previously served as Chief Performance Yahoo!. Steve is the author of High Performance Web Sites and Even Faster Web Sites. He created YSlow, the performance analysis plug-in for Firefox. He serves as co-chair of Velocity, the web performance and operations conference from O’Reilly, and is co-founder of the Firebug Working Group. He recently taught CS193H: High Performance Web Sites at Stanford University. Licensed as Creative Commons Attribution-Share Alike 3.0 (http://creativecommons.org/licenses/by-sa/3.0/).

Carl and Richard talk to Steven Souders, creator of YSlow, an analysis tool for finding website bottlenecks on the client side of the equation.Support this podcast at — https://redcircle.com/net-rocks/donations