POPULARITY
Hosted by justin searls
7 episodes with justin searls
9 episodes with justin searls
4 episodes with justin searls
3 episodes with justin searls
3 episodes with justin searls
3 episodes with justin searls
4 episodes with justin searls
3 episodes with justin searls
Justin Searls joins Jerod in Apple's WWDC wake for hot takes about frosty UIs. We go (almost) point-by-point through the keynote, dissecting and reacting along the way. Concentricity!
Justin Searls joins Jerod in Apple's WWDC wake for hot takes about frosty UIs. We go (almost) point-by-point through the keynote, dissecting and reacting along the way. Concentricity!
Spoiler alert: I'm in the same country as I was for v37, but this time from a different nondescript business hotel. Also: I have good personal news! And, as usual, bad news news. I don't get to pick the headlines though, I just read them. This episode comes with a homework assignment. First, watch Apple's keynote at 10 AM pacific on June 9th. Second, e-mail podcast@searls.co with all your takes. I'd love your help by informing me where my head should be at when I show up on the Changelog next week. And now, fewer links than usual: The movie 父と僕の終わらない歌 Fukushima The Great East Japan Earthquake and Nuclear Disaster Memorial Museum Utsunomiya Fukui I got spicy about LLM neophytes Aaron's puns, ranked Entry-level tech hiring is down 50% AI Role in College Brings Education Closer to a Crisis Point Veo 3 marks the beginning of the end times (watch this supercut) If you're having an affair, don't use Claude Apple's turning it up to 26 My theory on what 2027's "all-glass" iPhone is really all about Nobody uses semicolons; they're pointless
Coming to you LIVE from a third straight week of Japanese business hotels comes me, Justin, in his enduring quest to figure out how to exchange currency for real estate in the land of the rising fun. [Programming note: apologies, as the audio quality at the beginning of the podcast suffered because I fucked up and left the hotel room's air conditioner on (I caught it and fixed it from the pun section onward)] Had a few great e-mails to read through this week, but now I'm fresh out again! Before you listen, why not write in a review of this episode? podcast@searls.co and tell me about how amazing it will be before it lets you down like your best friend and/or workplace mentor and/or parent figure. Video of this edition of the show is up on YouTube. Href time: Craigmod's Kissa by Kissa book @koic works on RuboCop and inspired this issue of my Searls of Wisdom newsletter In Japan, you're not a BDFL, you're a 優しい終身の独裁者 Speaking of newsletters, this month's took me way too damn long All the prefectures I've been to so far (36 as of v37) The US Embassy in Japan's 10" x 10" bag limit Aaron's puns, ranked CRISPR babies! (Archive) GTA 6's trailer SteamOS is one step closer to being real Fortnite is back on iOS CarPlay Ultra is nice, but will it scale? visionOS 3 will let us scroll with our eyeballs Apple is considering an AI-based search tool for iOS Rumor: iOS 19 will let developers invoke its on-board local models Sam + Jony, sitting in a tree / pile of cash ChatGPT Diminishes Idea Diversity in Brainstorming, Study Finds Microsoft Engineers forced to dig their own AI graves muscle-mem solves a huge issue with "agentic" programs Naturalizing relevance realization: why agency and cognition are fundamentally not computational Chicago Sun-Times Prints Summer Reading List Full of Fake Books mid college towns are screwed (News+) The Quiet Collapse of Surveys: Fewer Humans (and More AI Agents) Are Answering Survey Questions The Nomad Universal Cable Junglia Okinawa opens in July and this ad is absolutely bonkers Saw the Yakult Swallows with Tatsuhiko Miyagawa from Rebuild.fm Loved World Order's new single until the guy got milkshake duck'd 5 minutes later This Workforce AI promo video is peak smug AI hustler shit The Bechdel Test (not to be confused with the Becky Test)
I'm going away on a trip for an unexpectedly long time, and you'll never guess why! (You might guess why.) Anyway, here's something to remember me by. If you've ever been worried about whether something you cared about would work out okay, email podcast@searls.co and tell me about it so that I can share your story with a bunch of strangers on the Internet. References available upon request: Nobody knows how to turn on Vision Pro I released a new gem called searls-auth Aaron's puns, ranked CodeWeavers' founder's gracious post, Whisky's Legacy, and the Spirit it Leaves Behind DeX for iPhones? Finally! A menu bar for iPads? Finally! Backblaze: the only subsidized startup pricing schemes left are the fraudulent ones! Russia moves to seize World of Tanks developer over Ukraine support Amazon To Display Tariff Costs For Consumers, Report Says (Update: They Won't) Meta's Digital Companions want to have sex with you (News+) OpenAI's chat bot will tell you that you're really good at sex But they're fixing it But Reddit fixed it better Someone made an AI better by having it argue with itself, just like humans do Coding competitions are dead and gone forever The Coravin Pivot wine preservation system is great So is this pool skimmer robot that I talked about last week but forgot about and am talking about again A book! Landed: Japan. Everything you may not need to know about buying real estate
Your favorite podcast about nothing continues to find things to talk about. Whatever you do, DO NOT e-mail me at podcast@searls.co or else I will read it on air and tell everyone how smart you sound and how good you look. Video of this edition of the show is up on YouTube. Links to follow: Loving my Tariffmas gifts: external SSD array and pool skimmer, especially My first taste of GitHub Copilot's Agent mode Me putting Agent mode to the test in a fun little screencast Aaron's puns, ranked Videogame consoles like the Switch 2 are NOT exempt from tariffs Digital Foundry's technical analysis of Mario Kart World The stunning Marathon cinematic trailer Star Wars Zero Company is the X-Com game I want Almost 19% of Japanese people in their 20s have spent so much money on gacha they struggled with covering living expenses, survey reveals A bunch of Vision hardware leaks and rumors: 1, 2, 3, 4 People at Apple were calling the AI/ML group AIMLess, lol React Native might not be as popular as you think Boarding passes and check-in could be scrapped in air travel shake-up Incredible plot to print every single possible ticket to win the Texas lotto A Lack of Intelligence, Not Training, May Be Why People Struggle With Computers AI models still struggle to debug software, Microsoft study shows LLM bots + Next.js bankrupting people who design their sites badly Apps are being paid to install frameworks that sell users' bandwidth to proxy providers for AI scrapers OpenAI o3 and o4-mini announced (they also hallucinate more) GPT 4.1 is better at coding Codex CLI is OpenAI's answer to Claude Code Extremely long read: OpenAI is a Systemic Risk to the Tech Industry GPS magnetic quantum is 50x more accurate and unjammable The Gorge is good but takes a sharp left turn into horror town I went to Epic Universe and have opinions
Nothing like a peaceful Sunday morning at the end of an exhausting, historically-volatile week to pour a hot cup of coffee and spew absolutely scalding takes in all directions. If you get burned, don't say I didn't warn you. Read the message on the lid. We've done 34 of these now and my mailbag is getting full of old e-mails that don't make sense anymore. Please email new stuff to me at podcast@searls.co and we, like civilization, will start fresh next time! Video of this edition of the show is up on YouTube. You can read more about things on other websites below: My "new" podcast, Merge Commits Announcing TLDR 1.0 Late to the party on this: it's good that Siri is bubbling up to Craig, finally Aaron's puns, ranked Ethically sourced “spare” human bodies could revolutionize medicine OpenAI releases 4o Image Generation ChatGPT Users Are Creating Studio Ghibli-Style AI Images How OpenAI's Ghibli Frenzy Took a Dark Turn Real Fast (Archive) An image of an archeologist adventurer who wears a hat and uses a bullwhip Go to Truant Studio for all your branding and advertising needs Anthropic released their research into how LLMs "think" The 500 million worker problem India's domestic stock bubble Remember 15 years ago when we cared who would buy TikTok? Amazon might, still Eddie Burback's "No Phone" video College students are worse now, says professor, as always Ubisoft reportedly has lawyers ready to fight Assassin's Creed Shadows harassment Nintendo just carried out a major test of its reach in a post-Twitter world The Nintendo Switch 2 Direct Virtual Game Cards By "anti-scalping", they meant "for Japan" Third-party developers say Switch 2's horsepower makes them ‘extremely happy' Switch backwards compatibility is emulation Nintendo delays US preorders because tariffs Saturday Night film Titanic Still playing Avowed Not playing Inzoi How to change the oil on a Tesla Roguelike/Starfoxlike, Whisker Squadron: Survivor How SNL manages cue cards
Justin Searls from Breaking Change joins the show to discuss Apple's Intelligence blunder, the end of the good times in the tech industry, and POSSE Party, his in-progress product that lets "any dummy with a website enjoy a life of algorithm-free luxury."
Justin Searls from Breaking Change joins the show to discuss Apple's Intelligence blunder, the end of the good times in the tech industry, and POSSE Party, his in-progress product that lets "any dummy with a website enjoy a life of algorithm-free luxury."
In this episode, Justin Searls (open source author, speaker, and co-founder of Test Double) joins us in-person at Rails World to talk about his career, speaking, consulting, the One Person Framework, and building a web application for his wife's fitness business, Better with Becky.Follow JustinWebsiteTwitterMastodonLinkedInRelevant LinksThe Empowered Programmer talkTest DoubleBreaking Change podcastFred BrooksRubyKaigiThe One Person Framework
Justin Searls is a developer and the co-founder of Test Double. You can find his writing at justin.searls.co. You can listen to him on his podcast, Breaking Change. In this episode we dive into his experiences with the Xreal glasses, how the Mac integration in visionOS may long term hamper the Apple Vision Pro, the new APIs in visionOS 2 that enable camera access for enterprises, traveling with the Apple Vision Pro, and much more! This episode is sponsored by Agenda, the award winning app that seamlessly integrates calendar events into your note taking. Learn more at www.agenda.com. Agenda 19 is now available as a free download on visionOS, iPadOS, iOS, and macOS. Early episodes with chapter markers are available by supporting the podcast at www.visionpros.fm/patreon. Early episodes are also now available in Apple Podcasts!Show notes are available at www.VisionPros.fm. Feedback is welcomed at tim@visionpros.fm.Links: https://agenda.community/t/search-syntax-cheat-sheet/110704https://justin.searls.cohttps://justin.searls.co/posts/vision-pro-was-a-better-deal-than-my-mac-studio/https://www.xreal.com/us/Chapter Markers:00:00:00: Opening00:01:42: Support the Podcast00:02:17: Justin Searls00:09:31: Xreal Glasses00:13:30: Multiple Macs00:21:48: What is your work? 00:29:07: AirPlay Receiver and Continuity Features 00:39:38: Traveling with the Apple Vision Pro00:46:11: Typing on Apple Vision Pro00:51:59: Sponsor - Agenda 1900:54:12: Expectations vs Reality01:05:33: New Window Types01:05:47: The cost of Apple Vision Pro 01:10:50: Disappointments01:19:09: Mods01:25:38: Apple Intelligence01:40:29: Tethered01:42:02: Mac tweaks01:43:43: WWDC Announcements01:49:35: New APIs01:58:48: Real gaming02:04:56: visionOS 202:11:31: Anything else?02:13:58: Where to follow you online?02:15:37: Closing Hosted on Acast. See acast.com/privacy for more information.
Justin Searls joins us for hot takes on Apple's 2024 WWDC keynote. Apple Intelligence stole the show, but did it steal our hearts? Oh, and we learn all about Justin's Vision Pro Life and how he hopes/expects Apple's latest device to improve in future iterations.
Justin Searls joins us for hot takes on Apple's 2024 WWDC keynote. Apple Intelligence stole the show, but did it steal our hearts? Oh, and we learn all about Justin's Vision Pro Life and how he hopes/expects Apple's latest device to improve in future iterations.
If Changelog News had an extended edition, this might be it! Jerod & Adam discuss Hashicorp's Cease and Desist letter, Redis getting forked, Boston Dymanics' scary cool new robot, Justin Searls' extensive use of the Apple Vision Pro, Thorston Ball moving from Vim to Zed, Firefox becoming hard to use, Beeper joining Automattic & more.
If Changelog News had an extended edition, this might be it! Jerod & Adam discuss Hashicorp's Cease and Desist letter, Redis getting forked, Boston Dymanics' scary cool new robot, Justin Searls' extensive use of the Apple Vision Pro, Thorston Ball moving from Vim to Zed, Firefox becoming hard to use, Beeper joining Automattic & more.
Nikolay and Michael have a high-level discussion on all things search — touching on full-text search, semantic search, and faceted search. They discuss what comes in Postgres core, what is possible via extensions, and some thoughts on performance vs implementation complexity vs user experience. Here are some links to things they mentioned:Simon Riggs https://www.linkedin.com/feed/update/urn:li:activity:7178702287740022784/Companion databases episode https://postgres.fm/episodes/companion-databasespgvector episode https://postgres.fm/episodes/pgvectorFull Text Search https://www.postgresql.org/docs/current/textsearch.htmlSemantic search https://en.wikipedia.org/wiki/Semantic_searchFaceted search https://en.wikipedia.org/wiki/Faceted_searchFaceting large result sets in PostgreSQL https://www.cybertec-postgresql.com/en/faceting-large-result-sets/RUM index https://github.com/postgrespro/rum Hybrid search (Supabase guide) https://supabase.com/docs/guides/ai/hybrid-search Elastic https://www.elastic.co/ GiST indexes https://www.postgresql.org/docs/current/gist.html GIN indexes https://www.postgresql.org/docs/current/gin.html btree_gist https://www.postgresql.org/docs/current/btree-gist.html btree_gin https://www.postgresql.org/docs/current/btree-gin.html pg_trgrm https://www.postgresql.org/docs/current/pgtrgm.html Text Search Types (tsvector and tsquery) https://www.postgresql.org/docs/current/datatype-textsearch.html Postgres full text search with the “websearch” syntax (blog post by Adam Johnson) https://adamj.eu/tech/2024/01/03/postgresql-full-text-search-websearch/Understanding Postgres GIN Indexes: The Good and the Bad (blog post by Lukas Fittl) https://pganalyze.com/blog/gin-index ParadeDB https://www.paradedb.com/ ZomboDB https://www.zombodb.com/ Introduction to Information Retrieval (book by Manning, Raghavan, and Schütze) https://www.amazon.co.uk/Introduction-Information-Retrieval-Christopher-Manning/dp/0521865719 How to build a search engine with Ruby on Rails (blog post by Justin Searls) https://blog.testdouble.com/posts/2021-09-09-how-to-build-a-search-engine-with-ruby-on-rails/~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork
Jerod goes one-on-one with our old friend Justin Searls! We talk build vs buy decisions, dependency selection & how Justin has implemented POSSE (Post On Site Syndicate Elsewhere) in response to the stratification of social networks.
Jerod goes one-on-one with our old friend Justin Searls! We talk build vs buy decisions, dependency selection & how Justin has implemented POSSE (Post On Site Syndicate Elsewhere) in response to the stratification of social networks.
Changelog drops full-length musical albums in collaboration with Breakmaster Cylinder, Justin Searls on why the right tools fail for the wrong reasons, The Unix Sheikh says we have too many level of abstractions, Adam at PiCockpit compares the newly-announced Raspberry Pi 5 to the competition & Jorge Medina assures us that we're not lacking creativity, we're just overwhelmed by content.
Changelog drops full-length musical albums in collaboration with Breakmaster Cylinder, Justin Searls on why the right tools fail for the wrong reasons, The Unix Sheikh says we have too many level of abstractions, Adam at PiCockpit compares the newly-announced Raspberry Pi 5 to the competition & Jorge Medina assures us that we're not lacking creativity, we're just overwhelmed by content.
Changelog drops full-length musical albums in collaboration with Breakmaster Cylinder, Justin Searls on why the right tools fail for the wrong reasons, The Unix Sheikh says we have too many level of abstractions, Adam at PiCockpit compares the newly-announced Raspberry Pi 5 to the competition & Jorge Medina assures us that we're not lacking creativity, we're just overwhelmed by content.
Our friend Justin Searls recently published a widely-read essay on enthusiast programmers, inter-generational conflict & what we do with this information. That seemed like a good conversation starter, so we grabbed Justin and Landon Gray to discuss. Let's talk!
Our friend Justin Searls recently published a widely-read essay on enthusiast programmers, inter-generational conflict & what we do with this information. That seemed like a good conversation starter, so we grabbed Justin and Landon Gray to discuss. Let's talk!
Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! RubyKaigi (https://rubykaigi.org/2023/) WNB.rb (https://www.wnb-rb.dev/) Understanding the Ruby Global VM Lock by observing it by Ivo Anjo (https://rubykaigi.org/2023/presentations/KnuX.html#day1) gvl-tracing (https://github.com/ivoanjo/gvl-tracing) Justin Searls' RubyKaigi 2023 live coverage (https://blog.testdouble.com/field-reports/ruby-kaigi/) Prioritizing Learning episode (https://www.bikeshed.fm/362) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience? MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team. STEPHANIE: So, Mina, what's new in your world? MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer. STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough. MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs] STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether. [laughter] MINA: Well, I have a deadline, so... [laughs] STEPHANIE: That's true. When is your marathon race? MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit. STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs] MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes. STEPHANIE: That's true. You might have to come back on as a guest. [laughs] MINA: Just to talk about how it went. [laughs] STEPHANIE: Yeah, exactly. MINA: So that's what's new with me. What's new in your world, Steph? STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project. And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating. MINA: [laughs] STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together. MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff. STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance. MINA: [laughs] STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting. MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people. STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs. MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question. STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours. MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option. STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs] MINA: Yeah, it's a ChatGPT situation. STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do. WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB. MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me. STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity? MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer. So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice. STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev. MINA: I highly recommend doing that. STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting. MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected. STEPHANIE: Could you elaborate on what was surprising about the way that it was technical? MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting. STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat. Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language. MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs] STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs] But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes. But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise. MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool. STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs] MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run. STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it. As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of. But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation. And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi. MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like. STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort. And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions. MINA: Yeah, I think they call that peer review in the academic circles. STEPHANIE: [laughs] That's fair. MINA: [laughs] STEPHANIE: Was there anything else that you really enjoyed about the conference? MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference. STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning. MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier. But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment. STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally. I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called. But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S. I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available. MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale. STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing. MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs] STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference? MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that. And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge. STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out. I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation. I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know -- MINA: [laughs] STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus. MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet. STEPHANIE: That's very real as well. MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience? STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things -- MINA: [laughs] STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be. And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so -- MINA: For sure. STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be. MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful. STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference. MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well. STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else. MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up. But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know. STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience. MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences. STEPHANIE: Yeah, well said. On that note, shall we wrap up? MINA: Let's do it. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.
On this episode of Remote Ruby, Jason, Chris, and Andrew begin by sharing their thoughts on some shows they're watching such as “White House Plumbers,” “Curb Your Enthusiasm,” and “Seinfeld.” The conversation then shifts towards the exciting release of Ruby 3.3 Preview 1, which focuses on performance improvements for YJIT and the introduction of compiler RJIT. They dive into the challenges of implementing autosaving and error display forms using Turbo and Hotwire in Rails. Then, the conversation takes a turn towards serverless function, with Andrew sharing his experiences using Vercel, and a discussion on Hatchbox and Fly for hosting applications, and the appeal of PlanetScale for databases. Go ahead and press download now to hear more! [00:00:20] The guys discuss a few shows they're watching. [00:05:10] Chris announces the exciting release of Ruby 3.3 Preview 1, which introduces performance improvements for YJIT, and introduces the RJIT. [00:07:11] Jason brings up an interview with Aaron Patterson that Justin Searls did at Ruby Kaigi 2023 where he talked about two people working on different parsers which could benefit alternative Ruby implementations.[00:09:38] A conversation came up somewhere about Laravel being a feature-rich framework, while Ruby is considered a better language.[00:10:59] Jason brings up the challenge of implementing autosaving and displaying errors in a form using Turbo and Hotwire in Rails. Chris mentions morphdom as a solution which can help with preserving focus during form updates.[00:16:23] Chris talks about autosaving features as a standard in modern web applications, and the need for built-in solutions within Rails is emphasized to simplify the implementation process.[00:22:00] Andrew shares his frustrations with implementing autosaving and validations.[00:25:55] Andrew explains what he was doing with functions in Vercel.[00:28:00] Jason brings up talking to Crunchy Data at RailsConf and the appeal of Planet Scale for databases. [00:30:40] Hatchbox and Fly for hosting applications is discussed and plans for upgrading Ubuntu versions and Hatchbox features.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterWhite House Plumbers (HBO MAX)Curb Your Enthusiasm (HBO MAX)Seinfeld (Netflix)Ruby Kaigi 2023-Aaron Patterson Interview (YouTube)morphdom-GitHubRemote Ruby Podcast-Episode 178: José Valim, creator of Elixir and former Rails core contributorVercelCrunchy DataPlanetScaleHatchboxFlyUbuntuBuild and Learn Podcast by CJ Avilla and Colin LoretzRuby Radar TwitterRuby for All Podcast
Listen to Brittany Martin (The Ruby on Rails Podcast), Jason Charnes (Remote Ruby) and Paul Bahr (Peachtree Sound) as they interview guests from the community on a live podcast at Railsconf 2023 in Atlanta, GA. Guest #1: Aaron Patterson, Senior Staff Engineer at Shopify (https://twitter.com/tenderlove) Guest #2: Irina Nazarova, CEO of Evil Martians (https://twitter.com/inazarova) Guest #3: Voted on by the community in an online poll: Justin Searls, Meta Programmer at Test Double (https://twitter.com/searls?lang=en) Guest #4: Voted on by the community live at this session: Britni Alexander, Senior Software Engineer (https://twitter.com/TwitniTheGirl) Our Vanna White of Guest Selection: Danielle Greaves, Lead Web Developer, Pittsburgh Cultural Trust (https://twitter.com/danigirl329) Show Notes: A Ruby Community Podcast Live! | Railsconf 2023 (https://railsconf2023.sessionize.com/session/471526) Peachtree Sound (https://www.peachtreesound.com/meet-paul) Substitute Teacher - Key & Peele - YouTube (https://www.youtube.com/watch?v=Dd7FixvoKBw) Keynote - Aaron Patterson | Railsconf 2023 (https://railsconf2023.sessionize.com/session/471439) Rails as a piece of birthday cake | Railsconf 2023 (https://railsconf2023.sessionize.com/session/452834) Evil Martians (https://evilmartians.com/) N.E.A.T. (Not Everything's About Technology) (https://testdouble.com/neat) Justin's Field Report from RubyKaiji (https://testdouble.com/field) Hire Britni! | LinkedIn (https://www.linkedin.com/in/britnia) Sponsored By: Honeybadger (https://www.honeybadger.io/) You won't know if Honeybadger will really save you time and trouble until you see how it works in your own toolchain. With two lines of code and five minutes, you can see for yourself. Honeybadger automatically hooks into popular web frameworks, job systems, authentication libraries, and front-end JavaScript. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!
This is a special episode from RailsConf 2023 Atlanta, where we're having a Ruby Community Podcast LIVE! Today, we have on the panel Brittany Martin, Co-host of The Ruby on Rails Podcast, our very own Jason Charnes, and Paul Bahr, Audio Editor from Peachtree Sound, who edits over a dozen tech podcasts. We also have some great guests joining us: Aaron “tenderlove” Patterson, Irina Nazarova, Justin Searls, and Britni Alexander, who was selected by the audience to be our fourth guest. Today, our guests share some stories about who they are and what they do, give shout-outs, and answer questions from our audience. Hit download now to hear more! [00:04:30] We start with Aaron “Tenderlove” Patterson, sharing the origin of his nickname. [00:06:05] Since Aaron has switched companies over the years, he tells how his job has changed a lot, and how he spends one hundred percent doing open source at Shopify. [00:08:05] A question from the audience comes up on what Aaron is looking most forward to working on this year. He mentions some spoilers. [00:10:38] Since Aaron has been working Ruby and Rails for so long, Brittany asks if there's ever been a community that may have tempted him to leave. His answer is no. [00:11:44] Aaron leaves us with a shout-out to Mushroom Hunting since he is a mycologist. [00:12:46] Our next guest is Irina Nazarova, co-founder of Evil Martians, who tells us she had a dream that Brittany would invite her on a podcast. [00:15:44] Irina explains that consulting allows them to understand user needs, which they use to build useful tools.[00:16:44] She explains the open source products they build are a byproduct of consulting work, and they allocate resources to work on them once they show traction.[00:18:44] The focus here is on startups and if she recommends Ruby and Rails to startups. [00:19:51] An audience question comes up for Irina on how does Evil Martians foster the environment for a great company blog? She tells us about her great editors and the blog articles that bring value to the company. [00:21:23] Irina makes a shout-out for people to support Ukraine during the war.[00:23:18] Next, we have joining us Justin Searls, co-founder of Test Double, and Britni Alexander, former employee at Mailchimp. They introduce themselves and tell us a little bit about what they do. [00:27:48] Justin discusses his favorite talk he's given, “How to Scratch an Itch.”[00:29:14] Britni tells us her ideal job and her struggle to balance being kind and direct. [00:30:05] Justin tells us about an upcoming project called, N.E.A.T, which is focused on discussing ways to make software better that are not related to technology. [00:32:15] Britni talks about what her ideal job would be. [00:33:05] We hear about the RubyKaigi conference in Japan and Justin's plans to attend and report on it. [00:35:30] Britni gives a shout-out to her friend Eileen for being her friend, and Justin expresses his gratitude for the opportunities and connections he's gained through the Ruby community. Moderator:Brittany MartinPanelists:Jason CharnesPaul BahrGuests:Aaron PattersonIrina NazarovaJustin SearlsBritni AlexanderSponsor:HoneybadgerLinks:Jason Charnes TwitterBrittany Martin TwitterThe Ruby on Rails Podcast Aaron Patterson TwitterTenderlove Making ShopifyIrina Nazarova TwitterEvil MartiansJustin Searls WebsiteJustin Searls TwitterTest DoubleTest Double N.E.A.T. communityHow to Scratch an Itch-Justin Searls talk at ng-conf (YouTube)Britni Alexander LinkedInRubyKaigi 2023RubyKaigi 2023 Field Report Blue Ridge Ruby 2023
Ruby For All – Episode 32On this episode of Ruby for All, it's raining a lot by Julie, chilly outside by Andrew, and Andrew's birthday is this week! Happy Birthday, Andrew! Since it's a new month, Andrew and Julie decided to talk about debugging. So today, they'll be discussing various debugging tools for troubleshooting Rails applications such as binding.irb, binding.pry, puts debugging, the new debug gem, web console, RubyMine, and VS Code debugger. Also, they talk about when to bring in help when a problem has taken too long, and they share advice on the importance of not assuming the cause of the problem, isolating the issue, and taking breaks. Debugging can be difficult and hard to figure out what happened, but always remember, practice makes perfect! We hope you enjoyed this episode! Hit the download button now! [00:01:23] Andrew is ready to go and asks Julie what she does when she gets that red Rails error screen, and he tells us he reads in chunks.[00:02:11] What debugging tools does Julie use? She explains using binding.irb or binding.pry. Andrew tells us he uses pry a lot, and some others are puts debugging, a new debug gem that's in Ruby 3, and Web Console.[00:06:15] We hear about the debugger, RubyMine and the new debug gem that Andrew likes. He tells us he's huge binding.pry user since it comes naturally to him, and there's a video by Justin Searls you should check out. [00:07:37] Has Julie ever run into a bug that fixes itself when you restart the server? What did Julie do? Andrew brings up the spring gem that he's used, but it didn't work the way he wanted it to. [00:09:12] Julie shares an instance where she worked for hours on a bug, finally give up, walked away, went to bed, came back, and it was fixed. [00:12:32] Andrew has one more thing to tell us relating to doing puts debugging, and he tells us what he likes to do using ActiveSupport Deprecation.[00:14:11] Using Sandbox mode is brought up which is a great way if you're debugging in production, and Andrew tells us one of the hardest parts of debugging is recreating a certain thing and brings up a problem a customer who had with a bug and asked Julie where she would start. Andrew shares a third party service nightmare story with a debugging adventure. [00:17:48] Julie brings up a great question and wonders at what point do you bring another team member on to help you debug. [00:21:20] Julie and Andrew discuss using different browsers to figure out things.[00:24:28] As a junior, Julie doesn't look at the network tab and the log and wonders if Andrew looks at them. He explains he uses the debugging tools in the browser and the network tab all the time. Panelists:Andrew MasonJulie J.Sponsors:GoRailsHoneybadgerLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. Websiteputs_debuggerer 0.13.1debug.rbWeb ConsoleRubyMineSetup ruby/debug with VSCode by Stan LoDebugging Ruby on Rails with Visual Studio Code by Justin SearlsSpring 1.7.2ActiveSupport DeprecationRuby for All Podcast-Episode 4: Getting Unblocked
Welcome to 2023 — we're kicking off the year talking to Justin Searls about the state of web development and why he just might write a “You Might Not Need React” post. He's been so productive using Turbo and Stimulus (and tailwind) in Rails 7 that we had to talk about the state of Rails development today and a bunch of other fun topics around building for the web in 2023.
Welcome to 2023 — we're kicking off the year talking to Justin Searls about the state of web development and why he just might write a “You Might Not Need React” post. He's been so productive using Turbo and Stimulus (and tailwind) in Rails 7 that we had to talk about the state of Rails development today and a bunch of other fun topics around building for the web in 2023.
Justin Searls on TwitterMatt Swanson on TwitterArrowsTest DoubleJustin's "What do you like about RSpec" thread (2016)Dan North BDDNate Berkopec "Reading rspec documentation like..." tweetCorey Haines: Fast Rails TestsKent Beck: "I get paid for code that works, not for tests..."Nick Quaranto's minitest CLI wrapperMocktail gemtest_data gem
When your engineering team grows from 10 to 100 engineers in the course of a year, there are so many things that you need to focus on, from operations and developer tooling to testing. Maintaining the health of the application is perhaps the most difficult part of all. Where exactly do you start?We sat down with Justin Searls, the co-founder and CTO of the Test Double agency. For many years, Justin has been consulting organizations on how to best tackle team's growth and ensure that good practices are in place when teams grow. We talked about how to grow engineering teams without losing sanity, how to divide work without stepping on one's toes, and keep your test suite maintainable.You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) Why has trust become so rare in the software industry? Developers don't trust their own ability to program, teammates don't trust each other to write quality code, and organizations don't trust that people are working hard enough to deliver on time. This talk by Justin Searls is a reflection on the far-reaching consequences distrust can have for individuals, teams, and organizations and an exploration of what we stand to gain by adopting a more trustful orientation towards ourselves and each other. 01:57 - Justin's Superpower: Having Bad Luck and Exposing Software Problems 04:05 - Breaking Down Software & Teams * Shared Values * Picking Up on Smells to Ask Pointed Questions * Beginner's Mindset * RailsBridge (https://www.bridgetroll.org/) 12:49 - Trust Building * Incremental Improvement * What Got You Here Won't Get You There: How successful people become even more successful by Marshall Goldsmith (https://www.amazon.com/What-Got-Here-Wont-There/dp/1846681375/ref=asc_df_1846681375/?tag=hyprod-20&linkCode=df0&hvadid=312118059795&hvpos=&hvnetw=g&hvrand=6049806314701265278&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9006718&hvtargid=pla-525029467829&psc=1) * Credibility * Reliability * Intimacy * Selfless Motivation * Authenticity * Detecting Authenticity * Laziness Does Not Exist (https://humanparts.medium.com/laziness-does-not-exist-3af27e312d01) 29:14 - Power Politics & Privilege * Leadership Empathy * Safety * Exposure; “Don't Cross The Net” * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 42:06 - Personal Growth & “Bring Your Whole/True Self” * RubyConf 2019 - Keynote: Lucky You by Sandi Metz (https://www.youtube.com/watch?v=c5WWTvHB_sA) How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers based in the United States and Canada. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JACOB: Hello and welcome to Episode 270 of the Greater Than Code podcast. My name is Jacob Stoebel and I'm joined with my co-panelist, Mae Beale. MAE: And I'm joined with another panelist, Chelsea Troy. CHELSEA: Hi, I'm Chelsea and I'm here with our guest, Justin Searls. He's a co-founder and CTO at Test Double, a consulting agency on a mission to improve how the work writes software. His life's work is figuring out why so many apps are buggy and hard to use, why teams struggle to foster collaboration and trust, and why it's so hard for organizations to get traction building great software. The Test Double Agents work with clients to improve in all of these ways and more. Hi, Justin! How are you today? JUSTIN: Hello. I'm great. Thank you so much for having me. CHELSEA: Of course. So we like to kick off our sessions by asking you, what is your superpower and how did you acquire it? JUSTIN: Well, one superpower might be that I like to give counterintuitive answers to questions and [laughs] my answer to this would be that I have really, really bad luck software and hardware. My entire life has just fallen over for me left and right. Bugs come and seek me out. In college, I was in the computer science program and so, I was around a lot of computers, like Linux data centers and stuff, and I think I went through either personally, or in the labs that I used 20 hard drive failure years in 4 years. People started joking that I had an EMP around me. So I started to just decide to lean into that not so much as an identity necessarily, but as a specialty of root cause analysis of like, why do things fail? When I see a bug, what does that mean? And to dig in to how to improve quality in software and that then extended to later in my career, when I was working on delivery teams, like building software for companies and institutions. That meant identifying more root causes about what's leading to project failure, or for teams to break down. Now I'm kind of moving, I guess, popping the stack another layer further. I'm starting to ask what are the second and third order consequences of software failing for people having for others? I see this in my family who are non-software industry family members, when they encounter a bug and I'm watching them encounter a bug, their reaction is usually to think that they're the ones who screwed up, that they're stupid, that they just can't figure it out. I'm literally watching software that somebody else wrote far away just fail and that's just no good, right? So I think that the fact that I just so easily expose problems with software and sometimes the teams that make it almost effortlessly, it's really given me a passion and a purpose to improve and find opportunities to just make it a little bit better. MAE: When you talk about software and/or teams breaking down and you're mentioning bugs. So I'm assuming that that's mostly what you mean by breaking down? I'm curious if you have kind of a mental model of software always breaks down these four ways. Teams always break down these three ways. I don't know if you have any reference texts, or things that you've come across as far as like a mental model for what is the world of breaking down? How do we characterize it? JUSTIN: That's a great question and I feel like having been basically doing this for 15 years now, I should be prepared with a better answer. I've always resisted building I guess, the communicative version of an abstraction, or a framework for categorizing, simplifying, and compartmentalizing the sort of stuff that I experience. In some ways, my approach [laughs] is the human version of machine learning where I have been so fortunate, because I've been a consultant my entire career, to be exposed to so many companies and so many teams that that has developed in me a pattern recognition system that even I don't necessarily understand—it's kind of a black box to me—where I will pick up on little smells and seemingly incidental cues and it'll prompt me to develop a concern, or ask a pointed question about something seemingly unrelated, but that I've come to see as being associated with that kind of failure. I think your question's great. I should probably spend some time coming up with quadrants, or a system that distills down some of this. But really, when I talk about bugs, that is a lagging indicator of so many things upstream that are not necessarily code related. One of the reasons I want to be on the show here and talk to you all the day is because I've been thinking a lot about trust and interpersonal relationships starting with us as individuals and whether we trust the work that we're doing ourselves, or trust ourselves to really dive in and truly understand the stuff that we're building versus feel like we need to go and follow some other pattern, or instructions that are handed to us. To kind of try to answer your question more directly, when I see teams fail, it usually comes down to a lack of authentic, empathetic, and logical targeted relationships where you have strong alignment about like, why are we in this room? Why are we working together? How do we best normalize on an approach so that when any person in any role is operating that is consistent with if somebody else on the team had been taking the same action that they would operate in the same way so that we're all marching in the same direction? That requires shared values and that requires so many foundational things that are so often lacking in teams as software is developed today, where companies grow really fast. The pay right now is really, really high, which is great, but it results in, I think a little bit of a gold rush mentality to just always be shipping, always be hustling, always be pushing. As there's less time for the kind of slack that we need to think about—baking in quality, or coming back to something that we built a couple weeks ago and that maybe we've got second considerations about. Because there's that kind of time, there's even less time sometimes for the care and feeding that goes into just healthy relationships that build trust between people who are going to be spending a third of their life working together. CHELSEA: You mentioned picking up on little smells that then lead you to ask pointed questions. I think that's really interesting because that kind of intuition, I've found is really essential to being a consultant and figuring out how to ask those questions as well. Can you provide some examples of situations like that? JUSTIN: Yeah. I'll try to think of a few. I had a client once that was undergoing—this is 10 years ago now—what we called at the time, an agile transformation. They were going from a Waterfall process of procuring 2 year, $2 million contracts and teams to build big design upfront systems that are just thrown over a fence, then a team would go and work on it, and then it would go through a proper user acceptance testing onto something more agile, I guess. Adopting Scrum and extreme programming, interpersonal process, and engineering practices. That was just meant to be more, I guess, iterative of course, innovative, collaborative, more dynamic, and able to let the team drive its own destiny. All that sounds great and you walk into the team room and they just invested millions of dollars into this beautiful newly restored historic building. I sit down with everyone and I look at them and they've got the cool desks at the time and cool open office because those were still considered cool. I sat down and I couldn't help, but—[chuckles] this is real silly. I couldn't help but notice that there was a pretty strong smell, [laughs] body odor throughout the whole room and it wasn't one person. I'm not picking on somebody here. It was that the interpersonal relationships were so afraid, the fear of failure was so strong, and the deadline pressure that had been exerted from on high was so overwhelming that there was no safety in the room. People were just scared at their job all day long and it was having a material impact that only an outsider who's walking in at 2:00 PM on a Friday detect because everyone else had acclimated. So I walked in and I was like, “Well, what do I –?” [laughs] Obviously, I'm not going to be like, “Hey, it stinks in here.” I've got to figure out a way to understand why do people feel unsafe and maybe I didn't have that sentence go through the voice in my head, but it definitely put me on a path towards to maybe the less privileged people in the room, the people who are not the managers to understand what's really going on, what pressures are they under? MAE: I love that the example includes legit real smell. So many times, especially in our industry and part of what this podcast is counteracting, is getting in touch with the fact that we are people and humans. Anyway, I love that you brought [chuckles] that home that way. Also, I wanted to say from earlier, I wasn't trying to corner you into expecting to have a philosophy. I thought you might and it was worth asking. But I recently got asked a similar question about my management philosophy and which authors do I appreciate most, or something. I've been a manager for 25 years and I'm like, “Uh. I don't know. I figure out what is needed and then I deal with that.” I don't understand how to answer. So I just want to give some – pay you back and apologize. I didn't mean to get you – [overtalk] JUSTIN: Not at all and it becomes one of those you know it when you see it. I struggle with this a lot because somebody introduced the concept years ago of beginner's mindset to me where sometimes if I'm a beginner at something, the best person to help me is not the expert—the person who's been doing it for 20 years. It's somebody who's just a few hours, or a few days, or a year, or two ahead of me because they can still remember what it felt like to be where I am right now. Because I talk a lot, because I tweet a lot, because I show up in a lot of places, and I have an outward facing sales role to potential clients and candidates, I meet a lot of people who come to me and they're like, “How do I learn how to code?” And I'm like, “I can tell you the 15-year version of this story, but it's probably going to be really depressing.” I've taken as a responsibility to like try to—and I need to do a much better job of this—be armed with either resources, or people that I trust, that I can refer folks to so that I'm not totally leaving them hanging. MAE: I love that and yes. Speaking of teaching people how to code and what you said, there's a name for it that I'm forgetting about being a teacher. If you are closer to the student, you actually are a more effective teacher. So there's just two comments. The first one is I'm a part of RailsBridge I helped found the Southeast regional chapter. So if anybody, any listeners out there still want to learn how to code, or are having that same, I don't know how to tell you about my [chuckles] zigzag story and ideally, they wouldn't all be depressing, [laughs] but I'm sure they all include some real low moments. But RailsBridge, which is bridgetroll.org, has recurring events where people can go all over the country and obviously, in pandemic times it's not as much in person, but yeah. And on the comment about teaching and when you mention talking to the people with the least privilege in the room, I'm just really sensitive and appreciative of your sensitivity to power politics and how much they impact so much of what is happening and trust. So for anybody out there who's being asked to help new people and you feel like you're still the new person, you're probably in a better position to help. So just want to offer some encouragement there. I have personally found a lot more confidence in helping people who are just behind me and that anytime you're teaching, you're learning. So just want to put those in. I love that actually your answer, instead of a quadrant, is really just the one word of trust and I appreciated the ways in which you were mentioning trust can be different things. Trust in what you're building. Trust in who's asking you to do it. Chelsea asked for a couple examples and I interrupted. So I apologize, but what are some trust building exercises that you have encouraged, or examples? Maybe even continuing that same story. Six months later, was it a fresher air in there and what are some things they did to make that happen? JUSTIN: Yeah, that story, like so many teams and companies in our industry, didn't undertake the redemption arc that I wish I could convey. I think in fact, to see a big picture problem and the desire to connect that with a big picture tidy solution, a future state where it's all rainbows and unicorns and everyone really getting along well. Sometimes that sets, for me personally and when I see consultants who are less experienced, who can see that end state in mind and they know maybe the top three hit list of stuff that needs to happen to help that organization get to where they need to be. We can sometimes set the bar so high for ourselves in terms of expectations of like, what does it mean to help them become better, that we can't help, but lose sight of the value of just incremental improvement. If I can just help restore relationship between two people on a team. I had one client years and years ago, [laughs] they were also undergoing a pretty big transition and they brought me in a – I think that what they thought they were hiring me for was to be a test-driven development coach to teach them that particular practice of TDD. They got, instead on day one, there was a room of 30 interdisciplinary cross-functional teams—some developers, some non-developers, and stuff—and I could just tell that they were like, it was a big epic rewrite from a Perl codebase that, I think they were moving to no JS and Angular as well as a chewing of cloud infrastructure at the same time, as well as Agile software practices at the same time. They were overwhelmed, they've seen this fail before, they felt a ton of pressure from the business, and they didn't even really understand, I don't think, the future business model. Even if they were successful, it wasn't clear this was going to solve systemic problems for the company. And I'm like, “Well, I can teach you all TDD. [laughs] But instead what my commitment to you all will be is that six months from now, you'll either have been successful and learned all of these things and built the thing as the business has asked you to do and then the business takes off, or I will have helped equip you with skills and ways of thinking about this industry and our work that will set you up to get much better jobs next time.” Again, the company didn't totally come together. It didn't take off like a rocket ship. The team was successful in the rewrite, which doesn't happen very often. But then you saw almost a diaspora of dozens of highly skilled people—and this was in Central Ohio—who then went to venture backed startups, some went to big, established enterprise-y kind of companies, some left the region and went elsewhere. That turned into, if I had to count, probably eight, nine additional Test Double clients [laughs] down the road where they came in and they could spot in a minute, this is a way that an outside perspective, who is here to help us at a moment of tremendous need, can move the needle just a little bit. By setting expectations realistically, being humane about it, and focused on what's best for the people involved because at the end of the day, all companies are is collections of humans. That was, I guess, more my orientation. CHELSEA: So Justin, I'm interested in your thoughts on this. I appreciate what you just shared. I worked at Pivotal Labs for a while—original labs when it was sort of a generalist's enablement. JUSTIN: Sure. CHELSEA: Very heavy on that kind of thing. One of the things that we ran into relatively frequently was similar to what you've just described wherein one of two things would happen. Either the clients were successful and there was a vastly improved, I guess, software delivery culture among the people that we were working with, or if that didn't work out, then there were individuals who took to it very well and had gained variety of skills that allowed them to go elsewhere. It happened enough times that then we would have to establish trust with potential new clients around this whole additional access, which was effectively, is this going to cause a diaspora of all of these engineers, designers, and PMs that I've managed to scrape together for this project? Do you find Test Double ever facing that, or how do you address either beforehand if product owners are aware of it, or after it happens, how do you address that with clients? JUSTIN: That's a fantastic question. Pivotal Labs was one of the companies that we looked at. We started Test Double 10 years ago. I was at the time, just starting to speak at user groups and conferences and I spent a lot of time with the people at the Boulder office at Pivotal Labs. Great people. I really appreciated the focus and the rigor and in fact, made to answer a question earlier about process, or abstraction about like, “Hey, boil it down for me.” Pivotal Labs sold a very branded, very discreet process for like, this is the way to build software and, in a sense, some of the decisions that we made when we started Test Double were a response against that. Just to say we trust the people closest to the work to make the right decisions based on tremendous experience and skills. Frankly, as we get bigger and more successful, having some somebody like me at the top of an organization who only talks at the beginning of a client relationship, which is the moment that we know the least and I've got the least amount of context, for me to go and say, “Well, this is the way that we got a test,” or whatever it is would just be ineffective and inappropriate. So to answer your question, Chelsea. Fortunately, our brand power, isn't nearly as strong as Pivotal Labs so no client has ever come to us in advance with that as a question to say, “Hey, I'm worried that you're going to train our people in this particular methodology and then they're going to leave for higher paying jobs,” or something. That's never come up in advance. In fact, one of the things that we talk a lot about is that because our consultants join client engineering teams to work with them inside of their own process, using their own tools, and their own system is we just try to be model citizens of somebody on that team. We trust our clients like, “Whatever your process is, it's apparently working for you. So let's just try it and if we have ideas for how to make that better, we will listen, we'll write them down.” But then only once we've built trust and rapport with the people on that team, will we start to share, “Hey, I've got a rainy-day list of a few things that you might want to try.” What that's actually done is has a detoxifying effect where from a context of high trust, the incongruity, the distrust, the kind of backchannel frustrations that our people pick up on because we're kind of “in the trenches” with our client folks, we're able to have multiple pathways into that client organization to help make it a better place to work. We got one of the best poll quotes that I've ever seen on our website recently. One of our clients is Betterment. They're a great financial management firm in New York where it's kind of an autopilot savings vehicle. The director of engineering, Katelyn, there said that she saw on the teams where testable people were deployed, attrition actually went down and I think it's because we help those teams to perform better. An old friend of mine named Leon Gersing, he used to have a thing he'd say. He'd said, “You can either change where you work, or you can change where you work.” Meaning you can either make the place that you're at better, or you can go find gainful employment elsewhere and we're in the make the place where people work better business, wherever possible as a first avenue. MAE: You're reminding me of a book that I'm reading right now called What Got You Here Isn't Going to Get You There. Are you all familiar with it? JUSTIN: I was so proud of my wife, because she asked for that on Audible earlier this week because I'm the person with the Audible credit and I'm like, “Oh, this is quoted in business leadership contexts left and right and all over the place. So it'll give us a touchstone to talk about.” MAE: Yeah. Well, the TLDR is so much of especially management focused and leadership focused thought is about things that you should do and this book is probably along your lines, Justin of giving the counterintuitive answer. This is here's 20 things that you might want to consider not doing and then replace it with the good behavior because that is such a stretch in real life to actually do that. It's how about you just pick a couple of these that you're a repeat offender and just stop. Just try to not do it. That's the main first thing and I've found that, a refreshing take on how to think about how to guide in ways that are building more trust and offering more safety. So definitely recommend that book. I don't know that it came out of this book, but the person who recommended it to me, my VP Scott Turnquist, who is amazing, shared that there are really four categories of things that can help build trust and it's definitely all done incrementally. So picking up on that word you said earlier, Justin, too. But the four kind of axes are credibility, reliability, intimacy, and selfless motivation. If you can demonstrate those recurringly, that is how to establish and/or course correct into a state of increased trust. So anyway, that was partly why my original statement was like, do you have this down? Because I've heard some things lately that I've been thinking about. JUSTIN: I really appreciate your perspective there and it makes me feel better because one of my commitments in life is to never write a book. But if I were to write a book, I'd probably have to come up with a tidy quadrant, a Harvard Business Review two by two, or something like that to I guess, support the good work at the people at CliffsNotes and Blinkist to boil down years' worth of work into a 13-minute podcast. I think that the advice as you expressed, it is completely valid and there's one thing that I think is a core ingredient to trust. Trust of ourselves, trust of people that we work with directly, and then trust of leadership and the people who run the organizations that we're a part of. The hardest, in my opinion, is authenticity. If you're not, I think you said credible. If you combine credible, intimacy, vulnerability, those are really useful words to prompt what I mean when I say authenticity. If I'm talking to somebody and I can lock eyes with them and I believe that what they're saying is what they actually feel and it's their true self and they believe it, then all sorts of other background processes in my head of trying to read the tea leaves of what's going on here, all the passive analysis I might do to try to understand what's the subtext that this person's operating from. That's just the form of kind of armor, or a guard that it depletes my cognitive ability to talk to the person. Authenticity is a signal that we pick up on as humans and this is why it's a miracle that we have video chat in this era and it's why I really relish one-on-one in-person interactions when I can have them. Authenticity is a signal that I can drop that guard a little bit. It's that I can really look and really listen to what the person's saying and take it at face value. The problem with just saying, “Oh, okay, well just be authentic. Just be your true self,” is that that is useless advice and way more likely to trigger somebody's defenses, or their self-doubt. When I think about authenticity in the context of a team, or an organization is that the people who are maybe not in a position of power, people who report up the chain, if they don't come across as authentic to their leaders, the leaders should not look at that as a failing of the person, but as a failure of their ability to figure out how to promote and draw out authenticity from the people who report to them. Maybe they don't have safety in the room to speak their true mind. Maybe they feel like the things that make them different from the other people that they work with are a liability, or a risk and so, they can't really bring their true self to work. It's the leader's job, when they spot inauthenticity, rather than go on a hunt like a political backchannels to try to figure out why is this person lying. What's under here? Figuring out what is it about the person's context, the environment, kind of the system that they are operating in. What could possibly be an explanation for why I can't develop an authentic connection with this person? And until you run out of every single possible explanation in that investigation, including self-reflection of what is it that I'm individually doing and how I communicate to this person that's getting in the way. Only then is it really useful to start thinking about maybe this person's not a good actor, maybe they're being duplicitous, or something. Because once you've hit that button, it is really hard to go back. So when we talk about authenticity, we often talk about the individual's responsibility to present it, to be it. If you can fake authenticity, then you can do anything, right? That is advice. It's fine. I hope that everyone feels the safety. Like I'm a cishet white dude who's pretty powerful in my little corner of the small pond. I have no problem just spouting off and being my true self and so, I should just tell other people to do that too. That's not fair. I think that what is better advice for people who are maybe not in positions of power is to be really good at detecting authenticity. When you detect authenticity and people are making their true selves known to you and you're feeling a connection with them, whether they're peers, or managers, spend more time with them, invest into those relationships, and use those people as anchors of trust. So that when you're failing to make that connection elsewhere, when you have doubts about others in the organization, you can have more points of perspective on how to best address it. MAE: I read an article yesterday that says, “Laziness Doesn't Exist.” That's the title of it and it essentially says that that same thing of what's the context in which this is happening. People don't procrastinate for fun. In fact, it usually takes more work and starting from a place of what shoes are you in, but I especially love the in what way am I impacting that person's ability to be themselves? Also, I must have said the word authenticity, because this list is credibility, reliability, intimacy, selfless motivation, but authenticity and credibility in all of these things do also have to do with the thing that I loved you bringing up about identity, power politics, and what happens and your environment is not allowing you to be credible. So another way in which people can as good peers, mentors, managers, and above can do is in what way am I bolstering these people's credibility? So always flipping it back to how are we the perp [laughs] and that's very similar to social justice, racial justice. The more we see how we are perpetuating and disenfranchising, regardless of our identity, that's where there's some hope for the humans in my mind. CHELSEA: Yeah. One of the things that I appreciate that you've both brought up, Justin and Mae, is the degree to which power gradients play a role in the way that we deal with these things. There are demographic power gradients with regard to race, with regard to gender. There are also power gradients with regards to our position in the company, with regard to technical privilege, with regard to our level of skill, with regard to the size of our network. We also, I think live in this individualist culture that has a tendency to place the responsibility on individuals to do what they can to resolve. For example, what you were saying, Justin, about how we effectively coach people to just be authentic. Maybe that coaching works fine in some context, but that's a subset of the context in which we're asking people to apply it and asking individuals to resolve this from the bottom up sometimes as opposed to looking for the systemic reasons why this is a thing that has to be solved in the first place. I'm curious as to whether you have thoughts on what a person can do, who finds themselves in a position of power, in a position of leadership in a company, for example, to address those sorts of questions with other folks who are working there. JUSTIN: I think one thing that can be helpful – and I realize your question is about what can a leader do. One thing that can be helpful is for those leaders to empathize and put themselves in the shoes of people who might not have the same privileges as you described and what would it take to—I'm waiting outside my area of expertise here—would be to think about what are the things that are in a given person's sphere of direct control, what isn't, what am I setting up, and what am I communicating in terms of expectations that I have of them? An example that came up a lot in our industry was the number of drink up events in tech in the early 2010s where there was sort of an assumption that everyone likes alcohol and when people in public drink alcohol, good things happen, which turns out isn't true, but it can also be the case. There are invisible expectations that we communicate because I'm a big fan of granting people autonomy to solve problems in their own way, to approach work the way that they feel is best. Our company has been remote from day one and a big part of that was we want people in control of everything from where they work to their home network, to the computers that they use. Because when I had that control pulled away from me in the role as developer, it just sapped my motivation, my drive, my engagement, my sense of control over the stuff that's right in front of me. When I now in a role of influence over other people, whenever I speak, I have to think about the negative space of what are the expectations that I might be conveying that are not explicit. I need to be careful of even expressing something like hobbies, or shows that I like, or stuff – especially in this remote world, we want to develop connectedness. But a challenge that I keep running into is that our ability to find mutual connection with people about stuff other than work, it rides the line really closely of communicating some other allegiance, or affiliation whether that's we talk about sports a lot because that's an obvious one, but even just interest in hobbies. So I find myself – and I realize Chelsea, I'm doing a really poor job, I think of answering the question as you asked it. I find myself only really able to even grapple with like what can leaders do to set the tone for the kind of environment that's going to be inclusive and safe for other people by really digging in, empathizing with, calling up, and dredging up what their own experience was when they were not in a position of power. If I have a secondary superpower, is I had a real rough start to my career. I was in really, really, really rough client environments that were super hostile. I had a C-level executive at a Fortune 500 company scream at me until his face was red in a room one-on-one with a closed door on a regular basis. The sorts of stuff that developed callus on me, that I look back at a lot of those experiences and I'm like, “I learned a bunch.” It's supercharged my career as an individual because it strengthened me. So the challenge that I have is what can I take from those really, really harsh experiences and translate them for people who are coming up in a way that they don't have to go through the same trials and tribulations, but that they can take away from it the lessons that I learned. And for me, it's all about not just safety for the sake of safety, but safety by which myself and others can convey the useful growth that people want to see in themselves, their skills, and their abilities that isn't diluted. That can convey the truth, the difficulty, and the challenge and how hard – Programming is really, really hard for me and I've been doing it for a long time. A lot of stuff about this is just not easy. The relationships are not easy. Like you're going to run into situations where there's massive differences between where people stand on stuff and what those perspectives look like. Navigating that is hard enough without adding a whole layer of toxicity and hostile work environment. So what's a way to promote that learning environment without just totally insulating somebody from reality. That's been, I think a challenge and attention that I see a lot of other like-minded leaders in tech trying to figure out how to create. MAE: You reminded me of a meme that someone shared with me that says, “What doesn't kill you can just regulate your nervous system, trap itself in your body, steal your sense of self, make you wish it did.” I don't know what makes you stronger means, but let's stop glorifying trauma as a life lesson we've been blessed with. [chuckles] Definitely along the same lines. JUSTIN: Yeah. Relatable. MAE: There's a thing, too about putting oneself in another's shoes and this is a place where I'm someone that can read people really well, but that makes that tricky. Because I start to trust my sense of it and I have a similar architecture going if I don't feel like I'm getting the whole story. So what's the read between the lines thing. But without a lot of exposure to a lot of very different people, and most people have not had a lot of exposure to a lot of different people, when they put themselves in the other person's shoes, they come up with a different conclusion. So I will feel hurt by people who do things that were I to put myself in their shoes would not have done that to me, or if they did, it's because of X, Y, Z about who they are, or what they think, or what is their whole context and environment. All of that is there's a tactic that we use at True Link Financial called “don't cross the net.” So you say and claim the story I tell myself about that is dot, dot. When leaders, who haven't had a lot of exposure to a lot of different people and a lot of different ideas, try to empathize and find themselves limited in that, there are other options which include one of the things you said earlier. Making it so that people can say the things on their mind so whether, or not that's persons being their authentic self this is a whole another level, but creating a place where we expect that we're all messing up and that it's okay to talk about uncomfortable things is one of my real soapboxes. It's totally okay. Yes, we are all racist. We are all sexist. We are all homophobic. There is no way to not be as a result of being in the culture we're in. We could do things to mitigate it. We can do things to name it. But if we just start from yes, we're all failing. This for me, it lowers the stakes because so many people feel that if someone brings up, “Hey, that's kind of sexist,” or “This is not supporting me in this way,” or “My credibility is not being seen because of this.” In the absence of already, yo, we're going to talk about some negative stuff sometimes, that's an introduction of negativity to the “positive, happy rainbow unicorn workplace” that you were talking about before. So one of my hopes and dreams is that we get some clouds to rain on the land to allow things to actually grow [chuckles] and this includes, yo, we are not perfect. And we are definitely doing things we don't intend all the time. JACOB: That made me think about authenticity again, because sopen about imperfection. I'm a neurodiverse person so I probably am autistic. If someone were to say to me at work, “We really want you to bring your authentic self,” probably the thing I would think is you don't want that person, [laughs] or at least without getting to know me a lot better. There's a concept called masking where it's basically, there are behaviors and traits that are exhibited by neurotypical people that just come naturally to them. By learning the hard way, I've sort of learned to do them, even if they don't feel natural at all like making eye contact, smiling at people when talking, things like that. So I think that complicates authenticity for me, which is that I'm intentionally not hiding, but choosing what parts of myself to show and what parts I just don't want to bring to work. [laughs] I don't have a clean answer for that, or a solution to that, but I think that just complicates things for me. JUSTIN: I thank you so much for sharing that and I think it's a really important perspective to bring, which is I talked earlier about sure, plenty of people's true, authentic selves, even if they were to bring them, they might be in a job, or in a space, or in a team where that wouldn't be understood as such, or appreciated, or literally safe. It's hard to tell people, “Hey, you should feel safe” when the truth when spoken would be an unsafe thing. That would be setting people up for risk, for danger, and it would be a seed of distrust, which is what we're all here to talk about avoiding. So I really appreciate you sharing that. When I talked about empathy earlier, Mae, in my brain, all that really comes through it is the E-M part of that word, like the root for emotion. I never really have been able to assume that I can get somebody's context, their perspective, and the moment that they're in into my brain well enough to role play and do a re-dramatization in black and white, sepia tones and slow motion, like this is what Justin would do if he was here. That's one reason why we trust people at our company to just do the work, because we know that they're going to have such a richer amount of data and context than we'll ever have. But one thing that I'm grateful for is that I've been able to experience what I feel like is a pretty broad range of emotion. [laughs] I'm a real emotionally volatile person. I go super high highs, super low lows and I'm just like, it's how I've been. I can't help it. So when I'm empathizing with people, I'm just trying to get in the mindset of how do they likely feel right now so that I can understand and try to do a better job, meeting them where they are. A big part of that is learning there are differences and so Jacob, of course, it's like if I worked with you, I understand that it might not be productive to bring all of yourself to work all the time. But I would hope to develop a trusting relationship with you where you can share enough so that I can know what are the boundaries that are going to be productive for you, productive for me so that we can make a connection and it's something – To make this a little bit more personal. I don't know where my career is going to go next. I founded Test Double with my partner, Todd. I was only 26 years old and we've been doing this for 10 years now. 2 years ago, we embarked on a journey of transferring a 100% of the equity of the company to our employees. So we're on an employee stock ownership plan now, it's ESOP, or any of the stuff, it is complicated because it's well regulated. We have to have outside auditors, a valuation firm, we have a third-party trustee to make sure that our people and the value of the company is transferred appropriately, treated right, and managed well. So it's naturally raised, especially in my circle of friends and family who realize that, this means that there's not an end date, but there's a moment at which I can start thinking about what my life is going to be next. The people who knew me when I was 25, 26, who look at me now, it's not that I've changed radically, or my identities are radically different, or anything. It's like, I am a very different kind of person than I was at 26, than I was at 20 before I got into this industry. I have changed in healthy ways and in maladaptive ones and in response to maybe drama and stress such that the ideal retirement that I would've imagined earlier in my life looks a lot different now where I've just kind of become habituated. I'm a really, really different person than I used to be and I'm grateful for that in almost every way. I feel like I've grown a lot as a person, but the thing about me that I really look at as an area of change is that I just work too much. [chuckles] I'm online all the time. I'm very focused on – I've optimized productivity so much that it's become ingrained in me. I understand that whatever I do next, or even if it's just changing my role inside my company, I need to find a way to create more space for slower paced asynchronous thought and learning how to, in the context of a career, not just bring your true self – I'm kind of curious Chelsea, Mae, and Jacob's perspectives. That true self might be changing [laughs] intentionally. There's a directionality and the growth isn't just learning new skills necessarily, but it might be changing core things about ourselves that will alter the dynamic of the relationships that we bring to work. CHELSEA: Yeah. I have two thoughts on that, that I can share. The first is the extent to which bringing my true self is a productive thing to do at work. So for example, my career prior to tech, I did a variety of different things to make ends meet, really a wide variety of things. I graduated directly into one of the bigger recessions. I won't tell you the exact one, because I don't feel like being aged right now, but [chuckles] it wouldn't take too much research to figure it out. I was trained to do a government job that was not hiring for the next 18 months at a minimum. I needed to figure out what to do and was trying to make ends meet. In my first year of employment, I got laid off/my job ended/something like that on four separate occasions in my first year of work and that resulted in, I do not trust when managers tell me that everything is fine. I have not ever effectively and that is something that I don't foreground that in work discussions for a variety of reasons. I don't want to scare other people. I don't want them to think I know something that they don't know about what's going to happen because I don't usually. When managers tell me, “Oh, everything's great, we're doing great,” all that kind of stuff, I just don't listen. I don't. My decisions do not take that's statement into account and I find that that's the kind of thing that I think about when I'm asked to bring my whole self, my authentic self to a place is that there are things that just sort of similar to what Jacob is saying. I'm like, “Trust me, trust me on this you don't want that.” So that's kind of the first thought in that realm. The second thought that I have around this is the degree to which work should really encompass enough of our lives to require, or demand our authenticity. So I had a variety of full-time jobs in tech and then I quit one of those full-time jobs and I was an independent consultant for a while bolstered chiefly, and I was lucky for this, by folks who had read my blog and then folks who had worked with me when I was at Pivotal. So the consulting effect of people knowing what it's like to work with you is real. That experience felt very different from a full-time position insofar as at the external validation of my work was naturally distributed in a way that it's not in a full-time position and I found that distribution is extremely comforting. Such that even though I now have a full-time job, I also continue client work, I continue teaching, and I continue writing and doing workshops and those kinds of things. This is not the chief reason that I do that, but one of the nice things about it is the diversification of investment in the feedback that I'm receiving and validation that I'm receiving. In order to do that, I have an amount of energy that I put to each of the things in my life and part of it is work, of course. But another reason that I think it works for me is that I no longer have to expect all of my career fulfillment from any one position, from any one employer, from any one place, which has worked out very well because I think that we pedal this notion implicitly that you bring your whole self to work and in return, work provides for your whole career fulfillment. But most places really kind of can't and it's not because they're terrible places to work. It's just because the goals of a company are not actually to fulfill the employees, they're just not. That's not the way that that works. So it has allowed me and I think would allow others to approach the role that a given employment situation plays in their life, from what I think is a more realistic perspective that ends up helping keep me more satisfied in any given work relationship. But it doesn't necessitate that I – I guess, for lack of a better term, it limits the degree of emotional investment that I have in any one thing, because I'm not expecting all of my fulfillment out of any one thing. But I think that to say that explicitly sometimes runs at best, orthogonal and at worst, maybe contraindicates a lot of what we talk about when we talk about bringing our whole selves to work and looking for those personal connections at work. I think there is pragmatic limit past which we maybe impose more guilt than we need to on ourselves for not doing that. JUSTIN: Yeah. Thank you so much for sharing that. I think Mae used the phrase “lower the stakes” earlier and I think that one of the problems with authenticity, the phrase “bring your whole self-trust” is that the stakes are super high because it seems like these are bullion contracts between parties. For example, you said that you don't trust managers. If I was filling out a form, like a personality inventory, or something, it's like, “Do you trust managers?” I'd say no and I think 90% of people would say no. It's sort of the economy right now. I think the economy approval rating of is the economy good, or bad is at 23%. But individuals are saying at roughly 60% levels, that they are individually doing okay in this economy. I would say the same. Like, do I trust my manager? Oh, hell yeah. I completely trust my manager right now. And to lower the stakes even further, when I've been talking about trust, it's not so much about where do I find fulfillment, or who what's my identity, or who am I being, it's about a snap orientation. It's the most immediate sphere. “Oh man, this PostgreSQL query is really slow and I can't figure it out.” Is my snap reaction, or my orientation to think, “I believe in myself enough to dig into this to figure it out”, or is it doubt myself and just kind of get lost in a sea of a thousand Stack Overflow tabs and just slowly lose my whole evening? When in a team, maybe working with them and we were in planning, or something, or maybe we're in a higher stake, let's say, a code review session and somebody makes a comment about something that I did. Is my snap reaction to doubt their motivations and think “Ah, they're just trying to passive aggressively shoehorn in their favorite architecture here,” or this is politics and gamesmanship, or is my snap reaction is to be like, “Nope, let's try to interpret the words that they're saying as literal words and take it on its face”? Like I said, I'm a highly emotionally volatile person, the weather vane shifts with me all the time and sometimes I can control it and sometimes I can just merely observe it. But the awareness of the out has been really helpful to understand [chuckles] when I hear a leader say something about the company, my reaction is I think that they've got ulterior motives and that they are probably not speaking in literal truth. If that's my snap reaction, I'm just trying to communicate that as that's a potential blind spot. Because I have a long rut of past companies that I worked for that had mission statements and vision statements that were kind of bullshit and that no one really believed in, that were just in a bronze plaque on a wall, or whatever. That's baggage that I carry. I just have to acknowledge that baggage and try to move forward. The best I can do is just be present in every moment that I'm in and to understand when I have a snap reaction, am I oriented towards what might lead me to a good outcome, or a bad one? MAE: Holy moly, so many amazing things have been shared today and Jacob, especially kudos to you for walking us into a deeper level of authenticity. Love it. Thank you. I'm, to answer some of your questions, Justin very similar to Chelsea in that tech was not my first rodeo. I didn't become a programmer until I was 37 years old and I am now 45. I'm totally fine with aging myself. Prior to tech, I did put a lot more of my identity in my job and I would usually do that job pretty much all of the hours possible and I've always worked for mission driven organizations. A lot of the things that we're talking about as far as job fulfillment and whether, or not it's a good environment, or if it's a toxic environment, there's a lot of privilege in what we're talking. My parents were paper mill workers and it was not pretty. They had me when they were 19, so they didn't have another option. That was the highest paying gig in our region and they had no education. So it was never an option to even change that. So I am someone who wants to put my whole self into what I do. It's a very working-class mode and gaining identity through what it is I'm able to do. It's also a pretty capitalist [laughs] mentality that I work to move around. But as a manager, when I am a manager, or in management, or managing managers, I'm never encouraging this everybody needs to bring their whole self to work. Although, I had this really instructive experience where one person truly did not want to have any of their self at work, that they truly only wanted to talk about work at work. We're not a family, nicely nice. I don't want to crochet together, or whatever. That is the most challenged I've ever been as a manager because my natural things are always to figure out what people need and want, and then amalgamate that across the group and see how we can do some utilitarian math and get it so that people are being encouraged in ways they would like, they are not being disadvantaged, and they have space to say when that's happening. But even still, I'm always going with the let's be buddies plan and it's not for everyone. So figuring out how to not have all of your eggs in any basket, no matter how many hours the job is, is definitely a tactic that has been successful for me. But what happens is I then am involved in so many things [chuckles] in all of the moments of life. So I still do that, but I do it by working more, which isn't necessarily the best option. The thing about the mission that I just wanted to pivot for a second and say is, we are no longer in a world where we allow failure. This is a little bit back to my earlier soapbox. The energetic reality is whatever anybody's mission statement is, that is the thing they are going to fail at, like the seamstress never has the best hemmed clothes. So when we write off anyone, or any company based their flawed attempt at the mission, we're discounting that flaws exist, [chuckles] contradictions exist. It's about where are we orienting and are we incrementally moving toward that, or away from it and not in this moment, are we this thing that we have declared because it's more of a path is how I see it than the declaration of success. JUSTIN: Yeah. Thank you so much for that, too. Because I think that one thing we didn't touch on is the universe – and we're talking a Greater Than Code podcast so it's software industry adjacent at least. The universe of people who got to stay home during this whole pandemic. The universe of people who are “knowledge workers”, or “white collar”, especially if you look at the population of the world, is vanishingly small. There was a season in my life where I was the person that you just described managing, where I just viewed myself as I was burnt out. I always wanted to be a mercenary. I had this mindset of I show up at work. “You want some great code? I'll sling you some great code.” Like I was a short-order cook for story points and feature development and that was the terms, right? I didn't want to bring my feelings to work. I didn't want to make friends with people because then God forbid, it would be harder to leave. I didn't have that available to me as a capacity at that time, but I went long enough and I realized it's not that I was missing something, or not being fed in some way by not having this emotional need filled at work. It was that I was failing to acknowledge when you say privilege, the literal privilege, that I get to wake up in the morning and think for a job [laughs] and the impact that I can have when I apply all of the skills, capabilities, and background asynchronous thoughts that are not literally in my job description. When I can bring those things to bear, I'm going to have a much, much bigger impact because what am I except for one person thinking and staring at a matted piece of glass all day, but somebody who is in a small community, or a group of a bunch of people who are in the same mode. So when I'm in a meeting, I can just be the mercenary jerk who's just like, “Hey, I'm just doing this,” and feeling like that's an emotionally neutral thing. When in fact, that negativity can be in an emotional contagion that could affect other work negatively, or and I'm not exactly – My friends who know me, I'm a stick in a mud, I'm a curmudgeon, I'm super negative. I complain constantly and I have taken it upon myself to strive to be a net increase in joy in the people that I talk to and that I interact with at work. Because it is a resource that is draining all of us all day long on its own and it needs to be filled up somehow. I have the capacity right now to take it upon myself to try to fill that tank up for the people that I interact with. So I want to touch on that because I just think it's super lucky that I get to work on a computer and talk out of a screen all day long. If I didn't have that, we wouldn't be having this conversation, I suppose, but I'm just here to make the most of it, I guess. MAE: I love that. And you reminded me of Sandi Metz's closer, Lucky You. JACOB: Tell us about it. MAE: She gave the closing talk a couple years ago and it's called Lucky You and it goes through how did we all come to be sitting in this room right now and what about redlining? What about the districting? What about all of these things that led to us to experience being here as lucky? I know you weren't saying it in that way, Justin, but it reminded me of that piece, too, which is relevant, but the talk is completely amazing and I definitely recommend it. JUSTIN: I think I mentioned it once before. The thing that brought me and our marketing director, Cathy, to think that this would be a great forum to talk a little bit about trust at work is that we're about out to – and I think that actually the day that this podcast publishes is the day that we're going to publish a new conference talk that I've prepared called How to Trust Again and we're going to post it to Test Double's YouTube channel. So we might not have a direct link for the show notes necessarily, but it'll probably be at the top of that as well as the top of our blog when the show goes live. I hope that anyone [laughs] who enjoyed this conversation will also enjoy the kind of high paced, frenetic, lots of keynote slide style that I bring to communicating about a lot of these topics while still understanding that it's just like n equals one. I'm sharing my experience and hopefully, as food for thought to maybe help you look back at your own experience and understand what connects from my experiences, my perspectives, and my context that might be useful and I hope that you'll find something. Special Guest: Justin Searls.
Justin Searls helped start Test Double—a software agency of experienced developers who work with clients to build great software together, as a team. He gave Brittany the scoop on Mocktail, an opinionated alternative to minitest's mocks, rr, mocha, and rspec-mocks. As a bonus: he offers his insights and advice on being a confident speaker. Show Notes & Links: testdouble/mocktail (https://github.com/testdouble/mocktail) Test Double | An Agency Improving the World's Software (https://testdouble.com/) Mockito framework site (https://site.mockito.org/) Jim Weirich's Tweet (https://twitter.com/jimweirich/status/77124604602228737) searls/gimme (https://github.com/searls/gimme) jimweirich/flexmock (https://github.com/jimweirich/flexmock) Please don't mock me - Justin Searls - JSConf US 2018 (https://www.youtube.com/watch?v=x8sKpJwq6lY) VCR - GitHub (https://github.com/vcr/vcr) How to Make a Gem of a Gem | Rubyconf 2021 (https://rubyconf.org/program/sessions#session-1203) Justin Searls (@searls) · Twitter (https://twitter.com/searls) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails).
This week Gerhard is joined by Justin Searls, Test Double co-founder and CTO. Also a
This week Gerhard is joined by Justin Searls, Test Double co-founder and CTO. Also a
Todd Kaufman and his partner Justin Searls started Test Double, a custom software development company, in 2011. The business was a success from the start and grew more than 25% a year. By 2019, Kaufman and Searls were generating more than $10 million in annual revenue and putting more than $3 million to the bottom line each year. An outside valuation consultant suggested if they ever wanted to sell, Kaufman and Searls could get around 6.5 times profit for their business or around $20 million.
Justin Searls from Test Double joins the party to talk about patterns he’s identified that lead to failure, minimalism, and of course, testing!
Justin Searls from Test Double joins the party to talk about patterns he’s identified that lead to failure, minimalism, and of course, testing!
In this conversation Justin and I talk about our respective experiences in software consulting, the different types of consulting/agency work, and how to get started in consulting.
Esther Derby on Drunken PM, Justin Searls on Maintainable, Lena Ross and Dr. Jen Frahm on Agile Uprising, Dr. Nicole Forsgren on Screaming In The Cloud, and Courtland Allen on Software Engineering Daily. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting October 28, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ESTHER DERBY ON DRUNKEN PM The Drunken PM podcast featured Esther Derby with host Dave Prior. Dave asked about Esther’s new book, “7 Rules for Positive, Productive Change: Micro Shifts, Macro Results” (https://www.amazon.com/Rules-Positive-Productive-Change-Results/dp/1523085797). She says it is a guide for people who need to bring change to their organizations, whether or not they have “change management” in their title. Esther told the story about getting a call from a company that had sent everyone to three days of Agile training, but then mandated that the company-wide process would now be “Agile” and any changes would need to be approved by the software engineering process group. They solidified things when they knew, if not the least, very little. She thinks these kinds of stories keep happening because we are suffering from a hangover of mechanistic thinking where we view our organizations as machines and we can just install a change like swapping out a part. Esther says that often when people try to create change, they don’t think enough about what they want to retain. This reminded me of something Tom DeMarco wrote in his book Slack when talking about vision: “Successful change can only come in the context of a clear understanding of what may never change, what the organization stands for. This is what Peter Drucker calls the organization’s culture. Culture, as he uses the term, is that which cannot, will not, and must not change.” She also says that people forget that they are not working on a blank slate. Whatever they do, they are putting it on top of existing traditions, reward structures, policies, and patterns of relationship, and the new thing is going to interact with that in unpredictable ways. They talked about cognitive empathy and being able to explain something like the Agile Manifesto to somebody who hasn’t experienced traditional project management. Esther talked about a client in the Dominican Republic that mostly hires people straight out of school and is particularly adept at collaboration because they haven’t had years of being rewarded for individual accomplishments take away their natural desire to work collaboratively. She likened this to the traits that are often associated with Millennials and how these are actually good traits to have. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/7-rules-for-positive-productive-change-w-esther-derby/id1121124593?i=1000449914205 Website link: https://soundcloud.com/drunkenpmradio/7-rules-for-positive-productive-change-w-esther-derby JUSTIN SEARLS ON MAINTAINABLE The Maintainable podcast featured Justin Searls with host Robby Russell. Robbie started by asking Justin what he thinks makes for a well-maintained codebase. Justin evaluates codebases as his job, so he has a process he follows. He starts outside-in. He looks at common things like the readme or other documentation and evaluates how easily he can get up-and-running. This is important because it says something about how often they on-board new people and whether they improve this aspect of their process. The second thing he looks at is what dependencies the codebase is using. He checks that dependencies are up-to-date and whether there are many or few dependencies. He tries to identify whether the team tends to rely on third-party libraries frequently or build their own. Next, he evaluates application-specific aspects of the codebase. If it is a web application, for example, he will evaluate the complexity of the routes. He’s checking that things are named clearly and kept small and whether the team prioritizes organization or not. After he feels that he has his bearings, he looks at statistics like churn to identify hotspots like god objects. That’s just what he gets from looking at the code. He says you can learn a lot from how the team communicates too. High-performing teams, he says, describe what their system does in humble, plain language, whereas the more technical and convoluted a team makes their applications sound, the more likely the team is attempting to imbue their application with unearned significance and this ends up creating barriers to understanding. Justin says that, as he has gotten further removed from the details of software delivery, he has begun to empathize with product managers and business managers for whom words like refactoring and technical debt have become four-letter words because all they’ve ever heard these words used for is excuses for why work isn’t getting done. Justin says that many programmers are often thrust into roles of professional responsibility well in advance of their ability to cogently and calmly understand and describe exactly what a system is doing. The combination of a high-pressure environment with a shaky understanding of the fundamentals of the software the engineer just built limits their ability to explain why things are taking longer than expected without resorting to language like technical debt. He calls this “obfuscating the conversation up a layer.” He talked about the challenges he faced when the industry transitioned around 2011 from largely co-located teams to asynchronous GitHub-based workflows and eventually to using tools like Slack for communication. He said that he didn’t realize at first just how much textual communication is read differently from being in a room with somebody. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/justin-searls-learn-to-understand-the-runtime/id1459893010?i=1000453441400 Website link: https://maintainable.fm/episodes/justin-searls-learn-to-understand-the-runtime-C6e05XWb LENA ROSS AND DR. JEN FRAHM ON AGILE UPRISING The Agile Uprising podcast featuring Lena Ross and Dr. Jen Frahm with host Andy Cleff. They started the conversation by talking about John Cutler’s blog post, “The Patient Change Agent” (https://medium.com/hackernoon/the-patient-change-agent-fd8548f04777) that caused Jen to rethink change resilience. Jen was running resilience workshops at a client at the time and was using Lois Kelly’s work on “change muscles” (http://foghound.com/blog/2016/3/29/build-the-change-musclesbuild-the-change-muscles). A particularly fearless change agent in the workshop told her she had it all wrong: she was using resilience from the perspective of “bracing for change” but needed to be working with resilience in the sense of “renewal”. Jen talked about the distinction between the Agile coach and the organizational change agent. The Agile coach is product development team-focused while the organizational change manager works beyond that. She sees many Agile coaches that do not address the impacts of releasing whatever the team is producing to operations. Andy asked his guests how they bring executives on board in supporting Agile transformations. Jen says she sees executives trying to do full Agile transformations company-wide and they are struggling to understand how much involvement they should have. These leaders need to find someone they trust who has the technology domain expertise to help them. Lena added that, in the last two years, she has seen that leaders are starting to understand enterprise agility. The old practices that served them well in the past aren’t cutting it anymore. They are realizing that they need to reach out and ask for help. Andy pointed out that asking for help and admitting they don’t know something requires a great deal of vulnerability from executives and asked Lena and Jen how they, as consultants, bring this about. Jen says you need to start by meeting with executives one-on-one and you need to be able to role model vulnerability in front of them. You use strength-based language to make them feel safe and you bring in threads from the conversations you’ve had with others so that they know they are not alone. She has also found a lot of success by running breakfasts with the executive team after she has already established trust. These breakfasts serve as safe environments where she role models and facilitates conflict and constructive conversations. Andy said it sounds like Jen is building empathy at the leadership layer. Jen agreed that it is empathy, but added that it is invitation-based. She doesn’t tell people that they must have the conversation; she invites them to consider the concepts. She then spoke about recently rethinking the notion of empathy as a result of mindful self-compassion training. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/empathy-and-resilience-in-leadership/id1163230424?i=1000451652567 Website link: http://agileuprising.libsyn.com/empathy-and-resilience-in-leadership DR. NICOLE FORSGREN ON SCREAMING IN THE CLOUD The Screaming In The Cloud podcast featured Dr. Nicole Forsgren with host Corey Quinn. This was the second part of a conversation with Dr. Forsgren. In the first part, they discussed the latest State of DevOps report. This episode focused more on the new cloud-specific section of the State of DevOps report. She quickly summarized what the overall report found about high and low performers and listed several things low performers can do to become high performers: invest in continuous delivery and automation, work in small batches, invest in observability and monitoring, develop a generative culture, and finally, make use of cloud computing. The big problem with cloud computing, she says, is that so many people keep redefining “cloud” in a million ways. Without a precise definition of what it means to use “the cloud”, there is no way to be able to give a statistically significant answer about whether and by how much it improves an organization’s performance. So she chose to use the NIST definition for cloud computing and its five characteristics. Measured this way, elite performers are twenty-four times more likely to be executing on all five characteristics. Compared to the total number of organizations that say they are using cloud computing, only 29% of them are meeting all five characteristics. Nicole started describing the five characteristics. The first is on demand self-service. You have to be able to automatically provision your compute resources without human interaction. You can’t be putting them behind a “service down” ticket that you wait for someone to approve. The second is broad network access - can you access it from multiple devices? The third is resource pooling - are the provider resources pooled in a multi-tenant model where resources are dynamically assigned on demand? The fourth is rapid elasticity - can you handle a Black Friday situation? The fifth is measured services - systems can automatically control, optimize, and report resource use and that’s all you’re paying for. She notes that these are all architectural outcomes, design outcomes, and automation outcomes. Regardless of whether you are on public cloud, private cloud, or even a mainframe environment, you can still improve your software delivery performance by architecting your infrastructure with these outcomes in mind. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/five-characteristics-that-define-cloud-nicole-forsgren/id1361244178?i=1000452015823 Website link: https://share.transistor.fm/s/3e21ecc7 COURTLAND ALLEN ON SOFTWARE ENGINEERING DAILY The Software Engineering Daily podcast featured Courtland Allen with host Jeff Meyerson. They talked about the changes to Courtland’s Indie Hackers business that occurred over the past three years. The first was that three years ago, there was no Indie Hackers podcast. There was just the website. Today, the podcast is bigger than the website. Also back then, Indie Hackers was its own business and today it is part of Stripe. Courtland talked about how Indie Hackers went from a media company to a platform and community. The core of any community, he says, is people who are empowered and able to help each other out. Indie Hackers is all about people starting internet businesses and helping each other overcome the challenges of doing so. To start Indie Hackers, Courtland followed the Reddit playbook. He created a forum, made a bunch of fake threads, made a bunch of fake accounts, talked to himself a lot, occasionally trapped a real person into a conversation with three Courtlands, and before long there were two, then three people talking to a bunch of Courtlands. Eventually, it becomes self-sustaining. His recommendation is to shrink time and space around the community so that it feels active and lively. You want to restrict space around your community online for the same reason that if you’re having a party for only ten people, you don’t hold it in an auditorium. Offline communities are usually easy to restrict in both time and space; you have a meeting time and a place. If you’re going to have a poker game on Wednesday night at six, even if nobody is participating in this poker community any other time, if everyone is at the game on Wednesday, it feels like a lively community. To achieve the same feel online, instead of creating a forum or a message board, do something like posing a question every Friday that community members answer. People will observe a thriving community even if it has only fifteen or twenty people. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/indie-hackers-3-years-later-with-courtland-allen/id1019576853?i=1000452268869 Website link: https://softwareengineeringdaily.com/2019/10/04/indie-hackers-3-years-later-with-courtland-allen/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:
Robby speaks with Justin Searls, Co-Founder at Test Double. Hear Justin's experience digging into technical debt, learn why software is like a sedimentary rock, and more.Helpful LinksFollow Justin on TwitterTest DoubleRuby gem: SutureJustin's Legacy Code talk at Ruby KaigiJustin on GithubConnect with Justin on LinkedIn[Book] Growing Object-Oriented Software Guided by TestsSubscribe to Maintainable on:Apple PodcastsOvercastOr search "Maintainable" wherever you stream your podcasts.
Panel Joe Eames Luis Hernandez Mike Dane Sam Julien Joined by special guest: Shai Reznik Episode Summary In this episode, the panelists talk to Shai Reznik, web developer, educator, consultant, and Angular Google Developer Expert, who teaches courses mainly on Angular and React, and makes sure that they are topped with some humor and fun! Joe kickstarts the show by asking Shai the reasons why he considers humor to be a consistent part of his personality as well as his teaching methods. Shai explains in detail how that makes learning interesting and effective by citing his own experiences. Joe opens up the discussion to the panel and asks their thoughts about using humor in learning, teaching and their opinions on it, in general. They then talk about the techniques they employ or those that others use, in order to make learning fun and memorable. Shai elaborates on what strategies he utilizes to keep a good balance between the technical content, and the jokes and entertainment he resorts to while teaching. In the end, the panel discusses resources and methods to help make the learning process fun and they wrap up the show by each stating one thing they would like to recommend to a friend. Links HiRez.io Angular Testing Shai’s Twitter Picks Mike Dane: Please don’t mock me - Justin Searls Luis Hernandez: GatsbyJS Sam Julien: Luna Display Shai Reznik: What we talk about when we talk about software - Nat Pryce Joe Eames: FIFA Women’s World Cup 2019
Panel Joe Eames Luis Hernandez Mike Dane Sam Julien Joined by special guest: Shai Reznik Episode Summary In this episode, the panelists talk to Shai Reznik, web developer, educator, consultant, and Angular Google Developer Expert, who teaches courses mainly on Angular and React, and makes sure that they are topped with some humor and fun! Joe kickstarts the show by asking Shai the reasons why he considers humor to be a consistent part of his personality as well as his teaching methods. Shai explains in detail how that makes learning interesting and effective by citing his own experiences. Joe opens up the discussion to the panel and asks their thoughts about using humor in learning, teaching and their opinions on it, in general. They then talk about the techniques they employ or those that others use, in order to make learning fun and memorable. Shai elaborates on what strategies he utilizes to keep a good balance between the technical content, and the jokes and entertainment he resorts to while teaching. In the end, the panel discusses resources and methods to help make the learning process fun and they wrap up the show by each stating one thing they would like to recommend to a friend. Links HiRez.io Angular Testing Shai’s Twitter Picks Mike Dane: Please don’t mock me - Justin Searls Luis Hernandez: GatsbyJS Sam Julien: Luna Display Shai Reznik: What we talk about when we talk about software - Nat Pryce Joe Eames: FIFA Women’s World Cup 2019
In this episode, Jason and Chris are joined by Justin Searls during RailsConf 2019. Justin is a co-founder of Test Double, an agency that's improving the world's software. They talked with Justin about his path to programming (it includes Blockbuster!), how Test Double got its start, public speaking, and using an iPad as a development machine.
GUEST BIO: Dave is a Software Developer who has been building web applications since using HTML tables for layout started to go out of style. A background in classical design and computer systems technology has enabled him to roam between the worlds of design and development. Dave hails from Ottawa, Canada where he works remotely for Test Double. EPISODE DESCRIPTION: Phil’s guest on today’s show is Dave Mosher. He has a background in classic design and computer systems technology. Today, he works remotely for Test Double as a Software Developer. Dave has also held this position at Shopify and Pillar Technology. For several years, he ran his own consulting company DAVEMO. He specializes in producing high-performance front-end web architecture and is currently working on getting more deeply involved in coaching and mentoring. KEY TAKEAWAYS: (1.04) – So Dave, can I ask you to expand on that intro and tell us a little bit more about yourself? Dave started his IT career working as a designer. He started out just working with HTML and CSS. At first, he did a lot of desktop publishing work. But, he soon moved on to development, working with databases. (2.27) - How did you get into Test Double? When did that come about? Dave spent a few years working at a start-up in Saskatoon, Saskatchewan, doing Python app development on Google App Engine. During that time, he grew a lot and learned to wear lots of hats. That role ended and Dave found himself at a loose end. Around the same time, Kevin Baribeau, a fellow test dabbler, was also under-occupied. He got a job at a consultancy called Pillar Technology. So, Dave applied for a role there too and was hired as a remote consultant. During much of his time with Pillar Technology he worked directly with the guy who hired him, Justin Searls. He also came across Ted Kaufmann while working there. Within about two years, Justin and Ted left Pillar Technology and set up Test Double. Dave ended up working for them as a consultant and later as a full-time employee. It was Justin that helped him to learn TDD, how to write tests and introduced him to the realm of Agile software development. Dave says he learned more in the nine months he worked directly with Justin than he had in the previous five years. (4.53) – Can you please share a unique career tip with the I.T. career audience? Dave’s advice is not to chase technology if you are not happy in your current role. In all likeliness a shiny new piece of technology is not going to solve your problems. If you start chasing after shiny tech it usually ends in disappointment. Ultimately, technology is not really the source of the challenge you are looking for. Solving people’s problems is what brings job satisfaction. You don’t need to be using the latest technology to do that. Phil asks if he is saying that you need to avoid the shiny penny syndrome. Dave confirms that is the case. Chasing after the latest tech is a trap that a lot of newcomers fall into. They tend to underestimate the human factors of software development. (7.09) – Can you tell us about your worst career moment? And what you learned from that experience. Before joining Double Test full time, Dave took a job with Shopify. He wanted to get away from using JavaScript and learn to use Ruby on Rails. Overall, it was a good move. He learned a lot while working there. But, it was also where his worst career moment took place. At the time, he was refactoring their asset pipeline. It was really slow, taking five minutes to run, so Dave re-tooled it. He did a good job and got the run time down to about 20 seconds. So, they rushed his enhancement out to production. That was a mistake, a big one. They ended up taking down the whole of Shopify for about 15 minutes. At the time, there were around 80,000 websites running on the platform, so it was a big deal. This incident taught Dave that if you are making a change to a big platform you need to be especially careful before proceeding. You have to slow things down a bit and vet everything in every possible environment. It is also important to keep your QA and production environments as closely aligned as possible. At the time, Shopify had not succeeded in doing that. Dave and the people he was working with had been lured into a false sense of security. When the enhancement test went green in the QA environment they, understandably, assumed it would work in production. Unfortunately, that is not what happened. (11.10) – What was your best career moment? For Dave, that was when he first started working for Double Test. At the time they were working on a contract for a very large firm. Like most large corporations, the work environment was incredibly restrictive and inflexible. They had lots of standards in place and hoops to jump through. It was impossible to work fast because Dave and his colleagues had virtually no autonomy. However, they did find a way around this. Working with one of the firm’s developers, who did a lot of API work, they were able to build a shim and their own tooling. This enabled them to work in isolation at the front end with the angular piece and JavaScript. That meant that they could work much faster. For everyone involved in coming up with this solution it was a great technical triumph. But, Dave took the most pleasure from the fact that they had been able to help the team lead they were working with to gain confidence and excel. They invested a lot of time and energy into coaching him and giving him personal encouragement. This included teaching him people skills, for example, how to avoid confrontations and not become defensive. By the end of their time together he was a completely different person. So much so that he actually said “you guys changed my life.” (13.50) – Can you tell us what excites you about the future of the IT industry and careers? The fact that the barrier to entry has been lowered significantly really excites Dave. Code boot camps are making the field of IT a lot more accessible. In particular those boot camps that have structured their courses so that you do not necessarily have to pay your tuition fees up front. Dave has also been involved in producing educational resources. He took what he was doing at work and replicated the processes via screencasts so that he could help and educate other people. It was wildly successful and Dave found that putting together the lessons helped to solidify his knowledge. So, the benefits were twofold. Both parties benefited. He has noticed that a lot more people are starting to do share their knowledge, recently, something he is very pleased to see. (17.10) – What drew you to a career in IT? Dave drifted into IT through design. But, to get involved in the back end he had to go back to school and complete a Computer Systems Technology diploma. It was the only way he could go from being a starving artist, so to speak, to making some real money. (17.36) – What is the best career advice you have ever received? That advice came from Justin. He was struggling to convince Dave that test-driven development was the way to go. Dave, like most developers, was used to starting with the code first, then thinking about tests. Justin knew, from experience, that he was right. But, when Dave did not listen he did not continue to badger him. Instead, he let him go his own way and discover the painful way that he was wrong and Justin was right. Test-driven development did work best. This experience taught Dave the value of allowing yourself the freedom to fail. He learned how to use his pain as a motivator. He still remembers how going down the wrong path feels, so stops and thinks more before choosing a course of action. Dave is also more inclined to listen to others than he was when he first started his career. (18.54) – If you were to begin your IT career again, right now, what would you do? Dave says that he would probably spend a lot more time working with relational databases. If you want to specialize, being a database admin, and understanding the nuts and bolts of PostgreSQL or Postgres is a great approach, right now. He would also get a better handle on data modeling. Developers have a tendency to start without the data. As a result, all too often, they end up painting themselves into a corner pretty quickly. (19.56) – What are you currently focusing on in your career? Right now, Dave wants to get more involved with mentoring. He wants to have more of an impact on people’s personal lives. Dave is currently figuring who the people in his community are so that he can make himself available to them and help others to level up. (20.39) – What is the number one non-technical skill that has helped you the most in your IT career? For Dave, that is his musical abilities. He plays piano, drums, bass, and guitar. Dave finds playing to be a good creative outlet and has noticed that there is a lot of crossover between musicality and IT. While playing music, you learn to pick up on patterns and how to improvise. This skill set is useful for IT professionals as well as musicians. Playing music with others sharpens your ability to spot where they are going and follow them or add to what they are doing. These skills are also useful in the workplace. (22.18) – Phil asks Dave to share a final piece of career advice with the audience. Dave’s parting piece of advice is - When you feel it's time to move on, reconsider. Usually, if you are at the end of your rope there will still be something you can do to reframe the engagement in a way that is positive. Adversity provides you with the chance to rise to the challenge and learn. So, when you are struggling, stop, think and see if you can solve the problem without necessarily changing companies. Only move on when you have considered things carefully and determined there is no way to fix the problem. BEST MOMENTS: (1.45) DAVE – "I was drawn to the web via the power of design." (3.05) DAVE – "Don't chase technology would be my number one career tip." (7.08) PHIL – "It's the right technology for the right solution as opposed to a specific technology." (10.45) DAVE – " Take a little bit more time than you think you need and try to vet all of the things that you're working on in every environment possible" (18.33) DAVE – "Allow yourself the freedom to fail." (22.23) DAVE – “When you feel like it's time to move on, reconsider.” CONTACT DAVE: Twitter: https://twitter.com/dmosher LinkedIn: https://www.linkedin.com/in/dmosher/ Website: https://blog.davemo.com
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan .TECH– tech/MRS and use the coupon code “MRS.TECH” and get a 1 year .TECH Domain at $9.99 and 5 Year Domain at $49.99. Hurry! CacheFly Host: Charles Max Wood Special Guest: Justin Searls Episode Summary In this episode of My Ruby Story, Charles hosts Justin Searls, co-founder of Test Double, a software agency which helps developers improve their quality of the software. Listen to Justin on the podcast JavaScript Jabber on this episode and this episode. Justin got into programming playing with his Casio Calculator when he was 10 years old. He came up with little games such as guessing the number. Later on, he added features and soon created an ephemeral checkers game. He had no knowledge about the basics of programming and everything was self-directive. Justin majored in Computer Science in college.However, he soon learned that Computer Science does not equal Application Development. The things taught to him by his professors were not very practical for building applications. He had his first hands-on experience in programming when he worked at the campus library. He was asked to work on their flash base citation generator which was meant to help those who were doing research for their bibliography. Millions of people used it and its feedback led him to build web applications that could provide a free useful service to other people. Over time, he found out that JavaScript was a good way to solve problems for people. However, he did not have a lot of autonomy over the jobs. He recalls an experience where every single Java library he wanted to pull off had to get approved by a committee. He ended up building an earlier Ajax application which uses JavaScript for services. That was a path for him to record productivity. To hear the rest of My Ruby Story Justin Searls, download and listen to the entire episode. Links JavaScript Jabber: Test Doubles with Justin Searls JavaScript Jabber: Jasmine with Justin Searls Justin's Twitter test double.js (library) SCNA SCNA Talk - How to Scratch an Itch Teenytest Test Double blog archive Social Coding Contract Jasmine https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Justin Searls: USB-C Charles Max Wood: Electro-Voice RE 20 Battlestar Galactica 2003 series Stranger Things Arcanum Unbounded
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan .TECH– tech/MRS and use the coupon code “MRS.TECH” and get a 1 year .TECH Domain at $9.99 and 5 Year Domain at $49.99. Hurry! CacheFly Host: Charles Max Wood Special Guest: Justin Searls Episode Summary In this episode of My Ruby Story, Charles hosts Justin Searls, co-founder of Test Double, a software agency which helps developers improve their quality of the software. Listen to Justin on the podcast JavaScript Jabber on this episode and this episode. Justin got into programming playing with his Casio Calculator when he was 10 years old. He came up with little games such as guessing the number. Later on, he added features and soon created an ephemeral checkers game. He had no knowledge about the basics of programming and everything was self-directive. Justin majored in Computer Science in college.However, he soon learned that Computer Science does not equal Application Development. The things taught to him by his professors were not very practical for building applications. He had his first hands-on experience in programming when he worked at the campus library. He was asked to work on their flash base citation generator which was meant to help those who were doing research for their bibliography. Millions of people used it and its feedback led him to build web applications that could provide a free useful service to other people. Over time, he found out that JavaScript was a good way to solve problems for people. However, he did not have a lot of autonomy over the jobs. He recalls an experience where every single Java library he wanted to pull off had to get approved by a committee. He ended up building an earlier Ajax application which uses JavaScript for services. That was a path for him to record productivity. To hear the rest of My Ruby Story Justin Searls, download and listen to the entire episode. Links JavaScript Jabber: Test Doubles with Justin Searls JavaScript Jabber: Jasmine with Justin Searls Justin's Twitter test double.js (library) SCNA SCNA Talk - How to Scratch an Itch Teenytest Test Double blog archive Social Coding Contract Jasmine https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Justin Searls: USB-C Charles Max Wood: Electro-Voice RE 20 Battlestar Galactica 2003 series Stranger Things Arcanum Unbounded
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan .TECH– tech/MRS and use the coupon code “MRS.TECH” and get a 1 year .TECH Domain at $9.99 and 5 Year Domain at $49.99. Hurry! CacheFly Host: Charles Max Wood Special Guest: Justin Searls Episode Summary In this episode of My Ruby Story, Charles hosts Justin Searls, co-founder of Test Double, a software agency which helps developers improve their quality of the software. Listen to Justin on the podcast JavaScript Jabber on this episode and this episode. Justin got into programming playing with his Casio Calculator when he was 10 years old. He came up with little games such as guessing the number. Later on, he added features and soon created an ephemeral checkers game. He had no knowledge about the basics of programming and everything was self-directive. Justin majored in Computer Science in college.However, he soon learned that Computer Science does not equal Application Development. The things taught to him by his professors were not very practical for building applications. He had his first hands-on experience in programming when he worked at the campus library. He was asked to work on their flash base citation generator which was meant to help those who were doing research for their bibliography. Millions of people used it and its feedback led him to build web applications that could provide a free useful service to other people. Over time, he found out that JavaScript was a good way to solve problems for people. However, he did not have a lot of autonomy over the jobs. He recalls an experience where every single Java library he wanted to pull off had to get approved by a committee. He ended up building an earlier Ajax application which uses JavaScript for services. That was a path for him to record productivity. To hear the rest of My Ruby Story Justin Searls, download and listen to the entire episode. Links JavaScript Jabber: Test Doubles with Justin Searls JavaScript Jabber: Jasmine with Justin Searls Justin's Twitter test double.js (library) SCNA SCNA Talk - How to Scratch an Itch Teenytest Test Double blog archive Social Coding Contract Jasmine https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Justin Searls: USB-C Charles Max Wood: Electro-Voice RE 20 Battlestar Galactica 2003 series Stranger Things Arcanum Unbounded
Code Style and Community with Sam Phippen and Justin Searls TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com or visit http://www.tablexi.com/workshops. Guests Sam Phippen (https://twitter.com/samphippen): Developer Advocate at Google and member of the RSpec (https://github.com/rspec) Core Team Justin Searls (https://twitter.com/searls): Cofounder of Test Double (http://testdouble.com/) Summary On this episode, we’ve got Sam Phippen and Justin Searls back for their third round on the show. Both of them have been working on new Ruby tools to better standardize your team’s style and code formatting. We talk about why they’ve decided these tools are important, what their philosophy of coding style is, how coding style relates to the Ruby community, and how they evaluate code when given a code sample to look at. We’d like to hear from you. How does your team handle differences of opinion in code style? Let us know at techdoneright.io/54 or on Twitter at @tech_done_right Notes 02:21 - Code Style Bikeshedding (https://en.wiktionary.org/wiki/bikeshedding) Standard JS (https://standardjs.com/) standard Ruby Gem (https://rubygems.org/gems/standard) rubocop (https://github.com/rubocop-hq/rubocop) Hash Rockets are good actually (https://samphippen.com/hash-rockets-are-good-actually/) Sandi Metz: Why We Argue Style (https://www.sandimetz.com/blog/2017/6/1/why-we-argue-style) 09:46 - Choosing Ruby: Community Standards vs Style 14:59 - Evaluating Code Samples for Developer Positions - Gilded Rose Refactoring Kata (https://github.com/emilybache/GildedRose-Refactoring-Kata) 21:04 - Ruby Format 29:05 - Selecting Rules For Standard 35:38 - Discrepancies in Rails View Template Files - haml-lint (https://github.com/brigade/haml-lint) 39:10 - What happens if these projects aren’t successful? - Why's (poignant) Guide To Ruby (https://poignant.guide) Previous Justin/Sam Episodes: Part I: Episode 004: In The Testing Weeds (http://www.techdoneright.io/004-testing-with-sam-and-justin) Part II: Back in the Testing Weeds with Sam Phippen and Justin Searls (https://www.techdoneright.io/33) Special Guests: Justin Searls and Penelope Phippen.
Sean and Sam talk all about testing. Sam created an ideal testing pyramid based on personal experience and from talking with test thought leaders, such as Justin Searls. The testing pyramid has “integrated” at the top, and “isolated/unit” at the bottom, along with a wide base and X axis for the number of tests you should be writing. Write as few integration tests as possible, although you may write some that you don't keep. Isolated tests refer to where the only thing you are executing is one file or function's worth of code. Then, there's some tests to never write. You should be able to look at a test and know instantly if it's correct or not. Whether using a pyramid or bowtie scheme, teams should embrace testing, rather than hate it.
In this internal episode, Charles and Wil talk about testing issues and BigTest solutions. Pieces of the testing story are discussed, such as the start and launch application, component setup and teardown, interacting with the application and component, convergent assertions, and network. Then they talk about testing issues: the fact that cross browser and device-simulated browsers are not good enough, maintainability and when and when not to DRY (RYE), slowness and why (acceptance) testing is slow, portability and why tests are coupled to the framework, and reliability. Finally, they talk about BigTest solutions: @bigtest/cli to start / launch (Karma recommended for now) @bigtest/react, @bigtest/vue, etc for setup & teardown @bigtest/interactor for interactions @bigtest/convergence for assertions @bigtest/network in the future (Mirage recommended for now) Resources: Justin Searls – Please don't mock me This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 115. My name is Charles Lowell, this episode's host and a developer here at the Frontside. With me today to talk some shop is Mr Wil Wilsman. WIL: Hello. CHARLES: Hello, Wil. WIL: How's it going? CHARLES: It's going good. I'm actually pretty excited to get to jump into this topic because we're going to be talking about some of the big things that are happening at Frontside and some of the things that we've been developing in almost for the last year. WIL: Yeah. It's been about a year now. CHARLES: It's been about a year and we've talked about it in various podcast but we're going to be talking about it again because there's just been so much progress that we've made, I think in a lot of clarity in kind of what we're going for here when we talk about BigTest and testing big and how we want to roll out the BigTest framework. We just have a lot more experience using it on a number of different projects, so we get to talk about that today. Before we get started, I just wanted to talk a little bit about what BigTest is, both in terms of the framework and also the philosophy. Wil, you're the one who works the most on BigTest. When you think about philosophically, what does BigTest mean to you? WIL: It's the size of your test, not a physical size like size and storage but how much your task actually does. The test itself can be very small as our test are but it tests the whole application from the user interacting with it down to the network requests. That's the definition of the philosophy of a BigTest to me. It's to tests your application from the biggest point of view. CHARLES: Actually, achieving that can be surprisingly difficult, especially in a frontend JavaScript application and there are a lot of solutions out there for testing and we've talked about them. One of the questions that arises is when we talk about BigTest, what exactly are we talking about? Are we talking about a product that you can download and install? Are we talking about the philosophy that you just outlined? Or are we talking about the individual pieces of software that make that philosophy real? I think the answer is we're kind of talking about all three but we want to take this episode to talk about where we're going with the product. What we've identified is the subcomponent pieces of that product. In other words, in order to get started testing big, what are the things that you need to think about? What are the things that you need to do? And then what are the component pieces? Because one of the things that I think is very important to us is that you be able to arrive at wherever you are in your project, whatever framework you are using, whatever current testing solution and be able to begin using BigTest. That means, you might be using some of it or you might be using a lot of it but we want to meet you exactly where you are, so that you can then, get onboarded and start testing big. WIL: Yeah. Definitely an important distinction that we get confusion about is what is BigTests and people just assume like this whole test suite is BigTest but we used the parts of it ourselves like we use Mocha, which is not part of BigTest. We use Chai, which is not part of BigTest. We use Mirage which is kind of part of BigTest but definitely it originate in BigTest and Karma and things like that. BigTest isn't your testing suite. It's not one thing to go-to to grab, to start writing tests. It is a small pieces that you can use in conjunction with other small pieces, just to make it really easy and flexible to test your application. CHARLES: Exactly. Because it turns out that there's a lot going on in the application. Maybe we should talk about what some of those pieces are that you might want to start using BigTest with or that you might need to test big, I guess I should say. What's a good place to start? Let's start with talking about some of the issues that you want to do when your testing big. Then we can talk about what pieces of the testing story that fit in to solve those issues. One of them is you need to test that your application works, like actually works. That means you need to be able to test on a multiplicity of browsers, for example. We're limiting to the domain of web applications. There are actually a shockingly large number of browsers. It's not just Chrome. It's not just Safari. There's Mobile Chrome, Mobile Safari, which are subtly different. There's Edge and I'm sure the Mobile Edge is slightly different too, so you want to be able to test cross browser, right? WIL: Yeah, absolutely and things like Nightmare and JS DOM and things that simulated browsers, we don't necessarily think those are the best tools for writing BigTest because we want to ensure that those browser quirks are caught and tested as well. CHARLES: This is not theoretical like sometimes you'll have a syntax, like the parser is slightly different and you have something that throws a syntax error in Safari or in the Internet Explorer and your whole app is completely busted. If you just take in the time, just even trying to load the app in that browser, you would have caught that. That's what I've been on many times. WIL: Yeah and what I just saw came up yesterday, which comes up frequently is not closing your CSS Selector and Chrome doesn't really care like web to browsers don't care too much but that will fail in Edge and depending on what you're missing, the failing is part of that too but mostly, Firefox and Chrome don't care about that kind of thing. CHARLES: Right. It seems like the majority of testing solutions are kind of focused around Headless Chrome or some variation of Electron. That entire class of really dumb errors has already been caught. Like I said, to actually catch it, it takes less than a millisecond of CPU time just to load it onto the browser and see that thing doesn't work. Unfortunately, they can be catastrophic errors but the problem is how do you actually do. We want to test like cross browser. This is something that we want to do. For me, I just can't imagine shipping an application without having some form of cross browser testing, some capability of being able to say, "I want to test it," like, "We want to work on these eight browsers and so we're going to test it on these eight browsers," but how do you actually go about doing that? WIL: Right now, we are working on the BigTest CLI which will help us launch browsers but that's not complete yet. It has some bugs on. For the meantime we've been using Karma, which is great. Basically, you just have this service that's able to find the browser binary on the system and just launch them pointing to local hosts with your app loaded up and your normal development server take care of loading the test up and running the test. Karma and the BigTest CLI is just there to capture output and launch those separate browsers. CHARLES: Yeah. I remember when I was first using working with Karma and I think Testim is another tool that's in this space. There's Testim, Karma and BigTest actually is we're developing a launcher because launching is something that you're going to need but it's such a weird problem. I feel like with the browser launchers, there's three levels of inversion of control because you're starting a server that then starts another process, which then calls back to your server, which then loads the app resources, which then loads the tests and then runs the test. There's a lot of sleight of hand that has to happen and – WIL: Including injecting the adapter that you use, like the Mocha adapter, the Jasmine adapter that ends up reporting back to the CLI. That's something that Karma and Testim and BigTest will handle for you. CHARLES: Right, so you're fanning out the test suite to a suite of browsers then collecting the results but basically, you need some sort of agent living inside the browser that's going to act on behalf of the test suite, to collect the results. I remember when I first came into contact with Karma and Testim, I was like, "This is so unnecessarily complex," but then, having used it for a while and I think there are some complexity that can be removed but if you want to do cross browser testing, that kind of level of ping-ponging is there's a certain amount of it that just necessary. It's something that's actually quite complex that you need to have in your stack, in your toolbox, if you want to truly test big. WIL: Yeah and all the solutions is mechanisms for detecting when the browser has launched and restarting the browser based on its health check, etcetera and things like that that you wouldn't think of actually loading up a browser but you need to think of when you're doing automated testing. CHARLES: What is it that sets apart, for example the launcher solution? We kind of call this class of solutions launchers, so Testim, Karma, the BigTest CLI. What is it that sets BigTest CLI apart from say, Karma and Testim? WIL: We're trying to be as minimal config as possible and just really easy to get started and going. Karma has a lot of plugins that you need to make sure you have installed and loaded in the options set for those plugins. Testim has some stuff bundled but it still requires this big config bulk at the beginning that you need to passing or that's all what you were doing. We're trying to avoid that with BigTest CLI and one of the ways that we're able to avoid that is by just letting your Bundler handle bunding the test. In Karma, you need Karma webpack or something. Testim has some stuff that it needs and really, we just want like in-testing mode. When you're in the testing environment, just change your index to point your tests, instead of your application and your Bundler will do all the work and we just serve that file and collect the results. CHARLES: Right, so it doesn't matter if you're using Parcel or you're using webpack or you're using Ember CI. WIL: Yeah, Rollup even. CHARLES: Or even just like low level Broccoli or Gulp or whatever. There's a preponderance of bundling solutions and that was always something that was just a huge pain in the butt with Karma. I know it's like just getting to the point where my tests are loaded and you look with Testim, most of my experience come with Testim comes through how it's used in Ember CLI like the histrionics that undertaken just to bundle all your tests assets and your application assets and your vendor assets and just kind of bootstrap that thing. It's a lot of work. WIL: Another thing with BigTest CLI that doesn't include in Karma and Testim does is a concept of a watcher because all these Bundlers, you have HMR -- hot module reloading, Rollup and things like that. It come with plenty of plugins. Parcel is always set out of the box, so if you're using your Bundler, your existing Bundler to bundle your test, you get that watch feature for free, so it's another complexity that the BigTest CLI kind of eliminates. CHARLES: What it means is we've hidden most of that complexity. Just let the Bundler handle it, right? The Bundler is the part of your project that bundles. WIL: Yeah. CHARLES: You should have your launcher actually doing that for you but we still do need to have some way to do that set up and tear down. When we have that testing endpoint, we have some way to say, "We're starting a test, not the application. We're ending the test, tear it down," so how do you abstract that away? WIL: That's kind of something that we can't really avoid. It is just like some sort of dependency on the framework itself, your application framework. It's like you need to mount a React app. You need to mount an Ember app, etcetera and there's different ways to mount those things. This is one of the things that can't really be decoupled as much as everything else can but BigTest has BigTest React and BigTest Vue and we want to eventually gets like BigTest Ember but really, the main export of all these packages is just a simple mount helper that will mount and clean up your application for you and your testing hooks, whether you're using before each from Mocha or before from something else like Jasmine. You know, no matter what you're doing, you just have a hook that mounts your application and then, cleans it up on the next mount. CHARLES: It's worth pointing out here that this is kind of a core concern of testing and testing big is being able to mount your application and tear it down with regularity and having hooks into that process. Whether you're using BigTest or whether you're not, can you still use BigTest React and BigTest Vue, even if you weren't using anything else? WIL: Yeah, absolutely. Like I said, they just export simple mount helpers. I don't even think they have any other inner BigTest dependencies. They just have pure dependencies on their frameworks. CHARLES: Right and so, you could use it, even if you wanted to roll everything else by hand or you wanted to get started somehow and you needed to do set up and tear down, again this is something that's key to being able to test big, so you should be able to use it independently, whether you use the CLI or not, whether you're using any of the other tools or not. All of the tools can be used independently. WIL: Then another feature of the BigTest React and BigTest Vue is the tear down that happens before set up, rather than happening after your test runs, having a separate tear down. This allows it. Whether your test passes or fails, you can look at it and play with it and inspect it and debug it much easier than if you had tear down. You have to disable at tear down or throw a pause in there to keep other or something. CHARLES: Yeah, I love that. When something goes wrong, you can just let the test case run and the last test that it runs, it just leaves at set up. It does the tear down right before the set up. WIL: Exactly, yeah. At the very end of the whole test run, there's an app there waiting for you to play with. CHARLES: If you focus in on a single test, we most commonly use Mocha, so you say a '.only' to run that single focus test, then you have the state of the application at that test case set up and ready to go. You can just play with it, you can inspect it, you can actually just use it as a starting off point and interact with the app normally as you would. WIL: I want to say, Cypress does this too. They do their tear down before they're set up as well. That's how you're able to play with Cypress test. CHARLES: Yeah, I like that trick. Now, we talked about launching, setup and tear down but we haven't actually talked about much of what actually happens in the test cases themselves. We talked about how to start and launch your test suite, how to do that across a bunch of different browsers, how inside of that, you have a separate concern as applications set up and tear down and how you want to lean on how you're actual app is actually bundled because that fits in with the philosophy of testing big. You don't want to use an external Bundler for your test suite. You want to use your real Bundler, how the asset is actually going to look. But when it comes down to actually writing the tests, you need to be able to interact with at the highest level as you possibly can. When I say highest level, we want to verify that the users, when they take certain actions, we'll see certain outcomes and so, we want those outcomes and we already talked about this to be reflected in a real DOM, in a real browser. But at the same time, the real interactions, we want those to be as high fidelity as possible, so you want to be sending events to the browser. You want real mount events, real key events, real interactions. WIL: Yeah, interacting with application. That's another core philosophy that we kind of talked about earlier that defines a BigTest. It's the user interacting with your application. We're not calling methods and expecting other callbacks or arguments to be passed or clicking on a button and expecting a message to pop up that says, "Form submitted successfully." These are user-facing things were starting on and acting on. CHARLES: Yeah and then, it can be really tricky because these things don't happen synchronously. They're happening inside of your browser's event loop. I click that button and then it goes off and there's some loading state and then, I might get an error message that pops up this thing that animates out and then, goes away. The state of the browser is in constant flux. It's constantly changing and so, it can be very difficult to put your finger and say, I want to be in this state if you are limiting yourself to only reading from the DOM. Some frameworks, Ember for example, you have kind of a white box where you can actually inspect the state of the Ember run loop and use that to do some synchronization but it can be very, very hard to coordinate these interactions. WIL: Yeah. You know, to talk about getting to the solution as a BigTest interactor, which is basically modern page components or page objects. If you ever heard of page objects, it's just a way to encapsulate interacting with big pieces of your pages. It's not a new concept. It's been around for a while but BigTest interactor has kind of a new twist on it where they're immutable, composable interactions that are also convergent, which we'll get into later, which basically means if your buttons not there, it won't click the button until it is there. They're really powerful and they're making really easy and fun to write these tests. CHARLES: Yeah, they're super powerful. I remember we talked about convergences last time when we talked about BigTest but interactors, I think are definitely a new development. I think we should spend a little bit of time there talking about, not just the power but also the ergonomics of interactors because they are like page components or page objects, except they're scope to the component. Not only do they have all this wonderful stuff where it'll make sure that the component exists before it starts to interact with it and things like that but their composable. If I have a button, then there are certain operations that are valid for that button. I can click it. I can hover over it. I can do all these things. They're the operations that make it unique to the button. Now, those might actually map to real events. WIL: Similarly, their assertions about that button as well, like as primary is secondary. If this button is repeated throughout your application, you might want to make sure that your form has a primary and secondary button. CHARLES: Exactly. It really encapsulates all the knowledge of how you can interact with both in terms of taking action and reading state from that button. It almost feels like an accessibility API. It would be easy to write a screen reader if you had these interactors for every single component on the page. WIL: That's kind of what it is. It's just like you're defining an API around how your user would interact with your application and what your user would expect in the application. That's the point of page objects and interactors as you're defining this user API, essentially. CHARLES: Yeah and so, really the step that interactor take is that they take the classic page object and it make them composable, so I can have, you kind of touched on this before, a modal dialogue interactor, which is composed out of two button interactors. One for the primary action, one for the secondary action and maybe, it's aware of its own title text, so you can assert on the title text but I didn't actually have to write the individual button interactors for that modal dialog interactor. Then I might have a second modal dialog interactor or a form that's on a modal dialog just composed of the modal dialog interactors and the individual form components, which appear on that particular modal dialog. WIL: It's essentially how we've been building applications lately with components but this is for page objects in your test if you want to mirror that. You don't have to have one-to-one mappings of an interactor to a component but if you do, it's really powerful. CHARLES: Yeah. I found that when we have one-to-one interactors, that's when it just feels the best. WIL: Yeah and on top of this, if you have a component library and your component library exports the interactor that it uses for the component test, like we said, this BigTest technology, they're sprinkled also. We don't have to use interactors in big acceptance tests. We can use them for smaller component tests too, so if we ship these component interactors with the component library, your application that's consuming this component library now can test those components for free, without having to write their own interactors. It can just compose the interactors exported by the library. CHARLES: Man, I almost want you to repeat that word for word again, just so it can sink in. It's so awesome. Because when you actually go to write your tests, you're not starting from ground zero like, "How do I do this?" They're like, "I'm writing some tests for this thing and I'm using these components and so, I've already got the prepackaged interactions for those components." It's like you start writing your tests. If your tests are a 10-story building, it's like you're starting on Floor 7 and you only have to walk up to Floor 10, instead of slogging up all 10 stories. WIL: One really helpful interactor that we work within the open source stuff we've been working on is a date-picker interactor because date-pickers can be really complex. Just having that common interactor and have a date-picker on multiple forms where we can just use that one interactor, we don't have to tell every single test how to interact with that date-picker. We just say pick date and pass the date. CHARLES: Yeah, it's so awesome. That is actually a great example. It doesn't feel scary to write a test for a page that has a date-picker on it or two. If you're doing like a date range or something like that, you're like, "Oh, my God. I don't write the selectors to test this." You just import your date-picker interactor, you set the date, it actually worries about all the low level events and there you go. It feels like you're operating at a much higher level. WIL: Yeah. The interactor API essentially, you're telling me the test what the user would be doing and what the user would be seeing. CHARLES: Yeah. It's worth pointing out again. We've identified starting and launching. We've identified set up and tear down but interaction is a core concern of BigTesting, no matter what tool you're using. One of the things that we found as interactors are something that you can sprinkle on literally any test suite if you're testing an interface and it makes it better. We've used it inside big acceptance tests. We use it inside Jest, doing just little component tests. There are people in the BigTest community who have used it to basically, write component tests against a JS DOM and while theoretically, philosophically, you want to make those tests as big as you possibly can, you can use that piece in your test suite. If you are using a simulated DOM and if you're running a node in a browser, these interactors will still work and you're going to get high fidelity test cases that are resilient to this asynchrony and are composable and if they do have a full-fledged test suite, you can reuse these interactors. They are a really awesome power up that you can bring into your test suite. WIL: And they are not tied to the framework at all. We use them in React for our stuff but we've also written some in Ember. Robert's written some in the Vue and ported some test and one of the beautiful things we've seen from this is that one interactor goes everywhere. You just write the interactor once and you can use it in Ember, in React, in Vue, in those test suites. If the rest of your test suite is framework agnostic, you have this test suite that you can jump frameworks in your test suites until it works and can test your application with high fidelity. CHARLES: Yeah, it's fantastic. I remember when we first tried using interactors inside an Ember test suite because Ember comes with like a big kitchen sink in testing set up but interactors just slotted right in and there's absolutely no issue. WIL: Yeah and there is actually a speed boost even because in most of the Ember test offers a hook into the Ember run loop and interactors are not. There is actually a good speed boos just using interactors. CHARLES: Yeah. This is a good point. It's a good segue because typically, we think of acceptance tests as being really slow and one of the reasons, even the people [inaudible] acceptance tests or testing big as they think like it's going to take a long time. We found that actually we've been able to maintain a happy medium of testing big but also, having those test be really, really fast. When you say you said a speed boost from using interactors with Ember, where is that speed boost actually come from? WIL: I mentioned the Ember test offers a hook into the Ember run loop and interactors aren't and the reason of this is because interactors are converging and they wait for things in the DOM to exist before interacting with them. Instead of waiting for the framework to settle, it just waits for the thing to appear and then interacts with it immediately. If you're starting something about a button toward the top of the page, you don't really care that another button at the bottom of the page has rendered yet, unless of course you have assertion about that but if they're converging, you don't need to hook into the wrong loop to wait for the entire page to load, to interact with just one piece of it. CHARLES: Right. You're just waiting and you say, "I'm expecting something to happen and the moment I detect it, no matter what else is going on, the page could be taking 30 seconds to load but if that button appears and I can interact with it, I can take my action then or I can make my assertion then." It's about kind of removing gates -- artificial gates. WIL: Yeah. Another common thing that's helped with is animations as most test that are hooked into the run loop, you kind of have to wait for some of these animations to finish before you can even interact with the element and that means if a model has a half second animation where it flies in and you have 30 tests around this modal, those tests are extremely slow now because you have to wait for that modal to come in, whereas -- CHARLES: -- Straight up flaky. WIL: Yeah, straight up flaky. Whereas in the actual DOM, that modal is inserted pretty immediately and can be interacted with pretty immediately. With interactors, they don't need to wait for the animation to finish. They can just immediately interact with that modal but of course, if you need to wait for the animation to finish, there are options for that as well. CHARLES: Yeah. If there's some fade in that needs to happen, you can kind of assert on any state and as long as it's achieved at some point, the interactor will recognize it and recognize it at the soonest possible time that it possibly could. I remember getting bitten on one project where the modal animations in particular were so brutal. Not only were they flaky, they just were slow because there was all these manual time outs. It wasn't even a paper cut. It was kind of like a knife cut, like there's someone sitting there and kind of slashing you with a pocket knife. It just was a constant source of pain in your side. WIL: Yeah and that's how you end up with things like waits and sleeps in your test suite. When you need to wait for the animation to happen or something, you just see a sleep for four seconds with a comment because we have to wait for the components to load in. That's kind of a code now. CHARLES: Yeah, that's just asking for trouble both in terms of slowness and in terms of it's going to get flaky again. That has been kind of one the most freeing things about working with interactors and working with convergent assertions on which they're based is you just don't ever have to worry about asynchrony. Really, really truly, most of the time, you're writing your tests, like it's all synchronous and that kind of makes sense because from the user's perspective, their consciousness is synchronous and they don't care about the internal run loop. It's just they were making observations in serial and at some point, they're going to observe something, so the interactor sits at that point and really observes the application the way that your user would. WIL: Yeah. We've mentioned a few times now the convergent assertions, which interactors are based on. A little caveat there if you're using interactors and you're making non-convergent assertions, they might fail or be flaky. That's because interactors wait for the thing to be there to interact with, so as soon as the buttons there, it clicks it but it doesn't wait for after that event has fired and your application has reacted to that event, that's your application is concerned. We need something there like our convergent assertions that can converge on that state and wait for that state to be true before it considers itself passing or in times out. CHARLES: Maybe we should dig a little bit into convergent assertions. I think the last time we had a public conversation on the podcast about this, this is kind of where we were, like we hadn't built the interactors, we hadn't built these other component pieces of the testing story. We were really focused on the convergent assertion. We've talked a little bit about this but I think it's worth rehashing a little bit because it's a unique way of approaching the system but it's also kind of horrifying when you see how it works under the covers. I think when we tell people about the fact that it's basically polling underneath the covers. The timeout is configurable but it's basically polling every 10 milliseconds to observe a state. I remember the first time being confronted with this idea and I was horrified and like my programmer hackles on the back of my neck, like raised up and I was like, "Wait a minute. This is going to be slow. It's going to be computationally intensive." WIL: Yeah. That was my exact thought too because this is going to be slow. If acceptance tests are slow and we're doing an acceptance test every 10 milliseconds, it's going to be really slow and that's actually not the case completely. It's actually the opposite. They're extremely fast. CHARLES: It is shockingly fast. You've got to try it to believe how fast it is, how fast you can run acceptance tests. WIL: Yeah, talking like 100 tests in just tens of seconds. CHARLES: Right. You basically gated by how fast your framework can render. Your tests are not part of the slowness. Your test -- WIL: And also, memory leaks can be costly too. We experience that recently where we had memory leaks that were slowing down our test but we fixed those up in test and put our backup. CHARLES: Yeah, because basically, running the assertion or running the convergence is very fast. It's just a very light ping. I kind of think of it is as it is light as the brush of a photon or something that was bouncing off of a surface, so that you can observe it. It's extremely light and most of the time, it's just waiting so the test and the convergence really just gets out of the way. Just because they can run a thousand times or a hundred times in a second, it's doesn't gun it up. But the thing is it means that your tests run as fast as your application will run. You get back to the point... Was it in React where the kind of the key insight is that JavaScript is not the bottleneck? Well, your tests are not the bottleneck. WIL: Yeah. CHARLES: I guess this is what it is. I don't know if there's anything else that you want to say about convergences. WIL: No. We pretty much summed it up there and that's what interactors are based on. That's how they're able to wait for things in a DOM. It basically polls the DOM until it exists and then it moves on and actually does the interaction. CHARLES: Once again, this is actually a very low level thing on which BigTest is based but this is once again, something that you can use independently. You can write your own convergent assertions. You can write your own convergences that honestly have nothing to do with testing your assertions. It's a free standing library that you can use in your test suite or elsewhere should you choose. WIL: That doesn't need to be a DOM for BigTest convergence there. I use BigTest convergence in BigTest CLI to converge on the browser being launched. Instead of waiting for the browser to report that, I can just kind of poll and see how that process is doing and the convergence waits for that process to start before moving on. CHARLES: Right. I guess the best way I've thought about it it's a way to synchronize on observations and not on callbacks. It's a synchronization mechanism and 99% of the synchronization mechanisms that we're used to, they've involved some sort of callback, a promise, an event-listener, things like that or even a generator where control is handed back explicitly to a piece of code when something happens. Whereas, this is a fundamentally different synchronization primitive, where you are writing synchronous code that's based on observations, so what I observe this, do this. When I observe this, do this. It's extremely robust. WIL: Yeah, very. CHARLES: It is a core piece. A fundamental thing that on which interactors are based on, which the CLI is based, I don't know if it's core to writing tests but -- WIL: It definitely helps. CHARLES: It doesn't helps. We couldn't have BigTest interactor without that. WIL: No, definitely not. CHARLES: Because that's what makes it fast, that's what makes it not flaky at all and having those things, I think it makes it easy to maintain because you can work at the interactor level or the level of user interaction and you don't have to worry about synchronization, so the flow of your tests are very natural. WIL: Yeah. We don't have to explicitly wait for request to be done for making an assertion about your app. That'll just come with convergences, just waiting for test date in application to true. CHARLES: Let's talk about one more piece of the testing issue because when you're testing big, when you're testing in the browser, there's always the issue of what are you going to do about your API. You got to have your API running. It's just always an issue and this is kind of interesting because this sits at the crossroads of testing big and also, getting the most utility out of your test because in an ideal world, if you're testing really big, you're going to be using a real API. You're not going to poke holes in reality. WIL: Yeah. One of the things that we avoid in BigTest is poking holes. We're not shallow mounting the components and testing the methods and the results. We're fully mounting these things and fully interacting with them through the full DOM API. CHARLES: Yeah, exactly, using real browsers. It just occurred to me the irony of us talking about reality being things that are still running inside of a computer processor. I think we've inherited this term from that talk that Justin Searls at AssertJS in 2017. It's a really, really excellent talk. I think he gave it at RubyConf. It's the 'Don't mock me.' WIL: Yeah, it's one of my favorite talks. CHARLES: Yeah, it's a great talk. In it, he talks about the value of a test is a balance of how many holes you poke in reality and sometimes, you encounter a test where all it is like holes in reality. Whether you're mocking this, you're mocking that, you're mocking the DOM, you're mocking the browser, you're mocking your network layer, you're mocking this external API and the more holes you poke, the less useful it's going to be. Network is one of those where it can be very difficult to not poke holes in that reality because it's a huge part of your application. Your frontend application is how it's going to interact with the server but at the same time, servers are gigantic pieces of software themselves, each with their own dependencies, each with their own set up and tear down -- WIL: Have their own concerns. CHARLES: Yeah, exactly. They might be in a different language. They've got runtime, things like they might need external C libraries and crazy stuff like that. They're their own beast. To get a true big end-to-end test, you going to have to stand up your server but the problem that presents is you want your tests to be also isolatable. If you're a developer, I can go to a repo, I can do an install of my dependencies and I can run the tests without having to do any external dependencies other than the repository and the language in which I'm working. This is one where we kind of have tried to walk the line of not wanting to poke holes in reality but also, have the test be containable to the actual application. In order to do that, you need something that presents a high fidelity version of the network. You can kind of try and have your cake and eat it too. You want to have something that acts like a server and really acts like a server but it's actually not a server. WIL: And still poke as few holes as possible and the application and how that's all set up, we don't want to be intercepting methods and responding with fake data. That's not a good way to mock that network. CHARLES: Right. We want to be calling actual fetches, calling actual XMLHttpRequest. Ideally, if you've got service workers, making actual service worker requests. WIL: Basically, as far as the application is concerned, it's talking to a real server on us. CHARLES: Yeah and that's kind of the litmus test for is it a hole in reality or is it just a really great illusion? WIL: Yeah and that's a good name for Mirage, right? It's a really great illusion. CHARLES: Yeah. It is a simulation of reality, so we use Mirage, which is something from the Ember testing world but something that we have extracted and made available as BigTest Mirage. WIL: Yeah. The main difference just being is that we've taken away the Ember dependencies and the run loop stuff. It's just plain JavaScript Mirage. It works exactly the same as you use it in Ember minus the auto imports and the file... Oh, man. I can't think of that word. Aside from automatically importing your files for your server config, you have to do that manually because Ember is what provides that but other than that, it's a form of Mirage. You define models and serializers and factories and all the good stuff. CHARLES: Right and then you can use those factories and you can use those models to really give a high fidelity server. If you are building something in whatever framework, you can use BigTest Mirage to simulate that network layer. Again, we've used it in a number of different scenarios but having that in place means that you're going to be able to have those high fidelity tests where your application is actually making XMLHttpRequest but it's all isolatable, so that it can be run in repo. This isn't really related to testing but it has a fantastic capability where you can prepopulate, you can use the factories to prepopulate your server with data, so that you can use the application without the actual server being implemented. WIL: Yeah. That's extremely powerful. That's we were talking about earlier and getting at is the scenarios which are setting up specific, essentially fixtures but you're generating these fixtures. Factories are essentially high level fixtures, network of fixtures. CHARLES: Yeah, higher order of fixtures. WIL: Yeah, so the scenarios are just setting up these fixtures for a scenario of your applications, like the backend is down or the list only responds with two items as opposed to 5000 items, something like that. You want to be able to, not only test these things but be able to develop against it and Mirage makes that really easy because you can just start your app with Mirage-enabled point to that scenario and you're there. You have that exhausted scenario to develop in. CHARLES: If you've never used Mirage, it is really hard to understand just how incredibly powerful it can be. We've used it now on at least four projects, where we did develop the entire first version of the product without any backend whatsoever. It's an incredible product development tool, even apart from testing, that then informs the shape of what the API was going to be. I know we've talked about this on the podcast before but it's really an incredible technology and it is available to you no matter what framework you're using. I think it's one of the best kept secrets in JavaScript development. WIL: Yeah. That's definitely great. That said, though it does have some fallacies. It's great but it can be a little slow sometimes, so we are eventually working on a BigTest network like another piece of the BigTest pie that you'll be able to sprinkle into your application but in the meantime, praise Mirage. CHARLES: Yeah. We are going to be offering an alternative or maybe collaborating for another version of Mirage but hopefully, we can make Mirage faster, we will be able to make this thing faster, so that it can use service workers and be used in a bunch of different scenarios. Just to recap, we've talked about a lot of different components but over the past year, a couple of years, these are the things that we've identified as being really key components as big part of your acceptance testing and really your testing stack. How you're going to start and launch these things? How are you going to set them up and tear them down? How are you going to interact with the application from a user, both in terms of making assertions and how are you going to take action on behalf of the user and still have it be maintainable, have it be resistant to flakiness, have it be performant? BigTest is the answer to that for those particular areas of the testing story and so, some were using we're using existing components like we use Karma, we use Mirage to date. Those, we did not develop but where we see kind of key pieces of that puzzle missing is where we started writing the BigTest solutions so things like the interactor. Eventually, we are going to make BigTest into a product that's you're going to be able to use kind of out of the box, just like you might install Cypress, where it's a very quick set up and we make all of the decisions about the components for you. But in the meantime, we're really trying to take our time, identify those pieces of the puzzle and build the software component that fits that piece of the puzzle at the absolute best so when they're polished, use them in a more comprehensive product. Things like convergence, things like interactor, things like BigTest React, BigTest Vue and very soon, BigTest Ember. These are things that you can use today, to make your tests just that much bigger and that much better, especially interactor. It's been an incredible journey this past year as we kind of develop these individual pieces and there's just going to be more goodness to come. WIL: Absolutely. Right now, I'm working on some validation type API for interactor that I'm hoping to land soon. That'll open up the possibilities of maybe hiding away those convergent assertions a bit more in your tests and just handling this automatically. It'll be pretty good. CHARLES: It's really exciting. Writing test has got more and more easy and more and more fun over the last year for us. I think we're already starting in a pretty good place. If you have any questions about BigTest, how would folks get in touch with us? WIL: We have a BigTest Gitter channel. You can find a link to that on the BigTest website: BigTestJS.io. Just ask us questions on Gitter and we'll try to answer them. CHARLES: And as always, you can ask us directly. You can send email to Contact@Frontside.io or reach out to us on Twitter at @TheFrontside or you can actually reach out to the BigTestJS Twitter account directly and just call us on Twitter at @BigTestJS. Thank you very much, Wil. WIL: Thank you, Charles.
GUEST BIO: Justin is co-founder of Test Double, an agency of highly skilled developers on a mission to fix what’s broken in software. As well as running Test Double, Justin is also an occasional conference speaker. EPISODE DESCRIPTION: Today, Phil is talking to Justin Searls who is the co-founder of Test Double. An agency that embeds their developers into businesses to deliver the software they really need. Their approach includes refactoring legacy code, where appropriate, and mentoring the clients they work with. Justin is also an occasional public speaker. KEY TAKEAWAYS: (0.41) – Phil asked Justin to share a bit more information about himself. Justin responded by saying that he is a lifetime consultant, so has worked on many different projects. As a result, he deeply understands how software teams fail. This, in part, inspired him to start Test Double. He realized that he needed to hire developers who were passionate, positive. People who were happy to act as teachers and mentors while fixing company’s software issues. (2.37) – Phil asks Justin to share a unique career tip. Justin explains that following your passions all of the time was not necessarily a good idea, at least in the long-term. He explained that when speaking at universities most students say they want to be games developers. This is understandable, but the market is flooded with games developers. So, many of those who go ahead and follow what they love end up being paid relatively low wages. When Justin started out he resisted the temptation to just do things he liked. He focused on JavaScript testing. At the time only a few other people were doing that. So, they ended up with an almost unique, highly sought-after skill set. Justin focused on what people needed more than what he wanted, which led to a successful career. (5.39) – Justin is asked about his worst career moment. For Justin that happened when he was working for a major financial institution. Many of their transactions had to be confirmed and recorded in writing, so they received around 40,000 pieces of mail every day. It all had to be opened and processed manually. Justin was a key part of the team that put together an OCR style system that would capture all of that data and improve the efficiency of the mail system. On the night of the handover, all of the servers went down. Justin had no internet and because the phones were VOIP no way of communicating with anyone. It turns out a cleaner had knocked a fire extinguisher over in the server room, which pressed the cut out button. It took the firm days to get the old system back online. Then they still had to go through the process of moving to the new system. It was a disaster. That experience showed Justin how important continuous delivery is when switching to new systems. Taking an incremental approach when you can is far safer and more efficient in the long run. (8.56) – Phil asks Justin to share a career highlight. Justin explained that Double Test now employs 40 people all of whom work remotely. Most of them rarely meet each other. However, every now and again they get together at a mentor retreat with their plus ones. Seeing them all together like that, the first time, made him realize that he had played a role in creating a group of people who all respected and cared for each other and were able to pull together as an effective team. For Justin, that was a truly joyful moment, a career highlight. (10.55) – Phil wants to know what excites Justin about the future for the IT industry. Justin starts by saying if you were to ask a group of business leaders about who would be coding in 10 years you would get conflicting answers. Half would say everyone, while the rest would say nobody. He suspects that both sides are right to some extent. Some things will be done automatically, but everyone will end up at least tinkering with code. For example, the Siri shortcuts that have recently been released will allow users to create their own custom workflows. The future of coding is going to be different, which is exciting and brings all kinds of opportunities. (15.36) – Phil asked Justin what drew him to a career in IT. Justin got the bug at a young age. On a school vacation his luggage was lost, which meant that he did not have the clothing he needed to be able to spend time outside. So, he was stuck indoors with just what was in his backpack. That happened to be his homework and a graphing calculator. Using this tiny handheld computer he started to program simple games. That was it, Justin had the IT bug. At that point he realized that coding opened up untold (17.25) – What is the best career advice you have been given? Justin says he was advised to live below his means for as long as possible as a student and after qualifying. He did it for a long time and saved up a lot of money. Doing this gives you the financial freedom to move jobs whenever you want. There is no need to be stuck in a bad job or one where you are not growing your skills. Financial safety is liberating. It makes you a better developer, you are not timid and afraid to speak up or share an idea. He also said that it is important to work on as a consultant, so you can gain experience, expand your horizons and be a well-rounded developer. (19.53) – If you were to start your career now, what would you do differently? Justin said that he would probably have progressed his career at a slower pace. He also said he would network more with people who were not from the same race, background, sex or socioeconomic class as him. The fact that he did not make an extra effort to do this at the start of his career meant that he inadvertently ended up with a firm made up almost entirely of straight white men. It is important to attend more meet-ups that include people who are different from you and have a different view of the world. (21.54) – Phil asks Justin what career objectives he is currently focusing on. When Justin and Todd founded Test Double they had to take on roles they had never trained for. Gradually, they are recruiting people to take over some of those processes. Most of the marketing and sales responsibility fell to Justin. So, currently they are developing a marketing and sales funnel that can be handed over and run successfully by someone else. (23.25) – What non-technical skill has helped you in your career so far? Justin said his liberal arts education coursework exposed him to a wide range of subjects. Having to study world religion, philosophy, history, political science and other subjects, helped to make him a more rounded and curious person. It contributed to his being good at analyzing complex algorithms. Having to absorb such an eclectic mix of information, while studying, made it easier for him to look at things from many different perspectives at once. (24.51) – Phil asks Justin to share a few final words of career advice. For Justin taking time out to observe and really think is important. Being able to control your attention and stay focused is a tremendously marketable skill. He recommends that people read Deep Work by Cal Newport and Hyperfocus by Chris Bailey to learn more about why that is and learn how to build that skill. BEST MOMENTS: (1.22) Justin - "Humans are nothing if not pattern recognition machines. You know, before there was machine learning there was learning, learning." (8.57) Justin - Speaking about implementing new projects Justin said - "If you just like let all that fear uncertainty about pile up into this big two-year event, all you're going to end up with is like, you know, a gigantic pizza party and a lot of pain." (10.55) Justin - "We have, like, mobilized effectively, a very healthy team of people who are then able to go and make other teams more healthy." (16.53) - Justin - "I just saw this tremendous potential for magic for making a computer do what I wanted it to do by dint of just spending enough time in a very tight feedback loop." (19.00) Justin - "If you are financially independent paycheck to paycheck on that job, not just disappearing, you're going to act from a defensive crouch that is more conservative." CONTACT JUSTIN SEARLS: Twitter: https://twitter.com/searls @searls LinkedIn: https://www.linkedin.com/in/searls/ Website: https://www.testdouble.com
In this episode of The Yak Shave, Sean shares the most nightmarish debugging experience he has had in a long time. rails_fast_attributes was down to one failure, which manifested itself as a test where a query was expected to run 269 times, but only ran 265 times. After testing, troubleshooting, and finding the root cause, he determined that it was actually behaving completely fine. Shopify Careers In the Testing Weeds with Sam Phippen and Justin Searls
The team continues the live-ish from JSConf US series with Test Double's Justin Searls. Listen in for a lively discussion on presentations, vulnerability, and solving complex problems. The post Episode 17: Presentations, Vulnerability, and Solving Complex Problems with Justin Searls (Live at JSConf US) appeared first on TalkScript.FM.
The team continues the live-ish from JSConf US series with Test Double's Justin Searls. Listen in for a lively discussion on presentations, vulnerability, and solving complex problems. The post Episode 17: Presentations, Vulnerability, and Solving Complex Problems with Justin Searls (Live at JSConf US) appeared first on SitePen.
Programming Languages and Communication With Kerri Miller TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Get your FREE career growth strategy information and techniques! (https://stickynote.game) Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) is updated, available, and shipping! Guest Kerri Miller (https://twitter.com/kerrizor): Senior Developer at TravisCI (https://travis-ci.org/) and Ruby Community Member. Co-Organizer of the Open Source and Feelings Conference (https://www.osfeels.com/). Blog (http://kerrizor.com/). Summary Why is Smalltalk the Elizabethan English of programming languages? Why has it been so influential, and how does the programming language you use affect the way you think about programming. On this episode, Kerri Miller and I talk about programming languages and communication, and what we've learned from our most recent programming language adventures. Notes 01:56 - Introduction Twitter Stream (https://twitter.com/kerrizor/status/974391130484752385) Creole Languages (https://en.wikipedia.org/wiki/Creole_language) Pidgin (https://en.wikipedia.org/wiki/Pidgin) 06:18 - SmallTalk is to Ruby as Elizabethan English is to Modern Day 08:11 - SmallTalk’s History Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age (https://amzn.to/2JxTtss) Squeak (http://squeak.org/) By the way, I did get the Squeak history partially wrong. The original work was done at Apple, and when they went to Disney after that, they downloaded their Apple work as Open Source to continue. (It is possibly named Squeak because they were being wooed by Disney). The technical details are basically right, though. 17:55 - Thinking About Programming and Software Projects in a Flexible Way Sapir-Whorf Hypothesis (http://www.dictionary.com/browse/sapir-whorf-hypothesis) 22:01 - Object-Oriented Programming, Thinking, and Design The Overton Window (https://en.wikipedia.org/wiki/Overton_window) 28:37 - Learning New Programming Languages, Concepts, and Techniques The Silmarillion by Tolkien (https://en.wikipedia.org/wiki/The_Silmarillion) Nothing is Something by Sandi Metz (https://www.youtube.com/watch?v=OMPfEXIlTVE) Much Ado About Naught by Avdi Grimm (http://www.virtuouscode.com/introduction-to-much-ado-about-naught/) Related Episodes Back in the Testing Weeds with Sam Phippen and Justin Searls (http://www.techdoneright.io/33) Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) The Elm Programming Language With Corey Haines (http://www.techdoneright.io/17) Special Guest: Kerri Miller.
Back in the Testing Weeds with Sam Phippen and Justin Searls TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Get your FREE career growth strategy information and techniques! (https://stickynote.game) Rails 5 Test Prescriptions (https://pragprog.com/titles/nrtest3) is updated, available, and shipping! Guests Sam Phippen (https://twitter.com/samphippen): Tech Lead at DigitalOcean (https://www.digitalocean.com/) and member of the RSpec (https://github.com/rspec) Core Team Justin Searls (https://twitter.com/searls): Co-founder of Test Double (http://testdouble.com/) Summary I'm back in the testing weeds with Sam Phippen, lead maintainer for RSpec-Rails, and Justin Searls, co-founder of Test Double and author of testdouble.js. We talk about long-running test suites: are they bad, or just misunderstood? Does parallel CI solve all testing speed problems, or just some of them? Then we move to a wider view, what does it mean to test your library as part of a larger ecosystem. And, how can we leverage coverage or CI information to make for more useful testing tools over the lifetime of a project. Notes 02:32 - Dealing with Longer and Longer Test Suites - High Cost Tests and High Value Tests (http://confreaks.tv/videos/rubyconf2017-high-cost-tests-and-high-value-tests) 09:43 - What causes people to get into this trouble? - On Writing Software Well #5: Testing without test damage or excessive isolation (https://youtu.be/Tc5z64XIwIY) 12:46 - If you had a fast test suite, would you still parallelize it in the CI? 15:12 - What does it mean for your library to still be functional? - dont-break (https://www.npmjs.com/package/dont-break) 21:35 - Bugs found via the dont-break style of testing - GRPC (https://grpc.io) 24:06 - Inferring which tests are run from a production code diff 29:31 - Coverage, what's it good for? - RSpec (http://rspec.info/) 33:53 - What kind of features would you expect out of a CI-aware testing suite? Related Episodes Part I: Episode 004: In The Testing Weeds (http://www.techdoneright.io/004-testing-with-sam-and-justin) Special Guests: Justin Searls and Penelope Phippen.
Panel: Dave Kimura Eric Berry David Richards Special Guest: Justin Searls and Josh Greenwood In this episode, the Ruby Rogues speaks with Justin Searls and Josh Greenwood. Justin and Josh both work for a software agency called Test Double, who are a fully remote software agency. Both Josh and Justin are well versed in many technologies and platforms of development such as Ruby, Javascript and much more. Both Justin and Josh are on the show to talks about their recent presentation “There's Nothing New Under the Sun,” which was presented at conferences. In particular, we dive pretty deep on: History and the knowledge of the community Abandoning Gems Exploratory The rise of Rails How much of what you do is in Ruby and Rails? New contracts - How long do they last? Secrets to onboard members or developers? Overwhelmed with projects? Where do you see Ruby in the next few years? Slowing of processors - intel Working with other languages, then into Ruby Jim! Our industry’s obsession at placing novelty/newness above deeper truths and wisdoms. Once the shine has worn off we tend to ignore it, and even the timeline-style most information consumption software is designed with goes out of its way to bury anything “old” What important context new Ruby developers tend to lack (this was the motivation for the talk in the first place) and what can we do to make them more comfortable & capable Straight up nostalgia time. Folks who’ve been in Ruby for a while should find motivation and encouragement by celebrating our past more often to remind ourselves of why we love Ruby and much much more. Links: https://github.com/searls http://testdouble.com @searls @joshtgreenwood Picks: David Gilmore Girls Programming Language - Julia Eric Orville BoJack Horseman Dave A Good Snowman is hard to build Dos Strap Justin Ruby Warrior SkyrimVR Osaka Josh Elm Space Max text editor Mini Metro
Panel: Dave Kimura Eric Berry David Richards Special Guest: Justin Searls and Josh Greenwood In this episode, the Ruby Rogues speaks with Justin Searls and Josh Greenwood. Justin and Josh both work for a software agency called Test Double, who are a fully remote software agency. Both Josh and Justin are well versed in many technologies and platforms of development such as Ruby, Javascript and much more. Both Justin and Josh are on the show to talks about their recent presentation “There's Nothing New Under the Sun,” which was presented at conferences. In particular, we dive pretty deep on: History and the knowledge of the community Abandoning Gems Exploratory The rise of Rails How much of what you do is in Ruby and Rails? New contracts - How long do they last? Secrets to onboard members or developers? Overwhelmed with projects? Where do you see Ruby in the next few years? Slowing of processors - intel Working with other languages, then into Ruby Jim! Our industry’s obsession at placing novelty/newness above deeper truths and wisdoms. Once the shine has worn off we tend to ignore it, and even the timeline-style most information consumption software is designed with goes out of its way to bury anything “old” What important context new Ruby developers tend to lack (this was the motivation for the talk in the first place) and what can we do to make them more comfortable & capable Straight up nostalgia time. Folks who’ve been in Ruby for a while should find motivation and encouragement by celebrating our past more often to remind ourselves of why we love Ruby and much much more. Links: https://github.com/searls http://testdouble.com @searls @joshtgreenwood Picks: David Gilmore Girls Programming Language - Julia Eric Orville BoJack Horseman Dave A Good Snowman is hard to build Dos Strap Justin Ruby Warrior SkyrimVR Osaka Josh Elm Space Max text editor Mini Metro
Panel: Dave Kimura Eric Berry David Richards Special Guest: Justin Searls and Josh Greenwood In this episode, the Ruby Rogues speaks with Justin Searls and Josh Greenwood. Justin and Josh both work for a software agency called Test Double, who are a fully remote software agency. Both Josh and Justin are well versed in many technologies and platforms of development such as Ruby, Javascript and much more. Both Justin and Josh are on the show to talks about their recent presentation “There's Nothing New Under the Sun,” which was presented at conferences. In particular, we dive pretty deep on: History and the knowledge of the community Abandoning Gems Exploratory The rise of Rails How much of what you do is in Ruby and Rails? New contracts - How long do they last? Secrets to onboard members or developers? Overwhelmed with projects? Where do you see Ruby in the next few years? Slowing of processors - intel Working with other languages, then into Ruby Jim! Our industry’s obsession at placing novelty/newness above deeper truths and wisdoms. Once the shine has worn off we tend to ignore it, and even the timeline-style most information consumption software is designed with goes out of its way to bury anything “old” What important context new Ruby developers tend to lack (this was the motivation for the talk in the first place) and what can we do to make them more comfortable & capable Straight up nostalgia time. Folks who’ve been in Ruby for a while should find motivation and encouragement by celebrating our past more often to remind ourselves of why we love Ruby and much much more. Links: https://github.com/searls http://testdouble.com @searls @joshtgreenwood Picks: David Gilmore Girls Programming Language - Julia Eric Orville BoJack Horseman Dave A Good Snowman is hard to build Dos Strap Justin Ruby Warrior SkyrimVR Osaka Josh Elm Space Max text editor Mini Metro
We try to answer what happens to an open source project after a developers death, we tell you about the last bootstrapped tech company in Silicon Valley, we have an update to the NetBSD Thread sanitizer, and show how to use use cabal on OpenBSD This episode was brought to you by Headlines Life after death, for code (https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death/) YOU'VE PROBABLY NEVER heard of the late Jim Weirich or his software. But you've almost certainly used apps built on his work. Weirich helped create several key tools for Ruby, the popular programming language used to write the code for sites like Hulu, Kickstarter, Twitter, and countless others. His code was open source, meaning that anyone could use it and modify it. "He was a seminal member of the western world's Ruby community," says Justin Searls, a Ruby developer and co-founder of the software company Test Double. When Weirich died in 2014, Searls noticed that no one was maintaining one of Weirich's software-testing tools. That meant there would be no one to approve changes if other developers submitted bug fixes, security patches, or other improvements. Any tests that relied on the tool would eventually fail, as the code became outdated and incompatible with newer tech. The incident highlights a growing concern in the open-source software community. What happens to code after programmers pass away? Much has been written about what happens to social-media accounts after users die. But it's been less of an issue among programmers. In part, that's because most companies and governments relied on commercial software maintained by teams of people. But today, more programs rely on obscure but crucial software like Weirich's. Some open-source projects are well known, such as the Linux operating system or Google's artificial-intelligence framework TensorFlow. But each of these projects depend on smaller libraries of open-source code. And those libraries depend on other libraries. The result is a complex, but largely hidden, web of software dependencies. That can create big problems, as in 2014 when a security vulnerability known as "Heartbleed" was found in OpenSSL, an open-source program used by nearly every website that processes credit- or debit-card payments. The software comes bundled with most versions of Linux, but was maintained by a small team of volunteers who didn't have the time or resources to do extensive security audits. Shortly after the Heartbleed fiasco, a security issue was discovered in another common open-source application called Bash that left countless web servers and other devices vulnerable to attack. There are surely more undiscovered vulnerabilities. Libraries.io, a group that analyzes connections between software projects, has identified more than 2,400 open-source libraries that are used in at least 1,000 other programs but have received little attention from the open-source community. Security problems are only one part of the issue. If software libraries aren't kept up to date, they may stop working with newer software. That means an application that depends on an outdated library may not work after a user updates other software. When a developer dies or abandons a project, everyone who depends on that software can be affected. Last year when programmer Azer Koçulu deleted a tiny library called Leftpad from the internet, it created ripple effects that reportedly caused headaches at Facebook, Netflix, and elsewhere. The Bus Factor The fewer people with ownership of a piece of software, the greater the risk that it could be orphaned. Developers even have a morbid name for this: the bus factor, meaning the number of people who would have to be hit by a bus before there's no one left to maintain the project. Libraries.io has identified about 3,000 open-source libraries that are used in many other programs but have only a handful of contributors. Orphaned projects are a risk of using open-source software, though commercial software makers can leave users in a similar bind when they stop supporting or updating older programs. In some cases, motivated programmers adopt orphaned open-source code. That's what Searls did with one of Weirich's projects. Weirich's most-popular projects had co-managers by the time of his death. But Searls noticed one, the testing tool Rspec-Given, hadn't been handed off, and wanted to take responsibility for updating it. But he ran into a few snags along the way. Rspec-Given's code was hosted on the popular code-hosting and collaboration site GitHub, home to 67 million codebases. Weirich's Rspec-Given page on GitHub was the main place for people to report bugs or to volunteer to help improve the code. But GitHub wouldn't give Searls control of the page, because Weirich had not named him before he died. So Searls had to create a new copy of the code, and host it elsewhere. He also had to convince the operators of Ruby Gems, a “package-management system” for distributing code, to use his version of Rspec-Given, instead of Weirich's, so that all users would have access to Searls' changes. GitHub declined to discuss its policies around transferring control of projects. That solved potential problems related to Rspec-Given, but it opened Searls' eyes to the many things that could go wrong. “It's easy to see open source as a purely technical phenomenon,” Searls says. “But once something takes off and is depended on by hundreds of other people, it becomes a social phenomenon as well.” The maintainers of most package-management systems have at least an ad-hoc process for transferring control over a library, but that process usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it. "We don't have an official policy mostly because it hasn't come up all that often," says Evan Phoenix of the Ruby Gems project. "We do have an adviser council that is used to decide these types of things case by case." Some package managers now monitor their libraries and flag widely used projects that haven't been updated in a long time. Neil Bowers, who helps maintain a package manager for the programming language Perl, says he sometimes seeks out volunteers to take over orphan projects. Bowers says his group vets claims that a project has been abandoned, and the people proposing to take it over. A 'Dead-Man's Switch' Taking over Rspec-Given inspired Searls, who was only 30 at the time, to make a will and a succession plan for his own open-source projects. There are other things developers can do to help future-proof their work. They can, for example, transfer the copyrights to a foundation, such as the Apache Foundation. But many open-source projects essentially start as hobbies, so programmers may not think to transfer ownership until it is too late. Searls suggests that GitHub and package managers such as Gems could add something like a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time. But a transition plan means more than just giving people access to the code. Michael Droettboom, who took over a popular mathematics library called Matplotlib after its creator John Hunter died in 2012, points out that successors also need to understand the code. "Sometimes there are parts of the code that only one person understands," he says. "The knowledge exists only in one person's head." That means getting people involved in a project earlier, ideally as soon as it is used by people other than the original developer. That has another advantage, Searls points out, in distributing the work of maintaining a project to help prevent developer burnout. The Last Bootstrapped Tech Company In Silicon Valley (https://www.forbes.com/sites/forbestechcouncil/2017/12/12/the-last-bootstrapped-tech-company-in-silicon-valley/2/#4d53d50f1e4d) My business partner, Matt Olander, and I were intimately familiar with the ups and downs of the Silicon Valley tech industry when we acquired the remnants of our then-employer BSDi's enterprise computer business in 2002 and assumed the roles of CEO and CTO. Fast-forward to today, and we still work in the same buildings where BSDi started in 1996, though you'd hardly recognize them today. As the business grew from a startup to a global brand, our success came from always ensuring we ran a profitable business. While that may sound obvious, keep in mind that we are in the heart of Silicon Valley where venture capitalists hunt for the unicorn company that will skyrocket to a billion-dollar valuation. Unicorns like Facebook and Twitter unquestionably exist, but they are the exception. Live By The VC, Die By The VC After careful consideration, Matt and I decided to bootstrap our company rather than seek funding. The first dot-com bubble had recently burst, and we were seeing close friends lose their jobs right and left at VC-funded companies based on dubious business plans. While we did not have much cash on hand, we did have a customer base and treasured those customers as our greatest asset. We concluded that meeting their needs was the surest path to meeting ours, and the rest would simply be details to address individually. This strategy ended up working so well that we have many of the same customers to this day. After deciding to bootstrap, we made a decision on a matter that has left egg on the face of many of our competitors: We seated sales next to support under one roof at our manufacturing facility in Silicon Valley. Dell's decision to outsource some of its support overseas in the early 2000s was the greatest gift it could have given us. Some of our sales and support staff have worked with the same clients for over a decade, and we concluded that no amount of funding could buy that mutual loyalty. While accepting venture capital or an acquisition may make you rich, it does not guarantee that your customers, employees or even business will be taken care of. Our motto is, “Treat your customers like friends and employees like family,” and we have an incredibly low employee turnover to show for it. Thanks to these principles, iXsystems has remained employee-owned, debt-free and profitable from the day we took it over -- all without VC funding, which is why we call ourselves the "last bootstrapped tech company in Silicon Valley." As a result, we now provide enterprise servers to thousands of customers, including top Fortune 500 companies, research and educational institutions, all branches of the military, and numerous government entities. Over time, however, we realized that we were selling more and more third-party data storage systems with every order. We saw this as a new opportunity. We had partnered with several storage vendors to meet our customers' needs, but every time we did, we opened a can of worms with regard to supporting our customers to our standards. Given a choice of risking being dragged down by our partners or outmaneuvered by competitors with their own storage portfolios, we made a conscious decision to develop a line of storage products that would not only complement our enterprise servers but tightly integrate with them. To accelerate this effort, we adopted the FreeNAS open-source software-defined storage project in 2009 and haven't looked back. The move enabled us to focus on storage, fully leveraging our experience with enterprise hardware and our open source heritage in equal measures. We saw many storage startups appear every quarter, struggling to establish their niche in a sea of competitors. We wondered how they'd instantly master hardware to avoid the partnering mistakes that we made years ago, given that storage hardware and software are truly inseparable at the enterprise level. We entered the storage market with the required hardware expertise, capacity and, most importantly, revenue, allowing us to develop our storage line at our own pace. Grow Up, But On Your Own Terms By not having the external pressure from VCs or shareholders that your competitors have, you're free to set your own priorities and charge fair prices for your products. Our customers consistently tell us how refreshing our sales and marketing approaches are. We consider honesty, transparency and responsible marketing the only viable strategy when you're bootstrapped. Your reputation with your customers and vendors should mean everything to you, and we can honestly say that the loyalty we have developed is priceless. So how can your startup venture down a similar path? Here's our advice for playing the long game: Relate your experiences to each fad: Our industry is a firehose of fads and buzzwords, and it can be difficult to distinguish the genuine trends from the flops. Analyze every new buzzword in terms of your own products, services and experiences, and monitor customer trends even more carefully. Some buzzwords will even formalize things you have been doing for years. Value personal relationships: Companies come and go, but you will maintain many clients and colleagues for decades, regardless of the hat they currently wear. Encourage relationship building at every level of your company because you may encounter someone again. Trust your instincts and your colleagues: No contractual terms or credit rating system can beat the instincts you will develop over time for judging the ability of individuals and companies to deliver. You know your business, employees and customers best. Looking back, I don't think I'd change a thing. We need to be in Silicon Valley for the prime customers, vendors and talent, and it's a point of pride that our customers recognize how different we are from the norm. Free of a venture capital “runway” and driven by these principles, we look forward to the next 20 years in this highly-competitive industry. Creating an AS for fun and profit (http://blog.thelifeofkenneth.com/2017/11/creating-autonomous-system-for-fun-and.html) At its core, the Internet is an interconnected fabric of separate networks. Each network which makes up the Internet is operated independently and only interconnects with other networks in clearly defined places. For smaller networks like your home, the interaction between your network and the rest of the Internet is usually pretty simple: you buy an Internet service plan from an ISP (Internet Service Provider), they give you some kind of hand-off through something like a DSL or cable modem, and give you access to "the entire Internet". Your router (which is likely also a WiFi access point and Ethernet switch) then only needs to know about two things; your local computers and devices are on one side, and the ENTIRE Internet is on the other side of that network link given to you by your ISP. For most people, that's the extent of what's needed to be understood about how the Internet works. Pick the best ISP, buy a connection from them, and attach computers needing access to the Internet. And that's fine, as long as you're happy with only having one Internet connection from one vendor, who will lend you some arbitrary IP address(es) for the extend of your service agreement, but that starts not being good enough when you don't want to be beholden to a single ISP or a single connection for your connectivity to the Internet. That also isn't good enough if you are an Internet Service Provider so you are literally a part of the Internet. You can't assume that the entire Internet is that way when half of the Internet is actually in the other direction. This is when you really have to start thinking about the Internet and treating the Internet as a very large mesh of independent connected organizations instead of an abstract cloud icon on the edge of your local network map. Which is pretty much never for most of us. Almost no one needs to consider the Internet at this level. The long flight of steps from DSL for your apartment up to needing to be an integral part of the Internet means that pretty much regardless of what level of Internet service you need for your projects, you can probably pay someone else to provide it and don't need to sit down and learn how BGP works and what an Autonomous System is. But let's ignore that for one second, and talk about how to become your own ISP. To become your own Internet Service Provider with customers who pay you to access the Internet, or be your own web hosting provider with customers who pay you to be accessible from the Internet, or your own transit provider who has customers who pay you to move their customer's packets to other people's customers, you need a few things: Your own public IP address space allocated to you by an Internet numbering organization Your own Autonomous System Number (ASN) to identify your network as separate from everyone else's networks At least one router connected to a different autonomous system speaking the Border Gateway Protocol to tell the rest of the Internet that your address space is accessible from your autonomous system. So... I recently set up my own autonomous system... and I don't really have a fantastic justification for it... My motivation was twofold: One of my friends and I sat down and figured it out that splitting the cost of a rack in Hurricane Electric's FMT2 data center marginally lowered our monthly hosting expenses vs all the paid services we're using scattered across the Internet which can all be condensed into this one rack. And this first reason on its own is a perfectly valid justification for paying for co-location space at a data center like Hurricane Electric's, but isn't actually a valid reason for running it as an autonomous system, because Hurricane Electric will gladly let you use their address space for your servers hosted in their building. That's usually part of the deal when you pay for space in a data center: power, cooling, Internet connectivity, and your own IP addresses. Another one of my friends challenged me to do it as an Autonomous System. So admittedly, my justification for going through the additional trouble to set up this single rack of servers as an AS is a little more tenuous. I will readily admit that, more than anything else, this was a "hold my beer" sort of engineering moment, and not something that is at all needed to achieve what we actually needed (a rack to park all our servers in). But what the hell; I've figured out how to do it, so I figured it would make an entertaining blog post. So here's how I set up a multi-homed autonomous system on a shoe-string budget: Step 1. Found a Company Step 2. Get Yourself Public Address Space Step 3. Find Yourself Multiple Other Autonomous Systems to Peer With Step 4. Apply for an Autonomous System Number Step 5. Source a Router Capable of Handling the Entire Internet Routing Table Step 6. Turn it All On and Pray And we're off to the races. At this point, Hurricane Electric is feeding us all ~700k routes for the Internet, we're feeding them our two routes for our local IPv4 and IPv6 subnets, and all that's left to do is order all our cross-connects to other ASes in the building willing to peer with us (mostly for fun) and load in all our servers to build our own personal corner of the Internet. The only major goof so far has been accidentally feeding the full IPv6 table to our first other peer that we turned on, but thankfully he has a much more powerful supervisor than the Sup720-BXL, so he just sent me an email to knock that off, a little fiddling with my BGP egress policies, and we were all set. In the end, setting up my own autonomous system wasn't exactly simple, it was definitely not justified, but some times in life you just need to take the more difficult path. And there's a certain amount of pride in being able to claim that I'm part of the actual Internet. That's pretty neat. And of course, thanks to all of my friends who variously contributed parts, pieces, resources, and know-how to this on-going project. I had to pull in a lot of favors to pull this off, and I appreciate it. News Roundup One year checkpoint and Thread Sanitizer update (https://blog.netbsd.org/tnf/entry/one_year_checkpoint_and_thread) The past year has been started with bugfixes and the development of regression tests for ptrace(2) and related kernel features, as well as the continuation of bringing LLDB support and LLVM sanitizers (ASan + UBsan and partial TSan + Msan) to NetBSD. My plan for the next year is to finish implementing TSan and MSan support, followed by a long run of bug fixes for LLDB, ptrace(2), and other related kernel subsystems TSan In the past month, I've developed Thread Sanitizer far enough to have a subset of its tests pass on NetBSD, started with addressing breakage related to the memory layout of processes. The reason for this breakage was narrowed down to the current implementation of ASLR, which was too aggressive and which didn't allow enough space to be mapped for Shadow memory. The fix for this was to either force the disabling of ASLR per-process, or globally on the system. The same will certainly happen for MSan executables. After some other corrections, I got TSan to work for the first time ever on October 14th. This was a big achievement, so I've made a snapshot available. Getting the snapshot of execution under GDB was pure hazard. ``` $ gdb ./a.out GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64--netbsd". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./a.out...done. (gdb) r Starting program: /public/llvm-build/a.out [New LWP 2] WARNING: ThreadSanitizer: data race (pid=1621) Write of size 4 at 0x000001475d70 by thread T1: #0 Thread1 /public/llvm-build/tsan.c:4:10 (a.out+0x46bf71) Previous write of size 4 at 0x000001475d70 by main thread: #0 main /public/llvm-build/tsan.c:10:10 (a.out+0x46bfe6) Location is global 'Global' of size 4 at 0x000001475d70 (a.out+0x000001475d70) Thread T1 (tid=2, running) created by main thread at: #0 pthreadcreate /public/llvm/projects/compiler-rt/lib/tsan/rtl/tsaninterceptors.cc:930:3 (a.out+0x412120) #1 main /public/llvm-build/tsan.c:9:3 (a.out+0x46bfd1) SUMMARY: ThreadSanitizer: data race /public/llvm-build/tsan.c:4:10 in Thread1 Thread 2 received signal SIGSEGV, Segmentation fault. ``` I was able to get the above execution results around 10% of the time (being under a tracer had no positive effect on the frequency of successful executions). I've managed to hit the following final results for this month, with another set of bugfixes and improvements: check-tsan: Expected Passes : 248 Expected Failures : 1 Unsupported Tests : 83 Unexpected Failures: 44 At the end of the month, TSan can now reliably executabe the same (already-working) program every time. The majority of failures are in tests verifying sanitization of correct mutex locking usage. There are still problems with NetBSD-specific libc and libpthread bootstrap code that conflicts with TSan. Certain functions (pthreadcreate(3), pthreadkeycreate(3), _cxaatexit()) cannot be started early by TSan initialization, and must be deferred late enough for the sanitizer to work correctly. MSan I've prepared a scratch support for MSan on NetBSD to help in researching how far along it is. I've also cloned and adapted the existing FreeBSD bits; however, the code still needs more work and isn't functional yet. The number of passed tests (5) is negligible and most likely does not work at all. The conclusion after this research is that TSan shall be finished first, as it touches similar code. In the future, there will be likely another round of iterating the system structs and types and adding the missing ones for NetBSD. So far, this part has been done before executing the real MSan code. I've added one missing symbol that was missing and was detected when attempting to link a test program with MSan. Sanitizers The GCC team has merged the LLVM sanitizer code, which has resulted in almost-complete support for ASan and UBsan on NetBSD. It can be found in the latest GCC8 snapshot, located in pkgsrc-wip/gcc8snapshot. Though, do note that there is an issue with getting backtraces from libasan.so, which can be worked-around by backtracing ASan events in a debugger. UBsan also passes all GCC regression tests and appears to work fine. The code enabling sanitizers on the GCC/NetBSD frontend will be submitted upstream once the backtracing issue is fixed and I'm satisfied that there are no other problems. I've managed to upstream a large portion of generic+TSan+MSan code to compiler-rt and reduce local patches to only the ones that are in progress. This deals with any rebasing issues, and allows me to just focus on the delta that is being worked on. I've tried out the LLDB builds which have TSan/NetBSD enabled, and they built and started fine. However, there were some false positives related to the mutex locking/unlocking code. Plans for the next milestone The general goals are to finish TSan and MSan and switch back to LLDB debugging. I plan to verify the impact of the TSan bootstrap initialization on the observed crashes and research the remaining failures. This work was sponsored by The NetBSD Foundation. The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can: The scourge of systemd (https://blog.ungleich.ch/en-us/cms/blog/2017/12/10/the-importance-of-devuan/) While this article is actually couched in terms of promoting devuan, a de-systemd-ed version of debian, it would seem the same logic could be applied to all of the BSDs Let's say every car manufacturer recently discovered a new technology named "doord", which lets you open up car doors much faster than before. It only takes 0.05 seconds, instead of 1.2 seconds on average. So every time you open a door, you are much, much faster! Many of the manufacturers decide to implement doord, because the company providing doord makes it clear that it is beneficial for everyone. And additional to opening doors faster, it also standardises things. How to turn on your car? It is the same now everywhere, it is not necessarily to look for the keyhole anymore. Unfortunately though, sometimes doord does not stop the engine. Or if it is cold outside, it stops the ignition process, because it takes too long. Doord also changes the way your navigation system works, because that is totally related to opening doors, but leads to some users being unable to navigate, which is accepted as collateral damage. In the end, you at least have faster door opening and a standard way to turn on the car. Oh, and if you are in a traffic jam and have to restart the engine often, it will stop restarting it after several times, because that's not what you are supposed to do. You can open the engine hood and tune that setting though, but it will be reset once you buy a new car. Some of you might now ask themselves "Is systemd THAT bad?". And my answer to it is: No. It is even worse. Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value. And this is not theoretical: We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu. Yes, you read right: too expensive. While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Using cabal on OpenBSD (https://deftly.net/posts/2017-10-12-using-cabal-on-openbsd.html) Since W^X became mandatory in OpenBSD (https://undeadly.org/cgi?action=article&sid=20160527203200), W^X'd binaries are only allowed to be executed from designated locations (mount points). If you used the auto partition layout during install, your /usr/local/ will be mounted with wxallowed. For example, here is the entry for my current machine: /dev/sd2g on /usr/local type ffs (local, nodev, wxallowed, softdep) This is a great feature, but if you build applications outside of the wxallowed partition, you are going to run into some issues, especially in the case of cabal (python as well). Here is an example of what you would see when attempting to do cabal install pandoc: qbit@slip[1]:~? cabal update Config file path source is default config file. Config file /home/qbit/.cabal/config not found. Writing default configuration to /home/qbit/.cabal/config Downloading the latest package list from hackage.haskell.org qbit@slip[0]:~? cabal install pandoc Resolving dependencies... ..... cabal: user error (Error: some packages failed to install: JuicyPixels-3.2.8.3 failed during the configure step. The exception was: /home/qbit/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-x86_64-openbsd-ghc-7.10.3: runProcess: runInteractiveProcess: exec: permission denied (Permission denied) The error isn't actually what it says. The untrained eye would assume permissions issue. A quick check of dmesg reveals what is really happening: /home/qbit/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-x86_64-openbsd-ghc-7.10.3(22924): W^X binary outside wxallowed mountpoint OpenBSD is killing the above binary because it is violating W^X and hasn't been safely kept in its /usr/local corral! We could solve this problem quickly by marking our /home as wxallowed, however, this would be heavy handed and reckless (we don't want to allow other potentially unsafe binaries to execute.. just the cabal stuff). Instead, we will build all our cabal stuff in /usr/local by using a symlink! doas mkdir -p /usr/local/{cabal,cabal/build} # make our cabal and build dirs doas chown -R user:wheel /usr/local/cabal # set perms rm -rf ~/.cabal # kill the old non-working cabal ln -s /usr/local/cabal ~/.cabal # link it! We are almost there! Some cabal packages build outside of ~/.cabal: cabal install hakyll ..... Building foundation-0.0.14... Preprocessing library foundation-0.0.14... hsc2hs: dist/build/Foundation/System/Bindings/Posix_hsc_make: runProcess: runInteractiveProcess: exec: permission denied (Permission denied) Downloading time-locale-compat-0.1.1.3... ..... Fortunately, all of the packages I have come across that do this all respect the TMPDIR environment variable! alias cabal='env TMPDIR=/usr/local/cabal/build/ cabal' With this alias, you should be able to cabal without issue (so far pandoc, shellcheck and hakyll have all built fine)! TL;DR # This assumes /usr/local/ is mounted as wxallowed. # doas mkdir -p /usr/local/{cabal,cabal/build} doas chown -R user:wheel /usr/local/cabal rm -rf ~/.cabal ln -s /usr/local/cabal ~/.cabal alias cabal='env TMPDIR=/usr/local/cabal/build/ cabal' cabal install pandoc FreeBSD and APRS, or "hm what happens when none of this is well documented.." (https://adrianchadd.blogspot.co.uk/2017/10/freebsd-and-aprs-or-hm-what-happens.html) Here's another point along my quest for amateur radio on FreeBSD - bring up basic APRS support. Yes, someone else has done the work, but in the normal open source way it was .. inconsistently documented. First is figuring out the hardware platform. I chose the following: A Baofeng UV5R2, since they're cheap, plentiful, and do both VHF and UHF; A cable to do sound level conversion and isolation (and yes, I really should post a circuit diagram and picture..); A USB sound device, primarily so I can whack it into FreeBSD/Linux devices to get a separate sound card for doing radio work; FreeBSD laptop (it'll become a raspberry pi + GPS + sensor + LCD thingy later, but this'll do to start with.) The Baofeng is easy - set it to the right frequency (VHF APRS sits on 144.390MHz), turn on VOX so I don't have to make up a PTT cable, done/done. The PTT bit isn't that hard - one of the microphone jack pins is actually PTT (if you ground it, it engages PTT) so when you make the cable just ensure you expose a ground pin and PTT pin so you can upgrade it later. The cable itself isn't that hard either - I had a baofeng handmic lying around (they're like $5) so I pulled it apart for the cable. I'll try to remember to take pictures of that. Here's a picture I found on the internet that shows the pinout: image (https://3.bp.blogspot.com/-58HUyt-9SUw/Wdz6uMauWlI/AAAAAAAAVz8/e7OrnRzN3908UYGUIRI1EBYJ5UcnO0qRgCLcBGAs/s1600/aprs-cable.png) Now, I went a bit further. I bought a bunch of 600 ohm isolation transformers for audio work, so I wired it up as follows: From the audio output of the USB sound card, I wired up a little attenuator - input is 2k to ground, then 10k to the input side of the transformer; then the output side of the transformer has a 0.01uF greencap capacitor to the microphone input of the baofeng; From the baofeng I just wired it up to the transformer, then the output side of that went into a 0.01uF greencap capacitor in series to the microphone input of the sound card. In both instances those capacitors are there as DC blockers. Ok, so that bit is easy. Then on to the software side. The normal way people do this stuff is "direwolf" on Linux. So, "pkg install direwolf" installed it. That was easy. Configuring it up was a bit less easy. I found this guide to be helpful (https://andrewmemory.wordpress.com/tag/direwolf/) FreeBSD has the example direwolf config in /usr/local/share/doc/direwolf/examples/direwolf.conf . Now, direwolf will run as a normal user (there's no rc.d script for it yet!) and by default runs out of the current directory. So: $ cd ~ $ cp /usr/local/share/doc/direwolf/examples/direwolf.conf . $ (edit it) $ direwolf Editing it isn't that hard - you need to change your callsign and the audio device. OK, here is the main undocumented bit for FreeBSD - the sound device can just be /dev/dsp . It isn't an ALSA name! Don't waste time trying to use ALSA names. Instead, just find the device you want and reference it. For me the USB sound card shows up as /dev/dsp3 (which is very non specific as USB sound devices come and go, but that's a later problem!) but it's enough to bring it up. So yes, following the above guide, using the right sound device name resulted in a working APRS modem. Next up - something to talk to it. This is called 'xastir'. It's .. well, when you run it, you'll find exactly how old an X application it is. It's very nostalgically old. But, it is enough to get APRS positioning up and test both the TCP/IP side of APRS and the actual radio radio side. Here's the guide I followed: (https://andrewmemory.wordpress.com/2015/03/22/setting-up-direwolfxastir-on-a-raspberry-pi/) So, that was it! So far so good. It actually works well enough to decode and watch APRS traffic around me. I managed to get out position information to the APRS network over both TCP/IP and relayed via VHF radio. Beastie Bits Zebras All the Way Down - Bryan Cantrill (https://www.youtube.com/watch?v=fE2KDzZaxvE) Your impact on FreeBSD (https://www.freebsdfoundation.org/blog/your-impact-on-freebsd/) The Secret to a good Gui (https://bsdmag.org/secret-good-gui/) containerd hits v1.0.0 (https://github.com/containerd/containerd/releases/tag/v1.0.0) FreeBSD 11.1 Custom Kernels Made Easy - Configuring And Installing A Custom Kernel (https://www.youtube.com/watch?v=lzdg_2bUh9Y&t=) Debugging (https://pbs.twimg.com/media/DQgCNq6UEAEqa1W.jpg:large) *** Feedback/Questions Bostjan - Backup Tapes (http://dpaste.com/22ZVJ12#wrap) Philipp - A long time ago, there was a script (http://dpaste.com/13E8RGR#wrap) Adam - ZFS Pool Monitoring (http://dpaste.com/3BQXXPM#wrap) Damian - KnoxBug (http://dpaste.com/0ZZVM4R#wrap) ***
Toran Billups: @toranb | GitHub | Blog Toran Billips joined us for an insightful conversation regarding glimmer-redux: Predictable state management for Glimmer apps. Resources: Glimmer Redux Demystified Talk from Tom Dale on glimmer internals (contrast with Preact made in this talk) ember-redux Glimmer progress report that mentions the migration to Glimmer 0.8 (Big Changes) Blog post following EmberConf 2017 that announced GlimmerJS (for the Ember dev) The Frontside Podcast 086: Routing in Ember with Alex Matchneer An ember-rideshare Blog Post A Rollup plugin for glimmer-redux RollupJS Transcript ELRICK: Hello and welcome to another Frontside Podcast, Episode 89. My name is Elrick Ryan, a developer here at the Frontside. I'm joined by Wil Wilsman, another developer here at the Frontside. Wil, how are you doing? WIL: I'm good. How are you? ELRICK: I'm great, man. I'm excited for this podcast that we have coming up here. Today we are fortunate to have with us a podcast elite member now, Mr Toran Billups. Toran, how are you doing? TORAN: Oh, man. I joined the elite platinum club or something? ELRICK: Yes, you are in the platinum club right now. I think this is probably what? Your third or fourth episode by now? TORAN: Oh, yeah. I think the fourth. ELRICK: Oh, yeah. You're in the elite club right now. You are a Midwest programmer and I hear there is a difference between a Silicon Valley programmer and a Midwest programmer. Could you tell us about what the difference is? Because it's the first time I've heard anything about this. TORAN: Admittedly, I stole this from a very popular developer, Justin Searls who spoke at length one time on a podcast, not too different in this one about his experiences in consulting for companies, who are more in the startup phase or a company that you'll find in Silicon Valley that is mostly just trying to test an idea and get to market, versus his experience for finance or insurance companies based out of the Midwest. I like that idea because my experiences have taught me. I'm a little bit happier when I'm working for companies that are interested in quality or attributes of quality and view the software longevity as mission-critical versus a software that is really just a byproduct of an interesting idea and if we validate that idea in a market, we can always rewrite the software later. Midwest, I guess the short version is we care about the work we're doing and we understand that rewrites are difficult, if ever possible. ELRICK: Interesting, so the Midwest seems to be concerned with long term goals. TORAN: Yeah, I think sustainable -- ELRICK: Sustainable software, at least. TORAN: Yep. ELRICK: Today, you are joining us to not only talk about the Midwest and the beautiful Midwest programmers. You're here to talk about Glimmer Redux. TORAN: Glimmer Redux is a little library I wrote, I think last month. I should start off by asking you guys if you're familiar with a Glimmer JS or if you've heard of that. ELRICK: I've heard of Glimmer JS. I haven't had an opportunity to play around or mess around with it yet. I don't know if that's good or bad because I'm just really busy but I really want to get into it. Wil, what about yourself? WIL: I've read through the docs but I haven't played with it at all. It looks really nice. TORAN: I think the joke that was off the air last time I was on, Wil you might remember this. You're on that podcast with Charles. I said something like, "I'm not young enough to actually be working with Glimmer," and I felt that way for a long time because one thing you should know is it's a pre-1.0 and if you guys have ever worked in a pre-1.0 ecosystem, myself the biggest experience I have to draw from is really pre-1.0 Ember and there were some big changes before 1.0. You can imagine back to that throwaway comment about being very young, there was actually a big change in Glimmer itself recently where they decided to... I don't know if the right word is Pascal Case but they've literally gone away from that 'dasharized' components. It used to have 'foo-bar' and in your template, you would actually see lower case of 'foo-bar' and now that would just be all uppercase. Well, not all uppercase but 'FooBar' and no dash, which is a big change recently. WIL: So a class case, kind of like React or JSX. TORAN: Yeah, exactly. They have a great blog post. Actually, we can reference that in the show notes, about some of these big changes in that release. It was Glimmer 0.8 so it's still, it's making its way to the 1.0 but I got interested in this really for two reasons in the last couple of months. The first was, if you actually go build something with Glimmer -- and this is my experience -- is for the novice programmer just taking a look at it, it's really just a way to use web components to build an application. There's no routing. There's no opinions, really. There's no services like you have in Ember or contexts like you have in React. The first challenge you run up against is when you get beyond a single component or two components and suddenly, you need to share some state across this application. How do you do that? If you guys have some experience, I know the Frontside, with React, if you're not using MobX or Redux or something like that, a lot of times you'll see this pattern where you're actually passing a piece of state through the entire tree or the shared state through a big part of the component tree. Of course, that becomes painful as the application gets to a certain size. One of the things I thought about is if I was to build a real application, the one in mind that was certainly not built yet because I'm not using Glimmer at work but I always think about the ember-rideshare. I know you guys had Alex Matchneer, recently talking about routing and Alex mentions in that episode this challenge for the Ember router today, to be reactive to server-sent events. In the case, imagine you have an Uber or a Lyft app and after the ride is over, the server wants to send an event, maybe and then the app needs to react to that event -- sending you maybe to a new route or sending you back to the map to pick a new ride. The gist of the ride share app is, and Alex, of course I would reference anyone to that podcast, he does a lot better job describing the routing challenges and those are a little bit out of scope for this discussion, but imagine you're going to build an app that ambitious and you're going to build a Lyft in Glimmer. What I found was missing is really what we take for granted in Ember, which is the Ember Service and that is like a singleton or an object that allows you to have a piece of state and then share that state around by injecting that service in only the components that need to reach up and grab that shared state. Redux, which I know your audience is pretty familiar with but a quick recap, Redux is just kind of a global JavaScript object that has state and there's often a library that lets you connect to that state so you can use it in your various components. Glimmer Redux is no different than that, actually. It just allows you, instead of having to create maybe one global JavaScript object and kind of pass it down the hierarchy, you can instead just connect the components that need to be aware of Redux. The ones that don't, of course they just don't connect. ELRICK: I know that you had a hand or build ember-redux and now you build Glimmer Redux. Were there any challenges between building those two different add-ons into two different ecosystems? TORAN: I should take one minor step back because that question is a great segue. I didn't want to touch on the second motivation for Glimmer Redux, which is actually really closely related here and that is, of course I did write ember-redux so with every open source project, there's a little selfish motivation here. I imagine last year when Glimmer was announced at EmberConf that there would be a story from Glimmer to Ember. The idea being you're a small startup, you just want to get your web application going, you don't necessarily like all the big conventions or you just don't think you need all of Ember when you get started but six months down the road, you're suddenly looking at tree shaking and lazy loading with engines and you're thinking, "I wish we had that." Realistically speaking, like today what would a transition for a Glimmer shop to Ember be. Honestly, I think it's tough without a library like Glimmer Redux. Of course, I wrote this with pretty much a mere of the connect API. If people were to check out the ReadMe of Glimmer Redux and ember-redux and you looked at a connected or redux-aware component in both of those cases, the best case scenario is the only difference would be in the import. Instead of import connect from a Glimmer Redux, you would be import connect from ember-redux. Everything else underneath, all the ecosystem of Redux that you can use and both are completely compatible. In fact, if you were to move, imagine you Ember new and you're thinking, "I got to move my Glimmer ride-share to ember-rideshare. Since Redux does a good job in encapsulating all of the state transformations in vanilla JavaScript, you don't have to really worry about the differences between a number object and not having Ember object. After you did Ember new, essentially you would copy over your components. For the most part, they're still template-driven. A lot of handlebars and a lot of TypeScript to JavaScript is the biggest mismatch you would have between Glimmer and coming over to Ember, of course but there is Ember CLI TypeScript or Ember TypeScript, I think. Long story short, you essentially copy the directories of your reducers or middleware from your Glimmer app over to Ember and there should be no changes necessary at all. ELRICK: I know that is the dream that you touched on, I think they phrase it as 'NPM installing your way up to Ember.' In your perspective, do you think that is going to be a thing? Is it going to get there? What are your feelings on that? TORAN: I would definitely be in trouble if I didn't say upfront that I'm not on the Ember core team. Sometimes, people get that confused for some reason but I don't speak for the core team and I'm not really privy to anything. But I do think that the core team has this in mind that there will be a set of NPM installable modules that eventually land you the full set of tools and abstractions that we see in Ember today. A big one that I'd hit on earlier is services. What will services or the Glimmer 0.5 version of services look like when it lands and what about routing and those sort of things? This was really my personal take on how could I make that migration right now without asking permission from the core team. In a Glimmer Redux, I think honestly it offers a good 80% of that. You still have the routing issue, which is a little challenging and you have the TypeScript issue, which you just have to be aware of some of the limitations of using TypeScript in Ember. ELRICK: That's an excellent point that you made because when people outside of the core team take it upon themselves to then try to implement different things around the ecosystem, that can then be motivation or an example for people outside of the core team to see like, "This is a possible solution to a goal we're trying to reach." Kudos to you. TORAN: Back to your original question about 15 minutes ago, what was different about the ecosystems writing ember-redux the add-on and Glimmer Redux, which is... I don't really even want to call it an add-on. I kind of label it as a Glimmer library but to your point just a second ago, when I got interested and saying, "I wrote Glimmer Redux, now I want to share it so other Glimmer authors don't need to copy/paste this file," and the first resistance I hit up on is there really is no Glimmer library or Glimmer add-on. You could write an Ember add-on because if you guys get into Glimmer, you'll find this as well. There are certain hooks that are used in the Glimmer build process where Ember add-ons like Ember CLI SASS can be used from Glimmer. But the challenge I had using an Ember add-on, of course is that this wasn't an Ember component or anything Ember related. It needed to really be test driven from a Glimmer apps. Really, if you went to NPM installers, what you're pulling in is effectively my Glimmer app that also exports publicly this connect function, which is not necessarily you're leading, maybe anything to core team that could happen. A big reason for that as well and one of the challenges building this, is that Glimmer right now, after to try to emulate my 'quasi-success' in doing this, is really bring your own build system, to actually share a Glimmer components or internals like this connect API that Glimmer components can use. What I mean by that is on the website, one of the challenges I faced was -- this isn't a knock against the core team, this is just my honest experiences -- when I read the Glimmer JS docs and it says right in the installing guide, "Glimmer uses Ember CLI, this battle-tested command line interface from the Ember project." Now, pause right there because again, not to beat up on the Ember core team or anything but assuming in that one sentence that they're using Ember app, what I noticed when I opened the Ember CLI build file is the project was actually a Glimmer app. Now, I did a little bit of digging here and I think this is validated, at least back when I worked on Glimmer Redux last month, that Glimmer app is not like inheriting or pulling in a bunch of shared code from Ember app. It's actually a completely separate build tool. As part of this process, I actually for the first time had to go through and learn Rollup and understand how the Broccoli process is kicked off, how both Rollup and Babel are used to build this and then how to apply some convention. If you guys are familiar with Ember, you have this add-on directory and an app directory. The guidance from the Ember team is around how to structure add-ons. Of course, you write all of your kind of private-ish or add-on code in the add-on directory and then whatever you think will be public, you export from the app directory and that sort of merges it into the tree when the application is built. People are allowed to use your code but then also, they can override that code. One of the challenges here is if I wanted that exact same API and I want people to make this migration from Glimmer to Ember using Redux, I had to actually invent that convention so I wrote a Rollup plugin and it's all listed in the docs here. One of the strange things people who are checking out Glimmer Redux hit me with first is, "I see a Yarn installed Glimmer Redux but then second step is installing this Rollup plugin. What's the deal?" I think it is because most people assume the Ember CLI you're using is identical and somehow, I should have written an Ember CLI add-on for this. I think that was the biggest learning curve and people should just be aware of that. If you're interested in sharing code right now, there is really not a baked story and that's okay. It allows people to innovate. Of course, the innovator's dilemma being that, I don't really know without [inaudible] some migrating RFC or getting involved with the core team, how to make that thing. I ultimately just hope the core team improves this and I'm sure they will but for right now, I don't really want to wait around for it. ELRICK: Got you. What is Rollup, for people that are not familiar with what Rollup is? I'm sure everyone is probably familiar with Babel by now because it's used everywhere but what is Rollup? TORAN: Embarrassingly, I don't know the technical... But I would say the role that you can see, if you actually step through the node process as your Glimmer app is being built, is it helps really condense the overall build size. What I see is it's essentially traversing like Browserify in some ways. This is, again just my primitive look but it traverses all the imports you have and it tries to pull in the bare minimum to keep the bundle size as small as possible. ELRICK: Toran, you have had a lot of experience with Redux and Redux is now being used in several different software platforms, I guess or software areas like Vue and they probably even have in Angular now. They have it in Ember and React. Redux is kind of spreading its wings and it seeds across every ecosystem. Do you feel that Redux has reached a state where people are just satisfied with the current state of Redux or do you think that people are going to be then, looking to build another abstraction on top of Redux? Do you have any thoughts on that? TORAN: The fact that Redux is so simple has allowed it to become so ubiquitous. I heard someone say this term the other today, which is like, 'ubiquity over consistency,' and that I think describes the both the growth of Redux and why it is kind of de facto for data management across all ecosystems. I think there's two camps that I hear about and I'm curious if you guys see this in your consulting work but there is certainly, the developer see this ubiquity but no consistency and see chaos in their experiences. I can totally relate to this. There are development shops I've seen where one team goes this direction because there's no strict guidance goes another and then when those teams meet up for a project in 12 months, they look at each other and the apps are, of course nothing alike, which is a big problem that Ember tries to solve. My biggest question here really is kind of curving us slightly back to the Glimmer story. If I can reframe your question, Ember is traditionally very big on convention and I think a lot of the community that is still in Ember today in large part is because of this convention, these guide rails about the community has set up but Glimmer being this NPM install your way to Ember, I think along the way, there's going to be either a new set of users that are coming just for the winds of the Glimmer VM and they happen to find themselves, not necessarily in love with some restrictions or opinions that would come with a migration directly to Ember and I'm curious if the Glimmer community that will show up for that is mostly Ember backed, meaning that they want to slowly build with RFC as a process that the entire community uses and there's one solution like we end up with often an Ember. If a community evolves more experimentally like you saw in React, where there was, of course Redux but then there was MobX and then there was various little wares for Redux that different teams would try out and eventually, there was no one proven way but there was always at the heart of it, Redux with some extensions or other add-ons around it that got teams to where they are today. I'm curious to see where this Redux, especially with the Glimmer influence, will end up. WIL: You touched on a little, I think one of the, maybe not a problem necessarily but one of the biggest barriers in Redux and React and maybe Glimmer -- I'm not sure -- is that it's almost too loose without any opinions at all so it kind of gives developers the freedom to mess things up big time. What's your opinion on that with Glimmer, like Glimmer is headed toward this NPM install? Is it too loose? TORAN: I guess that's the question, I wish we both had the answer to. It's funny. It's a double-edged sword. If it's loose, it seems like somebody is going to go create a mess but at the same time, if it's loose on the surface, it often seems like it has less surface area and as a result, a lower learning curve. React is a good example where most people, I think have gone to React or at least in my experience, I like React because it was so simple and there wasn't a huge amount of things to learn. There wasn't this full ecosystem, at least out of the gate but of course, what you find the moment you want to join a team or go build something ambitious is that you've got to make a bunch of decisions and that is certainly the calling card of Ember. What makes Ember special is they've settled on a handful of those decisions. I think ideally, I'd like to see the community in Glimmer check out Redux, get an idea of what problem it actually solves for them and if it is useful, then find a set of middleware or extensions from the wider ecosystem that actually solve the problems they face. Back to this Glimmer rideshare example, I think one thing that stands in the way as I play around with that is just a very basic routing story. Even if that is as simple as I have a component that I'll just call it route, what hooks in this Glimmer component are correct to fetch data. In the Ember ecosystem, we have a very special route object, essentially who has a set of hooks that are known for handling the asynchronous stuff in our Ember apps but there isn't anything like that yet, in Glimmer which is the next stumbling block for me to actually go build something big. I'm kind of messing around with the idea of this reactive router built out of Glimmer components but until that's actually kind of surface, mostly just spit balling here. ELRICK: With flexibility comes a lot of power but then there's also the case where our flexibility could lead to chaos. But being that something as flexible, it allows you to adapt it to whatever your particular needs are -- you know, the 'special snowflake' as everyone ends up being. Because Ember has been around for a while now and has proven itself and its battle-tested in a lot of areas, now as NPM install in our way from Glimmer up to Ember, do you think that they'll be able to then, extract some of those hardened pieces of Ember out of Ember and then give us a solution inside of the Glimmer ecosystem based off of the Ember ecosystem? Then not have so many varying different opinions or different packages or add-ons or libraries that you may need to pull from that you may just have like a set of Glimmer-approved libraries or add-ons to use to then, get your way up to this full Ember app. Do you think that that's a road they're taking? Or a possible road? TORAN: Yeah, I think for sure. A lot of the talk right now if you're in the Glimmer channel on Slack in the Ember community, I think the next big step here is having the ability to take a Glimmer component as it exists today and use that, extrapolate from there and the plan is to prove out things in a more experimental ecosystem as pre-1.0 Glimmer ecosystem. As they become more solid, we essentially just adopt them and then use them as a first class. In Ember actually, this isn't true but I envision a world where in the months ahead, we're essentially using Glimmer components in Ember so I'm already challenging myself with how would a library or add-on author help people make this progression from Glimmer to Ember if they don't do something like I've done here with Glimmer Redux because eventually, there will be this shared component world, at least in the middle ground, where Ember has both Ember components and Glimmer components. I think it's a road yet to be traveled and that's what I'm excited to be on the podcast and get people talking about building libraries for Glimmer, just because there is not a cow path or a paved road for you right now. I think if you learn just a little bit of Rollup or you dive in and take a look at the DI system built in a Glimmer right now, there is a lot you can actually do with it. I know there are certainly big named add-on authors already checking it out in preparation for such a migration. WIL: Besides the whole Rollup process, was there any other friction points in integrating Redux with Glimmer? TORAN: One that I want to call out but it is, I believe still Rollup related. It's mostly a PSA, to warn people. If you are building one of these little libraries like I talked about with Glimmer and you're going to do a Yarn link, which means that you're going to just work locally and not really publish to NPM until you're done, be aware that if you're Yarn linking and then going over to another project to test this Glimmer library, then you'll actually get temporarily two copies of Glimmer. In fact, that is how this Rollup plugin I wrote -- sort of 'bring your own build' for Glimmer -- became essential as I was like, "I'm getting two copies of the Glimmer component," so what was happening is example, I was playing with this connect API, it was always calling into the wrong Glimmer code so the code that I was expecting in my add-on was never firing. We come to find out when you're not doing Yarn link or you're not working locally, this isn't a problem. Actually, Tom Dale reached out and helped me a little bit later because my first version of the Rollup plugin had this little hack in there that said essentially, "I'm going to mask away this duplicate Glimmer problem," and it turns out it's not a problem. If you are working locally, be aware that you will have this problem as my guess. ELRICK: What gets you most excited using Glimmer? Are there any specific features or things within Glimmer to get you most excited? I guess the second question would be, what do you think Glimmer is going to unlock for the future of app development in Ember? TORAN: I think the first thing I get excited about was visible in this talk that Tom Dale gave a couple weeks ago. I'll try and dig that up for the show notes where he show the advantages of Glimmer over the competition today. The big thing that just blew me away was some of the advantages over, even Preact, which I was kind of surprised that a lot of times there's this rivalry for performance especially between React and Angular and Ember but no one ever really talks about Preact, which is known in a lot of ways as the thinner, lighter-weight React, if I'm not completely wrong. I'm sure somebody is going to be table flip on that definition. But my view was that if you were really performance-hungry, you could check out Preact, which was for performance reasons there was a smaller bundle size so you're just actually shipping less JavaScript, which means they're parsing less JavaScript and Tom went directly after this library in his talk and just showed a very interesting point at the end. I don't want to spoil it for people but let's just say, it appears to show Glimmer as just an order of magnitude better as a primitive for building web components. I think that is the big draw and how will that make Ember better. I think, mostly in the same way that I just described, where we'll essentially get a component for free in Ember that is just a better performing primitive for the web. ELRICK: I'm not too familiar with the guts of Glimmer but from what I understand, Glimmer compiles down and it has some opcodes that then compile down to binary. Is that correct? TORAN: Yeah, I think there is a binary format that they're shipping or they will soon be shipping. If you're really interested in the technical details of that, I'll definitely be sure you check out this talk from Tom because now the real magic behind this is they essentially boil it down to the ability to compile these templates down to 'byte code,' as they call it and Tom has a really funny part in his talk where he says, "You know, it's not a marketing term, this byte code word," and it becomes true because later in the talk, you hear that, essentially the Glimmer VM or the big value add of Glimmers VM is that you're just feeding it with byte code until the next 16 millisecond buffer comes up to paint, in which case you just pause and that allows, I think as he describes, less jank or allows less freezing up that main thread because you're releasing control back to the UI every 16 milliseconds, essentially. ELRICK: Yesterday, there was a meet up with a lot of the Ember core team. Ed Faulkner had made a point that since Glimmer compiled down to byte code that then is not too far of a stretch to then use that with something like Web Assembly, that with then give Glimmer an extreme performance boost. He sets up Glimmer to be used in what can be potentially the future of the web, which is Web Assembly, which I thought was really interesting and it kind of blew my mind to think, "Oh, yeah. That is true since it compiled down to byte code and Web Assembly compiles down to that." We can get that performance boost in that Glimmer is forward thinking in a sense. TORAN: Yeah, man. I totally agree. One of the things I honestly value about the Ember core team is they're very both tactical and visionary at the same time, where in the short term, they're doing things to accomplish real pain points we have but without anyone really realizing it, they're also setting up the stage to solve huge problems that we're all going to face in six, 12, 18 months. I definitely appreciate and love the work these guys are doing. They should hear about it. Obviously, this is all open source and most of this time is gifted, just given away so I really appreciate the core team. WIL: Speaking of performance, we know that the Ember has a run loop and basically, most of these libraries have some sort of loop that determines when they should batch things together or render things to the screen. Does the Glimmer have this concept? What do they take advantage of to make it as performant as you say? TORAN: Yeah, that's actually a really good question and I'm probably minimally equipped to answer it but the short version of it is there is no equivalent run loop for batching work that I've seen inside of Glimmer. Instead, you're more directly interacting with request animation frame, which we miss directly from Mozilla here but requests animation frame tells the browser you [inaudible] browser call specific function to update an animation before the next repaint. Where does this come in for Glimmer? Essentially when you call set or you decide to change a property that Glimmer is listening to and if anyone was not familiar with Glimmer, you designate this by using the tracked attribute. The tracked attribute, when you change a value, it fires this 'set property did change' and behind the scenes, 'set property did change,' if you are familiar with Ember, in my mind is close to 'notify property change,' which is what happens when you do Ember.set. If you've ever actually change something in Ember behind the scenes, there is a notify property change event fired and then we queue that work and it's a similar-ish process except that there is no run loop. What we do is we just call schedule rerender, I think in Glimmer and that just fires off request animation frame to try and rerender within that 16 millisecond window before the next repaint. WIL: From my understanding, the request animation frame is Glimmer's run loop essentially. TORAN: I think I saw actually a discussion between someone at Ember core kind of saying in the public channel that, if you're using Embers run loop, the equivalent-ish today would be request animation frame but the point came up that there's really no way to have a different set of cues because Ember itself has many different cues in the run loop and request animation frame, as far as I know really is just one function with a single callback, where you try and fit in as much work before that repaint as you can. I don't think there's prioritization that you would get in the Ember run loop. But at the same time, I'm not sure if that's actually a requirement. I don't think request animation frame was as mature as it is today back when backburner, which is behind the scenes of what Ember run loop is using, was built years ago. ELRICK: Since Glimmer is using requests animation frame and not the Ember run loop, is it going to continue to use requests animation frame in the future or they're going to develop like a run loop equivalency for Glimmer? TORAN: That's definitely out of my depth. I know from looking inside the code, the rerender work essentially calls like a 'begin,' to say begin doing your work, which I believe is like the reconciliation type work if you have a React background, I believe. I don't know what decides to end that. If the request animation frame is truly saying, "We're at the 16 millisecond budget and we're going to quit feeding the Glimmer VM byte code instructions now because we need to go back and paint." I would guess that that is the high level narrative but I actually don't know the implementation details. ELRICK: Since Glimmer is pre-1.0, it's a place for you to experiment, try out new things, really exciting area to play around in. What kind applications do you see people building today using Glimmer and what's the good application that's a good fit for Glimmer right now for you to experiment with? TORAN: The big application that I've seen that exists is being built with Glimmer in its current form is the Glimmer Playground. The Glimmer Playground is an area to go mess around with Glimmer, if you've never used it or you just want to go [inaudible] with the basics. As far as what is an ideal application, honestly I think we're at a point where we need to push the bounds of what a purely component based library can do. I think if you could come up with some kind of basic routing story and have a mechanism to share state and bubble events, whether that's Redux or some kind of home grown service layer at some point. That would allow you, in my opinion to build just about anything. The only caveat that you're going to be missing is a ton of opinions and you're going to be paving new grounds so just be aware that happy path for any pre-1.0 is be aware that they could change anything, anytime. But that shouldn't really restrict you from making a hobby project out of it. Back to your original question, I would say building any app that you're okay to go back and rework, not necessarily reinventing Facebook or something like that with it at this moment but at the same time, it would be great if someone did in a hobby way because we need to see some of the constraints and challenges. I got playing around with it myself and noticing if I'm going to build anything with Glimmer, I've got to have a way to share state and bubble events up to the single atom at the top that allows me to share all state. I think without some experimentation, we just won't know what apps are possible. ELRICK: You've been talking a lot about Glimmer today and using Glimmer. Since Glimmer is pre-1.0, are there any limitations that people should be aware of when they're going to be going into building a new Glimmer app? TORAN: For Glimmer Redux specifically, one of the challenges that people would see and they should know about if they're going to use this little Glimmer library, is that it doesn't yet allow you to write reducers in TypeScript, which would be a little counterintuitive because if you get into Glimmer, you'll notice the big differences -- everything is in TypeScript and not JavaScript. Luckily though, I think this is really just a build tool decision. Truthfully, the spike version of this that I have where you can use TypeScript, it doesn't require any change to the Glimmer Redux library at all. In fact it's completely unchanged. The difference here is that the Rollup plugin I use needs to see a change. It's kind of weird in that way, back to my point earlier where you kind of bring your own build chain and one of the things I don't like right now, which is the reason I haven't published this TypeScript version of it is that I'm actually doing a TypeScript compile of all the reducers or middleware in the Rollup plugin. With the mass confusion right now between Broccoli, Rollup and Babel, I just don't feel really great about it. Mostly because I have not truly been in the guts of the Glimmer app build tool or the application pipeline yet and I want to be a bit more educated there before ship something, back to being a Midwest developer here. I just don't feel good about shipping something and say, "Oops, we got it wrong." I take a lot of time and I also take a lot of pride in what I am shipping so I want to have a really good story about TypeScript. It does make for a little bit of a weird experience: bouncing between Glimmer components written TypeScript and flipping back to reducer file written in JavaScript. just be aware of it and at the same time, I didn't want to completely halt shipping it because again, I think we need to actually build apps with this and a concession here being that, of course you have to write reducers in JavaScript was still enough for me personally to get some value out of building Glimmer apps and honestly, it got me building them sooner. WIL: Is there a way to use Glimmer Redux without the Rollup? Can we import something into our Glimmer app to use it or this Rollup is required? TORAN: Yeah, that's a great point. You can omit the Rollup plugin entirely. What that results in is you'll have to do some hand wiring yourself. One of the upsides or one of the benefits of this Rollup plugin that I wrote is this conventionally provides a store and redux-thunk, kind of like a happy path for people who are just not familiar with wiring up their own Redux store. If you forego this plugin, you just have to do that yourself. You may actually have to do some kind of Rollup hacking in your Glimmer app, which is the thing I want to avoid. The one in particular that I know you'd have to do is there is a Node ENV that is looking for a production setting in Redux so the first thing you have to do is use a Rollup replace plugin to replace Node ENV with Ember ENV. If you can't do that, you actually get an error in just trying to stand up your Glimmer app with Redux. ELRICK: Toran, are you giving any talks or have any books or anything that you want to get out there and talk about? TORAN: I'm not actually on speaking circuit right now. I am certainly, probably like you guys are, thrown a talk or two together for the EmberConf proposals that are now out. I think they're open until November 21st. If anyone is thinking about submitting a talk to EmberConf, this should be in next March. Now is the time to get those in and I certainly have one out there but I've got one, off the top of my head that I would certainly like to find some time and submit that's related to Glimmer. ELRICK: Cool. We had a wonderful podcast today. We touched on Glimmer Redux and Glimmer and I want to thank Toran for coming on. Thank you, Toran. TORAN: Thanks for having me, guys. The fifth time I have to be on, I don't know if that will be in 2017, though. ELRICK: Yeah, we're going to bring you back for a fifth time and I would also like to thank Wil for coming on the podcast as well. Wil, thank you. WIL: Thanks for having us, Elrick. ELRICK: Anytime. Toran, if people want to reach you, is there a particular place on Twitter or anything that people can reach out to you or email or anything? TORAN: Yeah, at GitHub, I got my email out there but also on Twitter, of course. You can reply me there. If you have a question specifically about Glimmer Redux, of course you can got to GitHub and throw an issue up there or hit me in the Redux channel on the Ember Community Slack. ELRICK: Thank you all once again for listening. This is the Frontside signing off and if you want to reach out, you can always hit us up at the Frontside.io and we always want to hear about your new project that you're working on. Thank you for listening and that's peace from the Frontside. WIL: Everybody have a good Thanksgiving!
We chat with Justin Searls about testing, programmer personality types, programming communities, and putting spreadsheets on the Internet. Justin Searls Justin's RailsConf Keynote My Favorite Way to TDD by Justin Searls Searls-Briggs Type Indicator Test Double Deep Work
We talk to Matt Casper about contributing to Diesel, Rust's ecosystem, and the next big thing. Matt Casper Matt's Diesel's Diesel contributions The Rust Book DHH's RailsConf Keynote Rocket Clap Justin Searls' RailsConf Keynote Procore Jobs
On this week's episode of My JS Story, Charles Max Wood interviews Justin Searls. Justin was on the show on episode 38 and 226 in the show. He co-founded Test Double, a software agency which helps developers improve the quality of the software they write. Want to know how he got into this career path? Stay tuned!
On this week's episode of My JS Story, Charles Max Wood interviews Justin Searls. Justin was on the show on episode 38 and 226 in the show. He co-founded Test Double, a software agency which helps developers improve the quality of the software they write. Want to know how he got into this career path? Stay tuned!
On this week's episode of My JS Story, Charles Max Wood interviews Justin Searls. Justin was on the show on episode 38 and 226 in the show. He co-founded Test Double, a software agency which helps developers improve the quality of the software they write. Want to know how he got into this career path? Stay tuned!
Episode 004: Testing Summary Sam Phippen, Justin Searls, and Noel Rappin spend this episode talking about the value of test-driven development (TDD) as well as its cost. They discuss the kinds of problems that developers are likely to have after they learn TDD and attempt to apply it to a large application. Learn why Rails is both great and terrible for automated testing, and how testing can influence the structure of your code. Guests Sam Phippen (https://twitter.com/samphippen): Engineer at Digital Ocean (https://www.digitalocean.com/) and member of the RSpec (https://github.com/rspec) Core Team Justin Searls (https://twitter.com/searls): Writes bad code effortlessly and cofounder of Test Double (http://testdouble.com/). Maintainer of several testing tools, and frequent speaker on test related topics. Show Notes 01:30 - Intermediate Level Problems in Testing 04:58 - The Value of Testing Boundaries by Gary Bernhardt (https://www.youtube.com/watch?v=yTkzNHF6rMs) 15:15 - Isolated Unit Tests 17:52 - Structuring Applications 23:13 - Test-Driven Development (TDD) (https://en.wikipedia.org/wiki/Test-driven_development) Growing Object-Oriented Software, Guided by Tests (https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627) 33:22 - TDD in a Smalltalk (https://en.wikipedia.org/wiki/Smalltalk) Environment 35:00 - Isolating Tests in a Rails Environment Rake Without Rails (http://blog.testdouble.com/posts/2016-12-15-rake-without-rails.html) 36:54 - Test Tools minitest (https://github.com/seattlerb/minitest) Dan North: Introducing BDD (https://dannorth.net/introducing-bdd/) teenytest (https://github.com/testdouble/teenytest) RSpec (https://github.com/rspec) Tips & Resources: Sam: Sandi Metz: The Magic Tricks of Testing @ Rails Conf 2013 (https://www.youtube.com/watch?v=URSWYvyc42M) Test Smells (https://github.com/testdouble/test-smells#test-smells) Justin Searls: How to Stop Hating Your Test Suite @ RubyConf 2015 (https://www.youtube.com/watch?v=VD51AkG8EZw) Justin: Find some little problem and instead of implementing it in a Rails app, type bundle.gem and then make up a name and then practice and invent your own way of organizing code and tests so you can break things down. Noel: JUnit Test Infected: Programmers Love Writing Tests (http://junit.sourceforge.net/doc/testinfected/testing.htm) As you’re trying to test stuff, really try to focus on going back and forth between the tests and the code more rapidly than you’re probably doing so right now. Special Guests: Justin Searls and Penelope Phippen.
Justin Searls chats with us on testing Asynchronous JavaScript as well as best practices for Continuous Integration, Unit testing vs. Integration testing, and tools we can use to help us understand how to test code. Resources Test Double - https://testdouble.com Talks & articles by Justin: http://blog.testdouble.com/posts/2016-06-05-happier-tdd-with-testdouble-js.html http://blog.testdouble.com/posts/2015-11-16-how-to-stop-hating-your-tests.html http://blog.testdouble.com/posts/2016-09-16-surgical-refactors-with-suture.html http://blog.testdouble.com/posts/2016-12-01-a-creativity-talk.html Justin on JSJ - https://devchat.tv/js-jabber/226-jsj-test-doubles-with-justin-searls Supertest - https://github.com/visionmedia/supertest Pretender - https://github.com/pretenderjs/pretender Sinon - http://sinonjs.org/ Testim - https://www.testim.io/ Cabybara - http://teamcapybara.github.io/capybara/ TestDouble's alternative to Sinon - http://blog.testdouble.com/posts/2016-03-13-testdouble-vs-sinon.html Testem - https://github.com/testem/testem Guests Justin Searls (@searls) Jan Tenpas (@jtp4) Panel Danny Blue (@dee_bloo) Erik Isaksen (@eisaksen)
React Remote Conf and Angular Remote Conf 03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)
React Remote Conf and Angular Remote Conf 03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)
React Remote Conf and Angular Remote Conf 03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)
Guest: Justin Searls @searls Full show notes are at https://developeronfire.com/podcast/episode-134-justin-searls-hip-to-be-slow
In this week's podcast Richard Seroter talks to Lisa Crispin who works on the tracker team at Pivotal Labs, and is an organiser of the Agile Alliance Technical Conference. Lisa is the co-author of several books on Agile Testing, and is also the 2012 recipient of the Agile Testing Days award for Most Influential Agile Testing Professional Person. Richard also talks to Justin Searls, software craftsman, presenter of "How to Stop Hating Your Tests" and co-founder of Test Double, a company whose goal is to "improve how the world writes software." Why listen to this podcast: - Agile is mainstream, and being adopted by big enterprises, but there's a place to help small companies and startups. - Cloud Foundry pair testers to write production code with the programmers. - Developers have to be focused on right now, testers have freedom to look at more of the big picture - People know testing is good and there a lot of tools for it, but some tools are ill-conceived. - We need a better language for talking about good QA and full stack testing. Notes and links can be found on InfoQ: http://bit.ly/1U0ip8Q 2m:00s - The first XP universe conferences were mainly about XP practices, values and principles, and were attended by developers 2m:17s - Over time, topics moved towards processes and frameworks, and the number of developers who attend Agile conferences has gone down dramatically. 3m:51s - Now Agile is mainstream, it's being adopted by big enterprises, but there's a place to help small companies and startups. That's usually where the innovation comes from, and the Agile Alliance wants to encourage innovation. Quick scan our curated show notes on InfoQ. http://bit.ly/1U0ip8Q You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. http://bit.ly/24x3IVq
In this interview with Justin Searls, Co-Founder at development agency Test Double, we discuss issues in open source software and what we can do about them. Justin raises problems for both consumers and contributors - like managing hundreds of dependencies to security issues and burnt-out maintainers. We dive into the efforts being made to address these and what you can do too.
Test-Driven Development (TDD) is a mature methodology now, right? So how do you get it right? Carl and Richard talk to Justin Searls about his experiences helping teams implement TDD. As Justin says, TDD is just a tool in the toolbox for making long-lived software. In its maturity, different flavors of TDD have emerged, and Justin digs into the Detroit or Classical TDD versus the London TDD. It's all about testing, but with some style variations. How do you keep your tests resilient as software evolves? Justin talks about the right amount of abstraction and organizing a hierarchy of tests so that you can manage change effectively. TDD works!Support this podcast at — https://redcircle.com/net-rocks/donations
Test-Driven Development (TDD) is a mature methodology now, right? So how do you get it right? Carl and Richard talk to Justin Searls about his experiences helping teams implement TDD. As Justin says, TDD is just a tool in the toolbox for making long-lived software. In its maturity, different flavors of TDD have emerged, and Justin digs into the Detroit or Classical TDD versus the London TDD. It's all about testing, but with some style variations. How do you keep your tests resilient as software evolves? Justin talks about the right amount of abstraction and organizing a hierarchy of tests so that you can manage change effectively. TDD works!Support this podcast at — https://redcircle.com/net-rocks/donations
Justin Searls runs a software consultancy called Test Double out of Columbus, Ohio. Test Double has a unique model built on trust and learning. Justin talks to us about his consultancy, the layers of understanding that go into a complex software project, and things you should do to keep learning and advance your career as a software developer. http://www.rubysteps.com/podcast/005-justin-searls-runs-a-software-consultancy-based-on-trust-and-learning/
Grab Bag! Derek and Sean talk about math, augmented reality, RailsConf wrap up, Minimum Viable Products, Accessibility... Homography Isomorphism Homomorphism Sean's Augmented Reality PoC Kerbal Space Program Derek's talk on Cultivating Code Review Culture Sean's talk on Designing a Great Ruby API Attributes API documentation Minimum Viable Product Chandra Carney's talk on Programming with Accessibility in Mind Nothing is Something by Sandi Metz Sometimes a Controller is Just a Controller by Justin Searls
Ep. 007: Lucrative and Kinda Sickening with Brett Pennings Live from Release Mode Village Lee & Jorge welcome back developer Brett Pennings to talk about cash and your side projects. How does monetization affect a project or hobby? Should you monetize your project? Can you do it without losing your fanbase? Also: Trolls are great. Some follow-up on our TDD talk. Follow up: * The Failures of “Intro to TDD” by Justin Searls h/t @jasich Mentioned in this episode: * Soccer Physics * Threes * Acceptable Ads Manifesto * Jack Conte * Patreon * Kickstarter * Indie GoGo Picks of the week: * Jorge: STEM * Brett: Open Systems Technologies (OST) * Brett: Ludum Dare Grand Rapids * Lee: 80 Days
Check out RailsClips on Kickstarter!! 02:23 - Justin Searls Introduction Twitter GitHub Blog Test Double @testdouble 03:02 - Justin Searls: The Social Coding Contract Open Source GitHub 04:58 - Transitive Dependences and Understanding Technical Debt RailsConf 2014 - Keynote: 10 Years! by Yehuda Katz The CAP Theorem 15:21 - Learning Outside Work Hours Tracking Time Micromanagement 21:21 - Understanding Transitive Dependencies (Cont’d) Gary Bernhardt 23:00 - Use Someone Else’s Framework or Write Your Own? “It Depends.” “A dirty code base is the sign of a well-monetized application.” - Matt Scantland 31:25 - When Does it Hurt to Use Tools You Don’t Completely Understand? Elasticsearch 34:14 - Leaving Code Behind 36:26 - Be a Responsible Open Source User Pull Request Sample Amount of Investment Community Management Communication cancan => cancancan GitX Graphical User Interface (GUI) rowanj GitX 47:22 - Reacting to Change Process and Ceremony Deming’s Common Cause and Special Cause Pair Programming [YouTube] Justin Searls and Aaron Patterson: The act of using vim, tenderly. 54:16 - Just Blog It! Picks Royalty Free Music by Kevin MacLeod (David) Rebif (David) Ruby Rogues Episode #188: Community Building with Pieter Hintjens (Jessica) Commercial Users of Functional Programming 2015: Call for Presentations (Jessica) James Clear: Forget About Setting Goals. Focus on This Instead. (Jessica) Screw motivation, what you need is discipline. (Jessica) A Wizard of Earthsea by Ursula K. Le Guin (Chuck) Conform: Exposing the Truth About Common Core and Public Education by Glenn Beck (Chuck) Sony NEX-5T Compact Interchangeable Lens Digital Camera (Justin) Justin’s Talk at RailsConf 2015: Boring Code (Sometimes a Controller is Just a Controller) (Justin) Alpine iLX-007 7-Inch In-Dash Receiver with Apple CarPlay (Justin)
Check out RailsClips on Kickstarter!! 02:23 - Justin Searls Introduction Twitter GitHub Blog Test Double @testdouble 03:02 - Justin Searls: The Social Coding Contract Open Source GitHub 04:58 - Transitive Dependences and Understanding Technical Debt RailsConf 2014 - Keynote: 10 Years! by Yehuda Katz The CAP Theorem 15:21 - Learning Outside Work Hours Tracking Time Micromanagement 21:21 - Understanding Transitive Dependencies (Cont’d) Gary Bernhardt 23:00 - Use Someone Else’s Framework or Write Your Own? “It Depends.” “A dirty code base is the sign of a well-monetized application.” - Matt Scantland 31:25 - When Does it Hurt to Use Tools You Don’t Completely Understand? Elasticsearch 34:14 - Leaving Code Behind 36:26 - Be a Responsible Open Source User Pull Request Sample Amount of Investment Community Management Communication cancan => cancancan GitX Graphical User Interface (GUI) rowanj GitX 47:22 - Reacting to Change Process and Ceremony Deming’s Common Cause and Special Cause Pair Programming [YouTube] Justin Searls and Aaron Patterson: The act of using vim, tenderly. 54:16 - Just Blog It! Picks Royalty Free Music by Kevin MacLeod (David) Rebif (David) Ruby Rogues Episode #188: Community Building with Pieter Hintjens (Jessica) Commercial Users of Functional Programming 2015: Call for Presentations (Jessica) James Clear: Forget About Setting Goals. Focus on This Instead. (Jessica) Screw motivation, what you need is discipline. (Jessica) A Wizard of Earthsea by Ursula K. Le Guin (Chuck) Conform: Exposing the Truth About Common Core and Public Education by Glenn Beck (Chuck) Sony NEX-5T Compact Interchangeable Lens Digital Camera (Justin) Justin’s Talk at RailsConf 2015: Boring Code (Sometimes a Controller is Just a Controller) (Justin) Alpine iLX-007 7-Inch In-Dash Receiver with Apple CarPlay (Justin) Special Guest: Justin Searls.
Adam and Jerod talk with Justin Searls about Lineman.js, building for the web with JavaScript, and his abstract “The Social Coding Contract.”
Adam and Jerod talk with Justin Searls about Lineman.js, building for the web with JavaScript, and his abstract “The Social Coding Contract.”
At the Houston #ModernApps2013 Road Trip stop, Carl and Richard talk to Justin Searls about using Javascript in the enterprise. Besides referencing an awesome number of tools around Javascript (check out the huge list of links!), Justin focuses in on how enterprise's often ignore the actual care and feeding of Javascript code within their organization. While he's certainly taken advantage of that ignorance, better that we all figure out how to treat Javascript like a first class language citizen with source control, testing and proper management. You know, like a real language!Support this podcast at — https://redcircle.com/net-rocks/donations
At the Houston #ModernApps2013 Road Trip stop, Carl and Richard talk to Justin Searls about using Javascript in the enterprise. Besides referencing an awesome number of tools around Javascript (check out the huge list of links!), Justin focuses in on how enterprise's often ignore the actual care and feeding of Javascript code within their organization. While he's certainly taken advantage of that ignorance, better that we all figure out how to treat Javascript like a first class language citizen with source control, testing and proper management. You know, like a real language!Support this podcast at — https://redcircle.com/net-rocks/donations
While at DevReach in Sofia, Bulgaria, Carl and Richard moderated a panel on Javascript libraries with Phil Japikse, Dan Wahlin and Justin Searls. The conversation starts out exploring the panelists' favorite libraries and combinations of libraries hereafter referred to as 'tribes.' Lots of discussion on Single Page Applications, mobile web and library management.Support this podcast at — https://redcircle.com/net-rocks/donations
While at DevReach in Sofia, Bulgaria, Carl and Richard moderated a panel on Javascript libraries with Phil Japikse, Dan Wahlin and Justin Searls. The conversation starts out exploring the panelists' favorite libraries and combinations of libraries hereafter referred to as 'tribes.' Lots of discussion on Single Page Applications, mobile web and library management.Support this podcast at — https://redcircle.com/net-rocks/donations
Panel Justin Searls (twitter github blog) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) AJ O’Neal (twitter github blog) Charles Max Wood (twitter github Teach Me To Code) Discussion 01:33 - Justin Searls Test Double 02:14 - Jasmine Pivotal Labs 03:42 - Testing JavaScript 05:29 - CoffeeScript 07:22 - What Jasmine is Unit testing library RSpec DOM agnostic 10:16 - Testing the DOM 14:01 - Tragedy of the commons factory_girl 18:29 - Testing 23:53 - Syntax in Jasmine 26:23 - RSpec and Jasmine 28:07 - Async support in Jasmine 32:18 - Spies mockito Conditional stubbing jasmine-stealth jasmine-fixture 37:30 - jasmine-given Cucumber 43:19 - Running Jasmine jasminerice jasmine-rails jasmine-headless-webkit Testacular testem 49:17 - tryjasmine.com Picks Running MongoDB on AWS (Jamison) The Clean Coder by Robert C. Martin (Joe) Squire.js (Joe and Merrick) Rdio app (Merrick) Square (AJ) Allrecipes.com (AJ) Jenkins CI (Chuck) Apple’s Podcast app (Chuck) lineman (Justin) StarTalk Radio Show with Neil Degrasse Tyson (Justin) To The Moon PC Game (Justin) Transcript JAMISON: Holy cow! JOE: That was not annoying. CHUCK: What’s not annoying? MERRICK: He is punching a bag of Fritos? JOE: Yeah. [Laughter] CHUCK: Well, I was closing it up so they don’t get stale as fast. JOE: You’re very thorough. Those are going to be the least stale… MERRICK: Do you have like a Frito resealer or something? [Laughter] [Shrill sound] CHUCK: Okay, sealed. [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.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] CHUCK: Hey everybody, and welcome to Episode 38 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON: Hi guys! CHUCK: Joe Eames. JOE: Howdy? CHUCK: Merrick Christensen. MERRICK: What’s up? CHUCK: AJ O’Neal is trying to join the call. He’s here. AJ: Yo! Yo! Yo! Coming at you live from the Rental Agreement sphere of Provo, Utah. MERRICK: He lives! CHUCK: I’m Charles Max Wood from DevChat.tv. And this week, we have a special guest. That’s Justin Searls. JUSTIN: Hello. CHUCK: So, why don’t you tell us a little bit about yourself, Justin? JUSTIN: Okay. Well, now that I’m on the spot, my name is Justin. I’m a software developer. I live in Columbus, Ohio. About a year ago, me and a guy named Todd Kaufman started a new company called Test Double. Previously, he and I had been doing consulting for a long, long time. And we’re up to eight people now. And we have a good time building software with an emphasis on terrific interaction design which has resulted in us kind of developing a specialty for well-crafted frontend code, predominantly JavaScript. And I imagine that’s probably why I’m here today. CHUCK: Awesome. Alright. Well, we brought you on to talk about Jasmine. Jasmine was written by, was it Pivotal Labs? JUSTIN: Yeah, Pivotal Labs guys. A guy names Christian Williams who I think has since moved on to Square, and D.W. Frank who’s still at Pivotal. They wrote the core library and me and a whole bunch of other people in the community have piled on with different runners and add-ons and extensions in the sort of like little ecosystem of the 25 people who write unit tests for JavaScript. CHUCK: All 25 of you, huh? JUSTIN: Well, it’s not a lot, right? It’s been a fun journey of being one of the very few people who really, really got excited or chose to get excited about making it easier for folks to write tests in JavaScript or as easy as it would be for whatever servers and language they’d be using.
Panel Justin Searls (twitter github blog) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) AJ O’Neal (twitter github blog) Charles Max Wood (twitter github Teach Me To Code) Discussion 01:33 - Justin Searls Test Double 02:14 - Jasmine Pivotal Labs 03:42 - Testing JavaScript 05:29 - CoffeeScript 07:22 - What Jasmine is Unit testing library RSpec DOM agnostic 10:16 - Testing the DOM 14:01 - Tragedy of the commons factory_girl 18:29 - Testing 23:53 - Syntax in Jasmine 26:23 - RSpec and Jasmine 28:07 - Async support in Jasmine 32:18 - Spies mockito Conditional stubbing jasmine-stealth jasmine-fixture 37:30 - jasmine-given Cucumber 43:19 - Running Jasmine jasminerice jasmine-rails jasmine-headless-webkit Testacular testem 49:17 - tryjasmine.com Picks Running MongoDB on AWS (Jamison) The Clean Coder by Robert C. Martin (Joe) Squire.js (Joe and Merrick) Rdio app (Merrick) Square (AJ) Allrecipes.com (AJ) Jenkins CI (Chuck) Apple’s Podcast app (Chuck) lineman (Justin) StarTalk Radio Show with Neil Degrasse Tyson (Justin) To The Moon PC Game (Justin) Transcript JAMISON: Holy cow! JOE: That was not annoying. CHUCK: What’s not annoying? MERRICK: He is punching a bag of Fritos? JOE: Yeah. [Laughter] CHUCK: Well, I was closing it up so they don’t get stale as fast. JOE: You’re very thorough. Those are going to be the least stale… MERRICK: Do you have like a Frito resealer or something? [Laughter] [Shrill sound] CHUCK: Okay, sealed. [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.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] CHUCK: Hey everybody, and welcome to Episode 38 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON: Hi guys! CHUCK: Joe Eames. JOE: Howdy? CHUCK: Merrick Christensen. MERRICK: What’s up? CHUCK: AJ O’Neal is trying to join the call. He’s here. AJ: Yo! Yo! Yo! Coming at you live from the Rental Agreement sphere of Provo, Utah. MERRICK: He lives! CHUCK: I’m Charles Max Wood from DevChat.tv. And this week, we have a special guest. That’s Justin Searls. JUSTIN: Hello. CHUCK: So, why don’t you tell us a little bit about yourself, Justin? JUSTIN: Okay. Well, now that I’m on the spot, my name is Justin. I’m a software developer. I live in Columbus, Ohio. About a year ago, me and a guy named Todd Kaufman started a new company called Test Double. Previously, he and I had been doing consulting for a long, long time. And we’re up to eight people now. And we have a good time building software with an emphasis on terrific interaction design which has resulted in us kind of developing a specialty for well-crafted frontend code, predominantly JavaScript. And I imagine that’s probably why I’m here today. CHUCK: Awesome. Alright. Well, we brought you on to talk about Jasmine. Jasmine was written by, was it Pivotal Labs? JUSTIN: Yeah, Pivotal Labs guys. A guy names Christian Williams who I think has since moved on to Square, and D.W. Frank who’s still at Pivotal. They wrote the core library and me and a whole bunch of other people in the community have piled on with different runners and add-ons and extensions in the sort of like little ecosystem of the 25 people who write unit tests for JavaScript. CHUCK: All 25 of you, huh? JUSTIN: Well, it’s not a lot, right? It’s been a fun journey of being one of the very few people who really, really got excited or chose to get excited about making it easier for folks to write tests in JavaScript or as easy as it would be for whatever servers and language they’d be using.
Panel Justin Searls (twitter github blog) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) AJ O’Neal (twitter github blog) Charles Max Wood (twitter github Teach Me To Code) Discussion 01:33 - Justin Searls Test Double 02:14 - Jasmine Pivotal Labs 03:42 - Testing JavaScript 05:29 - CoffeeScript 07:22 - What Jasmine is Unit testing library RSpec DOM agnostic 10:16 - Testing the DOM 14:01 - Tragedy of the commons factory_girl 18:29 - Testing 23:53 - Syntax in Jasmine 26:23 - RSpec and Jasmine 28:07 - Async support in Jasmine 32:18 - Spies mockito Conditional stubbing jasmine-stealth jasmine-fixture 37:30 - jasmine-given Cucumber 43:19 - Running Jasmine jasminerice jasmine-rails jasmine-headless-webkit Testacular testem 49:17 - tryjasmine.com Picks Running MongoDB on AWS (Jamison) The Clean Coder by Robert C. Martin (Joe) Squire.js (Joe and Merrick) Rdio app (Merrick) Square (AJ) Allrecipes.com (AJ) Jenkins CI (Chuck) Apple’s Podcast app (Chuck) lineman (Justin) StarTalk Radio Show with Neil Degrasse Tyson (Justin) To The Moon PC Game (Justin) Transcript JAMISON: Holy cow! JOE: That was not annoying. CHUCK: What’s not annoying? MERRICK: He is punching a bag of Fritos? JOE: Yeah. [Laughter] CHUCK: Well, I was closing it up so they don’t get stale as fast. JOE: You’re very thorough. Those are going to be the least stale… MERRICK: Do you have like a Frito resealer or something? [Laughter] [Shrill sound] CHUCK: Okay, sealed. [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.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] CHUCK: Hey everybody, and welcome to Episode 38 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON: Hi guys! CHUCK: Joe Eames. JOE: Howdy? CHUCK: Merrick Christensen. MERRICK: What’s up? CHUCK: AJ O’Neal is trying to join the call. He’s here. AJ: Yo! Yo! Yo! Coming at you live from the Rental Agreement sphere of Provo, Utah. MERRICK: He lives! CHUCK: I’m Charles Max Wood from DevChat.tv. And this week, we have a special guest. That’s Justin Searls. JUSTIN: Hello. CHUCK: So, why don’t you tell us a little bit about yourself, Justin? JUSTIN: Okay. Well, now that I’m on the spot, my name is Justin. I’m a software developer. I live in Columbus, Ohio. About a year ago, me and a guy named Todd Kaufman started a new company called Test Double. Previously, he and I had been doing consulting for a long, long time. And we’re up to eight people now. And we have a good time building software with an emphasis on terrific interaction design which has resulted in us kind of developing a specialty for well-crafted frontend code, predominantly JavaScript. And I imagine that’s probably why I’m here today. CHUCK: Awesome. Alright. Well, we brought you on to talk about Jasmine. Jasmine was written by, was it Pivotal Labs? JUSTIN: Yeah, Pivotal Labs guys. A guy names Christian Williams who I think has since moved on to Square, and D.W. Frank who’s still at Pivotal. They wrote the core library and me and a whole bunch of other people in the community have piled on with different runners and add-ons and extensions in the sort of like little ecosystem of the 25 people who write unit tests for JavaScript. CHUCK: All 25 of you, huh? JUSTIN: Well, it’s not a lot, right? It’s been a fun journey of being one of the very few people who really, really got excited or chose to get excited about making it easier for folks to write tests in JavaScript or as easy as it would be for whatever servers and language they’d be using.
In this episode, Justin Searls of Test Double, shares his experiences – both good and bad, in working with distributed teams, how to turn the tides when things are going noticably sour within a project, and...
This week we’re joined by Justin Searls, JavaScript developer and JS testing EXPERT. We talk lots about building and testing “fat” browser apps, particularly about best practices and different testing approaches. After a while Chris felt bad and told us to shut up. This was the first podcast we broadcast live while recording. Big ups to WonderNetwork for providing the streaming bandwidth, and Engine Yard for sponsoring the podcast. Keep an eye on the @dev_hell Twitter account for info on our next live stream. If you love us, you will do these things: You should follow us on Twitter here. You should rate us on iTunes here Listen Download now (MP3, 33.1MB, 1:16) Notes TestDouble training.gaslightsoftware.com Backbone Idiomatic JS Require.js Jasmine Cucumber Behat Michael Feathers book on working with legacy code Rails asset pipeline Dieter for Clojure Kohana Assets Assetic Webassets for Python Drumkit.js by Chris Powers QUnit Searls on GitHub https://github.com/searls/jasmine-fixture https://github.com/searls/jasmine-given https://github.com/searls/jasmine-stealth Pro JavaScript (John Resig)
© 2020-2025 Ivy Podcast Discovery LLC
