POPULARITY
3 episodes with PhantomJS
3 episodes with PhantomJS
3 episodes with PhantomJS
2 episodes with PhantomJS
4 episodes with PhantomJS
Kimmo Brunfeldt a software developer and an entrepreneur joins Ari Koponen on the Frontend Greatness podcast to talk about "Automated Visual Testing." In this episode: - Common challenges with visual testing - Tools for visual testing - Discussion on if visual testing worth all the trouble --- Episode Notes Social - Kimmo on Twitter: https://twitter.com/kimmobrunfeldt - Ari on Twitter: https://twitter.com/apkoponen Show Notes - Swarmia: https://www.swarmia.com/ - PhantomJS: https://phantomjs.org/ - CasperJS: https://github.com/casperjs/casperjs - SlimerJS: https://github.com/laurentj/slimerjs - Puppeteer: https://github.com/puppeteer/puppeteer - Playwright: https://github.com/microsoft/playwright - Squint: https://github.com/kimmobrunfeldt/squint - Cypress: https://www.cypress.io/ - Percy: https://percy.io/ - Chromatic: https://www.chromatic.com/ Kimmo's Recommendations - Frontend Focus: https://frontendfoc.us/ - Dan Abramov's blog: https://overreacted.io/
Enggak hanya membuat PhantomJS, Ariya Hidayat juga berhasil mengantarkan dua perusahaan di Silicon Valley sampai dibeli perusahaan besar. Dulu, Ariya pernah bergabung dengan Sencha Inc. dan Shape Security. Sencha Inc. adalah perusahaan software penyedia framework JavaScript yang open-source. Sedangkan Shape Security adalah perusahaan teknologi penyedia layanan keamanan cyber bagi perusahaan kelas dunia. Keduanya adalah perusahaan teknologi di Silicon Valley. Di Sencha Inc. Ariya berperan sebagai Engineering Director. Di sana ia berjasa dalam membangun perusahaan ini sampai akhirnya dibeli oleh IDERA Inc. yang berada di bawah naungan Embarcadero, perusahaan pencipta Turbo Pascal, Dephi, dan C++ Builder. Sebelum Secha Inc. dibeli, Ariya sempat dihubungi oleh Co-Founder Shape Security dan memintanya bergabung. Di perusahaan ini, ia berperan sebagai VP of Engineering yang memimpin tim dengan 50 engineer di dalamnya. Kurang dari dua tahun, Ariya beserta timnya berhasil meluncurkan sebuah produk. Setahun kemudian, penjualan produk tersebut melesat. Lalu setahun setelahnya, Shape Security jadi bernilai setara dengan Unicorn. Perusahaan ini pun kemudian dibeli oleh F5 Networks pada beberapa bulan yang lalu dengan nilai seharga 1 miliar dolar. Saat ini, Ariya tengah sibuk memajukan teknologi di Indonesia dengan berbagai cara. Salah satunya dengan membangun Deep Tech Foundation bersama teman-teman lainnya. Ikut terlibat dalam mengembangkan, memajukan, dan mendobrak teknologi di Indonesia adalah hal yang penting dilakukan bagi Ariya. Tujuannya agar Indonesia enggak hanya menjadi konsumen, tapi juga menjadi penggerak dalam pasar teknologi. Yuk, dengar cerita pengalaman dan pelajaran lainnya yang Ariya Hidayat dapatkan sampai bisa mengantar 2 perusahaan teknologi di Silicon Valley diakuisisi. Versi video: https://www.youtube.com/watch?v=ta827eDRSSQ Donasi: https://karyakarsa.com/rizafahmi
⁃ Об опыте перехода на JS после работы со статически типизированным C# (04:36) ⁃ Как Виталий стал Core Contributor в PhantomJS (08:04) ⁃ Как и почему было принято решение о прекращении поддержки PhantomJS (14:30) ⁃ О том где найти информацию о работе headless-браузеров (17:37) ⁃ О работе в GitLab и почему в GitLab выбрали именно Vue.js (24:17) ⁃ О запрете найма сотрудников из России в GitLab — https://habr.com/ru/company/flant/blog/474436/ (31:05) ⁃ О скандале со сбором метрик в GitLab — https://habr.com/ru/news/t/473850/ (39:30) ⁃ IT-сообщества в Ростове-на-Дону (47:23) ⁃ Плюсы работы в GitLab (58:22) ⁃ Плюсы и минусы жизни в Ростове-на-Дону (1:07:46) Доп. ссылки: Блог Lin Clark на mozilla.org - https://hacks.mozilla.org/author/lclarkmozilla-com/ Подкаст “How do browser work?” (Lin Clark) - https://dev.to/codenewbie/s2e2--how-do-browsers-work-lin-clark “How Browsers Work: Behind the scenes of modern web browsers” - https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ Доклад Виталия “Headless browsers: что, как и почему” - https://www.youtube.com/watch?v=kkP0PFeRJdQ Доклад Виталия “Сквозь Open Source к звездам” - https://www.youtube.com/watch?v=bI9Mi7qvBUI Твиттер сообщества RND.JS - https://twitter.com/rndjsmeetup Ростовское IT-сообщество - https://it61.info/ Telegram—канал CSSSR: https://t.me/csssr Twitter CSSSR: https://twitter.com/csssr_dev Telegram ведущего: https://t.me/sgolovin Twitter ведущего: https://twitter.com/_sgolovin Telegram редакции: https://t.me/Vindizh Twitter редакции: https://twitter.com/Vindizh
On this podcast, Wes talks to John Xmas. Johnny works for Kasada, a company that offers a security platform to help ensure only your users are logging into your web applications. Johnny is a well-known figure in the security space. The two discuss common attack vectors, the OWASP Top 10, and then walk through what hackers commonly do attempting to compromise a system. The show is full of advice on protecting your systems including topics around Defense in Depth, Time-Based Security, two-factor authentication, logging/alerting, security layers, and much more. Why listen to this podcast: - While there are sophisticated web attacks out there that use things like PhantomJS or Headless Chome, the vast majority of the web application attacks are the same unsophisticated scripted attacks that you always hear about. These are simple scripts using tools like curl and BurpSuite with Python or JavaScript. These simple scripts are still incredibly effective. - OWASP Top 10 really hasn’t changed all that much in the last ten years. For example, despite being the number one approach used to educate defensive engineers on how to protect their apps, SQLI (SQL Injection) is still the most common attack. We continue to repeat the same mistakes that have exposed systems for a decade now. - Phishing is by and far the quickest way to compromise a system. Defensive in Depth, security boundaries, limiting local admin rights are all things that corporations can implement to minimize the blast radius. - Attackers have hundreds of gigs of actual username/password combinations that have been exposed from all the breaches over the past few years. These are often a first step when attempting to compromise a system. It’s more often likely that they will figure out a valid email pattern for a company and then feed actual names into that pattern to go after the username. From there, brute force attacks with those usernames against libraries of passwords is a common approach. - A common approach is to go after an email login. While the email can be a treasure trove of information, it’s more about using those credentials in other places. It’s pretty common, for example, to use those credentials to get into a network with a VPN. - Captcha/reCaptcha is not very effective and preventing these brute force attacks. There are a large number of bypasses and even Mechanical Turk companies that are available to bypass these tools. What can be effective is Time Based Security because it slows the attackers down. If you can slow them down, you can make the attack say long to succeed that they’ll go somewhere else. - Once inside the network, most companies often have little security on internal systems. Multi-factor authentication, not just on the front door, but on internal systems is a huge step in the right direction. Monitoring not only for failed login attempts but, in some situations, valid login attempts (such as when a domain admin logs into a domain controller) should absolutely be used. - When it comes to application security between services within a network, the best advice is to make sure developers really understand what is trying to be accomplished by something like JWT (JSON Web Tokens). Often its the lack of understanding of what they’re actually doing that leads to system vulnerabilities. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2MSIAXG You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2MSIAXG
An interview with Freek Van der Herten, lead developer at Spatie. @freekmurze Spatie ColecoVision HyperCard BASIC Krautrock Antwerp Browsershot package Spatie Postcard Page Oh Dear! Transcription sponsored by Larajobs Editing sponsored by Tighten Matt Stauffer: Welcome back to the Laravel podcast, season three. Today we're going to be talking with Freek Van der Herten, (pronounced) something like that. He works with Spatie, and they make packages and do all sorts of great things. Stay tuned, you'll learn more. Matt Stauffer: All right, real quick note going into this episode. I just moved offices, and I only noticed after moving that the movers bumped the gain knob on my audio. So it's not going to sound great. I apologize ahead of time. But don't blame Michael, it's not his fault. It's my fault. Sort of the movers, but mainly just me. All right, let's get on with the episode. Matt Stauffer: All right, welcome back to the Laravel podcast, season three. This is a season where we learn about all sorts of amazing people. You may have heard of them before, you may not have heard of them before, but they're all absolutely incredible, and if their name is not English, then I also mangle it terribly and they fix it up for me. Matt Stauffer: Today we're talking to ... okay, Freek Van der Herten, (pronounced) something like that, who is one of the leads ... [crosstalk] Oh, no, you're going to do it for me in a second, and then you can grade me on how well I did. And you're also going to have to grade me on how well I do the name of your company, because I have been told that I say it wrong. So, Spatie, which apparently is close but not quite right. So that's a company. They make packages, they do open source Laravel stuff, all this kind of stuff. You've seen their open source packages, used those packages, you've seen his blog, you've seen him on Twitter, all that kind of stuff. Matt Stauffer: So the first thing that I'm going to ask him to do is first say his name and his company's name right. Second, grade my pronunciation and see if he can make me do it any better. And third, ask the first question we always ask, which is, when you meet people in the grocery store, how do you tell people what it is that you do? Freek Van der Herten: Okay. Let me pronounce it just right. My name is Freek Van der Herten. I work for a company called Spatie. And I would rate your pronunciation an 8 out of 10 or a 9 out of 10, so it's pretty good. You did it pretty well. Matt Stauffer: All right, for an American, that's a pretty good number, so I'll take it. Freek Van der Herten: So at the grocery store, if somebody asks what I do, I simply say that I make websites, I'm a programmer. So I try to make it really easy, because I am mostly on the back end stuff, and for people that are not into back end, that's all a little bit fuzzy. And with websites, they immediately know, oh yeah, he creates those. Yeah. Freek Van der Herten: And I always say, I'm not going to install printers. That's not my job. I program stuff. Matt Stauffer: That's perfect, because if you say I work with computers, that leaves that open. You might be a networking person or something like that. So I can hear in your pronunciation a little bit of the ways that I'm off. So I'll go back, listen to this 10,000 times, and see if I can get it right. But an 8 out of 10 or a 9 out of 10 for a Southern American, I'm going to take that as a win. Freek Van der Herten: It's pretty good, man. Matt Stauffer: Right. So I mentioned this real quick, but Spatie, Spatie, whatever it is, they have 10,000 packages. Some of our questions are going to be about all of the Laravel packages you have, a little bit about your tweeting and your sharing of content. But of course, if anybody doesn't know who he is, just check him out. So I also don't know ... I know that I asked you personally, and I know where your Twitter handle comes from, but not everybody else does, and I don't actually know how you pronounce it. So tell us your Twitter handle, where it comes from, and how you actually say it in your mind. Freek Van der Herten: Well, my Twitter handle is @freekmurze, and it's actually a very good question, where it comes from. Freek is just my first name, but I have actually three names, and that's not that uncommon in Belgium. Most people have multiple first names, and mine are Frederick, because Freek is just a nickname, actually. My second name is [inaudible 00:03:59]. And the third name, which is a very special name, I don't think anybody has it now, it's Murzephelus. And Murzephelus is a name given by my parents, and it's an emperor, it's a Byzantium emperor, because both my parents are lawyers, and when they had me, there was this law in Belgium that you had to pick the name of your child from this big list of names that were approved, and they wanted to see what the city clerk would do if they just picked a name out of history that is not on that list. So they picked Murzephelus- Matt Stauffer: Rebels. I love it. Freek Van der Herten: And the clerk didn't say anything, they just wrote it down. Matt Stauffer: Nice. Very cool. It's funny, because- Freek Van der Herten: And I've also passed it down to my kids. So they also have Byzantium emperor names. Matt Stauffer: I love it, that's awesome. It's funny, 'cause when I first looked it up, I was like, oh, Mur-zeph-el-us. But it sounds a lot more regal when you say Murz-e-phlus. Matt Stauffer: All right, so that's your Twitter handle. So go follow him on Twitter if you don't know, he's got a newsletter and a blog. And one of the things that Freek does a lot is collect together the best stuff from other people, and so Spatie creates an incredible number of packages. Quite a few of them are original content, but one of the things they also do is they take stuff that other people are doing and they package it up together in a normalized way. So if somebody says, here's a thing on Laracasts or here's an idea or something like that, they will often make a package around it. And Freek both writes his own articles, and the people at Spatie write their own articles, and then they also collect together links to articles from other people around the community. So they're both creators and curators, and that's something kind of they're known for. So if you haven't seen them, go check out that stuff that they're doing. Matt Stauffer: Okay, that's fun. Moving on, when did you first get access to a computer? In what context, and what was your interaction with that computer like? Freek Van der Herten: I started using computers at a very early age. It was actually, also, my dad had bought a ColecoVision. I don't know if you know that console. Matt Stauffer: I've never heard of it. Freek Van der Herten: It was very big in the '80s, I think around '82 or '83. So I must have been three or four when my dad had a console and he let me play on it, and that was the first time I interacted with this on a screen. Matt Stauffer: What kind of operating system was it on? Freek Van der Herten: I don't know, it's a game console, so it's only- Matt Stauffer: Oh, a gaming console. Freek Van der Herten: Yeah, yeah, it only had games on it, and that was the first time I interacted with something and saw something moving on a screen. Matt Stauffer: Got it. Freek Van der Herten: Now shortly after that, I think two years after, we got our first computer in the house, which was, I think ... It was definitely a Macintosh, and I think it was an SE model. It's one of the first models. So my dad was a little bit of a computer freak, and he wanted, he had to buy this new stuff. So I started out with a System 6, I think it was, on Mac OS. And, yeah, I started ... yeah, there was a program on there called, maybe some people know it, called HyperCard, which was- Matt Stauffer: I've heard of it. Freek Van der Herten: It's a very simple application, which makes it very great. It's just a stack of cards which you can programmatically do stuff with. You can say, if somebody clicks here, go to card number three. If somebody clicks here, go to card number five. So I started to ... And if you click here, play a sound or display this image. So I made my first ... I don't know if I can call it computer programs, but I made my first projects with that little ... little games like that. So that was- Matt Stauffer: That's funny how different Mac and PC are, because I know about HyperCard, I saw it in school, but I never worked with it. But my first one was BASIC, and it's probably around the same time period. I was six or something, so it was around late '80s, early '90s. Freek Van der Herten: Yeah. Matt Stauffer: And it was such a different experience. I was learning syntax and code and able to do almost nothing, whereas with the Mac, it's giving you this visual, interactive system, and it's such a difference even back then of what you're getting from each of them. Freek Van der Herten: Yeah, 'cause at the school, we had a Windows computer. Yeah, a Windows 3.1 computer. But the Windows subsystem, that was just a shell. You had also MS-DOS behind it, and when I saw that, I thought, what is this? I'm going back in time, we have something way better at home. We have this thing like a mouse on there. Matt Stauffer: Yeah. Yeah, that's interesting. Freek Van der Herten: So that was fun. So I've always been busy with computers and creating my own little things on it. Matt Stauffer: Did your interests keep up through school? Did you always think of yourself as a computer person? Freek Van der Herten: Yeah, I always knew I wanted to do something with computers. I studied IT as well, so I'm one of the lucky ones. At a very age, I knew I wanted to do this. But IT is very big, so I did a lot of things on my computer as well. At one point, I also did some sound technology, some songs, because that's another passion of mine. I'm also busy with music, I have my own band, and- Matt Stauffer: Okay, you're going to tell us more about that in a second. Freek Van der Herten: Yeah. So way before Laravel was there, when I still had time to do other stuff, I created music as well. But that helps a little bit with all the background, right, the background right now. Matt Stauffer: Okay. You know what, I actually am going to pause there. What musical instruments do you play, and it sounds like you were also recording. Were you doing mixing and mastering and production and everything? Freek Van der Herten: Just recording stuff, and a little bit of mastering, but then I'm not really good at it. Matt Stauffer: Yeah, yeah. Freek Van der Herten: My musical taste is a little bit lo-fi, so what I recorded was lo-fi as well. Matt Stauffer: Yeah, yeah. Freek Van der Herten: So I started ... My first instrument was, I think, the saxophone, when I was 10 years old. I had to do that for my parents. Yeah, you have to do musical school. Matt Stauffer: Yeah, yeah. Freek Van der Herten: But I didn't like it that much. I think the first two years were great but then I wasn't interested in the saxophone anymore. I tried to pick up the piano, and did a year of piano. And then I learned guitar myself, and that's an instrument where ... I stick a little bit by. So in all the bands that I- Matt Stauffer: Do you play acoustic or electric more? Sorry. Freek Van der Herten: It's more electric these days, 'cause, yeah, I play in a band and I have my electric guitar installed there. So I do that more. I do a little finger picking at home. I have the acoustic guitar here. But it's not as much as I used to. Matt Stauffer: What style of music do you play? Freek Van der Herten: It's a style called krautrock. I don't know if you know that. Matt Stauffer: I don't. You're going to have to send me the link later so I can put it in the show notes. Freek Van der Herten: Well, it's like this ... It's my favorite kind of music. It's like ... house music, like dance music. Very repetitive. But with guitars instead of electronic instruments. Matt Stauffer: Okay, all right. Freek Van der Herten: So there's some good bands that you should check out from the territory. It's very big in the '90s, there are bands like Can and Neu! And the ideas behind those bands revolve around ... with how, how do you say it in English, how can we keep things interesting with the least amount of notes? With three notes, what can we do. Just by repeating them, we'll make it interesting again. Matt Stauffer: Very interesting, yeah. Freek Van der Herten: And that's an aesthetic that I really like, just the simple things. The fertile things. Not too many whistles and bells with it, but just fertile, pure, straight to the point. Matt Stauffer: It's funny, 'cause when you said repetitive, the first thing I thought of was jam bands. And a lot of jam bands are a lot of noise. You've got 20 people on stage, but they're very repetitive and they're not interesting to me, because everybody's playing the same noisy notes over and over and over again, so it seems almost the opposite, at least in my very judgmental perspective, where you're trying to have very little noise, but actually keep it interesting. Freek Van der Herten: Yeah. I'll send you some interesting pieces to you. I have- Matt Stauffer: Yeah, I'll put it on the show notes, everybody. Freek Van der Herten: I've recently listened again to a few versions of a piece called In C. I don't know if you know it. It's a musical piece, I can't remember the author right now. It's probably going to go in my mind in a few seconds. And it's like 18 melodies of music, and it's 20 people playing them, and there are a few rules around it. When somebody plays the fourth tune, everybody still on the first tune should skip to the second. There can only be a gap of two. And then you go slowly to the end, and it lasts about an hour. And it's very simple melodies, but they interlock very, very well together. And it's not written on paper, how much times you have to repeat each melodic phrase. So every version is a little bit different. Matt Stauffer: Interesting, yeah. Freek Van der Herten: And that's interesting music to me. Matt Stauffer: So you could theoretically have one musician who's just really antsy to move on, and the whole thing would be done in 20 minutes? Freek Van der Herten: Yeah, yeah. Matt Stauffer: Oh, very interesting. Freek Van der Herten: That could be the case, yeah. Matt Stauffer: Everyone's glaring at that one guy. Freek Van der Herten: There are hundreds of versions of that, but they're all amazing. Matt Stauffer: Very interesting, okay. Like I said, I'm going to get him to write all this down for us. Links in the show notes later. Freek Van der Herten: Yeah, sure. Matt Stauffer: I'm super interested to learn about that. So you said you don't do as much music now, is that true? Freek Van der Herten: Yeah, that's true. Matt Stauffer: I hear you right? Freek Van der Herten: Yeah. So when I was a little bit younger, I think when I was around 20s, then I had a little studio in my own apartment, and I recorded lots of songs. That was my main hobby then. Nowadays, it's programming, but then it was every moment of free time that I had, I have to record stuff, I have to experiment with stuff, which is ... Yeah, sometimes I listen back to those recordings, like every five years or something, and I am still a little bit proud that there's something that I accomplished. Matt Stauffer: Yeah, yeah, definitely. Yeah, I spent that much time, I got that good, even if I couldn't do that right now, that's still something I did. Freek Van der Herten: Yeah, yeah. Absolutely. Matt Stauffer: All right, well, I want to ask you more questions about that, but I also want to get to the end as well. All right, so when you first got into that, you said you had access to those Windows computers in school. So what did your school education look like? At what point did you start getting more than just typing lessons? Freek Van der Herten: I think when I was 14 or 15, we had lessons in a thing called Isolab. I don't know if that is a well-known program or not, but it's something we teach at school, and it's basically this grid, and there's a car in it and there are certain obstacles, and you have to write an algorithm to let the car reach a special end spot. Matt Stauffer: I want to do that now. Freek Van der Herten: And it's something to exercise things like loops, like memory, like and or not kind of stuff. And that are the first things that I learned to do. We also had a little bit of Visual Basic if you were ... I went into higher education, so we programmed things in Access. Access is this Microsoft database, where we had to program the streams and special reports and stuff like that, and I only got into programming, into real programming with computer languages, in higher education, where I got to learn C++ and COBOL. Things like that. Yeah, I learned COBOL. Matt Stauffer: Now, were you doing IT? Was it IT then, or were you specializing more in computer science? Freek Van der Herten: It was ... I don't know how you say it, how you translate that thing that I said it in English, but it's focused on practical IT. But it was in 1989 that I studied higher education, and yeah, internet wasn't as big like it is now. And we didn't have any lessons on HTML or the web. It was all on this enterprisey kind of stuff that we had to learn, like Java, like C++. Things like that. Matt Stauffer: Yeah. Huh. So when you say secondary education, do you mean when you were 18 years old, or when you were 14 years old? Freek Van der Herten: Secondary education, that's from 12 years old to 18 years old. Matt Stauffer: Oh, got it. Okay. Freek Van der Herten: And when you're 18 years old, you go to higher education. Some people go to ... Most people. Matt Stauffer: So even in 12-18 years old, you were able to specialize, 'cause in the US, in 12-18, you just do whatever they tell you to do. There's no specialization like that. Freek Van der Herten: Yeah, there are. Matt Stauffer: So you were able to focus on a certain track. Freek Van der Herten: Yeah, yeah. From 12 years old, or I think from 13, you can really pick your direction if you want to ... a language kind of education, a mathematical based education, an IT kind of education. So you can make a choice there a little bit. Matt Stauffer: Okay. And also did you ... Oh, go ahead. Freek Van der Herten: And of course, when you're 18, then you have much more choices, so they get you basically anything that you want. Matt Stauffer: Okay. So where did you go after secondary education, then? Freek Van der Herten: So, I did my secondary education in my hometown, which is a small town in the northern part of Belgium. But I always knew that when I'm going to higher education, I don't want to live at home anymore. I want to live by myself. All my friends were in that mindset. We're 18, we're going to move, we're going to get away from our parents, even though we all love our parents, it's not [crosstalk]- Matt Stauffer: Yeah, yeah. Freek Van der Herten: We're now grownups. Matt Stauffer: Yeah, yeah. Exactly. Freek Van der Herten: So I moved to the biggest city in the vicinity of my hometown, which is a city called Antwerp. Matt Stauffer: Okay, yeah. Freek Van der Herten: Where I've lived for a long time, and Spatie is still based here. And I went to school there, and I left home. My student life in the city of Antwerp. Matt Stauffer: Okay. That's actually one of the only cities I know there, so that's a good win for me. I'm nodding, I actually heard of that before, that's good. Go me. Freek Van der Herten: You should come to Antwerp, it's a beautiful city. You would enjoy it. Matt Stauffer: Oh, I would love to. Yeah. Freek Van der Herten: It's not that far from Amsterdam. Matt Stauffer: I said in the last podcast, once you get Americans over to Europe, we don't want to leave, because it's so expensive to get over there, which is why it was so crazy. I was there for Laravel Live UK for five days and then came home. But the next ... I'm trying to get my kids to the age where I can take them over, because once I have the whole family over there, I'll just work from there. It doesn't matter. So I'm hoping someday in the next couple years, we'll get a whole month and just go see everybody in the whole Laravel world, and just stay in everybody's town for a couple days. So Antwerp's on the list. Freek Van der Herten: Well, you're certainly welcome here. So do that. Matt Stauffer: All right. I won't get booted out of town, that's good. Matt Stauffer: Okay, so you went out ... So what did you study? Was it continued practical IT, or was it something different when you went into higher education? Freek Van der Herten: Yeah, that was practical IT that I studied. So that was more enterprise stuff, things that I learned there. Things like C++, like some math was still there. Things like analysis, how do you cope with a big, big project. And looking back at it, I really like what I was taught there, but a lot of the things that I learned there, after the years, I thought, yeah, what they taught me was a little bit wrong. Matt Stauffer: I was going to ask how you reflected on your education. Is there more you can say about that? Is there broad strokes you can make about what was good and what was bad? Freek Van der Herten: Yeah, so something that has really stuck with me is in one of the first lessons, I was taught, and I did it for years ... It's a very practical thing. A function can only have one return statement. And that fucked my career up so bad. Matt Stauffer: Yeah, I believe it. Freek Van der Herten: Enlightenment came only 10 years after. Hey, it's actually better to have early returns. But things like object calisthenics, I don't know when those ideas came, but they certainly weren't taught in school. So I'm skipping ahead 10 years now, but there was a time that I thought, man, I really wish that there were a few teachers back then that knew about the stuff that I'm learning now, because there is much more than the stuff that they taught me. Freek Van der Herten: It's not all bad. It's not all bad. They taught some good stuff as well. With the things I learned there, I landed my first job, which was something I didn't expect. I was a COBOL programmer for seven years or something like that, and I still remember when I was at the job interview, and they asked me, "So, what do you want to do?" And I said, "Anything except COBOL." And they gave me COBOL, and I did it for seven years. Freek Van der Herten: But it was kind of fun to do it. It was ... I worked for a major bank, maybe you know it. It's called ING. I think you have- Matt Stauffer: Yeah, yeah. I have, I used to have, or maybe still do. I don't know. For sure. Freek Van der Herten: I think they're operating in America as well, and yeah, I programmed COBOL there for the mainframe. Matt Stauffer: Okay, wow. Freek Van der Herten: So we did the financial stuff. So it was kind of important, what we did there. And I still look back very fondly to that period, because I had very good colleagues there, and we could do amazing stuff. Even with an old language like COBOL, we could really do some ... We really could program some nice solutions. And sometimes I miss the scale a little bit of programming in that way, because it's like, one-fifth of the country has an account on ING. Matt Stauffer: Yeah. Freek Van der Herten: And that's kind of fun to work on. Matt Stauffer: I know we're getting ahead of ourselves just a bit, but I asked this of J.T. as well. Programming in COBOL, and the programmers who have been in COBOL for years, and the patterns and practices you have are a little different, I imagine, than working with Laravel. Freek Van der Herten: Yeah. Matt Stauffer: Is there something, one or two things, that you experienced or learned during your time there that you think a lot of us that haven't had that sort of experience could benefit from hearing about? Any practices or any maxims or any sayings, or testing patterns or anything that you experienced there that you wish more people knew about? Freek Van der Herten: Let me think. One of the things that I already did at the time is testing a lot, but it was in an old way, so I can't recommend that. I think what sticks with me most from the time is not a technical programming thing that we did, but the team we did it with. The client communication between the team, and we were ... within the firm, we were one of the first groups that wrote standards for ourselves. We were going to name variables like this, we are indenting our code a little bit like that. We're going to use prefixes for that. We're going to use suffixes for that, which was really beneficial. And that's something we do at our company, at Spatie now as well. And that's something I think a lot of people could learn a little bit from, just some guidelines and be very, how do you say that in English, I can't remember, just where everything is always the same- Matt Stauffer: Consistent. Freek Van der Herten: Consistence. Keep consistence. Things like a dash or an underscore or when you case things. They seem like, hey, it's not important, but it's actually very important when you work in a team. Matt Stauffer: Yeah, I totally agree. Freek Van der Herten: Yeah, and that's something I picked up with working in a good team at ING. Matt Stauffer: Very cool. All right, so you got a job at ING right out of higher education, right? Freek Van der Herten: Yeah, yeah. Matt Stauffer: Okay. So what made you move, and where'd you move to? Freek Van der Herten: Well, that's a good question. So when I was working at ING for a couple of years, there were plans to split up the branch I was working in. So I worked in the insurance branch, and ING sold it off to another company. So it became apparent that our team had to split and had to move to different cities, and at the time, I didn't want to move cities. So I went for another job in Antwerp, another company that also does COBOL. But I was a little bit shellshocked there, at ING, because I had worked there for so long. I had this network of people, and I could get things done. I didn't have to follow the rules. I could cut some red tape. But at the new company, I didn't have a network, and it was so, so very frustrating for me that I couldn't get any things done. Freek Van der Herten: Now, at the time, I also had a friend of mine called Willem, and Willem, he just started this little company called Spatie- Matt Stauffer: I was going to say, I've heard that name before. Freek Van der Herten: Yeah, and he was doing everything by himself, and everything by himself. He programmed a little, he designed a little, he did all the client work by himself. And I'm sure it came up at a band rehearsal that we have, I really hate my job now. And then he said, "Yeah, would you want to program for the web?" Because I felt that he couldn't do everything by his own anymore. He was good in design but he didn't like programming as much, so he looked for somebody that wanted to program a little bit. Freek Van der Herten: But I wasn't certain at the time. So I did a couple of stuff for Willem first. But there's no way to sugarcoat this, because I was so bored at my job, I started just creating websites at my job itself, because I had basically ... This is the honest truth. They didn't give me enough work. So they gave me an assignment. Yeah, this is your assignment for a week, and after two hours it was done. So I reported to management, give me more work. And they didn't give me more work. So I started programming for the web and learning stuff for the web. Freek Van der Herten: And after half a year or something, I said, yeah, this is silly. I'm just working for myself at this job, so I just quit. And then I started working for Spatie. Matt Stauffer: What's your official role there right now? Freek Van der Herten: I'm, I guess, the lead developer there, although I don't like the term a little bit. That's what we tell people that we meet. Freek is our lead developer. So I still do a lot of programming day to day myself, but I also help my colleagues getting things done. I don't like thinking about the lead, with the term lead programmer. The thing that I don't like is this is the one that makes all the decisions and does all the code stuff, but I don't see that as my role. I have to help the other people getting their job done, so that's an important factor of the things I do day to day. Freek Van der Herten: And there's also a little bit leading the company a little bit, because I'm a partner there, so there's a lot of corporate stuff I need to do there as well. But the best thing is- Matt Stauffer: How many people are- Freek Van der Herten: The best days are the days that I can program myself. Matt Stauffer: Yeah. I totally feel you. How many people are on your team? Freek Van der Herten: Right now, it's seven people. Matt Stauffer: Okay. So the two of you. Is that five programmers, or are there any non-programmers on the team? Freek Van der Herten: There are now two non-programmers. Actually, we're at eight. We had a new hire two weeks ago. We're at eight now. Matt Stauffer: Congrats. Freek Van der Herten: We're with five programmers, one designer, and there is a project manager. So they handle client stuff. Matt Stauffer: Right, right. Freek Van der Herten: But our focus is in programming bigger Laravel applications now. So we started with smaller CMS kind of sites. But we moved on a little bit to the bigger things. That's also a story in itself, really. Matt Stauffer: Cool, yeah. Yeah, I don't know if we're going to have time for it, but I'm actually very curious about that story. But I have to pause this one time. Is there a sound at the end of the name of your company or not? Is it purely just Spatie? Freek Van der Herten: Yeah. Matt Stauffer: Cause sometimes I hear a little T, and sometimes I don't. Freek Van der Herten: No, it's Spatie. It's like, your pronunciation for Spatie is 10 out of 10. It's perfect, it's good. Yeah. Just Spatie. Matt Stauffer: Okay. Yeah. Spatie, okay. See, I was saying Spat-zie for a while, with a T. So Spatie (Spa sea). Freek Van der Herten: Spatie. Matt Stauffer: That's it. Freek Van der Herten: Yeah, yeah. That's perfect. Matt Stauffer: Okay. Now it's 10 out of 10. I got an 8 out of 10 the first time, you didn't even notice. Okay. All right, so I do want to talk about your relationship with the company, what kind of stuff you're all doing, 'cause I think that there's a lot of companies that do Laravel, and there's not a lot of companies that have public presence that are creating a lot of content and stuff like that. Matt Stauffer: And so I think what I want to know is, let's not even talk about the company yet. Let's talk about you. When did you go from being a programmer to a programmer who had garnered a reputation as someone who created packages and taught stuff? How intentional was it, what did that transition look like? What was Freek being a programmer who did web stuff to being Freek being a well-known teacher? What'd the shift between those look like? Freek Van der Herten: Well, it certainly wasn't intentional. I think now, six or seven years ago, we were still ... This was the time before we did Laravel. We were creating sites with Zend Framework 1. CMS kind of sites. And I remember getting a little bit bored with it, because at the time, the B2B world was becoming a little bit stale, I thought. This was also free composer. There was another ecosystem that attracted my attention, and it's really no surprise. That's Ruby, Ruby on Rails. Matt Stauffer: Rails, yeah. Yeah. Freek Van der Herten: That's a story I share with a lot of people in our community, I think. So I created a few Rails sites, and I thought, yeah, we're ready to jump ship off PHP. PHP is done. But then Composer happened and Laravel happened. So we started doing Laravel sites, and in Zend Framework, we had this whole CMS, a homegrown CMS build up, and I wanted to have that in Laravel. Freek Van der Herten: Now, I wanted to do it a piece at a time, and at the time, there was this guy called Jeffrey Way. He started Laracasts. Matt Stauffer: This little site. Freek Van der Herten: Yeah, this little site. Very small. And he put out a video of how to use Travis and GitHub together. And my mind was a little bit blown that you could just run your tests and see in the interface of GitHub if your tests were passing or not. And the lesson of Jeffrey was also around package development, and I thought, yeah, I want to do that as well. So I'm going to try to write a package. Freek Van der Herten: And I think one of the first ones was ... I think the Geocoder one, which was a wrap around the Geocoder service of Google. Or it was a Browsershot, maybe, which was a package that used PhantomJS to create screenshots of a web page. And I put that out, and some people liked it, which was mind-blowing to me. There's somebody here that did a pull request to fix a typo? Wow. This is really awesome. Freek Van der Herten: So I thought, yeah. I have to write another package. And when I took a look again at the Zend Framework 1 CMS, I saw, yeah, there's MailChimp in here. There's Google Analytics. There's something called the media library to handle assets. And I thought, yeah, these are all packages. Maybe I should package them all up for Laravel, so it wasn't planned, but I spent the next two or three years just doing that, putting that out. Matt Stauffer: Just repackaging, yeah, yeah. Freek Van der Herten: Just repackaging the old Zend Framework in code, Zend Framework 1 code, to modern packages with all the stuff I learned on Laracast. Freek Van der Herten: Now, at the same time, I was still the only programmer at Spatie, so we were only a three-man company. And we had an internal platform, something Microsofty, I can't remember the name, where we put interesting links on. And I was discovering so much interesting good content on the internet, and I'd post it there. But my two colleagues, the project manager and the designer, would say, "We're not interested in the deep programming stuff that you're putting there. We're interested in the ideas, but not in the nitty gritty details." Freek Van der Herten: So then I thought, hey, I'll just start a blog and I'll just put those things publicly on there. This is the stuff that interests me, maybe other programmers are interested as well. And with that combination, with starting a blog and writing about those packages, I guess, yeah. It picked up a little bit from there. People just liked the contents that was there, both my own stuff as the links that I shared. And yeah, it totally grew from there. Freek Van der Herten: But it certainly wasn't planned, like we were going to be well-known with this, that was the plan from the get-go. Matt Stauffer: Yeah. I noticed this initial commit on Browsershot is May 2, 2014. Freek Van der Herten: Yeah. Matt Stauffer: So four short years ago. Freek Van der Herten: Yeah, yeah. So yeah, I did a lot in the past few years. Matt Stauffer: Yeah. I think that it really helps to have some kind of structure to work along. The structure you're saying is, hey, you know what, I'm going to take this list of packages and I'm just going to work through them. And those sorts of structures that just give you something to work on next means you're never stuck asking the question, "Oh no, what do I do next?" You've always got something, you've just gotta make the time and put the effort in. Freek Van der Herten: Yeah, sure. And nowadays, actually the couple of past years, the most packages get born in client projects. So if there's a client project that's API-heavy, that we create some packages to make API development a little bit more easy in Laravel. And I also want to mention, because I'm talking about me here a lot, but now it sounds like that I'm the only one creating packages, but my colleagues do a tremendous amount of work on that as well. I want to emphasize that the open source efforts are a team effort, so it's not me alone. Although I'm the most known one, my colleagues, Brent, Alex, Seb, and Willem, do also incredible stuff out there. Matt Stauffer: Yeah. And actually, that's one of the things I was going to ask, because we're always figuring things out at Tighten ... We give everybody 20% time, so quite a bit of the work that's done at Tighten is done on those Fridays, but not all of it. Sometimes people are doing stuff on their own personal time. And you and I have talked a little bit in the past about what that looks like for you all, especially because you put out just such a prolific number of packages as a company. Are you able to make that much time available, or are people doing work at night? Matt Stauffer: So you and I have talked about it, but again, let's imagine that we have not. What does it look like for you, and what does it look like for the other people on the team, and how much of this stuff are you doing during the day job, and how many hours are you and the other folks working in the evenings, or nights and weekends, I guess? Freek Van der Herten: Well, for the company, we always plan the stuff that we need to do on Monday. We sit together and we say, "Hey, you're doing this this week. You're doing that this week." And we only plan four days. So for the fifth day, you can do whatever you want, but that fifth day, that isn't a separate day. It's like, the time in between. It's when you're bored with this project, yeah, go do something open source, write a blog post or write a package or whatever. Freek Van der Herten: So we have one day a week for everybody that can work on this open source stuff. Now, that's the theory, but yeah, in practice, packages get made in project time a little as well, because they're made for the project. Matt Stauffer: Right. Freek Van der Herten: So it's a little bit hazy, where to draw the line, a little bit. Matt Stauffer: Sure, sure. Freek Van der Herten: And I know that I spend a lot of time also open sourcing a little bit after the hours, because I like it. And sometimes, colleagues, when they have this good idea or a good vibe, I notice that they too do stuff in the evening, even though that's really not required to do so, it's really because they personally like-- Matt Stauffer: Yeah, just kind of excited about it, yeah. Freek Van der Herten: --just like doing this. And I think we've made so many packages now, it's really not such a big effort for us now to work on a package, because we know what the good things, the basic guidelines are for a good package. We know that have to have tests, we know that we need to have good documentation, we know how things like a service provider works. We have empathy enough now to imagine how people are going to use our stuff. So because we've done it a lot, it gets a little bit easier for us as well to do too. So people sometimes ask, isn't that difficult to invest so much knowledge and time in that? But I think for a company, it's kind of easy, because it has grown a little bit in our DNA. Matt Stauffer: Yeah, yeah. Freek Van der Herten: And if in a project, a colleague of mine says, "Hey Freek, should I package this up?" My default answer is, yeah, if you can do it, just do it. Take a couple of hours. Or if it's a bigger package, a couple of days extra, and just do it, 'cause we will benefit from it anyways. Maybe not because we are going to attract clients with it, but the programmer who made the package will become a better programmer. For Spatie it's good, because we have something in our package tool developed a little bit more. I always, when somebody takes an effort of making the package, I make sure that I mention the principal author of that package, which is not always me, also, on things. So everybody benefits with this. Freek Van der Herten: And I wish more companies would do this, 'cause if you take some time to do this, it isn't hard anymore. It just becomes part of your workflow to do this. Matt Stauffer: It's interesting, because at Tighten, we have a little bit of an inverse culture. People say, "Oh, we should make a package out of that." I'm like, "Are you sure that you want to maintain that for the next four years, 'cause if you don't, then don't make a package out of it." And I've actually talked people out of making packages, because I know that they don't yet understand what the cost of being an open source author looks like. Matt Stauffer: And it's not that I'm ever going to tell anybody no, but I am going to tell them, make sure that you know the burden that comes on. The moment people have this package in there, in their three years out of date app, what kind of customer support you're asking. And so I'm actually talking people out of it frequently, and what I'm more likely doing is when somebody says something interesting, I'm like, "Have you written a blog post about it? Have you written a blog post about it?" And quite a few people are like, "Yeah, Matt, I just put it on the list of 40 blog posts you're telling me I'm supposed to write. You have to start giving me more than one day a week to do these things." Matt Stauffer: But, no, I love your attitude towards packages. And one of the things that we've talked about in the past is we need all kinds of types. And for example, the packages we have at Tighten, there's only a few of them, and we maintain them back to Laravel 5.1. And one of the things you mentioned, is you say, look, we keep up to the most modern versions. And if somebody else wants to fork it and make an older version, then they're welcome to do so. Matt Stauffer: And so each group, each company, each author, has different things to contribute and to offer. And so I love the more people that are willing to make those packages, the more of a broad spectrum we have of people who are willing to participate in some way, shape, or form. There might be some company or some person who comes along, and their goal in life is to maintain all of Spatie's packages back to Laravel 5.1 or something like that, who knows. So each person is contributing a different thing to the community. Freek Van der Herten: Yeah, sure. Yeah, the cost of being a maintainer, it's a high cost sometimes. Matt Stauffer: Yeah, yeah. Freek Van der Herten: It's good that you make people aware of that. For us, we carry the load as a team, so everybody does a little bit of maintenance, and we have the pleasure of having a lot of people in the community helping us out as well. For every package there are a lot of contributors there, so, yah, I'm pretty happy where we stand right now. And I've also learned to sometimes just let it go, you know? Two or three or years ago I wanted to have the issue count as low as possible, and now I've learned that that really isn't important, if there's some more stuff to do, just leave it open. I'm not obliged at all to do this kind of work unless I'm very happy to do it myself, you know? Matt Stauffer: Yeah, for sure. Freek Van der Herten: And this idea that you should be happy with this kind of work—that's also where that idea comes from, that we only do the latest Laravel version, that we do the latest PHP version. Because this is what we use on our own project, and these are the versions we like working with. Nobody on our team liked working with the older Laravel versions. I'm not saying the older Laravel versions are bad or something, but we take the most joy from working with the latest stuff. So it makes sense for us only to do support for the later stuff in our packages as well. Unless it's very easy to support older things, then we do that as well, but we're also not afraid to just abandon an old package if we just don't like it anymore. No? It's not like anyone is going to sue us. Matt Stauffer: Yeah it comes down to the question of what do you feel obligated to do? And I think there's often a perception, right or wrong, that once you put that code out there, you're obligated to maintain it. And interestingly I see both sides of the issue. On the one hand, I don't think that you could be forced to do anything. On the other hand, I could imagine somebody saying, "Well, I can't." Matt Stauffer: We have a lot of clients who can't upgrade to the latest Laravel or the latest PHP, because they're stuck on whatever Red Hat releases and they're several versions behind, and they're saying, "Man I'd really like to use that new Spatie package but I can't." But at the same time, what's the inverse? You have to do something? No, nobody can force you to do anything. I have bounced back and forth a lot of times. And I think where I've ended up is just saying, nobody can be forced to do anything. Matt Stauffer: Each person needs to be honest about what they're planning to do, and also the world needs to allow them to change what their plans are if they change what their plans are. And as long as your not manipulating or tricking people. Then you're an open source contributor, who's putting work out there in the world. People can consume it, and if they're not happy with it, they can take the responsibility to fix it up. If they're not willing to take that responsibility to fix it up then it's kind of like well, you're getting free stuff. Don't look a gift horse in the mouth, is an American saying. Matt Stauffer: So I'm very sad because I have to go home to take care of my kids, but I can't leave just on that note because as always I ask people in Tighten what questions they have for you. I can't ask all of them because of my timeline. But I am going to at least ask you a few of them. So especially the ones that are the most esoteric. Number one, how many post cards do you get per month? Freek Van der Herten: We should get more. It's about, between 15 or 35. Something like that. Matt Stauffer: Your packages are postcard-ware. Which means basically, what you ask people to do is, if they use the package, consider sending you a postcard from where ever they're from. Freek Van der Herten: Yeah. Matt Stauffer: I assume that most people don't feel the pressure to send you 5,000 postcards if they use your package, but you probably should at least get one postcard from each user. So listeners, if you've ever used a Spatie package somewhere, consider going and buying a postcard from your local and going sending it. They've got a thing on their website about it, I'll link it in the show notes. But it sounds like that number should be a little bit higher, so let's all go chip in there to thanks them. Freek Van der Herten: Thank, Matt. Matt Stauffer: The next random question, I don't even know how to pronounce this, so I'm just going to read the words in front of my face. Did Romelu Lukaku deserve the golden boot? Freek Van der Herten: Yeah. I think he does. Or even Hazard. Matt Stauffer: Okay. Freek Van der Herten: Those are two football players if you don't know. Matt Stauffer: I have no idea at all. There's a lot of people taking care about this but I don't, so. Freek Van der Herten: I'm not that big into football, but I did watch for the world cup. That's when I'm interested in the Belgium team. Looking at Belgium matches this time, was really amazed what our player Eden Hazard could do. Did some amazing stuff. So that's your answer. Matt Stauffer: Several people asked this, but I feel like you're not going to have this list ready. So if you don't have this list ready, just say, "I don't have this list ready." Some people asked, what packages have you made that have been adopted into the Laravel core. Freek Van der Herten: I think none. Matt Stauffer: Oh really. Okay well that's a no list. Freek Van der Herten: Wait, there are none in the dependencies but there are that few were totally- Matt Stauffer: Absorbed, yeah. Freek Van der Herten: Inter locked with I think migrate fresh is one of ours. That Dale picked up on because we made it. And I think there is another one, where if you, in Tinker, use a class name that it can fetch the fully qualified class name. We packaged that up. Matt Stauffer: Yeah that was Caleb right? Freek Van der Herten: That was from Caleb. Matt Stauffer: Very cool. Alright, I didn't realize that got pulled into the core. Freek Van der Herten: Yeah, and that's in the core now, if you open begin session, and do one of the classes there, then it will try to get the fully qualified class name. Matt Stauffer: I like that, it's a joint Tighten Spatie effort. Freek Van der Herten: Yeah, cool. Matt Stauffer: Jose asks, which Artisan commands do you use the most? Freek Van der Herten: I think Tinker all day. All day I use Tinker. Matt Stauffer: Interesting. Freek Van der Herten: I have this package called Laravel Tail which can tail a log file. Matt Stauffer: That's the one that was pulled out of the old from the old Laravel right? Freek Van der Herten: Yeah, it was pulled out of Laravel, I don't know why. Because it was such a help. And I used it all day long. Matt Stauffer: I love it. Freek Van der Herten: Tailing stuff. Various make commands as well. So nothing too special there. Matt Stauffer: Alright, one last one. Marje asks, what was your most interesting challenge as a new developer? Freek Van der Herten: I think, getting to know the best practices in communities. It's so easy to adjust, to program a little thing, like a little PHP script, but how to do it well and how to structure it really well, that was really hard as a newcomer. To find good sources of information. And for PHP I know my way around. I know where I can find good stuff. I know where the people are. But if I want to get the feeling again, I know I can try to do some Elixir stuff or maybe even some JavaScript stuff and it's like I'm a newcomer all over again. Matt Stauffer: It's the difference between knowing how to do the thing and the best way to do the thing, right? Freek Van der Herten: Yeah, exactly. And it's comforting that in PHP, I have the feeling that I can be happy with the stuff that I write. I'm always learning of course. But it's difficult to have to in another language, because you're so familiar and it feels so warm doing PHP. But I have to force myself to do some other stuff as well. Matt Stauffer: Yeah, I hear that. Well, as always, I can tell, I can talk for hours on several of our subjects, but is there anything you wanted to cover that we haven't gotten to today? Freek Van der Herten: If I can make a shameless plug? Matt Stauffer: Go ahead. Freek Van der Herten: I launched my first software service project, a half year ago. It's called Oh Dear. It's like the best uptime tool out there. It can also detect mixed content, when your certificates will expire. Things like broken things, you will get notifications from that. It's something, I'm really proud of and you should check it out. It's ohdear.app. Matt Stauffer: Yep. And we will link all this in the show notes. I will make sure that is all available there. The pricing of Oh Dear, it's based on the number or sites right? Freek Van der Herten: It's based on the number of sites and nothing else. Matt Stauffer: Yeah, so your site can be massive. It can have 10's of thousands of pages and you're not going to pay extra for it. So, definitely check it out. OhDear.app we'll put this on the show notes, we're always down for the shameless plugs. You took your time to talk to us so, we got to show you some love. Freek Van der Herten: Alright, thanks man. Matt Stauffer: Alright, so if someone wants to follow you, where's the best place for them to go to do that? Freek Van der Herten: I think it's twitter, is a good way. So by having this @freekmurze it will be in the show notes as well I presume. Matt Stauffer: Yep. Freek Van der Herten: Or by murze.be where I talk about the package developments that my team and I are doing. And where I link amazing articles of others as well. So my blog and my twitter account, that are the best ways. Matt Stauffer: Love it. Thank you so much for everything you do for our community. Thank you for your time, I'm sorry I'm cutting us short, we can keep going but, look forward to seeing you soon and thank you so much for joining us today. Freek Van der Herten: My pleasure Matt, thanks. Matt Stauffer: Thank you. Bye bye.
Виталий Слободин, CTO в компании Elonsoft, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Насколько доклад про Headless Browsers на РИТ++ будет отличаться от прошлогоднего? 00:29 - Как стал разработчиком и почему первым языком был выбран C#? 02:10 - В какой момент и почему стал касаться frontend-разработки? 04:12 - Как появилась и чем занимается компания Elonsoft? 06:31 - Комфортно ли было стать руководителем и хотелось ли обратно разрабатывать? 09:34 - В какой момент и почему влился в core-команду PhantomJS? 11:38 - Как происходило развитие внутри этой core-команды и почему всё развалилось? 14:27 - Что стало последней каплей и почему продолжает говорить об этой теме? 19:32 - Как было создано и что из себя представляет Ростовское IT-сообщество? 22:01 - Как решаются проблемы площадок и докладчиков в Ростове? (и про South DevFest) 25:32 - Почему до сих пор никуда не переехал из Ростова-на-Дону? 29:15 - Кем бы хотел быть, если бы не стал разработчиком? 30:02 - React, Angular, Vue или Ember? 30:27 - Какая справедливая зарплата для разработчика в Ростове-на-Дону? 31:46 - Готовим вместе с frontend-разработчиком 33:47 - Узнайте, как работает используемый вами инструмент! 36:56 Ссылки по теме: 1) Сайт того самого South DevFest’а – https://devfest.gdgrnd.ru 2) Ростовское IT-сообщество – https://it61.info 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend
Виталий Слободин, CTO в компании Elonsoft, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Насколько доклад про Headless Browsers на РИТ++ будет отличаться от прошлогоднего? 00:29 - Как стал разработчиком и почему первым языком был выбран C#? 02:10 - В какой момент и почему стал касаться frontend-разработки? 04:12 - Как появилась и чем занимается компания Elonsoft? 06:31 - Комфортно ли было стать руководителем и хотелось ли обратно разрабатывать? 09:34 - В какой момент и почему влился в core-команду PhantomJS? 11:38 - Как происходило развитие внутри этой core-команды и почему всё развалилось? 14:27 - Что стало последней каплей и почему продолжает говорить об этой теме? 19:32 - Как было создано и что из себя представляет Ростовское IT-сообщество? 22:01 - Как решаются проблемы площадок и докладчиков в Ростове? (и про South DevFest) 25:32 - Почему до сих пор никуда не переехал из Ростова-на-Дону? 29:15 - Кем бы хотел быть, если бы не стал разработчиком? 30:02 - React, Angular, Vue или Ember? 30:27 - Какая справедливая зарплата для разработчика в Ростове-на-Дону? 31:46 - Готовим вместе с frontend-разработчиком 33:47 - Узнайте, как работает используемый вами инструмент! 36:56 Ссылки по теме: 1) Сайт того самого South DevFest'а – https://devfest.gdgrnd.ru 2) Ростовское IT-сообщество – https://it61.info 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend
Stromnetz lässt Uhren falsch gehen; #amazingsecurity und T-Mobile AT; Absolute und relative Pfade im Web; IT-Keller ist auf YouTube; FFmpeg Filter; Piwik bzw. Matomo; Unkonkrete Aussagen zur DSGVO; ELGA; Flickr "geht" zu SmugMug; Neues Gmail-Design; PhantomJS; torify; Computerspiele; The Witcher; Gothic; Kingdom Come: Deliverance; Marble Machine; YouTube-Kanal Wintergatan; Strandbeest; Fairphone 2; Strange Parts (YouTube); Lustige E-Mails auf Gmail; Punkte spielen in Gmail-Adressen keine Rolle; Netflix; Cloudfront Gäste: Bernhard und Ulrich
Юбилейный 50й выпуск RadioJS! Как и обещали, выдерживаем наш график и выпускаем ежеквартальынй выпуск (ну +-, да да). Подводим итоги года, фронтенд в 2017 году и в 2018, безбашенные браузеры, вебассембли, битва фреймворков, опенсорс и много чего еще. В гостях - Виталий Слободин, который убил PhantomJS ради хедлес хрома. Передаем приветы всему сообществу и, в частности, Петру Мязину с его пятиминутками, Вебстандартам, Девшахте, Фронтенд Юности, Смирнову Андрею и Фронтенд Викенду, Роману Дворнову, Алексею Охрименко, Сергею Рубанову...
uriboとkazutanの2人で、ぞうさん通信、rmarkdownに対するこだわり、仕事の中でのRとの付き合いについて話しました。 関連リンク R 2.8.0 is released R Release History 1997-2013 ぞうさん通信 ぞうさん通信のような立派なキュレーションがないとすべての情報を補足できないもんでして。。。— 正しい習慣のNagi Teramo (@teramonagi) July 14, 2016 お、次はぞうさん。#犬4匹本 裏話とかあれば、聞けたら面白いかも僕はぞうさん通信をよく知らないんですよね、そういえば。— niszetr (@niszet0) October 30, 2017 RWeekly R勉強会@広島(#HijiyamaR) HiRoshima.R Bayesian Cognitive Modeling: A Practical Course(赤い本) 魁!!広島ベイズ塾 R勉強会@比治山大(広島) The Final #HijiyamaR メモ:Rのariパッケージ(Amazon Pollyを介して文字を読み上げ、Rmdから動画を作れる)にはPhantomJSffmpegが必要。前者はwebshot::install_phantomjsでインストール。後者はMacならhomebrewでインストールできる。— Yuya MATSUMURA (@y__mattu) October 30, 2017 #おしえてぞうさん #おねがいぞうさん ベイズ統計モデリング―R,JAGS,Stanによるチュートリアル ベイズ統計モデリング #犬4匹本 あ、そうでした、弊社ブースにて『ベイズ統計モデリング』https://t.co/Ndzk2HmixO をお買い求めいただきましたお客さまに、先着でオリジナル「マグカップ」をプレゼントしています。重ねましてよろしくお願いいたします！♪ (*'▽') pic.twitter.com/mYpapsU8NH— 共立出版アリがと蟻 (@1738310) September 5, 2017 本を買ってマグカップをもらおう!『ベイズ統計モデリング』8856円（共立出版）内でも盛んになってきているベイズアプローチを用いた分析の入門書。 『ベイズ統計モデリング』をお買い上げの方にオリジナルマグカップ差し上げています!https://t.co/4MrlN6hk8B pic.twitter.com/Gyxq6VGXaI— 書泉グランデMATH (@rikoushonotana) October 24, 2017 どちくしょおおおおお！ほんまに！ほんまに！これだけは言わせろ，「開いたかっこは閉じろ！！！！」— kosugitti (@kosugitti) August 26, 2016 jupyter Japan.R 2017 2017年度 データ解析環境Rの整備と利用 RStudio、最近使ったプロジェクトを10個表示してくれてクリック一つで開けるんだけど、プロジェクト作りまくってるので10個じゃ全然足りない・・— h(o x o_)m＜
Kaylie Kwon: kaylieEB | kayliekwon@gmail.com Show Notes: 02:14 - Kaylie's Journey Into Software Development 09:25 - Implementing a Design System and Attacking Higher-level Workflows 15:43 - EDS Collaboration and Public Availability 19:07 - Getting Involved with The Yarn Project 20:57 - Selective Resolution 23:37 - The Warmth of the Yarn Community 27:11 - Handling Issue Communication and Tracking Resources: Eventbrite britecharts Eventbrite Spectrum Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles Lowell, I'm a software developer here at the Frontside and your podcast host-in-training. With me today is Elrick Ryan. Hello Elrick. ELRICK: Hey, what's up Charles? CHARLES: Not much. Are you enjoying your morning so far? ELRICK: Yeah, my morning is going well. Everything is good. CHARLES: Lots of cups of coffee? ELRICK: No cups of coffee yet. I've been drinking a lot of green tea. CHARLES: I've actually heard that's really good for you. ELRICK: That's what I heard too. That's why I started drinking it. CHARLES: Did you continue because it tastes good or do you just live on the idea of how good it is for you? ELRICK: A little bit of both. It doesn't taste that great but it's not horrible. It's almost like an acquired taste and then when you add in, "This is good for me," then it tastes great. CHARLES: Okay. We got a nice [inaudible] there. ELRICK: Yes. CHARLES: Anyway, I guess we should, at some point get on to the main content of our podcast. We have a very interesting guest with us today who has her fingers in all kinds of pies that we were talking about just at the pre-show, just before we were recording so we're really, really happy to have Kaylie Kwon. Thank you for coming on the show and welcome. KAYLIE: Hi. Thank you for having me. CHARLES: It's going to be great. Now, you are a software engineer at Eventbrite, that's correct? KAYLIE: Yep. CHARLES: What kind of things do you do over there? KAYLIE: I used to work on part of the feature team that worked on their reserved seating product but not too long ago, I moved to our frontend platform team, which is a team that helps other frontend engineers move faster through things like working on infrastructure or Eventbrite design system and dev tools. CHARLES: So like getting into the tools that unlock the exponential productivity of the developer team? KAYLIE: Uhm-mm. CHARLES: We're going to dig into all of that because you just listed a bunch of really interesting stuff. I'm really excited to talk about the design systems, in particular but lots of different stuff. But before we do, I understand that you have a fairly unique way of entering in to the position that you're in now. Your journey didn't follow the traditional arc. Would you be willing to elaborate on that or tell us that story? KAYLIE: Yeah, totally. I graduated with a degree in art history, not related to computer science at all. Then right after, I moved to New York and worked for a small startup. It was marketing/business development role and I wasn't really happy with it. I was working on some design-y stuff on the side with HTML and CSS but I just felt like my brain just needed to be stimulated a little more. I applied to this all women's bootcamp program called Hackbright in San Francisco. It was a three-month intensive program and luckily coming out of that, I had at least some initial knowledge to get my foot in the door and Eventbrite was one of the hiring partners. They brought me in for interview. I actually had no idea that it was going to be a frontend engineering role because my bootcamp was totally in Python and it just had more with a backend focus. Ben, who spoke at React Boston Conference with me, was actually one of the interviewers and he gave me this Clojure problem and I solved it but in Python just using recursion. He was like, "You got it. Just convert it to JavaScript," and I was like, "No, it just can't be done. No JavaScript." But there's the reason he would chose to hire me and they onboarded me as an internal bootcamp within Eventbrite. The first three months I was there, I learned about React, Redux, JavaScript, ES6, all of that good stuff. Then they moved me to a feature team, where I continued, I guess working on the product and then I became involved more with open source projects. I really expressed interest in when you're a new engineer and coming onboard, there's all these assumed knowledge that isn't documented anywhere or something will be really obscure and hard to use but people will just assume that that's the status quo. This idea around developer experience and helping other developers move faster, it just kind of become a natural interest of mine. I was talking to the platform team, Ben in particular, expressed my interest in working in these areas. Just about like a month ago, we did a big re-org and I landed on the platform team. Currently, we have a lot of projects in flight. One of them being moving our dependency system from our old codebase, which first was written in RequireJS to webpack. We're building out our Eventbrite design system, which is basically a shared UI component library that other teams could leverage. Our platform team will just come in and make sure that the API is usable across different teams and maintain a consistent brand in terms of look and feel. We're also working on other tooling stuff like making sure we use Docker for our dev environment and making sure that the frontend containers don't break, making sure that everyone is on the same version of ESLint, Node and things like that. CHARLES: How do you make sure that the frontend containers don't break? KAYLIE: It's actually hard. I think one thing that we're trying to test right now is using Yarn Offline Mirror and having better caching. When you build a container, it'll look into the cache directory, which is just bunch of committed tarballs. That way, they don't have to fetch to the network each time because once the lockfile or package.JSON changes at our current state, it'll rebuild the entire container and it could take a very long time. We just have a lot of packages that we've added over time. Other things, we're experimenting along with our platform team on the backend side about having remote images. Instead of devs building their containers locally on their computer, having them remotely built by a CI system and then just pulling the container and the images down. CHARLES: Really, really you're like all over the place. That sounds so much fun. KAYLIE: Yeah, it's a lot of context switching. Sorry, if I was jumping too many topics at once. CHARLES: No, absolutely not. I think it's actually fascinating and it's actually capture the kind of scope because when you are doing development, if you yourself are not running up and down the stack, the tools that you use are. The better the tools, the better you're able to focus on the one little sliver of the stack that you're working on. If I don't have to worry about where are my Docker images are coming from or if there's a temporary network flip that I can't install my dependencies, if I don't have to worry about those things, then that makes me more effective so it's important to just kind of lay out all of the stuff that goes into making a quality developer experience. KAYLIE: Yeah, the dream is like frontend people wouldn't have to worry about any of the backend stuff and they just have this isolated environment, where they could just work on what they do best, which is JavaScript and writing features in React. Everything else just works and they could see that replicated through their dev environment as well as QA and Prod and hopefully, make every tooling that they use, like testing and linting all easily, intuitive and accessible. CHARLES: How is it that you're working up and down the stack, making sure that your CI systems, your Docker images but then also at the same time, working on a design system, which you've got collaboration, I assume with some pretty hard core devops teams but also then you're interfacing with designers. You kind of flesh out your design system. Are those the same people on the platform team? Or there are different groups within it? KAYLIE: We have designers and researchers actually, as part of our engineering unit. We work pretty closely with them to define guidelines on what the design system should look like because coming into making this designs system, one thing we really wanted to make sure that is that both sides of engineering and design have input, rather than the previous old version called Style Guide, which was more engineering-driven that not. One team would need a model so they would build a model and a different team would build a slightly different model and we would end up with five different models. They want to be maintained over time and there wasn't really a focus on accessibility or consistency of brand so the design system project was to eliminate all of those pain points. CHARLES: For people who may not be familiar with design system but it's something that certainly is cramping up more and more, what's the general strategy you take? Clearly, you talked about the kind of the pains that it solves, like I'm experiencing this pain where I've got five dialogues, I've got three ways of laying out forms, I've got these problems. What's the strategy that I go about as my organization for trying to implement this? Like now, I want to do a design system, where do I start? KAYLIE: One big thing, I think that helped us was developing Eventbrite design system as just the standalone product. You could run Eventbrite design system as a standalone with all of the documentation and components with each of their different props that could be configured and it has its own set of tests. All of the components are API-driven so there's nothing specific about business logic that it assumes. For example, our button component just assumes that I'll be receiving a type of submission and some [inaudible] body. It doesn't make any assumptions that it's going to be anything Eventbrite specific. It's high-level configurable that the end user wants it to be. Another thing that helped is we have a planned approach session right before we start working on a new component. A developer who would be building the component would meet with one of the frontend platform members and will be discussing the API of the component, the CSS that would go in it and the designer would do the final QA. The development takes longer than if you were to write just a component for your app but we're trying to build it out for a long term use. We have versioning for Eventbrite design system as a library so whenever you make updates, we added to the changelog and then it gets released and we bumped in Core, which is where all of our apps live and people have to get the new version. Basically, it's an orchestrated effort and we have a process built around scheduled releases and bumping it in Core. CHARLES: I get the wanting to have a uniform buttons, uniform labels, dialogs and things like that. How do you attack the problem of higher-level workflows like a form submission and validation process that might have a lot of different pathways? How do you guide that using a design system? KAYLIE: Those are actually really good questions because we went through issues like that. Validation form field or components that have logic around more complex inputs and validation is really hard because different teams use it in a slightly different way so we ended up having two versions of complex inputs. Now, we're in the process of deprecating the V1 and then having people move over to V2. We also use the Atomic Design Principles for Eventbrite design system. It means, things like atoms would be composed of buttons and we have molecules, which are slightly more complex. Then one level above that would be organisms, which are things like forms. Obviously, as you move up to like the higher level, it becomes more difficult for us to decide does this belong in EDS or does it belong with the app. There's lots of refactoring that sometimes ends up happening as a result of something built one way and us realizing later down the road that it wasn't actually very extensible and we just built it for this particular use case. Sometimes, it's the opposite where this was too generic. We can make it a little bit more specific and add more logic to it. It really depends on the component but that's been our strategy, just taking the components as needed. We're still in the earlier stages. We've released EDS a year ago and now, we're almost close to finishing it. We're just missing a handful of components. They'll be more [inaudible] that's available as opposed to adding a brand new component. CHARLES: Did you find guidance in existing design systems? One thing is why not just use one of the existing ones that's out there. Is it a matter of branding? Is it a matter of, "There are certain interactions which are unique to our product that we need to design system to capture them?" I guess my question is, if this is something I want to take on myself, what tools would I be able to reach for and what other design systems would I be able to look to versus what I have to contribute myself? What am I going to be looking for to share with the community and what am I going to look for that's develop that's uniquely mine? KAYLIE: I think consistency was a big issue. Sort of the genesis of idea came actually even before I joined the company but I think what they were going for was that we already had an existing component library called Style Guide and it wasn't really working out for us. To build like a common UI library was a natural assumption but making it better, making it more reusable. We looked at companies like Airbnb and Microsoft and I learned a lot from what they were doing. You definitely wanted some components that are specific to Eventbrite such as a ticket card or a media card that we use for our browse pages which would be needed for Eventbrite specific pages. I think mostly, the designers wanted more control because relying on third library means we don't always get what we want. We're actually thinking about making EDS open source at some point in the future, where it could take themes so other companies or individuals can leverage it but use their own theming scheme. If Spotify came and wanted to use EDS but using their colors and brand logo, then they could do so, just by layering a different configuration style to it. CHARLES: That's such an interesting idea. Is this something that you all have explored, maybe collaborating with another company? I'm trying to think what would be the benefit of making it publicly available, unless you would be getting lots of contributions back to improve EDS itself. Is that the idea? KAYLIE: Yeah. We're definitely set on making it public at some point in the future but making it open source is a different conversation because like you said, there's pros and cons that comes with open sourcing a package. We recently open source britecharts, which is a D3 library. It's been getting a lot of contributions. It's a good recruiting tool but it's also a lot of maintenance work outside of developers normal work hours. Also, we have to start worrying about like when we make a breaking change to a component, we're not just breaking it for our own product but for other developers. We currently have external developers. We have Eventbrite plugin system called Spectrum so developers are already building on top of that and they've been asking for something like this, where they could leverage and match the look and feel with the rest of the product. The downside is lots of maintenance hours and worrying about all the people that would be breaking the component for by just solving your use case. I feel like I didn't fully answer one of your questions, which was you have a different dynamic of people working on both really backend ops things, as well as a really frontend design system work. We definitely got very smart people on the team. Some people definitely have expertise in one area versus on others. Currently, we have five developers and some of us lean more towards the backend of the frontend work and I am one of those people working on things like Yarn and Docker and build system work but it's funny because I was thinking if I had a portfolio then, there wouldn't be any visual components to it, even though I'm a frontend developer. It would just be like terminal screens. We try to divide the work but everyone tries to, I guess develop, at least some shared knowledge around why we make the decisions that we do. CHARLES: It's interesting how they all intersect. I feel like the trend of the last 10 years has been to dev of all the things. I think the first thing was this artificial divide between developers and testing and that came together with the test driven development and test obsessed. Then there was this divide between developer and an ops and that divide went away now with the advent of the devops movement. Now, there's this divide between developers and design and I feel like that kind of wall is collapsing right now. You have developers participating a lot more in design and designers spending a lot more in development. We're seeing that but it's just funny how the devs starts integrating with all the things. KAYLIE: Yeah, that's a really good insight. CHARLES: You said you kind of naturally gravitate towards more of the backend doing the working with Docker, working with Yarn. How did you get actually involved with the Yarn Project? KAYLIE: Eventbrite converted over from NPM to Yarn maybe a year ago and the benefits that we got from converting over was awesome because we were manually editing NPM shrinkwrap, which is a nightmare and the installation speed of the container was really slow just because we were on NPM and it didn't really have any advance caching mechanisms at that point. Yarn just sped up a lot of things for us. I really like the user interface outside of just installing. You actually get a lot of freebie commands like 'yarn why,' that tells you why you have a particular dependency or you could do 'yarn check.' It was just a lot more helpful. I've been wanting to contribute to open source for a while so I did a little bit of work before then but the community was really encouraging when I first try to solve and pick up some first contribution bugs off of their backlog. At the time, they were pushing for 1.0 release so there's a lot of excitement about what Yarn will be and all the new features will be adding. I kept trying to pick places where I felt like I could be of help and then, Christoph, the manager of the Yarn Team and I believe [inaudible] team as well, reached out and asked if I wanted to build the selective resolution feature for them. I was like, "Yeah. I'll give it a go." Then I did it. CHARLES: What is selective resolution? KAYLIE: Good question -- CHARLES: Because I use Yarn every day and I've never heard this term. KAYLIE: It's something that became available with 1.0 release, much like workspaces and most of the time, you're not going to need it but sometimes, you're using a library. That library will have a nested dependency that for some reason, has a bug or you can't work with that package or maybe you just want to dedupe the package so that all of your dependencies end up using one version of that particular nested package. Selective resolution is like a way for you to override other libraries dependencies -- CHARLES: Oh, that's really cool. I like that because I've had that happens to me where I want some version of a library that has got a bug fix and yet, some other library that's depending is requiring this library and they're getting the old version and I'm like, "Nah!" ELRICK: That was happening to me last night. I wish I knew about this. CHARLES: Yes, seriously. KAYLIE: Yeah. Before this -- CHARLES: I'm glad we had you on justifying about this. KAYLIE: Awesome. Before this, you would have to file an issue with the original maintainer and maybe, it'll get fix. Maybe it won't or maybe you're stuck on the old version and you can't do anything about it. We had a really similar issue with the PhantomJS package, where we wanted to use a next patch version with a bug fix but then, something that was requiring it wasn't letting us use it. It works. I verified it. It seems like Facebook started using it as well so it was a pretty rewarding to work on that. CHARLES: That's exciting. I also plan on using it the next time I encounter this. ELRICK: To get this feature, is this a flag that you have to pass? How does it do the selective resolution? KAYLIE: As long as you're using Yarn 1.0 or above, you define resolutions field inside of your package.json, like how you would define that dependencies, you also have extra [inaudible] resolutions. On the left hand side, you put in a glob pattern that you want to match and if you want to match all packages, you just enter the name of the package. Then on the right side, you enter whatever version or path that you wanted to match. It could be a file or a GitHub link or it could be a version or a range or whatever you want. ELRICK: Nice. CHARLES: That's fantastic. Now, you mentioned that as you were coming to work on this, you were looking for features to work on but the community actually did a very good job of drawing you in and getting that contribution from you, which is actually pretty amazing when you think about it. I think a lot of open source projects, either flourished or failed by their ability to attract contributors. What was it that was particularly inviting? KAYLIE: It was a combination of things. I think one thing is they tried to point you to the actual code like if you want to submit a PR, then this is where you would get started. I actually started doing that myself on some of the issues. Everyone loves PRs more than issues so I think giving people filing the issues, some, I guess empowerment to try to fix it on their own, I think is great. They also have a Discord Channel for devs to talk about any questions that they might have, how to set up their initial dev environment, to test things on Yarn. Also, they were really nice. They were really thankful when I posted a PR or commented on the fix. They also use a lot of emojis, which helps. I think I personally found it really rewarding because it made me a better developer. Before contributing to Yarn, I didn't know that much about Node. For me, it was just fun to learn more about like, "This is how something else works," and also, the codebase uses a lot of different linting configurations, which I hadn't really used before so that was a nice learning curve there as well. ELRICK: For your initial time going to Yarn when you didn't know much about it, was the champion from the project that worked with you to get you over the hump or places that you were stuck or did you just have to kind of figured it out on your own or did you ask questions on the Discord Channel or in Slack Channel or anything? How did that process go initially? KAYLIE: I definitely pace myself. I just picked up easier bugs on a repos if possible and BYK and Mel who maintain the project would give guidance, especially through PR comments and they also answer any questions on issues. If I ask questions like what's the right approach here, because sometimes you get a bug and it's not just a bug. It actually has to do with philosophy of like, what should Yarn do in this case. There be like really minor edge cases like maybe NPM does that in a particular way, should Yarn respect that or should it try to be better? Those discussions are, I think really helpful and interesting and understanding what's going on. CHARLES: It's fantastic when the conversation just builds and you're learning stuff and then you actually feel like you came out with the best solution that was available to you at the end of the process. ELRICK: You gain a lot of context about the project during those conversations. CHARLES: Right. KAYLIE: Yeah, what was good about those selective resolution feature was it was completely community-driven, even from the RFC standpoint which submitted by someone in the community and then it was implemented by me, who doesn't work in Facebook. I think that's awesome. CHARLES: There's been a lot of thought that was put into the feature even before the implementation. That's always so critical to getting people's and giving them some specifications, some blueprint of what they're actually going to build. One of the things also that I wanted to touch on too is you mentioned before the show that they have a very unique take on the way they handle communication with the community, not just in terms of pull request but also in terms of issues. KAYLIE: Yarn issue count is around 800 -- CHARLES: Boy, that's a lot. I can feel daunting when you look at that, right? KAYLIE: Yeah, but it's actively [inaudible] project, a lot of people are passionate about it and there are bots that other projects use to just automatically close issues when they're not active. But something that BYK told me was when issues are closed, people take it somewhat personally and we just want to make sure that there's like a human touch to it and we, at least get to the issues without just automatically closing them. I really respect that. I think even when people are really frustrated, the maintainers never really lose their shit. They're always very graceful and when someone is acting outside of the standards of Code of Conduct, there's a gentle reminder. So far, all of the interactions that I've seen to the issues have been really constructive, rather than being like, "Sorry, we're not going to work on this." It feels like it is a community project and people care about how it's being used. It's actually not easy given all the different operating systems that Yarn has to accommodate. It's like a pretty low level tool so I give the guys a lot of kudos for handling that. CHARLES: Eight hundred issues means that with a human touch, that means 800 people have to actually respond to those issues and usually those 800 people are not actually 800 people. They're like 10 people or some number significantly below 800. How do you attack them to try and make sure that they're responded to in a timely fashion? KAYLIE: I think issue tracking is the hardest part of open source. I think it's in the order of issue tracking and then reviewing PRs and then submitting PRs because writing code is writing code but understanding other people's code is more difficult and understanding other people's issues and what the bug is, actually is even more difficult. You don't, obviously have their exact dev environment so sometimes, it's hard to repro. I think we do a lot of things that a lot of other projects leverage, which is we label the issues, we define priority if it's actually impacting a lot of people or if it's a critical bug like you can install a package versus maybe a warning message that could be tweet. Then we kept a board, like a GitHub board to track issues when we were heading for the 1.0 release. I'm not sure if we're still doing that but that helped to a degree. Other people from the community, not just the maintainers, jump in to try and help out an issue, which is probably one of the best things. Then when we merge pull requests, we close the issues that have been referenced. CHARLES: Yeah, it's really wonderful when that thing happens. I'm so curious like how to [inaudible] because I know that it's so disheartening when you're working on a project and you file an issue and maybe, it doesn't even go answered for one day, two days or two weeks or you submit a pull request and no one's even commenting on it. It can be really disheartening and kind of make you question the viability of the product itself, especially if you see a lot of activity elsewhere. On the one hand, I also understand that the maintainers are human and they probably have a lot of obligations. I know that I've got a lot of projects where I let the issues languish and I even have one that I'm using where I can't get any response and it's just so frustrating. KAYLIE: Yeah, even Yarn is definitely not perfect. There are definitely issues that sort of go buried. You could add us at YarnPackage/Core. That pings all of us and the core team. You could call out specific people but that's a tough one. CHARLES: This isn't with Yarn, by the way. It's a totally separate project. It's fantastic when there's that basic acknowledgement. It makes such a difference in people's perception of the entire enterprise. Looks like we're actually approaching time. If we want to give a special shout out to any talks you're going to be giving, any events that you'll be at or -- KAYLIE: Actually, Ben on my frontend platform team is speaking at Nodevember about Next React. I think that's where the shout out. And then Christoph will be speaking at AgentConf in Austria, I think in January about the future of dev tools. I think both things are [inaudible]. CHARLES: All right. Fantastic. ELRICK: Any slick future features coming out in Yarn that we should know about? KAYLIE: I'll keep you updated. CHARLES: She's sworn to secrecy. KAYLIE: Yeah. I'm not sure what I'm supposed to [inaudible] yet. CHARLES: I could hear the pause of conspiracy in your voice. Thank you so much, Kaylie for coming on the show. This has been a really wonderful conversation that's just gone all over the map and those are my favorite kind. Thank you very much. KAYLIE: Thank you so much for having me. This has been a lot of fun, guys. CHARLES: Well, if people want to get in touch with you, how would they go about doing that? KAYLIE: I'm a rarity, where I don't have Twitter. You can email me, I guess. CHARLES: File an issue on Yarn. KAYLIE: Yeah. I'm KaylieEB on GitHub and KaylieKwon@Gmail. CHARLES: As always, you can get in touch with us. We're at @TheFrontside on Twitter or just drop us a line on the email. You use that on occasion too at Contact@Frontside.io. Thank you, Kaylie. Thank you, Elrick and thank you for listening.
Panel: Amie AJ Charles Max Wood Guest: Eric Berry This week on Ruby Rogues, we interview our very own, Eric Berry, to talk about the sustainability of open-source projects through ethical advertising. The team talks about once open source projects like PhantomJS, Cancan, and many others. The Rogues dive into the many different scenarios that lead open source projects astray. Problems like working on the project without compensation, be overworked, and no interest are many of the reasons these are not sustained in the long run. However, are there solutions like donations or sponsorship to sustain such projects? And how do we go about finding funding or compensation for these open source projects? Eric describes that advertising tactics and strategies for open source. Eric talks about his work with Code Sponsor and how they support the open source community with funding. In particular, we dive pretty deep on: Ruby Rogues talk about burnout on projects Working on projects for free and the project falls apart Solutions behind the more popular projects like Ruby on Rails and NPM. Lemonade Stand - Sustaining and bounty sourced projects Sponsorship or company supported projects. Crowdfunding - not sustainable, but helps. Donation buttons, do they work? Who would pay developers for this? Developers taking care of other developers Advertising, and helping pay for projects to stay alive! Help developers stay funded without a spam haven. and much, much more! Links: Cancan PhantomJS Code Sponsor Timber Rollbar CoreLogic TrackJS CircleCI CodeConf. Picks Amie Positive Experience for Women in Tech Hand Written Cards Charles Keto Diet - Fat Head Ruby Dev. Summit AJ Real Love by Greg Baer Eric Nate Hopkins Open Collective CarbonAds.Etc.
Panel: Amie AJ Charles Max Wood Guest: Eric Berry This week on Ruby Rogues, we interview our very own, Eric Berry, to talk about the sustainability of open-source projects through ethical advertising. The team talks about once open source projects like PhantomJS, Cancan, and many others. The Rogues dive into the many different scenarios that lead open source projects astray. Problems like working on the project without compensation, be overworked, and no interest are many of the reasons these are not sustained in the long run. However, are there solutions like donations or sponsorship to sustain such projects? And how do we go about finding funding or compensation for these open source projects? Eric describes that advertising tactics and strategies for open source. Eric talks about his work with Code Sponsor and how they support the open source community with funding. In particular, we dive pretty deep on: Ruby Rogues talk about burnout on projects Working on projects for free and the project falls apart Solutions behind the more popular projects like Ruby on Rails and NPM. Lemonade Stand - Sustaining and bounty sourced projects Sponsorship or company supported projects. Crowdfunding - not sustainable, but helps. Donation buttons, do they work? Who would pay developers for this? Developers taking care of other developers Advertising, and helping pay for projects to stay alive! Help developers stay funded without a spam haven. and much, much more! Links: Cancan PhantomJS Code Sponsor Timber Rollbar CoreLogic TrackJS CircleCI CodeConf. Picks Amie Positive Experience for Women in Tech Hand Written Cards Charles Keto Diet - Fat Head Ruby Dev. Summit AJ Real Love by Greg Baer Eric Nate Hopkins Open Collective CarbonAds.Etc.
Panel: Amie AJ Charles Max Wood Guest: Eric Berry This week on Ruby Rogues, we interview our very own, Eric Berry, to talk about the sustainability of open-source projects through ethical advertising. The team talks about once open source projects like PhantomJS, Cancan, and many others. The Rogues dive into the many different scenarios that lead open source projects astray. Problems like working on the project without compensation, be overworked, and no interest are many of the reasons these are not sustained in the long run. However, are there solutions like donations or sponsorship to sustain such projects? And how do we go about finding funding or compensation for these open source projects? Eric describes that advertising tactics and strategies for open source. Eric talks about his work with Code Sponsor and how they support the open source community with funding. In particular, we dive pretty deep on: Ruby Rogues talk about burnout on projects Working on projects for free and the project falls apart Solutions behind the more popular projects like Ruby on Rails and NPM. Lemonade Stand - Sustaining and bounty sourced projects Sponsorship or company supported projects. Crowdfunding - not sustainable, but helps. Donation buttons, do they work? Who would pay developers for this? Developers taking care of other developers Advertising, and helping pay for projects to stay alive! Help developers stay funded without a spam haven. and much, much more! Links: Cancan PhantomJS Code Sponsor Timber Rollbar CoreLogic TrackJS CircleCI CodeConf. Picks Amie Positive Experience for Women in Tech Hand Written Cards Charles Keto Diet - Fat Head Ruby Dev. Summit AJ Real Love by Greg Baer Eric Nate Hopkins Open Collective CarbonAds.Etc.
Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer
Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer
Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer
Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Gemfile's new clothes, Introduction to Concurrency Models with Ruby. Part II и Rails on Docker: Using Docker Compose with Your Ruby on Rails Apps Headless Chrome vs PhantomJS Benchmark и Superfast CSV imports using PostgreSQL's COPY command What service objects are not, About Rails concerns и Interactor - a common interface for performing complex user interactions JavaScript Announcing Yarn 1.0, Why we moved from Angular 2 to Vue.js (and why we didn't choose React) и Cycle.js: A Unified Theory of Everything for JavaScript Size Limit: Make the Web lighter, LookForward.js - a small library that helps you to create smooth transitions between pages with the easiest way, React PowerPlug - set of components to you add different types of state in your dumb components и Rythm.js - a javascript library that makes your page dance В гостях - Иван Фокеев Github Work
Scott has a wide-reaching conversation with Ariya Hidayat about how he - and software - endures. He started the popular PhantomJS project but also writes code in Free Pascal! Keeping positive, making small forward moves.
We discuss a tiny DOS caused when upgrading thoughtbot.com to Rails 5.1 and how Rails could better surface warnings that only occur in your production configuration. We also get an update on multi-table joins in Rust. Meaningful schema diffs in Rails 5.1 HSTS Firesheep Use a secure session cookie for new installs pshtt Observatory by Mozilla Encrypted secrets in Rails 5.1 PhantomJS maintainer steps down Sean solves his problem: Multi-tabls joins in Rust
In this episode we discuss custom lightning development, PhantomJS and Headless Chrome, Apple’s Q2 earnings, Hulu TV, Oracle restructuring its sales team, Benioff’s $400 billion job creation goal, and where to meet up for happy hour at Texas Dreamin 2017. How Hulu Reinvented Itself for Live Tv Salesforce CEO Marc Benioff dishes on his $400 billion job creation goal Apple boss Tim Cook says 'reports about future products' likely delayed quarterly iPhone purchases Massive Oracle sales re-org to accelerate cloud cash drive Ecobee4 PhantomJS Getting Started with Headless Chrome Trailhead.com Roger Mitchell Blog Brett Nelson Blog Eureka - Austin, TX
関連リンク Kyoto.js 12 - connpass 2017-01-04のJS: PostCSS概要、Chrome開発者ツール、FuseBox - JSer.info PostCSS まとめ - Qiita Optimise your web development workflow 2016 Fuse-Box bundler / API Reference Node.js Interview Questions and Answers (2017 Edition) | @RisingStack [https://tylermcginnis.com/react-interview-questions/) Front-End Performance Checklist 2017 (PDF, Apple Pages) – Smashing Magazine 2017-01-11のJS: Node.js v7.4.0とnpm v4、PhantomJS 2.5.0 Beta、クリーンコード - JSer.info npm/CHANGELOG.md at v4.0.5 · npm/npm · GitHub Comparison with QtWebKit 5.6 · annulen/webkit Wiki · GitHub 縦書きWeb普及委員会 たてよこWebアワード Flow Runtime Front-end Handbook 2017 · GitBook JavaScript Weekly Issue 316: January 5, 2017 The Web Bluetooth module for Angular – Google Developers Experts – Medium Web Bluetooth API - Chrome Platform Status Procedural Texture Generator in javascript
Summary Cypress.io is geared toward making testing easy and painless. Gleb Bahmutov (@bahmutov) and Brian Mann (@be_mann) chat with us on this upcoming project. Cypress eliminate the need for PhantomJS and Selenium. It aims to provide developers with instant feedback, reliable automation, and painless debugging, It is an interesting and different way of approaching how we think about testing code. Show Links Cypress.io - https://www.cypress.io/ Gitter - https://gitter.im/cypress-io/cypress Docs - https://docs.cypress.io Gleb's blog post: https://glebbahmutov.com/blog/web-testing-nirvana-with-cypress/
本期由 Terry 和 袁滚滚 一起主持， 邀请到了 Vue.js 的作者 尤小右, 聊聊前端框架开发背后的故事。 这一期我们将聊到非常多前端框架和技术，大家也可以听到小右同学对各种前端框架和技术的点评，如果你正愁如何选择你的前端工具栈, 我相信这一期将会对你有非常大的帮助。(涉及到的技术包含 Knockout, BackboneJS, Spine, Marionette, AngularJS, Ember, Ractive.js, React, Flux, webpack, Karma， Jasmine 等等等等) Meteor Parsons School of Design Clojure Colgate University ActionScript Zachary Lieberman openframeworks three.js Google Creative Lab Google Data Arts Team Aaron Koblin Chrome Experiments Dependency injection Object.defineProperty() Knockout Backbone.js Spine AngularJS Marionette MVVM Glimmer Ractive React React Virtual DOM shouldComponentUpdate (React) Flux Immutable JS CommonJS substack Browserify webpack Babel CoffeeScript TypeScript Jasmine Mocha Karma Selenium CasperJS PhantomJS Nightwatch.js Sauce Labs BrowserStack DailyJS Laravel Laracasts Processing TasteJS Avalon 尤小右 知乎 Relay Ember FastBoot react-server-example 功夫熊 硬派健身 硬派健身 － 知乎专栏 Python China 青城 Theme BTW: 录制中途，突然楼上开始敲东西，虽然后期做了一些处理， 但是可能还是略有影响，但并无大碍，希望大家多多饱含. 小右口误更正： 小右到达美国的时间是 05 年 Typescript 是有类型推导的 Special Guests: 尤小右 and 袁滚滚.
Check out RailsClips on Kickstarter!! 02:45 - Ashton Kemerling Introduction Twitter GitHub Blog 03:00 - Ruby and Clojure Pivotal Labs Pivotal Tracker Clojurescript Generative Testing PhantomJS Invariance 14:50 - Difficulty generative rantly 23:13 - Generative Testing and Documentation “Shrinking” 26:38 - Are Generative Tests Disposable? Capybara 29:09 - When Do You Start Generative Testing? 31:43 - Setup & Barriers to Entry 40:38 - Why Does Generative Testing Have a Bad Reputation? 42:49 - Getting Past ^^ 44:17 - Verifying Things Are Fixed 46:57 - Maintaining These Tests Multimethods 51:12 - Human Actions, Generative Testing, and Architecture Functional Programming 01:02:10 - Resources [YouTube] Integrating Test.Check and Javascript Jessica Kerr: TDD with generative testing: an example in Ruby Ashton Kemerling: Integrating Test.Check and Javascript Picks Joseph Wilk: Programming as Performance (Coraline) Linda Liukas: Principles of Play (Coraline) Hello Ruby (Coraline) QuickCheck CI (Jessica) CodeMesh 2014 - John Hughes - QuickCheck Evolution (Jessica) GeeCON 2012: Kevlin Henney - It Is Possible to Do Object-Oriented Programming in Java (Avdi) FUJITSU Image Scanner ScanSnap iX500 (Avdi) FFmpeg (Chuck) YouTube (Chuck) Developer’s Box Club (Chuck) Ruby Remote Conf (Chuck) RailsCasts on Kickstarter (Chuck) Datomic (Ashton)
Check out RailsClips on Kickstarter!! 02:45 - Ashton Kemerling Introduction Twitter GitHub Blog 03:00 - Ruby and Clojure Pivotal Labs Pivotal Tracker Clojurescript Generative Testing PhantomJS Invariance 14:50 - Difficulty generative rantly 23:13 - Generative Testing and Documentation “Shrinking” 26:38 - Are Generative Tests Disposable? Capybara 29:09 - When Do You Start Generative Testing? 31:43 - Setup & Barriers to Entry 40:38 - Why Does Generative Testing Have a Bad Reputation? 42:49 - Getting Past ^^ 44:17 - Verifying Things Are Fixed 46:57 - Maintaining These Tests Multimethods 51:12 - Human Actions, Generative Testing, and Architecture Functional Programming 01:02:10 - Resources [YouTube] Integrating Test.Check and Javascript Jessica Kerr: TDD with generative testing: an example in Ruby Ashton Kemerling: Integrating Test.Check and Javascript Picks Joseph Wilk: Programming as Performance (Coraline) Linda Liukas: Principles of Play (Coraline) Hello Ruby (Coraline) QuickCheck CI (Jessica) CodeMesh 2014 - John Hughes - QuickCheck Evolution (Jessica) GeeCON 2012: Kevlin Henney - It Is Possible to Do Object-Oriented Programming in Java (Avdi) FUJITSU Image Scanner ScanSnap iX500 (Avdi) FFmpeg (Chuck) YouTube (Chuck) Developer’s Box Club (Chuck) Ruby Remote Conf (Chuck) RailsCasts on Kickstarter (Chuck) Datomic (Ashton)
Check out RailsClips on Kickstarter!! 02:45 - Ashton Kemerling Introduction Twitter GitHub Blog 03:00 - Ruby and Clojure Pivotal Labs Pivotal Tracker Clojurescript Generative Testing PhantomJS Invariance 14:50 - Difficulty generative rantly 23:13 - Generative Testing and Documentation “Shrinking” 26:38 - Are Generative Tests Disposable? Capybara 29:09 - When Do You Start Generative Testing? 31:43 - Setup & Barriers to Entry 40:38 - Why Does Generative Testing Have a Bad Reputation? 42:49 - Getting Past ^^ 44:17 - Verifying Things Are Fixed 46:57 - Maintaining These Tests Multimethods 51:12 - Human Actions, Generative Testing, and Architecture Functional Programming 01:02:10 - Resources [YouTube] Integrating Test.Check and Javascript Jessica Kerr: TDD with generative testing: an example in Ruby Ashton Kemerling: Integrating Test.Check and Javascript Picks Joseph Wilk: Programming as Performance (Coraline) Linda Liukas: Principles of Play (Coraline) Hello Ruby (Coraline) QuickCheck CI (Jessica) CodeMesh 2014 - John Hughes - QuickCheck Evolution (Jessica) GeeCON 2012: Kevlin Henney - It Is Possible to Do Object-Oriented Programming in Java (Avdi) FUJITSU Image Scanner ScanSnap iX500 (Avdi) FFmpeg (Chuck) YouTube (Chuck) Developer’s Box Club (Chuck) Ruby Remote Conf (Chuck) RailsCasts on Kickstarter (Chuck) Datomic (Ashton)
Today, Web Components have emerged from cutting edge technologies to technologies we can implement in our small scale production. It won't be long before we are building large scale applications with Custom Elements, HTML Imports, Template Tags, and the infamous Shadow DOM. In embracing this type of developer environment, with it's flexibility and compositional nature, consider interoperabilty as a core concept. If you need a custom element for a card layout, as an example, you should be able to use any Web Component out there in the ecosystem regardless of which library or toolchain it comes from. If the component provides the desired functionality and styling you would require it should work seamlessly in your application. Furthermore, toolsets should not limit the the extending and composition of these custom elements. In practice, this may or may not always be the case and library & toolchain creators will need to be aware of these concerns. Rob Dodson (@rob_dodson), Developer Advocate on the Google Chrome team, talks about his thoughts on the subject. Rob is helping to educate developers, not just about Google's Polymer Library built on top of Web Components, but across the entire Web Components community. Rob goes through many of the changes made to Polymer 0.4.2, including accessibility and performance that help in making applications more integrated and how Google is working to share what the Blink Team has learned from implementing Web Components in Chrome with other browser vendors and developers. Working closely with Mozilla developers on his SFHTML 5 Meetup talk on Web Components Mashups, Rob was able to collaborate and share ideas so that Web Components could alleviate many of the concerns we had when migrating from one JavaScript library to another. It is painful for developers to have to remake components every time they switch libraries or frameworks. Web Components aims to make that a thing of the past and Rob has done much more on this topic since that talk. Have a listen and hear what he has to say. Resources Rob's Blog - http://robdodson.me/ I/O Presentation - http://webcomponents.org/presentations/unlock-the-next-era-of-ui-development-with-polymer-at-io/ Accessible Web Components Part 1 -https://www.polymer-project.org/articles/accessible-web-components.html SFHTML Mashup Video -https://www.youtube.com/watch?v=75EuHl6CSTo The Web Platform Status for IE - https://status.modern.ie/ IE Beta Channel - http://www.microsoft.com/en-us/download/details.aspx?id=43360 Polytechnic Events - http://itshackademic.com/ Polycast Playlist - https://www.youtube.com/playlist?list=PLOU2XLYxmsII5c3Mgw6fNYCzaWrsM3sMN Custom Elements on GitHub - https://twitter.com/polymer/status/464103568392200193 IE Platform Voting -https://wpdev.uservoice.com/forums/257854-internet-explorer-platform customelements.io - http://customelements.io/ Webcomponents.org -http://webcomponents.org/ Bosonic Shadow DOM Issue (#4) - https://github.com/bosonic/bosonic/issues/4 The Bower Package Manager - http://bower.io/ Divshot - http://divshot.io Divshot Blog - https://divshot.com/blog/ BuiltWithPolymer - http://builtwithpolymer.org/ Divshot's Web Component Playground - https://ele.io/ Angular 2 Web Components Data Binding Document - https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI/edit?hl=en&forcehl=1&pli=1#heading=h.xgjl2srtytjt ReadTheSource - http://hangouts.readthesource.io/hangouts/divshot-superstatic/ RailsCasts -http://railscasts.com/ PhantomJS -https://github.com/ariya/phantomjs/wiki/PhantomJS-2 saucelabs -https://saucelabs.com/ People Alex Russel -https://twitter.com/slightlylate Alice Boxhall -https://twitter.com/sundress Raphael Rugeron - https://twitter.com/goldoraf Jonathon Sampson -https://twitter.com/jonathansampson Arron Schaar - https://github.com/pennyfx Michael Bleigh - https://twitter.com/mbleigh Scott Corgan - https://twitter.com/scottcorgan Projects Reactive Elements -https://github.com/PixelsCommander/ReactiveElements X-Tags Imports - https://github.com/x-tag/x-tag-imports Enyo -http://enyojs.com/ React.js -http://facebook.github.io/react/ Famo.us -http://famo.us/ Chromium Blink -http://www.chromium.org/blink Polymer 0.4.2 -https://github.com/Polymer/polymer/releases/tag/0.4.2 Brick 2.0 -http://brick.mozilla.io/ X-Tags -http://www.x-tags.org/ Polymer -https://www.polymer-project.org/ Bosonic -https://bosonic.github.io/ Vulcanize - https://github.com/polymer/vulcanize generator-element -https://github.com/webcomponents/generator-element Firefox OS - https://www.mozilla.org/en-US/firefox/os/ web-component-tester -https://github.com/Polymer/web-component-tester Topeka -https://github.com/polymer/topeka Jquery UI -http://jqueryui.com/ Components core-a11ykeys -https://github.com/Polymer/core-a11y-keys core-list -https://github.com/Polymer/core-list core-animated-pages -https://github.com/Polymer/core-animated-pages Brick Components -http://brick.mozilla.io/v2.0/docs WinJS Polymer Samples -https://github.com/banguero/winjs-polymer-samples core-ajax - https://github.com/polymer/core-ajax google-map - https://github.com/GoogleWebComponents/google-map core-shared-lib - https://github.com/Polymer/core-shared-lib google-apis - https://github.com/GoogleWebComponents/google-apis core-selector - https://github.com/polymer/core-selector paper-menu-button - https://github.com/Polymer/paper-menu-button paper-tabs - https://github.com/Polymer/paper-tabs paper-elements - https://www.polymer-project.org/docs/elements/paper-elements.html core-signals -https://github.com/Polymer/core-signals
Max ist zum ersten Mal überhaupt zwei Folgen hintereinander in Köln, und diesen Umstand müssen er und Daniel natürlich gleich mit der siebzigsten Episode »feiern«. »Feiern« in Anführungszeichen, weil die Folgennummer überhaupt nicht thematisiert wird. Wo wir aber gerade so geschickt über Thematisierung sprechen: Heute geht es um Karneval, religiöse Briefe, Quadrokopter, TAR und Selenium auf Windows 7. Der Quadrokopter Tolles Bild von Arthur Darvill PhantomJS Lorem Ipsum nunc feugiat ipsum nec tellus @konferenz28 mauris et purus sit Metafolge.
Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel David Herman (twitter blog Effective JavaScript) Ariya Hidayat (twitter github blog) Tim Caswell (twitter github howtonode.org) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:48 - David Herman and Ariya Hidayat Introduction 044 JSJ Book Club: Effective JavaScript with David Herman 023 JSJ Phantom.js with Ariya Hidayat 01:54 - Parsing JavaScript and ASTs and Language Grammars 04:44 - Semantics 06:08 - Abstract Syntax Tree (AST) Esprima: Parser SpiderMonkey 10:37 - Lexer 12:16 - Writing your own language creationix / jack The C Programming Language 17:41 - Parser Generators JavaScriptCore 21:04 - Evolving a Syntax Automatic Semicolon Insertion Post correspondence problem Halting problem 28:05 - Language Design The Rust Programming Language 30:35 - Grammar Regular Expressions (Regex) Backus–Naur Form (BNF) Recursion How to Design Programs (HTDP) 38:00 - Recursive Descent Parsers 42:48 - Benefits of knowing language internals and syntax Apache Lucene - Apache Lucene Core LPeg - Parsing Expression Grammars For Lua 48:48 - Abstract Syntax Tree (AST) Picks Mass Effect 3 (Joe) A Beginner's Guide to Irrational Behavior | Coursera (Joe) Go write a programming language to learn one (Tim) Thumbs and Ammo (Jamison) ISM by Savant (Jamison) Vimcasts (Jamison) The iPhreaks Show (Chuck) Mozy (Chuck) Tech & Go Bright Pink Micro USB Cable (David) asm.js (David) Beyond Office Politics: The Hidden Story of Power, Affiliation & Achievement in the Workplace by Linda Sommer (Ariya) gotwarlost / istanbul (Ariya) Next Week Web Developer Skills Transcript JAMISON: I am Linus Torvalds and I pronounce Linux, Linix. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK: Hey everybody and welcome to Episode 54 of the JavaScript Jabber Show. This week on our panel, we have Tim Caswell. TIM: Hello. CHUCK: Jamison Dance. JAMISON: Hi guys. CHUCK: Joe Eames. JOE: Hey there. CHUCK: Merrick Christensen. MERRICK: Hey guys, what’s up? CHUCK: I’m Charles Max Wood from DevChat.tv. And we have two special guests this week. We have Dave Herman. DAVID: Hey there. CHUCK: Ariya Hidayat. ARIYA: Hello everyone. CHUCK: And these guys are so smart that we brought them back. So, if you’re interested, we’ll put links to the episodes that they were on. David was on when we talked about his book ‘Essential JavaScript’ and Ariya was on when we talked about PhantomJS. JAMISON: Effective JavaScript. CHUCK: Effective? What did I say? MERRICK: Essential. CHUCK: Essential? Well, it’s an essential book on Effective JavaScript. How’s that? [Laughter] MERRICK: Good save. DAVID: At least, you didn’t say Defective JavaScript. [Laughter] CHUCK: No, that’s what I write. I’m really good at writing defective JavaScript. ARIYA: Actually, there’s a book about Essential on Defective JavaScript. CHUCK: I also want to announce really quickly that Fluent Conf has given us a discount code. So, if you want to get 20% off on your registration for Fluent Conf, just enter JAVAJAB and you’ll get 20% off when you register for Fluent Conf. Alright. Well, let’s get started. This is going to be a really, really interesting topic and it’s something that I’ve wanted to know more about for a long time. And I just haven’t delved as deeply into it as I would like to. And that is,
Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel David Herman (twitter blog Effective JavaScript) Ariya Hidayat (twitter github blog) Tim Caswell (twitter github howtonode.org) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:48 - David Herman and Ariya Hidayat Introduction 044 JSJ Book Club: Effective JavaScript with David Herman 023 JSJ Phantom.js with Ariya Hidayat 01:54 - Parsing JavaScript and ASTs and Language Grammars 04:44 - Semantics 06:08 - Abstract Syntax Tree (AST) Esprima: Parser SpiderMonkey 10:37 - Lexer 12:16 - Writing your own language creationix / jack The C Programming Language 17:41 - Parser Generators JavaScriptCore 21:04 - Evolving a Syntax Automatic Semicolon Insertion Post correspondence problem Halting problem 28:05 - Language Design The Rust Programming Language 30:35 - Grammar Regular Expressions (Regex) Backus–Naur Form (BNF) Recursion How to Design Programs (HTDP) 38:00 - Recursive Descent Parsers 42:48 - Benefits of knowing language internals and syntax Apache Lucene - Apache Lucene Core LPeg - Parsing Expression Grammars For Lua 48:48 - Abstract Syntax Tree (AST) Picks Mass Effect 3 (Joe) A Beginner's Guide to Irrational Behavior | Coursera (Joe) Go write a programming language to learn one (Tim) Thumbs and Ammo (Jamison) ISM by Savant (Jamison) Vimcasts (Jamison) The iPhreaks Show (Chuck) Mozy (Chuck) Tech & Go Bright Pink Micro USB Cable (David) asm.js (David) Beyond Office Politics: The Hidden Story of Power, Affiliation & Achievement in the Workplace by Linda Sommer (Ariya) gotwarlost / istanbul (Ariya) Next Week Web Developer Skills Transcript JAMISON: I am Linus Torvalds and I pronounce Linux, Linix. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK: Hey everybody and welcome to Episode 54 of the JavaScript Jabber Show. This week on our panel, we have Tim Caswell. TIM: Hello. CHUCK: Jamison Dance. JAMISON: Hi guys. CHUCK: Joe Eames. JOE: Hey there. CHUCK: Merrick Christensen. MERRICK: Hey guys, what’s up? CHUCK: I’m Charles Max Wood from DevChat.tv. And we have two special guests this week. We have Dave Herman. DAVID: Hey there. CHUCK: Ariya Hidayat. ARIYA: Hello everyone. CHUCK: And these guys are so smart that we brought them back. So, if you’re interested, we’ll put links to the episodes that they were on. David was on when we talked about his book ‘Essential JavaScript’ and Ariya was on when we talked about PhantomJS. JAMISON: Effective JavaScript. CHUCK: Effective? What did I say? MERRICK: Essential. CHUCK: Essential? Well, it’s an essential book on Effective JavaScript. How’s that? [Laughter] MERRICK: Good save. DAVID: At least, you didn’t say Defective JavaScript. [Laughter] CHUCK: No, that’s what I write. I’m really good at writing defective JavaScript. ARIYA: Actually, there’s a book about Essential on Defective JavaScript. CHUCK: I also want to announce really quickly that Fluent Conf has given us a discount code. So, if you want to get 20% off on your registration for Fluent Conf, just enter JAVAJAB and you’ll get 20% off when you register for Fluent Conf. Alright. Well, let’s get started. This is going to be a really, really interesting topic and it’s something that I’ve wanted to know more about for a long time. And I just haven’t delved as deeply into it as I would like to. And that is,
Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel David Herman (twitter blog Effective JavaScript) Ariya Hidayat (twitter github blog) Tim Caswell (twitter github howtonode.org) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:48 - David Herman and Ariya Hidayat Introduction 044 JSJ Book Club: Effective JavaScript with David Herman 023 JSJ Phantom.js with Ariya Hidayat 01:54 - Parsing JavaScript and ASTs and Language Grammars 04:44 - Semantics 06:08 - Abstract Syntax Tree (AST) Esprima: Parser SpiderMonkey 10:37 - Lexer 12:16 - Writing your own language creationix / jack The C Programming Language 17:41 - Parser Generators JavaScriptCore 21:04 - Evolving a Syntax Automatic Semicolon Insertion Post correspondence problem Halting problem 28:05 - Language Design The Rust Programming Language 30:35 - Grammar Regular Expressions (Regex) Backus–Naur Form (BNF) Recursion How to Design Programs (HTDP) 38:00 - Recursive Descent Parsers 42:48 - Benefits of knowing language internals and syntax Apache Lucene - Apache Lucene Core LPeg - Parsing Expression Grammars For Lua 48:48 - Abstract Syntax Tree (AST) Picks Mass Effect 3 (Joe) A Beginner's Guide to Irrational Behavior | Coursera (Joe) Go write a programming language to learn one (Tim) Thumbs and Ammo (Jamison) ISM by Savant (Jamison) Vimcasts (Jamison) The iPhreaks Show (Chuck) Mozy (Chuck) Tech & Go Bright Pink Micro USB Cable (David) asm.js (David) Beyond Office Politics: The Hidden Story of Power, Affiliation & Achievement in the Workplace by Linda Sommer (Ariya) gotwarlost / istanbul (Ariya) Next Week Web Developer Skills Transcript JAMISON: I am Linus Torvalds and I pronounce Linux, Linix. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK: Hey everybody and welcome to Episode 54 of the JavaScript Jabber Show. This week on our panel, we have Tim Caswell. TIM: Hello. CHUCK: Jamison Dance. JAMISON: Hi guys. CHUCK: Joe Eames. JOE: Hey there. CHUCK: Merrick Christensen. MERRICK: Hey guys, what’s up? CHUCK: I’m Charles Max Wood from DevChat.tv. And we have two special guests this week. We have Dave Herman. DAVID: Hey there. CHUCK: Ariya Hidayat. ARIYA: Hello everyone. CHUCK: And these guys are so smart that we brought them back. So, if you’re interested, we’ll put links to the episodes that they were on. David was on when we talked about his book ‘Essential JavaScript’ and Ariya was on when we talked about PhantomJS. JAMISON: Effective JavaScript. CHUCK: Effective? What did I say? MERRICK: Essential. CHUCK: Essential? Well, it’s an essential book on Effective JavaScript. How’s that? [Laughter] MERRICK: Good save. DAVID: At least, you didn’t say Defective JavaScript. [Laughter] CHUCK: No, that’s what I write. I’m really good at writing defective JavaScript. ARIYA: Actually, there’s a book about Essential on Defective JavaScript. CHUCK: I also want to announce really quickly that Fluent Conf has given us a discount code. So, if you want to get 20% off on your registration for Fluent Conf, just enter JAVAJAB and you’ll get 20% off when you register for Fluent Conf. Alright. Well, let’s get started. This is going to be a really, really interesting topic and it’s something that I’ve wanted to know more about for a long time. And I just haven’t delved as deeply into it as I would like to. And that is,
In our action-packed 30th episode Ed and Chris discussed their experiences with JavaScript testing tools, specifically how certain tools push you towards specific refactoring patterns. Chris talked about the successful launch of his latest book on using PHPUnit and got into some honest talk about revenue and how the product development course helped him make this book do 4 times the launch day revenue of his previous one. Ed discussed his plans to talk about mental illness on the conference circuit this year. Please help out by donating to the campaign! Rate us on iTunes here Follow us on Twitter here. Like us on Facebook here Listen Download now (MP3, 25.2MB, 55:13) Links and Notes Mocha Sinon.JS Jasmine and Jasmine-node QUnit The Grumpy Programmer’s PHPUnit Cookbook 30x500 LoneStar PHP Open Sourcing Mental Illness Require.JS PhantomJS Zombie.js Karma “It’s pronounced ‘jif’” Chris' new favourite thought leader Async JavaScript made the jump from Leanpub to bigger publisher DadBoner
Justin and Jason discuss balancing time when bootstrapping, the categories and costs of context switching, strategies for recruiting AnyFu experts, the status of the AnyFu payout system, what was learned from the first five AnyFu sessions, the DNA of the perfect AnyFu expert, whether or not we're in a startup bubble, when it makes sense to bootstrap and when it makes sense to raise money, vaccinating yourself against customer feedback, Helmut's document signing demo, the Hacker News slap, why Jason believes the "donate to charity" business model won't work for AnyFu, the importance of keeping your message simple, the PhantomJS web stack, why writing business plans are a waste of time for web and mobile startups, the new Node.js profiler, how Justin got into business with Uri Geller, the story of MashAPI, and the scam of automatic traffic ticketing.
© 2020-2025 Ivy Podcast Discovery LLC
