Podcasts about RubyGems

If you like what you hear, please subscribe, leave us a review and tell a friend!

Episode OverviewMarty Haught joins Robby to discuss the sustainability of open-source projects, the challenges of maintaining RubyGems, and why the metaphor of technical debt may not fully capture how software ages. Instead, he suggests thinking of it as drift—the natural misalignment of software with its evolving purpose over time.They also dig into security challenges in package management, including how Ruby Central worked with Trail of Bits to audit RubyGems. Marty also shares insights on the EU Cyber Resilience Act and how it might affect open-source maintainers worldwide. Finally, they explore how companies can support open-source sustainability through corporate sponsorships and individual contributions.Topics Discussed[00:01:00] The two pillars of maintainable software: good tests and readability.[00:02:40] From Perl to Ruby: How readability changed Marty's approach to programming.[00:07:20] Is technical debt the right metaphor? Why "drift" might be a better fit.[00:11:00] What does it take to maintain RubyGems? Marty's role at Ruby Central.[00:14:00] Security in package management: How RubyGems handles vulnerabilities.[00:16:40] The role of external audits: Partnering with Trail of Bits for security improvements.[00:20:40] EU Cyber Resilience Act: How new regulations might affect open-source projects.[00:26:00] Funding open source: Why corporate sponsorships are becoming essential.[00:33:40] Advocating for technical debt work in teams: How to make a compelling case.[00:38:20] Processes in distributed teams: Balancing structure with flexibility.Key TakeawaysTechnical debt is often misunderstood. The real issue may not be shortcuts taken in the past, but the way software naturally drifts from its original purpose.Security in package management is a growing concern. Open-source ecosystems like RubyGems require continuous investment to remain secure.Open source needs sustainable funding. Relying on volunteers is not a long-term solution—companies need to contribute via corporate sponsorships.Advocating for code improvements requires strategy. Engineers should frame technical debt discussions around business impact, not just code quality.Resources MentionedMarty Haught on LinkedInMarty Haught on TwitterRuby CentralRubyGemsAuditing the Ruby Ecosystem's Central Package Repository – Trail of BitsEU Cyber Resilience Act OverviewWhat the EU's New Software Legislation Means for Developers (GitHub Blog)Ruby Central Open Source Program – Get InvolvedCorporate Sponsors ProgramGive and Take by Adam GrantConnect with MartyLinkedInTwitterBlueSkyThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly's got you covered!

In this episode, Jason and Chris welcome back Marty Haught, a long-time leader in the Ruby community, to discuss his history and continued involvement with Ruby Central. Marty shares his journey from joining the Ruby Central board in 2012 to his recent role as interim open source lead. The conversation dives into the origins of RubyGems, the evolution of RailsConf and RubyConf, and the challenges of managing these vital aspects of the Ruby ecosystem. Marty also talks about his plans for sustaining RubyGems' future and the infamous "Marty dinner" tradition at conferences. Hit download now to hear more! Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

In this episode of Maintainable, our host Robby Russell sits down with Martin Emde, a sage in the Ruby community and the current Director of Open Source at Ruby Central. Together, they weave through the intricacies of maintainable software, legacy code, and the unwavering power of the Ruby ecosystem. Martin, with his wealth of experience, shares tales from the trenches of open-source software development, focusing on RubyGems and Bundler, and how they've evolved to face the challenges of modern software needs.Martin addresses the elephant in the room - complexity in software. He muses on the natural progression of software projects from simplicity to complexity, drawing parallels to the growth of living organisms. It's not about fighting complexity, but embracing it with open arms, ensuring the software remains adaptable and maintainable. This conversation sheds light on the importance of testing, documentation, and community support in navigating the seas of complex software development.Diving deeper, they discuss the essence of technical debt, not as a villain in our stories but as a necessary step in the rapid evolution of technology. Martin's perspective on technical debt as a tool for progress rather than an obstacle is refreshing, encouraging developers to approach their work with more kindness and understanding.The discussion also highlights Ruby Central's pivotal role in nurturing the Ruby community, emphasizing the importance of contributions, whether code, conversation, or financial support. Martin's call to action for developers to engage with open-source projects, to adopt gems in need, and to provide support where possible, is a heartwarming reminder of the collective effort required to sustain the vibrant Ruby ecosystem.For those curious minds eager to dive into the world of Ruby, contribute to its growth, or simply enjoy a captivating discussion on software development, this episode is a delightful journey through the challenges and joys of maintaining open-source software. Don't miss out on the gems of wisdom shared in this episode, and be sure to check out the useful links below for more information on how you can contribute to the Ruby community.Book Recommendation:Project Hail Marry by Andy WeirHelpful Links:BundlerRuby CentralAdopt a GemMartin on GithubMartin's websiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Today's episode features a detailed discussion about the upcoming RailsConf 2024, itsprogramming, and significant updates in the Ruby community, particularly regardingRuby Central's contributions. Jason, Chris, and Andrew dive into a conversation withguest, Ufuk Kayserilioglu, Engineering Manager at Shopify's Ruby Infrastructure Team,who recently joined the board of Ruby Central and co-chairs RailsConf 2024. Ufukshares insights on the planned enhancements for the conference to make it morepractical and focused on Rails. He also highlights the formation of the Ruby DeveloperExperience team at Shopify, aimed at improving developer experiences within the Rubyecosystem. The conversation further dives into the financial support for Ruby's opensource projects, such as RubyGems.org and the efforts to sustain and secure Ruby'sinfrastructure. The conversation wraps up with details on RailsConf, an open invitationfor community interaction, and a teaser for special experiences awaiting in-personattendees. Press download now to hear more!Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Senior Developer Jenny Shen from Shopify joins me to discuss RubyGems. In this episode, we unravel the intricate mechanics of dependency resolution within RubyGems, exploring topics such as compact indexes and more. Our discussion extends to the paramount issue of security, where we examine the proactive measures undertaken by the RubyGems team to fortify gems for every Ruby programmer.  PubGrub version solving algorithmThe New Rubygems Index Format by Andre ArkoTrusted Publishing on RubyGems.org

Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service. But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling. And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction." JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun. STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that. JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future. STEPHANIE: Yeah, that's right. JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries. And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that. STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production? JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured. I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far. STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there? JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem. STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community. JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit. STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way. JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages. There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler. And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary. STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs]. The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other. JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems. STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one. JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools. STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs]. JOËL: Right, just insert some vowels in there. STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue. And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about. In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole. JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community. And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different. STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know. JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well. STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs] JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial. As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that. STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis. And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working. And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows. JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems. So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux. And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS. STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it. And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here. JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me. STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs]. JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages? STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?" JOËL: Have you ever sudo gem installed a gem? STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck. JOËL: There was a time where I think that that was in the READMEs for most projects. STEPHANIE: Yeah, that's a really good point. JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac. I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up." STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem? JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs. Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not. STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs]. JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future. STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other. JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path." And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once. STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs]. JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution. So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem. But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other? STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community. But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool. JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff? And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there. STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this. JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line. It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy. For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain. STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial. JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems." STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want. JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume? STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. 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: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Today on Elixir Wizards, Wojtek Mach of HexPM and Amal Hussein, engineering leader and former NPM team member, join Owen Bickford to compare notes on package management in Elixir vs. JavaScript. This lively conversation covers everything from best practices for dependency management to API design, SemVer (semantic versioning), and the dark ages of web development before package managers existed. The guests debate philosophical differences between the JavaScript and Elixir communities. They highlight the JavaScript ecosystem's maturity and identify potential areas of improvement, contrasted against Elixir's emphasis on minimal dependencies. Both guests encourage engineers to publish packages, even small ones, as a learning opportunity. Topics discussed in this episode: Leveraging community packages rather than reinventing the wheel Vetting packages carefully before adopting them as dependencies Evaluating security, performance, and bundle size when assessing packages Managing transitive dependencies pulled in by packages Why semantic versioning is difficult to consistently enforce Designing APIs with extensibility and backward compatibility in mind Using tools like deprecations to avoid breaking changes in new releases JavaScript's preference for code reuse over minimization The Elixir community's minimal dependencies and avoidance of tech debt Challenges in early package management, such as global dependency Learning from tools like Ruby Gems and Bundler to improve experience How log files provide visibility into dependency management actions How lock files pin dependency versions for consistency Publishing packages democratizes access and provides learning opportunities Linting to enforce standards and prevent certain bugs Primitive-focused packages provide flexibility over highly opinionated ones Suggestions for improving documentation and guides Benefits of collaboration between programming language communities Links mentioned in this episode: Node.js https://github.com/nodejs npm JavaScript Package Manager  https://github.com/npm JS Party Podcast https://changelog.com/jsparty Dashbit https://dashbit.co/ HexPM Package Manager for Erlang https://hex.pm/ HTTP Client for Elixir https://github.com/wojtekmach/req Ecto Database-Wrapper for Elixir https://github.com/elixir-ecto (Not an ORM) XState Actor-Based State Management for JavaScript https://xstate.js.org/docs/ Supply Chain Protection for JavaScript, Python, and Go  https://socket.dev/ MixAudit https://github.com/mirego/mixaudit NimbleTOTP Library for 2FA https://hexdocs.pm/nimbletotp/NimbleTOTP.html Microsoft Azure https://github.com/Azure Patch Package https://www.npmjs.com/package/patch-package Ruby Bundler to manage Gem dependencies https://github.com/rubygems/bundler npm-shrinkwrap https://docs.npmjs.com/cli/v10/commands/npm-shrinkwrap SemVer Semantic Versioner for NPM https://www.npmjs.com/package/semver Spec-ulation Keynote - Rich Hickey https://www.youtube.com/watch?v=oyLBGkS5ICk Amal's favorite Linter https://eslint.org/ Elixir Mint Functional HTTP Client for Elixir https://github.com/elixir-mint Tailwind Open Source CSS Framework https://tailwindcss.com/ WebauthnComponents https://hex.pm/packages/webauthn_components Special Guests: Amal Hussein and Wojtek Mach.

This week, Samuel Giddins and I discuss life on call as a developer, the upcoming RubyConf,  the pitfalls of online communications, Sam's beginnings as a developer, software supply chain security, and the difference between "amicable" and "amiable."  Sam will be at the Ruby Gems and Bundler open space at RubyConf in San Diego on Monday, November 13th 2023.Samuel Giddins' SiteSamuel Giddins on Hachyderm.ioRubyGems BlogRubyConf

Allen Wyma talks with Ian Ker-Seymer about his work on rb-sys which easily allows you to integrate Ruby with Rust. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you'd like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Timestamps [@00:00] - Guest introduction: Ian Ker-Seymer - Staff Software Engineer at Shopify [@02:04] - The connection between Liquid and Shopify [@06:19] - The nenefits of using WebAssembly [@11:14] - Exploring the languages in Shopify's stack, including Ruby [@14:24] - Rust's practical use cases [@16:44] - How Rust became part of Shopify's stack [@19:14] - Deep dive into rb-sys [@24:17] - RubyGems and Bundler: insights and considerations [@36:41] - Integrating Rust into the stack [@40:52] - Addressing challenges with Windows compilation [@47:46] - Spotlight on rb-sys: why it's worth exploring Credits Intro Theme: Aerocity Audio Editing: Plangora Hosting Infrastructure: Jon Gjengset Show Notes: Plangora Hosts: Allen Wyma

Ruby Central head of open source André Arko talks Bundler, Ruby Gems, supporting the community, and more.André Arko will be speaking at RubyConf 2023 this year Support Bundler/RubyGems open source work via Ruby CentralFollow us on Mastodon: Rooftop Ruby Collin Joel Show art created by JD Davis.

On today's episode of Remote Ruby, the conversation begins with Jason, Chris and Andrew discussing their experiences with podcasting and how they started. Then, the conversation takes a shift to discussing using the latest version of RubyGems in Bundler, the addition of a new feature called, gem exec, that allows for easy running of executables from gems that may or may not be installed, and more about GemX.  Twitter's new algorithm is mentioned, along with someone who leaked Twitter's source code on GitHub. Chris talks about some frustrating experiences with his Rails for Beginner's Course that he's releasing very soon which will be free, and some plans to expand the curriculum. There's a discussion on the challenges of teaching and learning programming, the process of recording tutorials, and Chris shares some tips and tricks for Ruby programming. Ruby is magic, so go make some magic and press download to hear much more! [00:03:18] The guys catch up on what's been happening with work, and Andrew tells us he tried the new gem exec stuff in RubyGems, he explains the new feature, and there's a discussion about the advantages of the new feature and how it works, which ends with a bit of confusion. [00:10:03] Andrew brings up an example and mentions a gem called GemX that people are using.[00:12:09] We hear about a gem Andrew wrote that was printed out a like business card with cool texts in the terminal and how he was inspired by someone in the Node community.[00:14:04] Jason brings up Twitter releasing “The algorithm,” and how someone leaked Twitter's source code on GitHub. [00:17:52] In Chris's world, he tells us how he's been re-recording his Rails for Beginner's Course and his frustrating experience with trying to use Digital Ocean Spaces for image uploading, as well as frustrations with CORS configuration and policy instructions.[00:28:41] Chris and Andrew discuss the challenges of teaching and learning programming, specifically Ruby on Rails. [00:32:15] Chris mentions the upcoming release of a new Rails for Beginner's Course, which will include six hours of Ruby content, and plans to expand the curriculum to include more topics like HTML, CSS, and JavaScript.[00:33:35] Andrew and Chris discuss the process of recording tutorials, which can be time consuming and difficult to balance between explaining concepts and providing practical examples. [00:37:06] Listen here for some tips and tricks from Chris for Ruby programming, including using simple delegator and modules on individual instances of a class. He also talks about a blog post on Thoughtbot and about The Gilded Rose Code Kata. [00:42:28] Jason chimes in saying he's just been writing maintenance task and talks about his struggles with abstractions.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterGemX GoRails[Experimental] Add gem exec command to run executables from gems that may or may not be installed #6309Evaluating Alternative Decorator Implementations in Ruby (Dan Croak-Thoughtbot)Refactoring: The Gilded Rose-Rubies in the RoughRuby Radar TwitterRuby for All Podcast

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

VIDEO of the Week Crashing Laptop Computers With Janet Jackson RealTek SoC flaw affects many millions of IoT devices 46 Million RPS - requests per second Chrome's 5th 0-Day of 2022 Apple: Not to be left behind... RubyGems to require MFA Closing The Loop: Domain Name Ownership Closing The Loop: Growing in Cybersecurity The Bumblebee Loader We invite you to read our show notes at https://www.grc.com/sn/SN-885-Notes.pdf Hosts: Leo Laporte and Steve Gibson Download or subscribe to this show at https://twit.tv/shows/security-now. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: canary.tools/twit - use code: TWIT barracuda.com/securitynow Melissa.com/twit

Josh and Kurt talk about PyPI mandating two factor authentication for the top 1% of projects. It feels like a simple idea, but it's not when you start to think about it. What problems does 2FA solve? How common are these attacks? What are the second and third order effects of mandating 2FA? This episode should have something for everyone on all sides of this discussion to violently disagree with. Show Notes PyPI announcement NPM expired domains Morten Linderud Tweet Congratulations: We Now Have Opinions on Your Open Source Contributions

This week in the AppSec News: SynLapse shows shell injection via ODBC, Java deserialization example, MFA for Ruby Gems ecosystem, simple flaws in firmware, the decade-long journey of a Safari vuln, & more!   IE has gone to 11 and is no more. There's some notable history related to IE11 and bug bounty programs. In 2008, Katie Moussouris and others from Microsoft announced their vulnerability disclosure program. In 2013 this evolved into a bug bounty program piloted with IE11, with award ranges from $500 to $11,000. Ten years later, that bounty range is still common across the industry. The technical goals of the program remain similar as well -- RCEs, universal XSS, and sandbox escapes are all vulns that can easily gain $10,000+ (or an order of magnitude greater) in modern browser bounty programs. So, even if we've finally moved on from a browser with an outdated security architecture, we're still dealing with critical patches in modern browsers. Fortunately, the concept of bounty programs continues. References: - https://www.blackhat.com/presentations/bh-usa-08/Reavey/MSRC.pdf - https://media.blackhat.com/bh-usa-08/video/bh-us-08-Reavey/black-hat-usa-08-reavey-securetheplanet-hires.m4v - https://web.archive.org/web/20130719064943/http://www.microsoft.com/security/msrc/report/IE11.aspx - https://web.archive.org/web/20190507215514/https://blogs.technet.microsoft.com/bluehat/2013/07/03/new-bounty-programs-one-week-in/   Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/secweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/asw201

This week in the AppSec News: SynLapse shows shell injection via ODBC, Java deserialization example, MFA for Ruby Gems ecosystem, simple flaws in firmware, the decade-long journey of a Safari vuln, & more!   IE has gone to 11 and is no more. There's some notable history related to IE11 and bug bounty programs. In 2008, Katie Moussouris and others from Microsoft announced their vulnerability disclosure program. In 2013 this evolved into a bug bounty program piloted with IE11, with award ranges from $500 to $11,000. Ten years later, that bounty range is still common across the industry. The technical goals of the program remain similar as well -- RCEs, universal XSS, and sandbox escapes are all vulns that can easily gain $10,000+ (or an order of magnitude greater) in modern browser bounty programs. So, even if we've finally moved on from a browser with an outdated security architecture, we're still dealing with critical patches in modern browsers. Fortunately, the concept of bounty programs continues. References: - https://www.blackhat.com/presentations/bh-usa-08/Reavey/MSRC.pdf - https://media.blackhat.com/bh-usa-08/video/bh-us-08-Reavey/black-hat-usa-08-reavey-securetheplanet-hires.m4v - https://web.archive.org/web/20130719064943/http://www.microsoft.com/security/msrc/report/IE11.aspx - https://web.archive.org/web/20190507215514/https://blogs.technet.microsoft.com/bluehat/2013/07/03/new-bounty-programs-one-week-in/   Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/secweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/asw201

Uppföljning/uppvärmning Lite prylfilosoferande, och undrande över Skypes vara och icke vara Grillevlande Poddredigeringsfilosofi Christian starstruck: superspeciell gäst: Jezper Söderlund! Fredrik på skärmoffensiv, i alla fall tillfälligt. Vild diskussion av skärmars placering och fönsterhantering utbryter En kortis om Android auto Ämnen Livet med Tesla, är det enklare och bättre än livet med Polestar? Spoiler: nja Playdate - en mysig liten maskin M1 - vilken trevlig processor det är ändå. Med en utvikning om telefoner, deras datatrafik, och att skilja på jobb och fritid Bloggar, vad ska man egentligen bygga dem på? Quest-rapporten. Det är svårt att komma över användandetröskeln Länkar Jezper En podd om teknik Slashat Sista avsnittet av En podd om teknik Första sista avsnittet av En podd om teknik - uppdelat på massor av avsnitt med start här Första sista avsnittet av En podd om teknik på Youtube Sizeup - app Jezper använder för att placera fönster Mosaic - app Jezper använder för att placera fönster Förra avsnittet Playdate Hades The forgotten city Spelen som följer med Playdate QWOP - löparspelet där du styr benmuskler Zipper - spel av Bennett Foddy, skaparen till QWOP Teenage engineering Playdatehögtalaren med pennfack Johan Flat file-CMS Ruby Ruby gems - Rubys pakethanteringssystem Fredriks bloggmotor Hugo deepedition.com femte.se Bear Panda - Bears nya Markdowneditor Winfs Quest 2 Tales from the galaxy's edge Vanishing Grace - det “Firewatch-aktiga” spelet Lone echo Eleven table tennis Deisim - gudaspelet Ghost giant Moss Vader: Immortal Tetris effect Inside Presentationen om ljuddesignen i Inside Limbo Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-315-en-skarm-som-inte-ar-upplyst-i-ett-land-som-aldrig-ar-ljust.html

This week in the AppSec News: SynLapse shows shell injection via ODBC, Java deserialization example, MFA for Ruby Gems ecosystem, simple flaws in firmware, the decade-long journey of a Safari vuln, & more!   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw201

This week in the AppSec News: SynLapse shows shell injection via ODBC, Java deserialization example, MFA for Ruby Gems ecosystem, simple flaws in firmware, the decade-long journey of a Safari vuln, & more!   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw201

• 00:00:34 - Cinnamon 5.4 • 00:09:40 - Radeon Memory Visualizer • 00:15:55 - Fedora Cloud возвращается • 00:20:50 - Oracle Linux 9 • 00:27:42 - RubyGems authentication • 00:33:00 - Proton 7.0-3 • 00:39:40 - KDE Plasma 5.25 • 00:50:02 - browser-linux • 01:01:50 - Kdenlive 22.04.2 • 01:09:10 - K-9 Mail & Thunderbird • 01:16:08 - Ubuntu Core 22 • 01:20:25 - Остановлена поддержка IE • 01:28:25 - Adobe Photoshop Web

Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/yanking-rubygems-big-ip-auth-bypass-and-a-priceline-account-takeover.html A lot of cool little bugs this week with some solid impact, Facebook and Priceline account takeovers, F5 iControl Authentication Bypass, and a couple other logic bugs. [00:01:55] rubygems CVE-2022-29176 explained [00:06:09] Multiple bugs chained to takeover Facebook Accounts which uses Gmail [00:15:16] [curl] curl removes wrong file on error [CVE-2022-27778] [00:18:33] [Priceline] Account takeover via Google OneTap [00:22:14] F5 iControl REST Endpoint Authentication Bypass Technical Deep Dive [00:29:02] The Underrated Bugs, Clickjacking, CSS Injection, Drag-Drop XSS, Cookie Bomb, Login+Logout CSRF… [00:30:20] Hunting evasive vulnerabilities The DAY[0] Podcast episodes are streamed live on Twitch (@dayzerosec) twice a week: Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The Video archive can be found on our Youtube channel: https://www.youtube.com/c/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming.

Where does the word "radio" come from? RubyGems supply chain rip-and-replace bug. A weird, weird, weird, weird, weird GoogleDocs bug. Colonial Pipeline back in the cybersecurity news. What about built-in password managers? Original music by Edith Mudge Got questions/suggestions/stories to share? Email tips@sophos.com Twitter @NakedSecurity Instagram @NakedSecurity

[00:03:05] Chris tells us more about the bug he was trying to fix, working on Stripe tax support, Stripe payment element and addresses, and he fills us in on a JavaScript tool that Shopify for formatting addresses in different countries that makes Andrew sweat.[00:07:28] As a follow up from last week's episode, Andrew defines “Posterized.”[00:08:06] The guys chat about WebAssembly stuff.[00:11:49] Andrew talks about playing around with mruby, and Chris tells us about what he did with a Raspberry Pi.[00:16:07] Jason tells us he's been reading the mruby docs and about how you take embedded Ruby and run it.[00:17:34] A previous episode is brought up with guest Terence Lee, where they talked quite a bit about mruby. [00:18:19] Chris brings up Ruby 3.2.0, some of the changes that are happening with it, especially rewriting it in Rust. Also, Ruby will be 30 years old next year! [00:26:04] Andrew tells us about a conversation he had with Drew Bragg recently because he offered to help him with automatic releases on his Ruby Gem, and he explains Release Please.[00:31:12] What does Andrew think about getting PR's on an open source project? [00:33:51] Andrew fills us in on how he used Semantic Commit and Conventional Commit messages everywhere, and a setting they changed in Ruby gems.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterTry Ruby PlaygroundPosterizedmrubyRemote Ruby podcast-Episode 27: Joined by Terence LeeRuby 3.2.0 Preview 1 ReleasedAdd release-please action for releasing to RubyGems #14 Release Please Action-GitHubRelease Please-GitHub

Robby speaks with Emily Giurleo, Senior Software Developer and co-founder/organizaer of WNB.rb. In this episode, Emily shares the importance of software communicating its purpose, the differences between maintaining open source versus propritary software projects, and community building.Additionally, they discuss Emily's experience of being a paid maintainer of MongoDB's Ruby client library, the importance of useful CHANGELOGs, debugging tips for Rubygems, when to and/or not to use mocks.Helpful LinksEmily's TwitterEmily's LinkedInEmily's WebsiteEmily's GithubWNB.rb @wnb_rb, contact organizersEmily's talk at RubyConf 2021: To mock, or not to mock?Sandi Metz: Making is Easy, Mending is a ChallengeMongo Ruby DriverEmily's Book Recommendation: Radical Candor by Kim ScottSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

As with many a programming language, ruby was originally designed as a teaching language - to teach programming to students at universities. From there, it is now used to create various programs, including games, interfaces for websites, scripts to run on desktop computers, backend REST endpoints, and business software. Although ruby is used for web development more than anything else. It has an elegant syntax that makes it easy to read the code; this is one of the reasons why Ruby is so popular, especially with beginners (after all it was designed to teach programming). Yukihiro Matsumoto, or Mats for short, originally developed the ruby's programming language in the 1990s. Ruby was initially designed as an interpreted scripting language. That first interpreter, MRI, or Mats's Ruby Interpreter, spread quickly. In part because he's nice. In fact, he's so nice that the motto MINASWAN, or “Matz is nice and so we are nice.” Juxtapose this against some of the angrier programmers who develop their own languages. And remember, it was a teach language. And so he named ruby  after a character he encountered in a children's book. Or because it was a birthstone. Or both. He graduated from the University of Tsukuba and worked on compilers before writing a mail agent in Emacs Lisp. Having worked with Lisp and Perl and Python, he was looking for a language that was truly object-oriented from the ground up. He came up with the idea in 1993 of another Lisp at the core, but something that used objects like Smalltalk. That would allow developers to write less cyclomatically complex code. And yet he wanted to provide higher-order functions for routine tasks like Perl and Python did. Just with native objects rather than those bolted on the side. And he wanted to do so in as consistent a manner as possible. Believe it or not that meant dynamic typing. And garbage collection for free. And literal notation for some things like arrays and regular expressions while allowing for dynamic reflection for meta programming and allowing for everything to be an expression. The syntax is similar to a python or a perl and yet whitespace in things like indentation doesn't play a part. It's concise and the deep thinking that goes into making something concise can be incredible. And yet freeing.  The first version of Ruby was released in 1995 and allowed programs to be concise, so written with fewer lines of code than would have been possible with other languages at the time. And yet elegant. In 1996, David Flanagan and Jim Weirich grabbed the MRI interpreter and started using ruby for real projects. And so ruby expanded outside of Japan.  As the popularity grew, Matz founded his own company called Object Technology Inc, This allowed him to continue developing Ruby while making money. After all, programmers gotta' eat too. In 2006 Matsumoto committed the first version of what would eventually become Rails on Version Control Systems (VCS), a precursor git.  Ruby is written in C, which means it has access to most underlying operating systems given the right API access. It has a vast dictionary with nearly 1 million entries. It can often be found in many event-driven frameworks, with the most popular being Ruby on Rails, a server-side web application framework developed by David Heinemeier Hansson of Basecamp in 2004. Other frameworks include Sinatra (which came in 2007), Roda, Camping (which comes in at a whopping 4k in size), and Padrino. And Ramaze and Merb and Goliath. Each has their own merits.  These libraries help developers code faster, easier, and more efficiently than if they had to write all the server-side code from scratch. Another aspect of Ruby that made it popular is a simple package manager. RubyGems came about in 2003. Here, we lay out a simple structure that includes a README, a gem spec with info about the gem, a lib directory (the code for the gem), a test directory, and a makefile for Ruby they call a Rake. This way the developer of the gem does everything needed to be able to call them in their code. And so there are now well over 100,000 gems out there. Not all work with all the interpreters. Ruby went from 1.0 in 1996 to 1.2 in 1998 to 1.4 in 1999 and 1.6 in 2000. Then to 1.8 in 2003 and by then it was gettin popular and ready to get standardized. This always slows down changes. So it went to become an ISO standard in 2012 - the hallmark if you will that a language is too big to fail. Ruby 2 came along the next year with nearly full backwards compatibility. And then 3 came in 2020 in order to bring just-in-time compilation, which can make the runtime faster than just interpreting. And unlike the XRuby variant, no need to do java-style compilation. Still, not all ruby tooling needs to be compiled. Ruby scripts can be loaded in tools like Amazon's Lambda service or Google Cloud Functions. From there, it can talk to tools like MySQL and MongoDB. And it's fun. I mean, Matz uses the word fun. And ruby can present a challenge that to experienced programmers might be seen as fun. Because anything you can do with other languages, you can do with ruby. Might not get as much for free as with a spring security for Java, but it's still an excellent language and sometimes I can't help but wonder if we shouldn't get so much for free with certain lanuages. Matz is now the chief architect of Heroku. He has since written a slimmed down version of ruby called mruby and another language called streem. He also wrote a few books on ruby. Because you know, he's nice.

Ivo Anjo joins the Rogues to discuss Ractors in Ruby and how they can be used. They're not actors as they appear in other languages. They communicate via message passing. Ivo clarifies several things about Ractors and what their powerful features and the understanding of what they do and how they work. Panel John EppersonValentino Stoll Guest Ivo Anjo Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Links  Ruby Ractor Experiments: Safe async communication - ivo's awfully random tech blog Unsafe Concurrent Ruby PatternsJRuby in production applications 1subscribe to my newsletter!Ivo Anjo.meTwitter: Ivo Anjo ( @KnuX ) Picks Ivo- Ruby Hacking Guide Ivo- Lone Echo II: Journey In Zero Gravity With Rift S | OculusJohn- bullet | RubyGems.org | your community gem hostJohn- RubyConf 2021Valentino- Creating a UDP server with Ruby Ractors Special Guest: Ivo Anjo.

Ivo Anjo joins the Rogues to discuss Ractors in Ruby and how they can be used. They're not actors as they appear in other languages. They communicate via message passing. Ivo clarifies several things about Ractors and what their powerful features and the understanding of what they do and how they work. Panel John EppersonValentino Stoll Guest Ivo Anjo Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Links  Ruby Ractor Experiments: Safe async communication - ivo's awfully random tech blog Unsafe Concurrent Ruby PatternsJRuby in production applications 1subscribe to my newsletter!Ivo Anjo.meTwitter: Ivo Anjo ( @KnuX ) Picks Ivo- Ruby Hacking Guide Ivo- Lone Echo II: Journey In Zero Gravity With Rift S | OculusJohn- bullet | RubyGems.org | your community gem hostJohn- RubyConf 2021Valentino- Creating a UDP server with Ruby Ractors Special Guest: Ivo Anjo.

Guest Dan Lorenc Panelists Eric Berry | Justin Dorfman | Richard Littauer Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Today, we have a very special guest, Dan Lorenc, who is a Staff Software Engineer and the lead for Google's Open Source Security Team. Dan founded projects like Minikube, Skaffold, TektonCD, and Sigstore. He blogs regularly about supply chain security and serves on the TAC for the Open SSF. Dan fill us in on how Docker fits into what he's doing at Google, he tells us about who's running the Open Standards that Docker is depending on, and what he's most excited for with Docker with standardization and in the future. We also learn a little more about a blog post he did recently and what he means by “package managers should become boring,” and he tells us how package managers can help pay maintainers to support their libraries. We learn more about his project Sigstore, and his perspective on the long-term growth of the software industry towards security and how that will change in the next five to ten years. Go ahead and download this episode now to find out much more! [00:01:09] Dan tells us his background and how he got to where he is today. [00:03:08] Eric wonders how Docker fits into what Dan is doing at Google and if he can compare Minicube and his work with what the Docker team is trying to drive. He also compares Kubernetes to Docker and how they relate. [00:06:13] Dan talks about if he sees a shift of adoption in the sphere of what he's seeing, and Eric asks if he feels that local development with Docker is devalued a little bit if you don't use the same Docker configuration for your production deploy. [00:08:49] Richard wonders in the long-term, if Dan thinks we're going to continually keep making Dockers, better Kubernetes, or at some point are we going to decide that tooling is enough. [00:10:35] We learn who's currently running the Open Standards that Docker is depending on and Dan talks about the different standards. [00:12:13] Dan shares how he thinks the shift towards open standards in particular with Docker, influences open source developers who are in more smaller companies, in SMEs, in medium-sized companies, or solo developers out there who may not have the time to get involved in open standards. [00:13:45] Find out what Dan is really excited about in terms of Docker, with standardization or in the future that will lead to a more sustainable ecosystem. [00:15:17] Justin brings up Dan's blog and a recent post he just did called, “In Defense of Package Managers,” and in it he mentions package managers should become boring, so he explains what he means by that. [00:18:01] Dan discusses how package managers can help pay maintainers to support their libraries. [00:22:03] Richard asks Dan if he has any thoughts on getting other ways of recognition to maintainers down the stack than just paying them. He mentions things that he loves that GitHub's been doing recently showing people their contribution history. [00:23:46] Find out about Dan's project Sigstore and what his adoption looks like so far. [00:26:35] Richard wonders if Dan thinks it's a good idea to have that ecosystem depend upon a few brilliant people like him doing this work or if there's a larger community of people working on security supply chain issues. Also, who are his colleagues that he bounces these ideas off of and how do we eliminate the bus factor here. Dan tells us they have a slack for Sigstore [00:30:03] We learn Dan's perspective on the long-term growth of the software industry towards security in general, how will that change over the next five to ten years, and how his role and the role of people like him will change. [00:31:35] Find out all the places you can follow Dan on the internet. Quotes [00:10:14] “You kind of move past that single point of failure and single tool shame that's actually used to manage everything.” [00:12:44] “So, they kind of helped contribute to the standardization process by proving stuff out by getting to try all the new exciting stuff.” [00:16:33] The “bullseye” release actually just went on a couple of days ago which was awesome.” [00:17:04] “It's a problem because there's nobody maintaining, which is a really good topic for sustainability.” [00:24:46] “But nobody's doing it for open source, nobody's signing their code on PyPy or Ruby Gems even though you can.” [00:29:50] “These are not the Kim Kardashians of the coding community.” [00:30:25] “Something that we've been constantly reminding, you know, the policy makers wherever we can, is that 80 to 90% of software in use today is open source.” [00:30:51] “And even if companies can do this work for the software that they produce if we don't think of, and don't take care of, and don't remember that these same requirements are going to hit opensource at the very bottom of the stack, and we're kind of placing unfunded mandates and burdens on these repositories and maintainers that they didn't sign up for it.” [00:31:11] “So we're really trying to remind everyone that as we increase these security standards, which we should do and we need to do, because software is serious, and people's lives depend on it.” Spotlight [00:32:32] Eric's spotlight is a game called Incremancer by James Gittins. [00:33:35] Justin's spotlight is Visual Studio Live Share. [00:34:04] Richard's spotlight is the BibTeX Community. [00:35:03] Dan's spotlight is the Debian maintainers. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) Dan Lorenc Twitter (https://twitter.com/lorenc_dan?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Dan Lorenc Linkedin (https://www.linkedin.com/in/danlorenc) Dan Lorenc Blog (https://dlorenc.medium.com/) Tekton (https://tekton.dev/) Minikube (https://minikube.sigs.k8s.io/docs/) Skaffold (https://skaffold.dev/) Open SSF (https://openssf.org/) Open Container Initiative (https://opencontainers.org/) Committing to Cloud Native podcast-Episode 20-Taking Open Source Supply Chain Security Seriously with Dan Lorenc (https://podcast.curiefense.io/20) “In Defense of Package Managers” by Dan Lorenc (https://dlorenc.medium.com/in-defense-of-package-managers-31792111d7b1?) Open Source Insights (https://deps.dev/) GitHub repositories Nebraska users (https://github.com/search?q=location%3Anebraska&type=users) CHAOSScast podcast (https://podcast.chaoss.community/) Sigstore (https://www.sigstore.dev/) RyotaK Twitter (https://twitter.com/ryotkak) Dustin Ingram Twitter (https://twitter.com/di_codes?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Incremancer (https://incremancer.gti.nz/) Visual Studio Live Share (https://visualstudio.microsoft.com/services/live-share/) Enhanced support for citations on GitHub-Arfon Smith (https://github.blog/2021-08-19-enhanced-support-citations-github/) Debian (https://www.debian.org/) Debian “bullseye” Release (https://www.debian.org/releases/bullseye/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Dan Lorenc.

Maxwell Anselm discusses the options that he's found to build multi-platform mobile applications. The panel chimes in on different options. Maxwell also goes into how he uses Ruby in non-Ruby codebases. Panel Darren Broemmer Dave Kimura John Epperson Luke Stutters Guest Maxwell Anselm Sponsors Dev Influencers Accelerator Level Up | Devchat.tv PodcastBootcamp.io Links The Definitive Guide to RUBY's C API Kotlin for Cross-Platform Mobile Development Flutter Shardbox RubyMotion Life in the slow lane GitHub: Max ( silverhammermba ) Picks Darren- Gosu Dave-  TKD Breakable Boards Dave-  12v USB Fan Cable  John- GitHub | svenfuchs/gem-release John- fastlane Luke- Linux Fun Luke- LRUG August 2021 Maxwell- ffi | RubyGems Contact Darren: Twitter: Darren Broemmer ( @DarrenBroemmer ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz ) Contact John: Rock Agile Consulting GitHub: John Epperson ( kirillian ) LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts )

Maxwell Anselm discusses the options that he's found to build multi-platform mobile applications. The panel chimes in on different options. Maxwell also goes into how he uses Ruby in non-Ruby codebases. Panel Darren BroemmerDave KimuraJohn EppersonLuke Stutters Guest Maxwell Anselm Sponsors Dev Influencers AcceleratorLevel Up | Devchat.tvPodcastBootcamp.io Links The Definitive Guide to RUBY's C APIKotlin for Cross-Platform Mobile DevelopmentFlutterShardboxRubyMotionLife in the slow laneGitHub: Max ( silverhammermba ) Picks Darren- GosuDave-  TKD Breakable BoardsDave-  12v USB Fan Cable John- GitHub | svenfuchs/gem-releaseJohn- fastlaneLuke- Linux FunLuke- LRUG August 2021Maxwell- ffi | RubyGems Contact Darren: Twitter: Darren Broemmer ( @DarrenBroemmer ) Contact Dave: Ruby on Rails ScreencastsTwitter: Dave Kimura ( @kobaltz )GitHub: David Kimura ( kobaltz ) Contact John: Rock Agile ConsultingGitHub: John Epperson ( kirillian )LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts ) Special Guest: Maxwell Anselm.

Maxwell Anselm discusses the options that he's found to build multi-platform mobile applications. The panel chimes in on different options. Maxwell also goes into how he uses Ruby in non-Ruby codebases. Panel Darren Broemmer Dave Kimura John Epperson Luke Stutters Guest Maxwell Anselm Sponsors Dev Influencers Accelerator Level Up | Devchat.tv PodcastBootcamp.io Links The Definitive Guide to RUBY's C API Kotlin for Cross-Platform Mobile Development Flutter Shardbox RubyMotion Life in the slow lane GitHub: Max ( silverhammermba ) Picks Darren- Gosu Dave-  TKD Breakable Boards Dave-  12v USB Fan Cable  John- GitHub | svenfuchs/gem-release John- fastlane Luke- Linux Fun Luke- LRUG August 2021 Maxwell- ffi | RubyGems Contact Darren: Twitter: Darren Broemmer ( @DarrenBroemmer ) Contact Dave: Ruby on Rails Screencasts Twitter: Dave Kimura ( @kobaltz ) GitHub: David Kimura ( kobaltz ) Contact John: Rock Agile Consulting GitHub: John Epperson ( kirillian ) LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts )

Maxwell Anselm discusses the options that he's found to build multi-platform mobile applications. The panel chimes in on different options. Maxwell also goes into how he uses Ruby in non-Ruby codebases. Panel Darren BroemmerDave KimuraJohn EppersonLuke Stutters Guest Maxwell Anselm Sponsors Dev Influencers AcceleratorLevel Up | Devchat.tvPodcastBootcamp.io Links The Definitive Guide to RUBY's C APIKotlin for Cross-Platform Mobile DevelopmentFlutterShardboxRubyMotionLife in the slow laneGitHub: Max ( silverhammermba ) Picks Darren- GosuDave-  TKD Breakable BoardsDave-  12v USB Fan Cable John- GitHub | svenfuchs/gem-releaseJohn- fastlaneLuke- Linux FunLuke- LRUG August 2021Maxwell- ffi | RubyGems Contact Darren: Twitter: Darren Broemmer ( @DarrenBroemmer ) Contact Dave: Ruby on Rails ScreencastsTwitter: Dave Kimura ( @kobaltz )GitHub: David Kimura ( kobaltz ) Contact John: Rock Agile ConsultingGitHub: John Epperson ( kirillian )LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts ) Special Guest: Maxwell Anselm.

This week I discuss the latest InfoSec news including Cloudflare, Git and infected Ruby Gems, ransomware news, the latest data leaks, as well as optimizing your reverse image search capabilities.

stdout.fm 38번째 로그에서는 RubyGems strong_password 해킹 사건, 소프트웨어 환멸감, Zoom MacOS 클라이언트 등에 대해서 이야기를 나눴습니다. stdout.fm are creating…

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Webpacker 4.0.2, Rubygems: March 2019 Security Advisories, Rails 6 adds Relation#reselect и Ruby's Hidden Gems, StringScanner Mruby/c - an another implementation of mruby, StoreModel - gem for handling JSON-backed attributes as ActiveRecord models, Active-record-query-trace - find the origin of all SQL queries in your Rails applications и What's New in Rails 6 (video) Web Storybook 5.0, JavaScript Performance Pitfalls in V8, Maintaining large JavaScript applications и JavaScript naming conventions: do's and don'ts JavaScript Algorithms and Data Structures, Handtrack.js: Hand Tracking Interactions in the Browser using Tensorflow.js and 3 lines of code и RFS - a font size engine which automatically calculates the appropriate font size based on the dimensions of the browser viewport

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby RubyGems 3.0.0 Released, Timeline for the release of Rails 6.0 и Ruby 2.6 JIT - Progress and Future Mastering data structures in Ruby — Recap, Disassembling Rails — Template Rendering (2) и Ruby Conferences ‘n' Camps in 2019 - What's Upcoming? JavaScript Electron 4.0.0, React v16.7: No, This Is Not The One With Hooks и Why Do React Hooks Rely on Call Order? Why I no longer use D3.js, Building Open Source Google Analytics from Scratch и Neural Network Knows When Cat Wants To Go Outside

Julie Moronuki: @argumatronic | argumatronic.com Show Notes: This episode is a follow-up episode to the one we did with Julie in September: Learn Haskell, Think Less. We talk a whole lot about monoids, and learning programming languages untraditionally. Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 93. My name is Charles Lowell, a developer here at The Frontside and I am your podcast host-in-training. With me today from The Frontside is Elrick also. Hello, Elrick. ELRICK: Hey. CHARLES: How are you doing? ELRICK: I'm doing great. CHARLES: Alright. Are you ready? ELRICK: Oh yeah, I'm excited. CHARLES: You ready to do some podcasting? Alright. Because we actually have a repeat guest on today. It was a very popular episode from last year. We have with us the author of ‘Learning Haskell: From First Principles' and a book that is coming out but is not out yet but one that we're eagerly looking forward to, Julie Moronuki. Welcome. JULIE: Hi. It's great to be back. CHARLES: What was it about, was it last October? JULIE: I think it was right before I went to London to Haskell [inaudible]. CHARLES: Yeah. JULIE: Which was in early October. So yeah… CHARLES: Okay. JULIE: Late or early October, somewhere in there. CHARLES: Okay. You went to Haskell eXchange. You gave a talk on Monoids. What have you been up to since then? JULIE: Oh wow. It's been a really busy time. I moved to Atlanta and so I've had all this stuff going on. And so, I was telling a friend last night “I'm going to be on this podcast tomorrow and I don't think I have anything to talk about.” [Laughter] JULIE: Because I feel like everything has just been like, all my energy has been sucked up with the move and stuff. But I guess… CHARLES: Is it true that everybody calls it ‘Fatlanta' there? JULIE: Yeah. [Laughs] CHARLES: I've heard the term. But do people actually be like “Yes, I'm from Fatlanta.” JULIE: I've heard it a couple of times. CHARLES: Okay. JULIE: Maybe it's mostly outsiders. I'm not sure. CHARLES: [Chuckles] JULIE: But yeah, it's a real cool city and I'm real happy to be here. But yeah, I did go in October. I went to London and I spoke at Haskell eXchange which was really amazing. It was a great experience and I hope to be able to go back. I got to meet Simon Payton Jones which was incredible. Yeah, and I gave a talk on monoids, monoids and semirings. And… CHARLES: Ooh, a semiring. JULIE: Semiring. So, a semiring is a structure where there's two monoids. So, both of them have an identity element. And the identity element of one of them is an annihilator. Isn't that a great word? It's an annihilator… CHARLES: Whoa. JULIE: Of the other. So, if you think of addition and multiplication, the identity element for addition is zero, right? But if you multiply times zero, you're always going to get to zero, so it's the annihilator of multiplication. CHARLES: Whoa. I think my mind is like annihilated. [Laughter] JULIE: So, it's a structure where you're got two monoids and one of them distributes over the other, the distributive property of addition and multiplication. And the identity of one of them is the annihilator of the other. Anyway, but yeah, I gave a history of where monoids come from and that was really fun. CHARLES: Yeah. I would actually like to get a summary of that, because I think since we last talked, I've been getting a little bit deeper and deeper into these formal type classes. I'm still not doing Haskell day-to-day but I've been importing these ideas into just plain vanilla JavaScript. And it turns out, it's actually a pretty straightforward thing to do. There's definitely nothing stopping these things from existing in JavaScript. It's just, I think people find type class programming can be a tough hill to climb or something like that, or find it intimidating. JULIE: Yeah. CHARLES: But I think it's actually quite powerful. And I think one of the things that I'm coming to realize is that these are well-worn pathways for composing things. JULIE: Right. CHARLES: So, what you encounter in the wild is people generating these one-off ways of composing things. And so, for a shop like ours, we did a lot of Ruby on Rails, a lot of Ember, and both of those frameworks have very strong philosophical underpinnings that's like “You shouldn't be reinventing the wheel if you don't have to.” I think that all of these patterns even though they have crazy quixotic esoteric names, they are the wheels, the gold standard of wheel. [Laughs] They're like… JULIE: Right. CHARLES: We should not be reinventing. And so, that's what I'm coming to realize, is I'm into this. And last time you were talking, you were saying “I find monoids so fascinating.” I think it took a little bit while to seep in. But now, I feel like it's like when you look at one of those stereo vision things, like I'm seeing monoids everywhere. It's like sometimes they won't leave me alone. JULIE: In ‘Real World Haskell' there's a line I've always liked. And I'm going to misquote it slightly but paraphrasing at least. “Monoids are ubiquitous in programming. It's just in Haskell we have the ability to just talk about them as monoids.” CHARLES: Yeah, yeah. JULIE: Because we have a name and we have a framework for gathering all these similar things together. CHARLES: Right. And it helps you. I feel like it helps you because if you understand the mechanics of a monoid, you can then when you encounter a new one, you're 90% there. JULIE: Right. CHARLES: Instead of having to learn the whole thing from scratch. JULIE: Right. And as you see them over and over again, you develop a kind of intuition for when something is monoidal or something looks like a semiring. And so, you get a certain intuition where you think, “Oh, this thing is like a… this is a monad.” And so, what do I know about monads? All of a sudden, this new situation like all these things that I know about monads, I can apply to this new situation. And so, you gain some intuition for novel situations just by being able to relate them to things you already do know. CHARLES: Exactly. I want to pause here for people. The other thing that I think I've come in the last three months to embrace is just embrace the terminology. JULIE: Yeah. CHARLES: You got to just get over it. JULIE: [Chuckles] CHARLES: Think about it like learning a foreign language. The example I give is like tasku is the Finnish word for pocket. JULIE: Right. CHARLES: It sounds weird, right? Tasku. But if you say it 10 times and you think “Pocket, pocket, pocket, pocket, pocket.” JULIE: Yes, yeah. [Laughs] CHARLES: Then it's like, this is a very simple, very useful concept. JULIE: Right. CHARLES: And it's two-sided. There on the one hand, the terminology is obtuse. But at the same time, it's not. It's just, it is what it is. And it's just a symbol that's referencing a concept. JULIE: Right, right. CHARLES: It's a simple concept. So, I just want to be… I know for our listeners, I know that there's a general admonition. Don't worry about the terminology. It's… JULIE: Right, right. Like what I just said, I said the word ‘monad'. I just threw that out there at everybody, but [chuckles] it doesn't matter which one of these words we'd be talking about or whatever I call them. We could give monads a different name and it's still this concept that once you understand the concept itself, and then you can apply it in new situations, it doesn't matter then what it's called. But it does take getting used to. The words are… well, I think functor is a pretty good word for what it is. If you know the history of functor and how it came to mean what it means, I think it's a pretty good word. CHARLES: Really? So, I would love to know the history. Because functor is mystifying to me. It sounds like, I think the analogy I use is like if George Clinton and a funk parliament had an empire, the provinces, the governors of the provinces would be functors. ELRICK: [Laughs] JULIE: Yes. CHARLES: But [Laughs] that's the closest thing to an explanation I can come up with. JULIE: I might use that. I'm about to give a talk on functors. I might use that. [Laughter] ELRICK: Isn't that the name of the library? Funkadelic? CHARLES: Well, that's the name of the library that I've been… JULIE: [Could be], yeah. ELRICK: That you'd been… CHARLES: That I'd been [writing] for JavaScript. ELRICK: Yeah. CHARLES: That imports all these concepts. JULIE: [Laughs] ELRICK: Yeah. JULIE: Yeah. ELRICK: So awesome. JULIE: Yeah. Yeah, I have… CHARLES: So, what is the etymology of functor? JULIE: Well, as far as I can tell, Rudolf Carnap, the logician, invented the word. I don't know if he got it from somewhere else. But the first time I can find a reference to it is in, he wrote a book about… he was a logician but this is sort of a linguistics book. It's called ‘The Logical Syntax of Language'. And that's the first reference I know of to the word functor. And he was trying to really make language very logically systematic, which natural language is and isn't, right? [Chuckles] CHARLES: Right. JULIE: But he was only concerned with really logically systematizing everything. And so, he used the word functor to describe some kinds of function words in language that relate one part of a sentence to another part of a sentence. CHARLES: Huh. So, what's an example? JULIE: So, the example that I've used in the past is, as far as I know this is not one that Carnap himself actually uses but it's the clearest one outside of that book… well the ones inside the book I don't really think are very good examples because they're not really how people talk. So, the one that I've used to try to explain it is the word ‘not' in English where ‘not' gets applied to the whole sentence. It doesn't really change the logical structure of the sentence. It doesn't change the meaning of the sentence except for now it negates the whole thing. CHARLES: I see. JULIE: And so, it relates this sentence with this structure to a different context, which is now the whole thing has been negated. CHARLES: I see. So, the meaning changes, but the structure really doesn't. JULIE: Right. And it changes the whole meaning. CHARLES: Right. JULIE: Not just part of the sentence. So, if you imagine ‘not' applying to an entire sentence because of course we can apply it just to a single word or just to a single phrase and change the meaning just of that word or that phrase, but if you imagine a context where you've applied ‘not' to a whole sentence, to an entire proposition, because of course he's a logician. So, if you've applied ‘not' to an entire proposition, then it doesn't change the structure or the meaning of that proposition per se except for it just relates it to the category of negated propositions. CHARLES: Mmhmm. JULIE: So, that's where it comes from. And… CHARLES: But I still don't understand why he called it functor. JULIE: He's sort of making up… well, actually I think the German might be the same word. CHARLES: Ah, okay. JULIE: Because he was writing in German. Because he's looking for something that evokes the idea of ‘function word'. CHARLES: Oh. JULIE: So, if you were to take the ‘func' of ‘function' [Laughs] and the, I don't know, maybe in German there's some better explanation for making this into a particular word. But that's how I think of it. So, it's ‘function word'. And then category theorists took it from Carnap to mean a way to map a function in this category or when we're talking about Haskell, a function of this type, to a function of another type. CHARLES: Okay. JULIE: And so, it takes the entire function, preserves the structure of the function just like negation preserves the structure of the sentence, and maps the whole thing to just a different context. So, if you had a function from A to B, functor can give you a function from maybe A to maybe B. CHARLES: Right. JULIE: So, it takes the function and just maps it into a different context. CHARLES: Right. So, a JavaScript example is if I've got an array of ints and a function of ints to strings, I can take any array of ints and get an array of strings. JULIE: Right. CHARLES: Or if I have a promise that has an int in it, I can take that same function to get a promise of a string. JULIE: Yeah. CHARLES: Yeah. I had no idea that it actually came from linguistics. JULIE: Yeah. [Laughs] CHARLES: So actually, the category theorists even… it digs deeper than category theory. They were actually borrowing concepts. JULIE: They were, yes. CHARLES: We just always are borrowing concepts. ELRICK: I like the borrowing of concepts. JULIE: Yeah. ELRICK: I think where people struggle with certain things, it's tying it back to something that they're familiar with. So, that's where I get… my mind is like [makes exploding sound] “I now get it,” is when someone ties it back to something that I am… CHARLES: Right. ELRICK: Familiar with. Like Charles' work with the JavaScript, tying it with JavaScript. I'm like, “Oh, now I see what they're talking about.” JULIE: Right. CHARLES: because you realize, you're using these concepts. People are using them, just they're using them anonymously. JULIE: Right. ELRICK: True. CHARLES: They don't have names for them. JULIE: Right. ELRICK: True. CHARLES: It's literally like an anonymous function and you're just taking that lambda and assigning it to a symbol. JULIE: Yeah. CHARLES: You're like “Oh wait. I've been using this anonymous function all over the place for years. I didn't realize. Boom. This is actually a formal concept.” ELRICK: True. And I think when people say like “Don't reinvent the wheel” it's a great statement for someone that has seen a wheel already. [Laughter] ELRICK: You know what I'm saying? If you never saw a wheel, then your'e going to reinvent the wheel because you're like “Aw man. This doesn't exist.” [Chuckles] JULIE: Yeah. ELRICK: But if people are exposed to these concepts, then they wouldn't reinvent the wheel. CHARLES: Right. JULIE: Right. Yeah. CHARLES: Instead of calling in some context, calling it a roller. [Chuckles] It's a round thingy. [Laughter] JULIE: Right. Yeah, so that's a little bit what I tried to do in my monoid talk in London. I tried to give some history of monoid, where this idea comes from and why it's worth talking about these things. CHARLES: Yeah. JULIE: Why it's worth talking about the structure. CHARLES: So, why is it worth the… where did it come from and why is it worth talking about? JULIE: Oh, so back when Boole, George Boole, when he decided to start formalizing logic… CHARLES: George Boole also, he was a career-switcher too, right? He was a primary school teacher. JULIE: Right, yeah. CHARLES: If I recall. He actually, he was basically teaching. Primary school is like elementary school in England, right? JULIE: I believe so, yes. CHARLES: Yeah. I think he was like, he was basically the US equivalent of an elementary school teacher who then went on to a second and probably, thankfully a big career that left a big legacy. JULIE: Right. Although no one knew exactly how big the legacy was really, until Claude Shannon picked it up and then just changed the whole world.[Laughs] Anyway, so Boole, when he was trying to come up with a formal algebra of logic so that we could not care so much about the semantic content of arguments (we could just symbolize them and just by manipulating symbols we could determine if an argument was logically valid or not), he was… well, for disjunction and conjunction which is AND and OR – well, disjunction would be the OR and conjunction the AND – he had prior art. He had addition and multiplication to look at. So, addition is like disjunction in some important ways. And multiplication is like conjunction in some important ways. And I think it took me a while to see how addition and disjunction were like each other, but there are some important ways that they're like each other. One of them is that they share their identity values. If you think of, it's sort of like binary addition and binary multiplication because in boolean logic there's only two values: true or false. So, you have a zero and a one. So, if you think of them as being like binary addition and binary multiplication then it's easier to see the connection. Because when we think of addition of just integers in a normal base 10 or whatever, it doesn't seem that much like an OR. [Laughs] CHARLES: Mmhmm. No, it doesn't. JULIE: [Inaudible] like a logical OR. So, it took me a while to see that. But they're also related then to set intersection and union where intersect-… CHARLES: So can… Let's just stop on that for a little bit, because let me parse that. So, for OR I've got two values, like in an ‘if' statement. This OR that. If I've got a true value then I can OR that with anything and I'll get the same anything. JULIE: Right. CHARLES: So, true is the identity value of OR, right? Is that what you're saying? So, one… JULIE: Well, it's false that's the identity of OR. CHARLES: Oh, it is? JULIE: Zero is the identity of addition. CHARLES: Wait, but if I take ‘false OR one' I get… oh, I get one. JULIE: Right. CHARLES: Okay. So, if I get ‘false OR true', I get true. Okay, so false is the identity. JULIE: Yeah. CHARLES: Oh right. You're right. You're right. Because… okay, sorry. JULIE: So, just like in addition, zero is the identity. So, whatever you add to zero, that's the result, right? You're going to get [the same] CHARLES: Right. JULIE: Value back. So, with OR false is the identity and false is equivalent to zero. CHARLES: [Inaudible] ‘False OR anything' and you're getting the anything. JULIE: Right. So, the only time you'll get a false back is if it's ‘false OR false', right? CHARLES: Right. Mmhmm. JULIE: Yeah. So, false is the identity there. And then it's sort of the same for conjunction where one is the identity of multiplication and one is also the… I mean, true is then the identity of logical conjunction. CHARLES: Right. Because one AND… JULIE: ‘True AND false' will get the false back. [Inaudible] CHARLES: Right. ‘True And true' you can get the true back. JULIE: Yeah. CHARLES: Okay. JULIE: And it's also then true, getting back to what we were talking about, semirings, it's also true that false is a kind of annihilator for conjunction. That's sort of trivial, because… CHARLES: Oh, because you annihilate the value. JULIE: Right. When there's only two values it's a little bit trivial. But it is [inaudible]. So… CHARLES: But it's [inaudible]. Yeah. It demonstrates the point. JULIE: Right. CHARLES: So, if I have yeah, ‘false AND anything' is just going to be false. So, I annihilate whatever is in that position. JULIE: Right. CHARLES: And the same thing as zero is the annihilator for multiplication, right? JULIE: Right. CHARLES: Because zero times anything and you annihilate the value. JULIE: Yeah. CHARLES: And now I've got… okay, I'm seeing it. I don't know where you're going with this. [Laughter] ELRICK: Yeah. CHARLES: But I'm there with you. ELRICK: Yup. JULIE: And then it turns out there are some operations from set theory that work really similarly. So, intersection and union are similar but the ones that are closer to conjunction/disjunction are disjoint unions and cartesian products. So we don't need to talk about those a whole lot if you're not into set theory. But anyway… CHARLES: I like set theory although it's so hard to describe without pictures, without Venn diagrams. JULIE: It is. It really is, yeah. So anyway, all of these things are monoids. And they're all binary associative operations with identity elements. So, they're all monoids. And so, we've taken operations on sets, operations on logical propositions, operations on many kinds of numbers (because not all kinds of addition and multiplication I guess are associative), and we can kind of unify all of those into the same framework. And then once we have done that, then we can see that there's all these other ‘sets'. Because most of the kinds of numbers are sets and there are operations on generic sets with set theory. So, now we can say “Oh. We can do these same kinds of operations on many other kinds of sets, many other varieties of sets.” And we can see that same pattern. And then we can get a kind of intuition for “Well, if I have a disjunctive monoid where I'm adding two things or I'm OR-ing two things…” Because even though those are logically very similar, intuitively and in terms of what it means to concatenate lists versus choosing one or the other, those obviously have different practical effects. CHARLES: So, I'm going to try and come up with some concrete examples to maybe… JULIE: Okay, yeah. CHARLES: A part of them will probably be like in JavaScript, right? So, to capture the idea of a disjunctive monoid versus a conjunctive monoid. So, a disjunctive monoid is like, so in JavaScript we're got two objects. You concat them together and it's like two maps or two hashes. So, you mash them together and you get… so, for the disjunctive one you'd have all the keys from both of the hashes inside the resulting object. You take two objects. Basically we call it object assign in JavaScript where you have basically the empty object. You can take the empty object and then take any number of objects. And so, we talked about… JULIE: That would become a disjunctive monoid, right? CHARLES: That would be a disjunctive monoid because you're like basically, you're OR-ing. Yeah. JULIE: You're kind of, [inaudible] CHARLES: Hard to find the terminology. JULIE: Yeah. CHARLES: But like object assign would be a disjunctive monoid because you're like mashing these two objects. And the resulting object has all of the things from both of them. JULIE: Right. So, it's like a sum of the two, right? CHARLES: Right, right. Okay, so then another one would be like min or max where you've got this list of integers and you can basically take any two integers and you can mash them together and if you're using min, you get the one that's smaller. Basically, you're collapsing them into one value but you're actually just choosing one of them. Is that like… JULIE: Yeah. CHARLES: Would that be like a conjunctive monoid? JULIE: No, that's also disjunctive but that's more like an OR than like a sum. CHARLES: Okay. JULIE: Right. So, that's what I said. It's hard to think of disjunctive monoids I think because there's really two varieties. There's some underlying logical similarity, like the similarity in the identity values. But they're also different. Summing two things versus choosing one or the other are also very different things in a lot of ways. CHARLES: Right. Okay. JULIE: And so, I think the conjunctive monoids are all a little bit more similar, I think. [Chuckles] But the disjunctive monoids are two broad categories. And we don't really have a monoid in Haskell of lists where you're choosing one or the other. The basic list monoid is you're concatenating them. So, you're adding two lists or taking the union of them. But for maybe, the maybe type, we do have monoids in Haskell where you're just choosing either the first just value that comes up or the last just value that comes up. So, we do have a monoid of choice over the maybe type. And then we have a type class called alternative which is monoids of choice for… so, they're disjunctive monoids but instead of adding the two things together, they're choosing one or the other. CHARLES: Okay. JULIE: Though we have a type class for that. [Laughs] CHARLES: [Sighs] Oh wow. Yeah. JULIE: Mmhmm, yeah. CHARLES: I'l have to go read up on that one. JULIE: That type class comes up the most when you're parsing, because you can then parse… like if you found this thing, then parse this thing. But if you haven't found this thing, then you can keep going. And if you find this other thing later, then you can take that thing. So, you allow the possibility of choice. The first thing that you come to that matches, take that thing or parse that thing. So, that type class gets mostly used for parsing but it's not only useful for parsing. CHARLES: Okay. JULIE: So yeah. That's the most of the time when I've used it. CHARLES: Is this when you're like parsing JSON? Or is this when you're just searching some stream for some value? Like you just want to run through it until you encounter this value? Or how does that…? JULIE: Right. Say you want to run through it until you find either this value or this value. I've used it when I've been parsing command line arguments. So, let's say I have some flags that can be passed in on my command line command. There are some flags that could be passed in. So, we'll parse until we find this thing or this thing. This flag or this flag. So, if you find this flag, then we're going to go ahead and parse that and do whatever that flag says to do. If you don't find that first flag then we can keep parsing and see if you find this other flag, in which case we'll do something different. CHARLES: Okay. JULIE: It'll take the first match that it finds. Does that make sense? CHARLES: Yeah, yeah, yeah. It does. But I'm not connecting how it's a monoid. [Laughs] JULIE: How is that a monoid? Well, because it's a monoid of OR-ing CHARLES: What's the identity value or the empty value in that case? JULIE: Well, the empty value would be… let's say you have maybes. Let's say you have some kind of maybe thing, so you're parser is going to return maybe this thing, maybe whatever you're parsing. Like maybe string. CHARLES: Yeah, yeah. JULIE: So, it's going to return a maybe string. So well, nothing would be the empty. CHARLES: Okay. JULIE: But nothing is like the zero because it's a disjunction, logical OR. So, only when you have two nothings will you get back a nothing. Otherwise, it will take the first thing that it finds. CHARLES: Okay. I see. JULIE: Yeah. So, the identity then is the nothing, like false is the identity for disjunction. CHARLES: Mmhmm. Okay. JULIE: Yeah. CHARLES: [Inaudible] JULIE: Yeah. If you have nothing or this other thing, then you return this other thing. Then you return the maybe string. If you have two nothings, then you get in fact nothing. Your parsing has failed. CHARLES: Right, because you've got nothing. JULIE: Because you've got nothing. There was nothing to give you back. CHARLES: So, you concatenated all of the things together and you ended up with nothing. JULIE: Right, because there was nothing there. CHARLES: Right. [Laughs] JULIE: You found nothing. So, it's useful when you've got some possibilities that could be present and you just want to keep parsing until you find the first one that matches. And then it'll just return whatever. It'll just parse the first thing that it matches on. CHARLES: Okay, okay. JULIE: Does that make sense? CHARLES: Yeah. No, I think it makes sense. JULIE: I'm not sure. Because I feel like I kind of went down a rabbit hole there. [Laughs] CHARLES: Yeah. [Laughs] No, no. I think it makes sense. And as a quick aside, I think… so, I was, when we were talking about min and max, are min and max also like a semiring? Because negative infinity is the annihilator of min and it's the identity of max. and positive infinity is the annihilator of max but it's the identity of min. JULIE: I guess. I don't really think of min and max as having identities. Is that how [inaudible]? CHARLES: I'm just, I don't know. Well, I think if you have negative infinity and you max it with anything, you're going to get the anything, right? Negative infinity max one is one. Negative infinity/minus a billion is minus a billion. JULIE: Yeah, okay. CHARLES: I don't know. Just off the cuff. I'm just trying to… annihilators sound cool. And so… [Laughter] CHARLES: And so I'm like, I'm trying to find annihilators. JULIE: Yeah, they are cool. CHARLES: [Laughs] JULIE: One of my friends on Twitter was just talking about how he used the intuition at least of a semiring at work because he had this sort of monoid to concatenate schedules. So, he's got all these different schedules and he's got this kind of monoid to concatenate them, to merge the schedules together. But then he's got this one schedule that is special. And whenever something is in this schedule, it needs to hard override every other schedule. CHARLES: Right. JULIE: And so, that was like the annihilator. So, he was thinking of it as a semiring, because that hard override schedule is like the annihilator of all the other schedules. CHARLES: Yeah. JULIE: If anything else exists on this day or whatever, then it'd just get a hard override. So, there's a real world use. [Laughs] CHARLES: Yeah, a real world example. That's the thing that I'm finding, is that all these really very crystalline abstractions, they still play out very well I think in the real world. And they're useful as a took in terms of casting a net over a problem. Because you're like… when I'm faced with something new, I'm like “Well, let's see. Can I make it a functor?” And if I can, then I've unlocked all these goodies. I've unlocked every single composition pattern that works with functor. JULIE: Right, right. CHARLES: And it's like sometimes it fits. It almost feels like when you're working on something at home and you've got some bolt and you're trying on different diameters. So you're like, “Oh, is it 15 millimeter? Is it 8 millimeter?” JULIE: Right. [Laughs] CHARLES: “Like no, okay. Maybe it'll work with this.” But then when it clicks, then you can really ratchet with some serious torque. JULIE: Right, right. Yeah. CHARLES: So, yeah. Definitely trying to look for semirings [Laughs] is definitely beyond my [can] at this point. But I hope to get there where it can be like, if it's a fit, it's a fit. That's awesome. JULIE: Right. Yeah, it's kind of beyond my can too. Semirings are still a little bit new for me and I can't say that I find them in the wild as it were, as often as monoids or something. But I think it just takes seeing some concrete examples. So, now you know this idea exists. If you just have some concrete examples of it, then over time you develop that intuition, right? CHARLES: Right. JULIE: Like “Okay, I've seen this pattern before.” [Chuckles] CHARLES: yeah. Basically, every time now I want to fold a list, or like in JavaScript, any time you want to reduce something I'm like “There's a monoid here that I'm not seeing. Let me look for it.” JULIE: Yeah. Oh, that's cool, yeah. CHARLES: Because like, that's basically, most of the time you're doing a reduce, then like I said that's the terminology for fold in JavaScript, is you start with some reducible thing. Then you have an initial value and a function to actually concatenate two things together. JULIE: Right. CHARLES: And so, usually that initial state, that's your identity. And then that function is just your concat function from your monoid. And so, usually anytime I do a reduce, there's the three pieces. Boom. Identity value, concatenation function, it's usually right there. And so, that's the way I've found of extracting these things, is I'm very suspicious every time I'm tempted to… JULIE: [Laughs] CHARLES: A fold. I'm like “Hmm. Where's the monoid I'm missing? Is it [under the] couch?” Like, where is it? [Laughs] Because it just, it cleans it up and it makes it so much more concise. JULIE: Oh yeah, that's awesome. CHARLES: So anyhow. JULIE: Have we totally lost Elrick? ELRICK: Nope, I'm still here. JULIE: Okay. [Laughs] ELRICK: I'm sitting in and listening to you two break down these complex topics is really good. Because you guys break them down to a level where it's consumable by people that barely understand it. So, I'm just sitting here just soaking everything in like “Oh, that's awesome.” Taking notes. Yes, okay, okay. [Laughter] JULIE: Cool. ELRICK: So, I'm like riding the train in the back just hanging out, feeling the cool breeze while you guys just pull the train ahead in… [Laughter] ELRICK: In the engine department, you know? It's awesome. CHARLES: Yeah. ELRICK: I don't know if they're related. But you were talking about semirings and I heard of semigroups or semigroups. I have no idea if those two things are related. Are they related or [inaudible]? JULIE: They're kind of related. So, a semigroup is like a monoid but doesn't have an identity value. CHARLES: What is an example of a semigroup out there in the wild? Because every time I find a semigroup, I feel like it's actually a monoid. JULIE: Well, you know I feel like that a lot, too. We do have a data type in Haskell that is a non-empty list. So, there is no empty list CHARLES: Ah, right. Okay. JULIE: So then you can concatenate those lists, but there's never an identity value for it. CHARLES: I see. JULIE: Yeah. So, that's a case. There's actually a lot of comparison functions, greater than and less than. I think those are semigroups because they're binary, they're associative, but they don't have an identity value. Like if you're comparing two numbers, there's not really an identity value there. CHARLES: Right. Well, would the negative infinity work there? Let's see. Like, negative infinity greater than anything would be the anything. Well, okay wait. But greater than, that takes numbers and yields a boolean, right? JULIE: Yeah, CHARLES: Right. So, it couldn't be… could it be a semigroup? Don't semigroups have to… Doesn't the [inaudible] function have to yield the same type as the operands? JULIE: Yes. CHARLES: But a non-empty list, that's a good one. Sometimes it's basically not valid for you to have a list that doesn't have any elements, right? Because it's like the null value or the empty value and it could be like a shopping cart on Amazon. You can't have a shopping cart without at least something in it. JULIE: Right. CHARLES: Or, you can't check out without something. So, you might want to say like the shopping cart that I'm going to check out is a non-empty list. And so, you can put two non-empty lists together. But yeah, there's no value you can mash together, you can concat with anything, that isn't empty. JULIE: Right. CHARLES: So, I guess going back to your question Elrick, I don't know if it's related to semiring. But semigroup is just, it's like one-half of monoid. It's the part that concats two values together. JULIE: Right. Well, yeah. And so, it's supposed to be half a group, right? But I don't remember… CHARLES: [Laughs] JULIE: [Inaudible] all of the group stuff is, all the stuff that these types have to have to be a group. And similarly, I forget what the difference between semiring and ring is. [Chuckles] Because a ring and a group I know are not the same thing. But I forget what the difference is, too. So, I kind of got a handle on what semigroups are, and I know all my Haskell friends are going to, when they hear this podcast they're going to tweet all these examples of semigroups at me, especially my coauthor for ‘Joy of Haskell', Chris Martin. He's really into semigroups. And so, I know he's going to be very disappointed in my inability to think… [Laughter] JULIE: To think of any good examples. But it's not something that I find myself using a lot, whereas semirings are something that I have started noticing a little bit more often. So, how a monoid relates to a group is something that I can't remember off the top of my head. And I know how semirings relate to monoids, but how monoids then relate to rings and groups, I can't really remember. And so, these things are sort of all related. But the relation is not something I can spill out off the top of my head. Sorry. [Laughs] CHARLES: No, It's no worries. You know, I feel like… ELRICK: It's all good. CHARLES: What's funny is I feel like having these discussions is exactly like the discussions people have with any framework of using one that we use a lot, which is EmberJS. But if you could do with React or something, it's like, how does the model relate to the controller, relate to the router, relate to the middleware, relate to the services? You just have these things, these moving parts that fit together. And part of… I feel like exploring this space is really, absolutely no different than exploring any other software framework where you just have these things, these cooperating concepts, and they do click together. But you just have to map out the space in your head. JULIE: Yeah. This is going to sound stupid because everybody thinks that because I know Haskell I must know all these other things. But I just had to ask people to recommend me a book that could explain the relationship of HTML and CSS, because that was completely opaque to me. CHARLES: [Laughs] Yeah. JULIE: I've been involved in the making now of several websites because of the books and stuff like that. And I have a blog. It's not WordPress or anything. I did that sort of myself. So, I've done a little bit with that. But CSS is really terrifying. And… CHARLES: Right. Like query selectors, rules, properties. JULIE: Yeah. ELRICK: [Laughs] CHARLES: Again, might as well be groups and semigroups and monoids, right? JULIE: Right, right. ELRICK: Yeah. CHARLES: [Laughs] ELRICK: That is really interesting. [Chuckles] I've never heard anyone make that comparison before. But it's totally true, now that I'm thinking about it. JULIE: Yeah, yeah. CHARLES: Yeah. In the tech world we are so steeped in our own jargon that we could be… we can reject one set of jargon and be totally fine with another set. Or be like, suspicious of one set of concepts working together and be totally fine with these other designations which are somewhat arbitrary but they work. JULIE: Right. CHARLES: So, people use them. JULIE: So, it's like what you've gotten used to and what you're familiar with and that seems normal and natural to you. [Chuckles] So, the Haskell stuff, most of it seems normal and natural to me. And then I don't understand HTML and CSS. So, I bought a book. [Laughter] CHARLES: Learning HTML and CSS from first principles. JULIE: Yes, yeah. I just wanted to understand. I could tell that they do relate to each other, that there is some way that they click together. I can tell that by banging my head against them repeatedly. But I didn't really understand how, and so yeah. So, i've been reading this book to [Laughs] [learn] HTML and CSS and how they relate together. That's so important, just figuring out how things relate to each other, you know? CHARLES: Yeah. ELRICK: Yeah. That is very true. JULIE: Yeah. ELRICK: We can trade. I can teach you HTML and CSS and you can teach me Haskell. JULIE: Absolutely. ELRICK: [Laughs] CHARLES: There you go JULIE: [Laughs] ELRICK: Because I'm like, “Ooh.” I'm like, “Oh, CSS. Great. No problem.” [Laughter] ELRICK: Haskell, I'm like “Oh, I don't know.” JULIE: Yeah. CHARLES: Yeah. ELRICK: [Laughs] CHARLES: No, it's amazing [inaudible] CSS. ELRICK: Yeah. CHARLES: It is, it's a complicated system. And it's actually, it's in many ways, it's actually a pretty… it's a pretty functional system, CSS is at least. The DOM APIs are very much imperative and about mutable state. But CSS is basically yeah, completely declarative. JULIE: Right. CHARLES: Completely immutable. And yeah, the workings of the interpreter are a mystery. [Laughs] ELRICK: Yup. JULIE: YEs. And you know, for the Joy of Haskell website we use Bootstrap. And so, there was just like… there's all this magic, you know? [Laughs] ELRICK: Oh, yeah. CHARLES: Yeah. JULIE: Oh look, if I just change this little thing, suddenly it's perfectly responsive and mobile. Cool. [Laughter] JULIE: I don't know how it's doing this, but this is great. [Laughs] CHARLES: Yeah. Oh, yeah. It's an infinite space. And yeah, people forget what is so easy and intuitive is not and that there's actually a lot of learning that happened there that they're just taking for granted. JULIE: I think so many people start from HTML and CSS. That's one of their first introductions to programming, or JavaScript or some combination of all three of those. And so, to them the idea that you would be learning Haskell first and then coming around and being like “Oaky, I have to figure out HTML,” that [seems very] strange, right? [Laughter] CHARLES: Yeah. Well, definitely probably stepping into bizarro world. JULIE: And I went backwards. But [Laughs] CHARLES: Yeah. JULIE: Not that it's backwards in terms of… just backwards in terms of the normal way, progression of [inaudible] CHARLES: Yeah. It's definitely the back door. Like coming in through the catering kitchen or something. JULIE: Yes. CHARLES: Instead of the front door. Because you know the browser, you can just open up the Dev Tools and there you are. JULIE: Exactly, yeah. CHARLES: The level of accessibility is pretty astounding. And so, I think t's why it's one of the most popular avenues. JULIE: Oh, definitely. Yeah. ELRICK: It's the back door probably for web development but not the back door for programming in general. JULIE: Mm, yeah. Yeah. CHARLES: Yeah. It seems like Haskell programming has really started taking off and that the ecosystem is starting to get some of the trappings of a really less fricative developer experience in terms of the package management and a command line experience and being able to not make all of the tiny little decisions that need to be made before you're actually writing ‘hello world'. JULIE: Right. ELRICK: Interesting. Haskell has a package manager now? CHARLES: Oh, it has for a while. ELRICK: Oh, really? What is it called? I have no idea? Do you know the name off the top of your head? CHARLES: So, I actually, I'm not that familiar with the ecosystem other than every time I try it out. So I definitely will defer this question to you, Julie. JULIE: This is going to be a dumb question, I guess. What do we mean by package manager? CHARLES: So, in JavaScript, we have npm. The concept of these packages. It's code that you can download, a module that you can import, basically import symbols from. And Ruby has RubyGems. And Python has pip. JULIE: Okay, okay. CHARLES: Emacs has Emacs Packages. And usually, there's some repository and people could publish to them and you can specify dependencies. JULIE: Right, yeah. Okay, so we have a few things. Hackage is sort of the main package repository. And then we have another one called Stackage and the packages that are in Stackage are all guaranteed to work with each other. CHARLES: Mm, okay. JULIE: So, on Hackage, some of the packages that are on Hackage are not really maintained or they only work with some old versions of dependencies and stuff like that, so the people who made Stackage were like “well, if we had this set of packages that were all guaranteed to work together, the dependencies were all kept updated and they all can be made to work together, then that would be really convenient.” And then we have Cabal and we have Stack are the main… and a lot of people use Nix for the same purpose that you would use Cabal or Stack for building projects and importing dependencies and all of that. CHARLES: Right. So, Cabal and Stack would be roughly equivalent then to the way we use Yarn or JavaScript and Bundler in Ruby. You're solving the equation for, here's my root set of dependencies. Go out and solve for the set of packages that satisfy. Give me at least one solution and then download those packages and [you can] run them. JULIE: Yeah, yeah. Right, so managing your dependencies and building your project. Because Haskell's compiled, so you've got to build things. And so yeah, we have both of those. CHARLES: And now there's like web frameworks and REST frameworks. JULIE: Oh there are, yeah. We have… CHARLES: All kinds of stuff now. JULIE: We had this big proliferation of web frameworks lately. And I guess some of them are very good. I don't really do web development. But the people I know who do web development in Haskell say that some of these are very good. Yesod is supposed to be very good. Servant is sort of the new hotness. And I haven't used Servant at all though, so don't ask me questions about it. [Laughter] JULIE: But yeah, we have several big web frameworks now. There are still some probably big holes in the Haskell ecosystem in terms of what people want to see. So, that's one thing that people complain about Haskell for, is that we don't have some of the libraries they'd like to see. I'd like to see something… I would really like to see in Haskell something along the lines of like NLTK from Python. CHARLES: What is that? JULIE: Natural language toolkit. CHARLES: Oh, okay. JULIE: So yeah, Python has this… CHARLES: Yeah, Python's got all the nice science things. JULIE: They really do. And Haskell has some natural language processing libraries available but nothing along the lines of, nothing as big or easy to use and stuff as NLTK yet. So, I'd really like to see that hole get filled a little bit better. And you know… CHARLES: Well, there you go. If anyone out there is seeking fame and fortune in the Haskell community. JULIE: That's actually why I started learning Python, was just so that I could figure out NLTK well enough to start writing it in Haskell. [Laughter] JULIE: So, that's sort of my ambitious long-term project. We'll see how that goes. [Laughs] CHARLES: Nice. Before we wrap up, is there anything going on, coming up, that you want to give a shoutout to or mention or just anything exciting in general? JULIE: Yeah, so on March 30th I'm going to be giving a talk at lambda-squared which is going to be in Knoxville and is a new conference. I think it's just a single-day conference and I'm going to be giving a talk about functors. So, I'm going to try to get through all the exciting varieties of functors in a 50-minute talk. CHARLES: Ooh. JULIE: So, we'll see how that goes. Yeah. And I am still working with Chris Martin on ‘The Joy of Haskell' which should be finished this year, sometime. I'm not going to… [Laughter] JULIE: Give any more specific deadline than that. And in the process of writing Joy of Haskell, I was telling him about some things that, some things that I think are really difficult. Like in my experience, teaching Haskell some places where I find people have the biggest stumbling blocks. And I said, “What if we could do a beginner video course where instead of throwing all of these things at people at once, we separated them out?” And so, you can just worry about this set of stumbling blocks at one time and then later we can talk about this set of stumbling blocks. And so, we're doing… we're going to start a video course, a beginner Haskell video course. I think we'll be starting later this month. So, I'm pretty excited… CHARLES: Nice. JULIE: About that. Yeah. CHARLES: Yeah, I know a lot of people learn really, really well from videos. There's just some… JULIE: Yeah. [Inaudible] for me, so I'm a little nervous. But [Laughs] CHARLES: Yeah, especially if you can do… are you going to be doing live coding examples? Building out things with folks? JULIE: Yeah. CHARLES: Yeah. Well, you just needn't look no further than the popular things like RailsCasts and some of the… yeah, there's just so many good video content out there. Yeah, we'll definitely be looking for the. JULIE: Cool. CHARLIE: Alright. Well, thank you so much, Julie, for coming on. JULIE: Well, thank you for having me on. Sorry I went down some… I went kind of down some rabbit holes. Sorry about that. [Laughs] CHARLES: You know what? You go down the rabbit holes, we spend time walking around the rabbit holes. JULIE: [Laughs] CHARLES: There's something for everybody. So… [Laughter] CHARLES: And ultimately we're strolling through the meadow. So, it's all good. JULIE: [Laughs] Yeah. CHARLES: Thank you too, Elrick. JULIE: It was nice talking to you guys again. CHARLES: Yeah. ELRICK: Yeah, thank you. CHARLES: If folks want to follow up with you or reach out to you, what's the best way to get in contact with you? JULIE: I'm @argumatronic on Twitter and my blog is argumatronic.com which has an email address and some other contact information for me. So, I'd love to hear questions, comments. [Laughs] Yeah. I always [inaudible]. CHARLES: Alright, fantastic. JULIE: To talk to new people. CHARLES: Alright. And if you want to get in touch with us, we are @TheFrontside on Twitter. Or you can just drop us an email at contact@frontside.io. Thanks everybody for listening. And we will see you all later.

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) ***

Wherein we discuss Rubygems and Bundler with André Arko. We discuss how he became the lead maintainer of Rubygems and Bundler, and what lead him to set up Ruby Together. Special Guest: André Arko.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby CanCanCan 2.0 is out, Bundler 1.15: Bundle Oh So Fast и Rails 5.1 does not share thread_mattr_accessor variable with subclass Fighting the Hydra of N+1 queries, Rubygems.org is now using Elasticsearch и GraphQL -Mutation Query Implementation - Ruby on Rails Your analytical research using Twitter, Why you shouldn't use the System Ruby и Red Arrow is a Ruby bindings of Apache Arrow JavaScript Security: Broken Authentication, Getting Started With The JavaScript Web Animation API и 3 ways to reduce webpack bundle size Javascript: Save time by avoiding re-writing these common functions, How Four Native Developers Wrote An Electron App и Rearchitecting Airbnb's Frontend Learn CSS Grid, Workbox - a collection of JavaScript libraries for Progressive Web Apps, Moments of Happiness и OpenLara: Tomb Raider in your browser

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32 Show Notes: 00:58 - Going Into Business Using Rust 03:42 - Getting Paid to do Open Source 05:31 - Prototyping Projects in Rust 06:21 - Why Rust? (Benefits) 09:58 - The Language Server 14:52 - Error Messages 19:46 - The Rust Programming Language Book 23:35 - Crates.io 27:41 - The Backend 31:11 - Working with Rust and Ember Together 33:31 - Rust Belt Rust Conference 35:59 - Integer 32 Resources: The Rust Programming Language Book The Frontside Podcast Episode 51: Rust and APIs with Steve Klabnik Rust For Rubyists Working Effectively with Legacy Code by Michael Feathers Clippy Cargo rustlings Python Koans Rust - exercism.io No Starch Tokio Diesel Rocket Nickel Iron Pencil Rust Belt Rust Conference RustFest.EU RustConf Transcript: STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols. CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol? CAROL: I'm great. Thank you for having me on the show. CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust? CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out. We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We've got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services. One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We've done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We've also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like. One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We've had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community. CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help? CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library. CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping? CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We're not going to come in and rewrite the whole project. We're going to come in and work with their style and make any modifications they want to be able to incorporate into their library. But as I said, a lot of libraries are gotten to a certain point and I think the maintainers would like their libraries to become more feature complete but everyone only has so much time and you don't necessarily know what's useful to people but this is a very, very strong signal that this library would be useful to someone if only it had this little extra thing. I think most maintainers are open to making their libraries more feature complete to be more useful to more people. CHRIS: Yeah, that is a pretty sweet deal from the standpoint of an open source maintainer. It's nice enough when people show up to help at all. It is especially nice to show up to help and aren't motivated by money. CAROL: Yeah. CHRIS: That's very cool. When it comes to prototyping things with Integer 32, what kind of projects are people coming to you and asking you to prototype in Rust? CAROL: A lot of them are existing projects that they have and written in something else that they want to either perform better and be safer as opposed to rewriting it in C or C++ to get performance out of it. Sometimes, they want something to interface with other Rust things. We're starting to see projects like that but mostly, they have a hunch that Rust will be good for their projects and solve some problem they're having with their current implementation. We scope their projects way down to whatever will let them evaluate, whether Rust is a good fit or not and we go with that. CHRIS: Cool. STEPHANIE: Going from there, the question that I have is why Rust? I don't know a lot about Rust so I'd like to know what would be some of the benefits of using Rust, if you're familiar with programming. If you are in web development like I'm familiar with Ember, why would I like to use Rust or learn Rust? CAROL: I could talk all day about this. I really love working with Rust. I feel like it is adding more tools to help me to write better code and taking care of little details that usually I would have to spend a lot of brainpower thinking about to get right all the time. But now I can actually concentrate on whatever it is I'm trying to get done and let the compiler take care of those details for me. The way it's implemented, it happens really fast. The way I got into Rust was I'm a Rails developer previously to this job and I spend a lot of time optimizing Rails, looking for places where essentially too many Ruby objects and memory leaks and [inaudible] a lot of trying to make Rails go faster. At some point, you can't. There's only so far you can take Ruby and Rails so I look at where I want my career to go next and I love making things go faster but I'm terrified of C. I should be nowhere near production C. You have to spend years learning all the quirks and all the ways that C can go wrong and crash and be insecure. Around this time, I know you had Steve Klabnik on the show, in the previous episode. Steve is from Pittsburgh, where I am and he came home for Christmas one year and came to a Ruby meet up and was talking about this new language called Rust and how awesome it was. Steve gets distracted by new awesome things all the time so I was like, "Yeah, yeah, okay, whatever." The next year, he came home for Christmas again and was still talking about how awesome Rust was. At that point, I was like, "There's got to be something to this." At that point, he was writing his book, 'Rust for Rubyist' which has lead into his work on the Rust programming language book. I was like, "Rust for Rubyist? I can handle this. This is something I can do and capable of," so I started reading his book and submitting corrections and things which is again, how I got involved with the Rust programming language book. If you've ever gotten the error 'undefined method on nil' or 'undefined is not a function' in JavaScripts, like in production at runtime that happens all the time. That's just normal in Ruby and JavaScript land. Rust prevents those problems at compile time so there's no null, there's no nil. It's strongly typed so it checks that you have the thing you think you have before your code even can run. There's no garbage collector so you don't have memory leaks. The system of ownership and borrowing and the borrow checker and lifetimes which is weird. It's tricky to get your head around at first because it's different than any other language. But once you get that that's the part that enables your code to go faster without needing the garbage collector. You actually don't have to think about your memory management as much as you would in C, where you have to say, "Please give me some memory." Okay, I'm done with it now. You are manually managing your memory but you don't have to think about it as much because the compiler is thinking about it for you, if that makes sense. CHRIS: I have a follow up question, kind of related to the fact that Rust is kind of performing at the level of C or C++ but a lot more friendly in the fact that both you and Steve and I think a lot of other people, have come to Rust from scripting languages, from higher level languages. I remember at first that I started paying attention on Rust like right before the 1.0 happened, I thought it sounded interesting and wrote it off because it was just insane and I had only ever done Python and JavaScript and higher level things. In a relatively short time, it has developed a level of ergonomics that I'm envious of, even in the 'more comfortable' languages, things like Cargo, things like the compiler is really great but now the compiler has really friendly and informative error messages so that 'undefined is not a function' never happens but when you try to make it happen, it now shows you like, "No, no, no. On this exact line, in this place, this is where you're doing it wrong." But I recently heard it and I'm curious if you know anything about it that there's also development on a Rust language service, kind of like I guess TypeScript test, where it's a whole set of tools that you can run under the hood that any editor can plug into so that you just get this tool box of things to help you develop in Rust that are all packaged up and handed over and all you have to do is hook into it. Have you try that at all? Are you familiar with that? CAROL: I am not. I've been watching but I haven't worked on it and I haven't tried it out yet. I am excited for the language server because it's going to enable IDEs to do more interesting things. Coming from Ruby where it's so dynamic that you can't do things like ensure that you renamed all of the places and method it's called because you can't know that. I've read books like Michel Feathers' Working Effectively with Legacy Code and a lot of the chapters in that talked about leaning on your IDE, on your refactoring tools to do automated refactoring. RubyMine has a few of those things but not all of them because it's just impossible so I'm really looking forward to having real refactoring tools that can let you do automated refactorings and things like that that are possible in other statically-typed languages but with Rust in an IDE. I haven't used an IDE in years because I haven't found them to be useful but once the language server is up and running, I'm thinking about going back to an IDE so it's definitely exciting. CHRIS: That's some pretty cool right now. There's one called Clippy which I love because of the name like it takes you back to my Microsoft Word days. There's a lot of very good stuff that they have added that I didn't expect from a 'systems language' but it has definitely benefited from a lot of things that people in the scripting world have learned. CAROL: One of the goals of 2017 for the core team is increasing people's productivity in Rust so getting people over the learning curve, providing them with tools like the language server and making it easier for people to build things in Rust without having to manage things around Rust. Just Cargo in itself has made systems programming so much better. I see people who develop in C and C++ who really try to minimize the amount of libraries they bring in because that makes your build system so much more complicated and you have to have libraries in the right place and so much more can go wrong. But with Cargo, it's just Cargo install and you have a Cargo.lock and cargo.toml that manages versions. It just work so it's been interesting watching people figure that out and change their opinions on bringing in dependencies with npm and JavaScript and Bower and Ruby Gems that we're all used to like, "Oh, there's a gem for that. Let's just pull that in and go." Systems people have been really reluctant to do that but Cargo is enabling that to be better and easier which is really exciting to watch. I want anyone listening to this who thinks, "I can't do system programming. It was too hard." No, you totally can. You can do Rust. Rust is going to let you do this and that's why Rust is really exciting because it's enabling a whole new group of people to get into the systems programming space where things need to be optimized and faster and letting people build these sorts of things without having the programs be vulnerable to crashes and security bugs and things like that. It's really, really exciting. CHRIS: Very cool. STEPHANIE: I'm curious in Rust, if there's an error, how would you know that there's an error? Is the whole thing going to stop? Is it going to break? Do you get a useful stack trace? What would I expect to see? CAROL: A lot of the errors in Rust are at compile time. It won't even let you try to run your code if you have certain kinds of problems and they tried to move as much as possible into that compile time space. There are always going to be things that you can't catch a compile time like the user enters a number that's too big for whatever you're trying to do. That's still going to be a runtime error because we can't possibly know what a user is going to put in when you're compiling. They've done a lot of work on the compiler errors as Chris was talking about, to make them friendlier and point here's where your error is, here's why it's happening, here's a hint as to how you might want to fix it. This has been really great. I was volunteering in a local code school with students just starting Ruby and I'm used to Ruby's error messages by now but they were just getting started and getting all sorts of errors and I was like, "Wow, these error messages are not helpful at all," and I forgot how bad that is and how confusing it can be for a beginner to just think you understand, think you have got it working and then you go and run the code and it's just like 'string is not a symbol' or whatever. The worst is when you forget to close the block and just expected to see [inaudible] end of file instead and it's not helpful at all. I was just like apologizing the whole time like, "I'm sorry. This is telling you that you need to write 'end' at the end of the file," but it's not telling you that in any way you could possibly know that. That made me appreciate much more all of the work that's going into Rust error messages that are really trying to help. Some people talk about, especially the borrow checker, fighting the borrow checker like they're not used to having a compiler tell them their code is wrong so often so people talk about fighting the borrow checker a lot but it's not trying to fight with you. It's not trying to make you feel bad about your code. It's trying to help you make your code better and prevent errors that might happen at runtime by catching them earlier. I actually have a little project called Rustlings that is full of little snippets of Rust that intentionally don't compile. You run them and you get an error message right away and your job is to read the error message and learn how to fix it. When I was starting out, I was really frustrated because I was trying to do something and I would get an error message and I would have to stop whatever is doing to deal with the error message. I was like, "If I could just get some practice just dealing with the error messages and learning how to fix them so that when I'm trying to do something else, I already have experience fixing that kind of error," so that's how that project came to be and people found that useful. I haven't had much time to work on it lately but it could definitely use more examples because I think people are used to error messages that are not helping. People used to back traces that are really long and don't say anything useful. Sometimes, you don't stop and read and think but the Rust error messages are really trying to help you and often times, they are telling you exactly what you need to do to change the code to work. I think getting practice seeing the compiler as more of a pair who is trying to help you and not someone who's trying to reject all your code is a different mindset that I don't think people are used to but I think it's really useful. STEPHANIE: That's excellent. I was going to ask you if there are any resources or any repos to check out for someone who is interested in getting into Rust. It's funny, last night I was poking around with Python and there's something similar to Rustlings. It's called Python Koans and it's basically like what you're already familiar if you do web development. You want to get your test to pass so it'll tell you, you need to think about this one or you need to meditate on this and then you try to get it to pass and then it says you have reached enlightenment or you have not yet reached enlightenment and you have to sit there and think about it and then run it again. It's very useful in trying to get started with language in a way that you are already sort of familiar with. CAROL: Yeah, I've definitely gotten inspiration from the Koans project that have existed in other languages. There's also an exercism track for Rust that people found really useful and of course, I'm working with Steve Klabnik on the Rust programming language book. We're rewriting the whole thing so there's an existing version that if you go to the Rust documentation and click on book, you'll get the existing version which is complete but the new version is going to be way better. Especially with the explanations of ownership and borrowing, people have said that the new version is way, way better than the old version. Someone even made the analogy of doing medical research and you see that trial case is doing so much better than the placebo case that is not ethical to continue the trial. It's more ethical to stop the trial and use the new thing because it's helping so many people. Someone was like, "You need to replace the old book with the new book right now because it's so much better," but the new book isn't complete yet. The new book is in a different repo which we can put in the show notes so I'd recommend starting with the new book and then working back and forth with the old book once you run out of content. But we're getting closer all the time so hopefully, that should be done and printed by No Starch sometime in 2017 -- CHRIS: Woah! It's being printed by No Starch? CAROL: Yeah. CHRIS: That's cool. I didn't know that. Congratulations. CAROL: I thought Steve mentioned that in the last one. CHRIS: He may have but he talked about it a long time ago and I thought he always meant the old one. How long have you been rewriting the Rust book for? CAROL: It's been a while. CHRIS: Longer than I knew about then, probably. CAROL: It's kind of like software. It's more work than you think it's going to be and estimating, it's going to be done when it's done. If you kept telling people, "It's going to be out on this time," and like Steve, "There's no way it's not getting done by then," so now he's not allowed to say it when it's going to be out. CHRIS: Nice. CAROL: I'm really grateful to see this opportunity because I don't think I would have written a book on my own and I'm learning a whole lot about the process of writing a book. It turns out there's a lot of editing, a lot of back and forth, a lot of trying to build a narrative through this long stretch of text so that you're building on top of what you've already covered and not introducing things that aren't mentioned. It's a lot of work and I'm learning a lot and I have no idea when it's going to be [inaudible] because I think there's more work that I still don't know about coming, as we get closer to going to print. It's definitely one of those things that you can't make agile because you've got to put it on paper that costs money and it's going to be around a long time at some point. It's definitely a different kind of working that I'm used to with software. CHRIS: Although, I have to say, I clicked around and I think this is the new version: Rustlings.Github.io/Book. Is that the new one? CAROL: Yes, that's the new version. CHRIS: There is a lot here and it's not quite what I would have expected to see here like it's not done yet. I've been clicking links and I have yet to find one that says 'to-do'. CAROL: I think 15 through 20 are like outlines right now. We're maybe three-quarters through with the content but then we have to go through revisions and editing and copyediting. CHRIS: I'm looking at the headings and I was a big fan of the first Rust book but I can already see it calling out things I wish had been hit on more specifically in the original book. There's a lot of good looking stuff here so I'm excited about this. I'm going to go and read this thing. CAROL: I'm excited for people to read it. CHRIS: Earlier, you were talking about one of the things that is really nice about the Rust tooling is that Cargo makes it really easy to bring in dependencies. I happen to know that you are recently, I believe the maintainer of Crates.io which is where all of Cargoes crates, which are the libraries are hosted. Is that correct? CAROL: That is correct. I have commitment Crates.io now which is very exciting. Crates.io is like Ruby Gems or npm. It's the site where people publish their libraries and you can go and search for a library for what you need. As part of the Rust 2017 goals, we want to make it easier for people to find high-quality libraries that do the things they needed to do. I've been doing some work on adding badges and categories. Rust makes major decisions on the language and on things through an RFC process, which I think Ember is doing now too. I forget which way we stole that. Do we steal it from Ember or did you steal from us? I can't remember. CHRIS: If I remember right, I think -- I could be wrong, Twitter -- Ember did it first. Rust borrowed it and then added the 'how do we teach this?' section. I think Ember took that back and added it to their RFCs. CAROL: Okay, I'm super excited about that section. Now, when you propose a change of language, you have to go through this RFC process where you write up what you want to change, why you want to change it, any downsides, any alternative designs. Then the community talks about it and makes comments when you revise it and things like that. Now, there's a new section that just got added. That's 'how do we teach this?' Before something can be stabilized in the language, you have to document it. This is still kind of starting to take effect but I'm super excited about it because people can't use something unless they know how to use it. Right now, Steve's the only person getting paid full time to work on the documentation and I need him to write the book so I'm excited that more people will be thinking about documentation and thinking about how to help people use their new features. Anyway, I have an RFC about how to rank Crates within a category that we're trying to work through. In some automated ways, we can recommend different Crates for different purposes. I'm working through that with the community to try and figure out how to best recommend Crates in different circumstances. Crates.io is written in Rust and it performs really well. It just got added to the Heroku things so you can deploy it too. Looking at the analytics and their response times for is just like the Ruby apps I work on would be thrilled to have these stats. The backend of it is Rust, the frontend is Ember and [inaudible] who was an Ember person is also interested in Rust and he thinks Rust on the backend and Ember on the frontend worked really well together. He's always trying to figure out ways that we can work together. Crates.io is an existing project that I'm still learning Ember. There's lots of words I don't really understand about like components and Bowers. I would love Ember help on Crates.io. I'm starting to pull out issues that would be good at first time issues or more Ember-focus or I have some idea of how to fix that I could help someone fix. I'm starting to tag those things with 'has mentor' in our labels so I love for people to come check out issues on Crates.io who know JavaScript and know Ember and might want to get into Rust because there are definitely some issues that need a little bit of frontend, a little bit of backend so it might be a good way for people to get into Rust. CHRIS: Very cool. I'm personally very interested in that and will likely hit you up. But I'm sure many of our listeners will as well because I think we have a lot of Ember-friendly listeners so look Carol up because it sounds like she could use some help. Actually, I'm curious, the backend, I know that pretty recently, Rust has kind of gone through this period of kind of explosion in terms of Rust as a web language. There have been a number of different things that have come out pretty recently for a web framework in Rust or there's that Tokio thing. I know Diesel is like the ORM for Rust in talking to databases. It looks like it's about to hit 1.0. There's a lot of stuff happening so I'm curious, what are you using to write the backend. I know you're using Rust but are you using one of these frameworks or have you rolled your own? How's that work right now? CAROL: Crates.io is one of the first web apps that has been written in Rust. Actually, if you look at the backend code, you'll see SQL being built by hand. It's going to the Rust postgres library so it has SQL injection protection. All the things are [inaudible] so don't worry about that but they're still like SQL with the Rust code so it's not using an ORM yet. I'm going to have to look up. There is a library that is using that I'm blanking on the name of it for but it's very low level. It just let you send HTTP requests and let you respond to HTTP. We're in kind of a Cambrian explosion period with Rust web frameworks. There's a lot of different ones. One that I'm excited about that I haven't gotten to tryout yet is Rocket. That was just released. The thing I love about Rocket is that everyone's really excited about it because it was announced and they have an awesome website with lots of awesome docs so that should be a lesson to any open source project that's launching is if you want to get excited about it, you've got to launch some docs. That will help so much. There's a lot of different frameworks happening. They're still little trilobites and little animals that can't walk on land on their own quite yet so there's still no Rails. There's the pieces of Rails. There's Diesel which would act like a record. There's Nickel and Pencil and Iron and Rocket. Tokio is the async framework that is getting more and more stable by the day. We got to try it out on a project recently and it's pretty fun. I still am working on wrapping my head around promises and futures and working in that way but I think as that stabilizes and people use that, that is going to cause like another explosion of libraries that enable really fast but safe web backend stuff, which I think is really exciting. If you're looking for the Rails experience of being able to plug things together and nicely, just declare a few things, it works but not quite there yet. But if it excites you to try out new things and figure out the best ways to do the things you want to do in Rust, this is a great time to jump in and help. CHRIS: I will say the Rocket website is beautiful and it even has this templating section, a testing library section. This is very exciting. It really looks like as the closest thing to a Rail-style web framework that I've seen in Rust so far. People should definitely check this stuff out. I'm curious, I know a lot is really interested in Rust and Ember, which doesn't surprise me because lots is really interested in Ember in general, which I think is awesome. But is there anything specific about working with the Rust and Ember together that seems, especially well suited or even like some gotchas that you guys have run into? One of the things I'm thinking of is like Ember is really big into JSON API spec and I don't know if Rust has a JSON API library for serializing things in that format. Is that something you guys have to tackle at all? CAROL: There might be. I'm not sure. Crates.io is using the Rust API adapter for Ember so we might not be keeping up with the latest of Ember. But I know there are people who want them to interface them better with each other. Actually, that's an interesting thing. Both Ember and Rust are on a six-week release trains sort of things so the way Rust people will say -- I don't know if Ember people do -- is stability without stagnation so they're both changing. Rust has backwards-compatibility guarantees so the code you wrote with Rust 1.0 is still going to compile today. You might have some warnings and there's probably new cooler stuff that you could switch to but it's still going to compile. I'm not sure about Ember's upgrade path things. Someone just sent in a pull request that we merged like three days ago to upgrade us from two Ember point versions. There were a couple of things that like [inaudible] and we weren't doing quite right and we had to fix. It's been interesting to kind of fit together, keep both of the sides, update it and upgrade it and continuing on using the best things. But I think they have similar philosophies around making things better all the time. CHRIS: Yeah, the whole stable upgrade path and backwards-compatibility guarantees is definitely mirrored on the Ember side of things. I can see that being a little kind of comforting place to be knowing that both your frontend and your backend are not going to suddenly just break on you one day because some new feature came out that breaks your router or something. That's very cool. One of the thing that I know you're involved in -- you're involved in a lot of things -- when it comes to Rust, it's very cool. But you also run or a co-run a conference, right? Rust Belt Rust? CAROL: Yeah, we had our first year in 2016 in Pittsburgh. I ran Steel City Ruby before then so I love running conferences and I love having them near me one, because it's convenient and I get to trick all of my friends into coming to visit me. But two, because there's a lot of tech stuff happening in the Rust Belt and places that aren't San Francisco or New York. People don't necessarily know about that and people who live here don't necessarily have the opportunities to travel as easy to conferences. I sort of start Rust Belt Rust, one because of the pun opportunity and one of our speakers drew a little bar graph. There were three conferences last year. There was Rust Fest in Europe which has [inaudible] amount of Rust. There's RustConf, the official Rust Conference in Portland that has a lot amount of Rust and then Rust Belt Rust has double the amount of Rust in its name so we're the Rust-serious Rust conference. We're going to do it again, in 2017 we're going to move it to a different Rust Belt city. I'm not going to say which one yet but we're closing in on a date and a venue in the Rust Belt city so watch out for an announcement on that. It was a lot of fun. We had a day of workshops and then a day of single-track talks and a lot of time for conversation. A bunch of the core team members came out and it was fun talking with a friend of mine who was trying out something with Tokio. This was in October so Tokio was still working towards their first big release and he was trying to do something with Tokio. I looked over and I saw Carl Lerche, Alex Crichton and Aaron Turon standing together and talking like 30 feet from us and I was like, "If only the three people working on Tokio were nearby to answer your question --" so he just walked over and talked about Tokio with them. I love getting people together to talk to other people working with things, talk to the people who are working on the things they're using and meeting the people behind the names on the internet so I love running conferences and having events like that. STEPHANIE: Carol, you have a Rust consultancy called Integer 32. How is that going? CAROL: It's going pretty well. We're learning a lot. One of the reasons I wanted to start it is because I felt like I wasn't learning more in my job. In my Rails job, I felt like I had kind of tapped out with that knowledge. In starting a business, I get to learn a lot of stuff like sales and marketing and taxes and invoices. Sometimes, I even get to program a little. We're still learning how to effectively find our target customers. We do have availability, if anyone listening is interested in hiring some Rust experts. Right now, I'm trying to figure out when can we bring more people on the team. I'm trying to decide if we can have an intern for the summer. It should be fun so yeah, it's going pretty well. It's been a slow build but we're lucky enough to have savings and be able to spend some time building our business but it's been really gratifying to feel like I'm in charge of my destiny somewhat, as opposed to the whims of a company. STEPHANIE: And if I were interested in some Rust consulting, what would be the best way to reach you? CAROL: We have a website at Integer32.com and a contact form on there. STEPHANIE: Thank you so much for speaking with us, Carol. It was a pleasure. I feel like I learned a lot about Rust. CAROL: Thank you for having me. STEPHANIE: All right, y'all. That's it from us. Thank you so much for tuning in. Until next time. Bye-bye.

How can the command line be cool? Carl and Richard talk to Richard Turner, freshly back into Microsoft, and working on the Bash on Windows project. So why would you want a Linux command line prompt? As Richard explains, there are cool bits of code you can create on your Windows box but don't really behave all that well - some Ruby Gems, etc. Having Linux, real Linux, running in Windows helps all that work better. And if you're headed toward the cross-platform world in the mobile space, or Linux on the backend, these tools can help you be more productive and less frustrated. It's early days yet, but there's lots to check out!Support this podcast at — https://redcircle.com/net-rocks/donations