Podcasts about Datomic

Abhay Paroha, an engineering leader with more than 15 years' experience in leading product dev teams, joins SE Radio's Kanchan Shringi to talk about cloud migration for oil and gas production operations. They discuss Abhay's experiences in building a cloud foundation layer that includes a canonical data model for storing bi-temporal data. They further delve into his teams' learnings from using Kubernetes for microservices, the transition from Java to Scala, and use of Akka streaming, along with tips for ensuring reliable operations. Brought to you by IEEE Computer Society and IEEE Software magazine.

This week's guest describes Event Sourcing as, “all I'm going to use for the rest of my career.” But what is Event Sourcing? How should we think about it, and how does it encourage us to think about writing software?In this episode we take a close look at systems designed around the idea of Events, with guest Bobby Calderwood. Bobby's been designing (and helping others design) event based architectures for many years, and enthusiastically recommends it not only as a system-design technique, but as a way of solving business problems faster and more reliably.During this discussion we look at the various ways of defining event systems, what tools we need to implement them, and the advantages of thinking about software from an event-based perspective. Along the way we discuss everything from Clojure, Bitemporality & Datomic to Kafka and more traditional databases - all in the service of capturing real-world events and building simple systems around them.–EventStoreDB: https://developers.eventstore.com/The CloudEvents standard: https://cloudevents.io/Datomic: https://www.datomic.com/Adam Dymitruk's Event Modelling Explanation: https://eventmodeling.org/Bobby's Event Modelling course: https://developer.confluent.io/courses/event-modeling/intro/Bobby on Twitter: https://twitter.com/bobbycalderwoodBoddy on LinkedIn: https://www.linkedin.com/in/bobbycalderwood/Kris on Twitter: https://twitter.com/krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/–#software #softwarepodcast #programming #eventsourcing #eventdrivenarchitecture #kafka

Francis Acila on GitHub - https://github.com/favila Datomic - https://www.datomic.com/ Shortcut - https://www.shortcut.com/

This is a recap of the top 10 posts on Hacker News on April 27th, 2023.(00:41): Datomic is FreeOriginal post: https://news.ycombinator.com/item?id=35727967(02:01): Steven Spielberg: ‘No film should be revised' based on modern sensitivityOriginal post: https://news.ycombinator.com/item?id=35724634(03:32): As I am currently in a war zone, I don't have many options for cablingOriginal post: https://news.ycombinator.com/item?id=35730074(04:52): Colorado governor signs tractor right-to-repair law opposed by John DeereOriginal post: https://news.ycombinator.com/item?id=35729558(06:14): Every web search result in Brave Search is now served by our own indexOriginal post: https://news.ycombinator.com/item?id=35730711(07:32): Dropbox telemetry can't be disabledOriginal post: https://news.ycombinator.com/item?id=35724939(08:48): Dropbox to reduce global workforce by about 16%, or 500 staffOriginal post: https://news.ycombinator.com/item?id=35728216(10:05): A visual book recommenderOriginal post: https://news.ycombinator.com/item?id=35726559(11:27): The unintentional dystopian beauty of oil rigsOriginal post: https://news.ycombinator.com/item?id=35725094(12:30): Google Cloud region currently down due to water intrusionOriginal post: https://news.ycombinator.com/item?id=35732384This is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

Andrew Stone of Oxide Engineering joined Bryan, Adam, and the Oxide Friends to talk about his purpose-built, replay debugger for the Oxide setup textual UI. Andrew borrowed a technique from his extensive work with distributed systems to built a UI that was well-structured... and highly amenable to debuggability. He built a custom debugger "in a weekend"!Some of the topics we hit on, in the order that we hit them: tui-rs Crossterm The reedline crate Episode about the "Sidecar" switch Elm time-travel debugging Replay.io Devtools.fm episode on Replay.io AADEBUG conference California horse meat law The (lightly) edited live chat from the show: MattCampbell: I'm gathering that this is more like the fancy pseudo-GUI style of TUI, which is possibly bad for accessibility ahl: we are also building with accessibility in mind, stripping away some of the non-textual elements optionally MattCampbell: oh, cool ahl: Episode about the "Sidecar" switch: https://github.com/oxidecomputer/oxide-and-friends/blob/master/2021_11_29.md MattCampbell: ooh! That kind of recording is definitely better for accessibility than a video. uwaces: Were you inspired by Elm? (The programming language for web browsers?) bcantrill: Here's Andrew's PR for this, FWIW: oxidecomputer/omicron#2682 uwaces: Elm has a very similar model. They have even had a debugger that let you run events in reverse: https://elm-lang.org/news/time-travel-made-easy bch: I'm joining late - 1) does this state-machine replay model have a name 2) expand on (describe ) the I/o logic separation distinction? ahl: http://dtrace.org/blogs/ahl/2015/06/22/first-rust-program-pain/ zk: RE: logic separation in consensus protocols: the benefit of seperating out the state machine into a side-effect free function allows you to write a formally verified implementation in a pure FP lang or theorem prover, and then extract a reference program from the proof. we're going to the zoo: lol i'm a web dev && we do UI tests via StorybookJS + snapshots of each story + snapshots of the end state of an interaction ig: At that point you could turn the recording into an “expect test”. https://blog.janestreet.com/the-joy-of-expect-tests/ we're going to the zoo: TOFU but for tests

Jaret Binford on GitHub - https://github.com/Jaretbinford Alex Miller on GitHub - https://github.com/puredanger 15 years of Clojure - https://www.youtube.com/watch?v=exSRG-iL74Q Request podcast - https://github.com/clojurestream/podcast Video Courses: https://clojure.stream https://www.learnpedestal.com/ https://www.learndatomic.com/ https://www.learnreitit.com/ https://www.learnreagent.com/ https://www.learnreframe.com/ https://www.jacekschae.com/

Datomic is an immutable database that borrows ideas from functional programming. We discuss how an immutable database changes the architectural possibilities of web apps. Links/Resources: - [Datomic with Rich Hickey](https://www.youtube.com/watch?v=9TYfcyvSpEQ) - [Database as Values with Rich Hickey](https://www.youtube.com/watch?v=V6DKjEbdYos) - [Intro To Datomic with Rich Hickey](https://www.youtube.com/watch?v=RKcqYZZ9RDY) - [KotlinConf 2018 - Datomic: The Most Innovative DB You've Never Heard Of by August Lilleaas](https://www.youtube.com/watch?v=hicQvxdKvnc) - [Love Letter To Clojure: And A Datomic Experience Report - Gene Kim](https://www.youtube.com/watch?v=5mbp3SEha38) - [Turning the database inside out](https://www.youtube.com/watch?v=fU9hR3kiOK0) - [Datomic - a scalable, immutable database system by Marek Lipert](https://www.youtube.com/watch?v=xGrCsIiiTUs) - ["Real-World Datomic: An Experience Report" by Craig Andera (2013)](https://www.youtube.com/watch?v=2WeFdAXZz30) - [https://tonsky.me/blog/unofficial-guide-to-datomic-internals/](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/) - [https://www.infoq.com/articles/Architecture-Datomic/](https://www.infoq.com/articles/Architecture-Datomic/) - [https://www.infoq.com/presentations/The-Design-of-Datomic/](https://www.infoq.com/presentations/The-Design-of-Datomic/) - [Talking about Datomic, Datalog, GraphQL, APIs](https://www.notion.so/Datomic-52000e1e65d345509cbcde4681d5522f) - [What Datomic does to REST](https://web.archive.org/web/20210421110723/http://dustingetzcom.hyperfiddle.com/:what-datomic-does-to-rest/) - [Unofficial guide to Datomic Internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/) - [Datomic Documentation Overview](https://docs.datomic.com/on-prem/overview/overview.html) - [The web after tomorrow](https://tonsky.me/blog/the-web-after-tomorrow/) - [APIs are about policy](https://acko.net/blog/apis-are-about-policy/) Chapters: 0:00 Intros [00:02:21] What is Datomic? [00:05:01] The Immutable Database [00:14:59] The N+1 Problem [00:20:59] Inference and Logical Programming [00:26:45] Database in the browser [00:39:24] Reducing the Impedence Mismatch [00:42:09] The Change in Perspective [00:51:14] Data as Social Artifact ===== About “The Technium” =====The Technium is a weekly podcast discussing the edge of technology and what we can build with it. Each week, Sri and Wil introduce a big idea in the future of computing and extrapolate the effect it will have on the world.Follow us for new videos every week on web3, cryptocurrency, programming languages, machine learning, artificial intelligence, and more!===== Socials =====WEBSITE: https://technium.transistor.fm/ SPOTIFY: https://open.spotify.com/show/1ljTFMgTeRQJ69KRWAkBy7 APPLE PODCASTS: https://podcasts.apple.com/us/podcast/the-technium/id1608747545

Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Customer.io (https://customer.io/) Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) Datomic (https://www.datomic.com/) About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) Apache Kafka (https://kafka.apache.org/) Resilient Management | A book for new managers in tech (https://resilient-management.com/) Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- STEPH: Oh, I have golden roads, yes. [laughter] CHRIS: You might should inform that you've got golden roads, yeah. STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. CHRIS: [laughs] STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? [laughter] CHRIS: Do you want to fight? STEPH: Yeah, are we going to fight? CHRIS: I might could fight you. STEPH: I might could. I might should. [laughter] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. STEPH: Oh, I'm behind. CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. [laughter] STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. STEPH: Yeah, that would be death by Top Gun. CHRIS: But not the normal way, the different, indirect death by Top Gun. STEPH: I don't know what the normal way is. [laughs] CHRIS: Like getting shot down by a Top Gun pilot. [laughter] STEPH: Yeah, that makes sense. [laughs] CHRIS: You know, the dogfighting in the plane. STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior's phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. STEPH: Cool. Well, that's a huge help to me. What's going on in your world? CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? [laughter] CHRIS: What am I actually? STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] STEPH: No, raving. I will never forget now, raving. [laughs] CHRIS: So, I mean, we've done this before. STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." [laughter] CHRIS: Actually, we got a handful of emails on that. [laughter] STEPH: Did you know the English language? CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. [laughter] STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It's like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user. That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle. CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event. And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event. And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying. STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product. CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls. Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them. STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important. CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you? STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that. But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else. So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans' core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing. The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles] So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together. What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this? And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management. So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes. CHRIS: That was just the first chapter? STEPH: Yeah, that was just the first chapter. CHRIS: My goodness. STEPH: And I shortened it drastically. [laughs] CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true. STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life. But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs] But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through. CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true. STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows? CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it. STEPH: Agreed. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

The foundational technology for Muse 2 is local-first sync, which draws from over a decade of computer science research on CRDTs. Mark, Adam Wiggins, and Adam Wulf get technical to describe the Muse sync technology architecture in detail. Topics include the difference between transactional, blob, and ephemeral data; the “atoms” concept inspired by Datomic; Protocol Buffers; and the user's data as a bag of edits. Plus: why sync is a powerful substrate for end-user programming. @MuseAppHQ hello@museapp.com Show notes Adam Wulf @adamwulf Fantastical Loose Leaf Wulf's iOS ink libraries OpenGL Bézier curves Houston Muse 2.0 launches May 24 Metamuse episode on local-first software Core Data Pocket Clue, Wunderlist CouchDB, Firebase Adam's writeup on sync technologies from 2014 Evernote Pixelpusher Slow Software CRDTs, operational transform Automerge Actual Budget last write wins Actual open source hybrid logical clock, vector clock CloudKit lazy loading API versioning Protocol Buffers Wulf's article on atoms Datomic “put a UUID and a version number on everything” Swift property wrappers functional reactive programming Sourcery Sentry HDD indicator light Muse job post for a local-first engineer Local-first day at ECOOP 2022

IPFS is a distributed storage network. The content is accessible through peers located anywhere in the world that might relay information store it or both, and IPFS finds data by its content address rather than its locations. We discuss the main principles behind IPFS, the current use cases, and how it changes the basic unit economics of some businesses, as well as its interplanetary future.Chapters:00:00 Intros02:25 What is IPFS?13:58 Three Principles of IPFS15:01 Content-addressable URIs18:44 Content Linking in a DAG21:27 Distributed Hash Table for Discovery22:48 Pinning Content30:58 Censorship-resistance36:38 Used for NFTs39:04 Used for Video and Music Streaming42:56 Use for Package Manager49:14 Use for Machine Learning54:38 Interplanetary Linked Data56:37 A Key Building Block59:22 As a Public Good01:06:36 Developers Tools on top of IPFS01:10:07 Shifting Operational Burden01:18:15 The Interplanetary FutureLinks/Resources:Content Addressing https://simpleaswater.com/ipfs-cids/Linked Data https://ontola.io/what-is-linked-data/Distributed Hash Tables https://www.cs.cmu.edu/~dga/15-744/S07/lectures/16-dht.pdfNapster, Kaaza, Gnutella https://www.slideshare.net/uschmidt/peertopeer-systems/20-Comparison_Napster_Gnutella_KaZaAType_ofJuan Benet of IPFS https://research.protocol.ai/authors/juan-benet/ProtoSchool https://proto.school/Marc Andressen's Blog Archive https://pmarchive.com/Left Pad Debacle https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/NPM as a private company https://www.youtube.com/watch?v=MO8hZlgK5zc&t=46sTransfer Learning https://builtin.com/data-science/transfer-learningDeno Programming language https://deno.land/IPLD https://ipld.io/Jack Dorsey Regrets Shutting down API https://www.revyuh.com/news/software/developers/twitters-founder-admits-that-shutting-down-the-api-was-worst-thing-we-did-it-affected-users-and-developers/Datomic https://www.datomic.com/===== About “The Technium” =====The Technium is a weekly podcast discussing the edge of technology and what we can build with it. Each week, Sri and Wil introduce a big idea in the future of computing and extrapolate the effect it will have on the world.Follow us for new videos every week on web3, cryptocurrency, programming languages, machine learning, artificial intelligence, and more!===== Socials =====WEBSITE: https://technium.transistor.fm/SPOTIFY: https://open.spotify.com/show/1ljTFMgTeRQJ69KRWAkBy7

Steph tells a cute story about escape artist huskies, and on a technical note, shares a journey in regards to class variables and modules inheritance. Chris talks about how he's starting to pursue analytics and one of the things that he's struggling with that he's always historically struggled with is the idea of historical data. He's also noticed a lack of formalization of certain things and is working with his team to remedy that. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Mike Burns: How to Skim a Pull Request (https://thoughtbot.com/blog/a-smelly-list) RSpec Documentation (https://rspec.info/documentation/) Don't Let the Internet Dupe You, Event Sourcing is Hard (https://chriskiehl.com/article/event-sourcing-is-hard) Datomic (https://www.datomic.com/) timefora_boolean (https://github.com/calebhearth/time_for_a_boolean) Sentry (https://sentry.io/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, it's an entirely new year. What is new in your new year? STEPH: Well, the year is off to an interesting start because we helped rescue a husky. CHRIS: Rescue as in now this is your dog or rescue as in the dog was trapped in a well, and another dog told you about the dog being trapped in a well, and then you helped the trapped? [laughs] Which of those situations are we working with? STEPH: [laughs] I'm really wishing it was the second version [laughs] where there's a dog that tells me about another dog trapped in a well. No, this is a third version where there was a husky that was wandering around the gym that we go to. And so Tim, my husband, called and said that "There's this husky, and he's super sweet, but he seems very lost." And our gym is located near a major road, and so we were worried that he was going to wander about and get hit. So I hopped into our car and took a crate and a leash, and he hopped right in. Clearly, he belonged to somebody; he'd just escaped. So he hops right in, and then we bring him home. But I put him in the backyard because I want to keep him separate from our dog, Utah, just because I don't know this dog, and I want to keep him safe. And I go back inside to grab a few things. I come back out, and the husky is gone. And I'm like, well, shit. [laughs] Now I'm starting to understand why this husky is missing or why this husky seemed lost. So then I started looking for the husky, and Tim comes home. He's helping me look for the husky. And it was one of those awful moments where we live near...it's not a major road, but people tend to speed on it. And the husky and I happen to see each other across the road. And so the husky was like, oh, human friend and starts coming across the road towards me. And there's this large SUV that's also coming from the other direction. I'm like, oh, this is it. This is my nightmare. This is becoming real. This dog is about to get hit. Thankfully, the driver saw the husky and stopped in time, so everything was fine. And the husky just finished trotting across the road to me, brought him in, kept him in the kennel in the garage. We didn't have any backyard adventures after that. The husky then thanked us by howling most of the night. [laughs] So this poor husky has had an adventure. We've had an adventure. And then, around 4:30 in the morning, I go out because I'm checking on the husky and going to let him out. And I'm scrolling on the app called Nextdoor. And I see that someone posted a picture of this exact husky that's like, "Please help me find my dog." And I was like, yes. Because we were going to have to take him to a county shelter or at least go see if he had a chip so then we could return him. But thankfully, we found the owner. I found out the husky's name is Sebastian. And then we had him for a few more hours, and then we had a wonderful husky and human reunion. CHRIS: That story had everything. It had ups; it had downs; it had huskies. It had escape artist huskies, in fact. I have...this is only through Reddit because that's how people learn about things in the world, but huskies are a rather vocal dog breed. So when you say the dog was howling, huskies have a particular way of almost singing, and it kind of sounds like yelling rather than more traditional dog sounds. Was that the experience you had? STEPH: Luckily, it wasn't too bad. His howling was more just; he didn't want to be in the crate. He seems like an indoor dog. So he's like, what am I doing outside in the garage? I should be indoors. And so he wasn't too loud. It was more he was just bemoaning his situation. But our dog Utah could hear him upset in the garage. And so that was also getting Utah upset because he didn't understand why there was a dog so close. And that was what led to the sleepless night because we couldn't get both of them to calm down. Because then, as soon as one of them calm down, the other one would get the other one riled. CHRIS: As it so often happens. STEPH: I'm so grateful that it turned out to be a happy story, though. That part was wonderful. And if we see the husky again, now we know his name is Sebastian and that he'll just come home with us. [chuckles] And we'll know how to return him since he seems to be an escape artist. CHRIS: And we were best friends forever. STEPH: On a more technical note, I have quite the journey to share in regards to class variables and modules inheritance. But before I dive in, I'm curious, what's new in your world? CHRIS: Oh. Well, I'm excited to dig into that story. But I've got two smaller things in my world this week that are top of mind. I don't really have answers on them. I have more questions. One is we're starting to pursue analytics. We want to try and understand our system a little bit better. What is the experience of our users? How are they coming into the system? What are they doing? How long does it take them to do the things that we want them to do? All those sorts of questions you want to be able to answer about your application. And one of the things that I'm struggling with that I've always historically struggled with is the idea of historical data. So data changes over time, and often we actually want to know about those transition points. We want to know about the different states that a user or any record in the system has been in. And I'm finding myself feeling the same pain that I felt many times and starting to think again about the relevant options out there in the world. To give a slightly more pointed example of what we're dealing with, users come in, and then there are a few steps for them to actually sign up for the application. And so their user record or their application, if you will, will go through a couple of different states. So they can be basically approved directly, and now they're an active user of the system, that's one option. But they can also end up in a state where they're pending review. And then eventually, depending on the outcome of that review, whether it's manual or someone intervenes or what have you, then eventually they can transition to either being denied or being accepted. And then they'll again be an active user. And so there's a question now of how many of the users that end up in that pending state end up transitioning into active. And as I looked at the database, I was like, I do not have this information right now. I know their current state. And the logs could tell me all of this. We don't have proper log archiving right now. And I also don't have a system for, like, let me pull down gigabytes of logs and try and sift through that to understand the answer, especially for something domain level like this. But this is one specific example that represents a category of things in my mind. The stuff that I've looked at in this space otherwise is Event Sourcing. So the idea that rather than having a discrete representation of the state of your application, you store every event as an individual log, essentially of like user did X, thing happened, Y occurred. And then, at any given point, you need to know about the state of your system; you just reduce all of those events through some magical reducer that produces the current state. I also very recently read an article called Event sourcing is Hard. So I have that in my head as a counterpoint. This seems like a thing that is non-trivial to do, makes sense for a certain scale. But of course, like anything else, it has its trade-offs. Another thing that I've looked at and never really pursued mostly because it's in a different ecosystem, is Datomic, D-A-T-O-M-I-C, which I think I've mentioned before. But it's a database that actually stores data in this historical format. And so you can ask for the current value, but then you can also ask for what are all the states that this user has been in? And what are the timestamps of those changes? One small thing that we do have that I really like...so this is one example of us; I think leaning into wanting to have more information, higher fidelity information, is often we want to know something like was this ticket paid? Did someone pay for this ticket? And so paid is a BooleanProperty on this ticket record within our system. So the ticket can be held for a little while and eventually gets paid. And now, yes, it has been paid for. It is good. You can use it. But often, we want to know not just that it's paid but when it was paid. And so there's a gem that we are using on the project called timeforaboolean by former thoughtboter, Caleb Hearth. And it does a wonderful job of basically instead of storing a Boolean value in the database, you store a timestamp. But then the Boolean can be inferred. If there is a value, if there's a timestamp for that record in the database, then there are a bunch of helper methods that get introduced that say, like, paid? That's now a method that I can ask, and it will tell us that. But we can also find the paidat, paid_at value. And so we have this higher fidelity data when we need it, but we can also collapse it down to the simpler representation. Because most often, all we need to know is, have they paid for it? Cool, then they're good. They can come into the concert, that sort of thing. But yeah, this is a broader question that I don't have a great answer to. I think Postgres and Rails and just the nature of how we approach these applications pushes us in a certain direction. Another thing I'm exploring is downstream analytic systems. What if I send a bunch of events to them, and they act as a half-event sourcing type thing? But yeah, this is going to be, I think, an open question for me for a while. STEPH: Yeah, you said a lot of really good options. When you're talking about in our ecosystem, we get pushed in one direction or the other that makes me think of the projects that I've been on. Typically, what they'll reach for first is something like a Papertrail. So then, that way, they can check for the historical versions of an object and how it was changed and see who changed it. That's one way to track the logs. I like the idea that if you can outsource it and send all of those events to a logging system and then essentially ask for that data back as you need it. You made me think of a recent project as well where we needed to track the state. So it was a patient matching system. And we really needed to know when a patient match was created or disconnected and then who did that and perhaps for what reason. And to ensure that we had as much information as possible, we took that opportunity to just create a record for it. So we had a patient match record or...I forgot the name of the other one where we created where a patient did not have a match. But we were creating a record every time someone did that. Granted, probably that's not going to happen nearly as often as someone paying for an event or the situations that you're describing. This was ideally infrequently that someone was going to unmatch a patient because it meant that our system had matched people that shouldn't be matched, and then a human had intervened. But yeah, it's interesting the space that you're in. And you listed all the good things that I would have thought of. CHRIS: I think you listed Papertrail, which is one that I hadn't actually thought of yet for this particular instance. This only came up earlier today also. So this is new in my head that I'm really being pushed in this direction. But I think Papertrail could be a good solution for where we're at. But it is one of those where you often don't know the thing you want to know. And I'm terrified of losing data of like; I had the data. I knew it at one point in time, but now I can't reknow it in the future because I didn't write it down. That's one of the things that I just don't want to happen in the world. And so finding those ways of like, how can we architect a system so that we can do the normal, straightforward, boring things most of the time but then when we need to expand out the analytics dimension of the system that we're working on...and trying to thread that needle and find the ideal optimization on both sides is a tricky one. But yeah, I'll definitely take another look at Papertrail and see if that...at a minimum, I think that's a good solution for where we're at now. And then this is going to be a thought that's going to roll around in the back of my head for a while. So if I come up with anything else, perhaps a grander solution, I'll certainly bring that back to The Bike Shed. But yeah, what else is up in your world? I want to hear the story of the class variables. STEPH: Well, it is quite a journey. So I hope you're ready. Specifically, I was pairing with Joël, who was working on fixing a test that had been marked as being skipped for a while. We weren't really sure why. We figured maybe because it's flaky. But then, as Joël had restored that test, he realized it was actually failing consistently. So it was a test that was failing for a reason folks maybe didn't understand, but they decided to cancel or to skip that test. But they didn't actually want to get rid of it because it seemed like a pretty important test based on the description. So Joël saw it and got excited because it seemed very relevant to some of the work he was already doing. So then, he is now investigating why this test is failing consistently. So in this story, we have four main characters: we have a class, two modules, and a class variable. So enter the class stage left. All right, so this class defines a class variable which I have to say is not something I work with very much in Ruby. So class variables kind of felt a bit novel and diving back into like, oh yeah, these are a thing. So the class defines a class variable that's called cache and assigns this variable to an instance of a cache. So then this class includes two modules who we'll call Module A and Module B. And we'll enter them stage right. And both of these models look to see if cache is already set. And if it's not, they also set the cache class variable. So with that information, in our test, we don't want to exercise the real cache just because then if other tests are reading from that cache, which is proving to be a source of flakiness for these tests, then they are overriding each other's expectations, and it's causing some of the tests to flake. So instead, we want to use a fake cache, just like an in-memory cache. So the test and its setup is already overriding. It's setting that class variable to say, hey, I want you to be a fake cache, just be in-memory. However, while executing that test, one of the modules is checking to see if that cache is set, which is being set in our test setup. So test setup sets the value. We're running the test but then in the module, the model checks to see if it's set, and it's suddenly nil instead of using the cache that we had set. So now it's defaulting back to say, "Oh, it's unset. So let me go back and set it to the real cache," which is exactly what we're trying to avoid. So then the question became, if we're setting the class variable in our class, why is it being populated in one of the modules but it's not being populated in the other module? So one of them has it set to the in-memory cache, but the other one does not. So I'm going to gloss over some of the details because this stuff is pretty tangling. But essentially, when the test is running, and it's loading the class, and we are overriding that class variable, it's getting shared with one of the modules because as soon as one of the models does set that class variable, there's a bidirectional link that gets set between the parent class which is the module in this case, and the class itself. And as soon as that module sets the class variable, then they're going to talk to each other, and they're going to reference the same value. However, this only seems to happen for one of the parents. You can't do this for both. So if you have two parents that are trying to share a class variable with the same class, that doesn't work. So that's a particular bug that we were running into. I do have some good news because if anybody is very nervous about the situation that I'm describing, I feel you. The good news is that in Ruby 3, they actually warn when this is happening and have introduced an error. So you don't have this inheritance confusion that can come out of the fact that these parent classes are also trying to share a class variable with this child class. So in Ruby 3, if you are writing a class variable in that class but then you try to overwrite that class variable in the parent of that class or by the module that's being included, then an error is going to be raised. So it's going to warn you if you're creating this bidirectional link between those two class variables and that you shouldn't be overriding the child's ownership of that class variable. Instead, if you're going to use class variables, which, one, is not my cup of tea, but if you're going to use class variables, it should be defined in the parent class, and then it can be shared downstream in the inheritance versus trying to go upstream and then having your ancestors essentially override some of those class variables. So all of that is to say we were on a very interesting journey of understanding how class variables work, how the inheritance works, how that bidirectional link is getting established, and then how Ruby 3 comes in to warn us if something funky is happening. CHRIS: Oh, that is interesting. And I'm now going to catalog that as a piece of information that my brain will retain for roughly the amount of time that we are recording this podcast and then immediately forget. STEPH: As you should. [laughs] CHRIS: It's one of the reasons that I try to avoid inheritance. And I try to avoid class variables as much as possible because of this category of problem, a very subtle bug that you have to try and really hone in. And you have to be very smart to debug this sort of thing. I don't want to be that smart. I want to code in a way that I can be less smart on any given Thursday. That's my goal in life. I will ask one other question, though. So there's just a cache that this class and pair of modules are hanging around with, and then you want to swap it out for in-memory. This sounds remarkably like the Rails cache. Is this cache distinct special? Could it not just be backed by rails.cache, THE cache within the rails context, which can be backed by Memcached, or Redis, or in-memory when you're in tests, or the NullStore, which I think is the default in development is probably how that goes? Is there a particular reason? Is this a special cache? Is there additional behavior that this cache has beyond the normal thing? Or is it just like, at some point, someone's like, oh, I need a cache. I'm just going to use a class variable, that'll be easy, which it definitely is, but then you run into complexities. And caches are one of those hard things to get right. So it's one where I would immediately be like, whoa, whoa, I would love to not make up our own cache here. So I'm wondering, is there a distinct reason, or is it just this happened, and here we are? STEPH: So I think we are using a custom cache that we are pointing to. So it is another service. It's not a Rails cache or an abstraction that we can point to and use. It is a different cache that we are using. And I'm trying to think back to the exact code. But there is a method that essentially checks to say, hey, should I use the real cache? Should I use the in-memory cache? And that is something that we've explored to find a way to make this more global for the test suite because we really want to control this for all the tests. Because it's very easy to not realize in the test that you should avoid using that shared global cache. And so that way, the tests don't interact with each other but instead always use an individualized cache for each test to make sure that it is self-sufficient and independent. But we haven't gotten that far yet in figuring out how we can take a more global approach with this. CHRIS: Gotcha. So I don't know the details. I assume there are reasons here. But just to play this out, if we find ourselves saying we have a reason to have a distinct cache, to have a special cache over here, but it's a cache...and caches fundamentally, that word always will raise my attention. It will be like, okay, this is a place that bugs will come and aggregate. And we need a distinct one that has special behavior as an external service, or that is just something like in... There's a wonderful blog post that Mike Burns wrote at one point that was about...I think it was something like things that will make me look at your pull request in more detail. And I really loved it because it did capsulate all of these like, yeah, there are good reasons to do everything on this list. But if you do any of them, I will look at your pull requests and be like, oh, that's interesting. Why are we doing that, though? Do we have to do that? Are you sure? Are you triple sure we have to do that? And this is definitely one of those things where caches automatically catch my attention. Even if we're using the built-in cache, I'm like, do we need to? Is that a definite thing? And then all the more so when we're using a custom bespoke one. Again, I assume that there are reasons that there's something special that's going on here. Perhaps the caching behavior is distinct from just it's Redis, and we throw data. And if it falls out the backside, that's fine. Maybe you need entirely different behavior here. But it is something that I would poke at a bunch. STEPH: Yeah, you're asking a lot of good questions. I will have to go back and look at some of the code because we spent enough time in Ruby specifics that I didn't pay as much attention to the cache. Because right now, as we are working on these tests, we're trying to fix just the test without changing the application code, one, because that feels like a safer space. And if the test is flaky, we're just trying to change the test first. But some of these tests we're starting to realize I'm not sure we can fix the test without also changing some of the application code, or the way that we do have to fix the test is really an incentive to back up and say maybe now's the time that we look at some of the application code. Because another question that comes to mind is why use a class variable, and does this need to be shared by the class and the modules? And there's a part of me that suspects that maybe some of this logic was extracted to a module, but then it wasn't cleaned up in the other places. And so that's why we still have a reference. And it's essentially then being shared and set and unset and reset in those different places. So I think you ask some good questions, and I have some more questions of my own when we have time to revisit that portion of the test and application. As another example of some of the tests that I've been working on, one of the tests that I...because we have a list, we can usually tell some of the tests that are flaky. So one of the ones that I was investigating was a similar issue where there was a shared resource, and someone had tried to mock it out. So they had taken the time to say, hey, I don't actually want to use that real resource that's over there; instead, I want to just return the scanned value. But instead, they'd accidentally stubbed out a class-level method instead of the instance-level method. And so it was running, but it wasn't actually stubbing anything else since that's the method that's not getting called. So that was just an oversight for that test. So I fixed that test. But I noticed that we were using allow any instance of, so then I did take the time to go through that file and change and move away from the use of allow any instance of. And for folks that are less familiar with allow any instance of, RSpec has some really great docs that talk about how it's very helpful for dealing with legacy code. But essentially, it is a code smell that you're using; allow any instance of because you are saying that my test is or my code is so complex that I can't really mock out the specific instances that I want to and then return specific behavior. So instead, I'm having to use this more global approach to say, hey, any instance of this method, I want you to mock it out versus this very specific instance that I know that I'm working with. But we can include a link in the show notes because there's a nice write-up that talks about some of the reasons that allow any instance of is not recommended. So that's been kind of fun. There's been a little bit of joy to get to refactor away from that and actually stub out a specific instance. Part of the work, too, that I'm noticing as Joël and I are going through these tests is leaving breadcrumbs for other developers as well because they have a very large team. And they're very junior friendly, which is just incredible. I love that so much about this company. And because they do hire a lot of juniors, then it is a tough codebase. It's a fairly old codebase. So as these juniors are coming in, they're seeing a lot of these patterns. And they're propagating these old patterns that aren't necessarily the best patterns to propagate. But they're doing their best, and then they are reusing what they're seeing. So part of the work as we are revising these tests, my hope is that people will see some of these newer patterns and use those instead of following some of the older patterns. CHRIS: I can only imagine that you're writing borderline novels in your pull request descriptions and commit messages there. I do wonder, is there an index of those that you're collecting? So there's like, here's the test remediation examples list, and you're slowly adding to them. This was a weird one with a class variable. And this was a weird one that had flakiness due to waiting or asynchronous behavior. And gathering examples of those, but specifically from the codebase. I could see that being a really useful artifact because I happily traverse through git blame all the time. But I don't know that that's always a thing. And frankly, I have to work for it sometimes. So if there is that list of here are pull requests that specifically did X, Y, and Z, I think that could be super useful. STEPH: Yeah, that's a great idea. And yes, they have some shared team documentation that speaks to specifically flaky tests because they're aware that this is a problem. They are working together to address this. And they have documentation that states ways to avoid flaky tests. If you encounter a flaky test, here are some of the ways that you can triage to find out what's wrong. So as Joël and I have been finding good examples, then we've been contributing to that document. And they also have team meetings. So our plan is to attend some of those meetings and be like, "Hey, this is just some of the stuff that we've seen this week, some of the things that we improved and changed," and share the progress that we're making. Since everyone is aware that there are these developers that are working hard to improve the test suite, but then share that information with the rest of the team so they too can feel...one, they can just see the changes that are taking place. But they too can also benefit and apply those strategies themselves when they see a flaky test. Oh, but you did just remind me of a thing. So one of the tests that I was going through...I'm very intentionally going through and making the smallest change possible. So I will do the gross, ugly fix whatever it is to get something to pass, and then I will commit it. And then I'll think about okay, well, how can I make this better? So essentially, I have the fix, whether it's pretty or not. And then, after that, I start to have other commits that make it prettier. And so, I had a pull request that had four commits that told the story that I was very happy about and progressed along in a more positive direction. And I issued that, and I discovered that Gerrit, when it sees four commits, it split all of them into their own change request. And so, instead of having what I thought would be this nice story, now got split across these four change requests. And I thought, well, that's less helpful. So I ended up squashing two of them, but I still kept three of them because they stood alone, and each told a story. But that's something that I've learned about Gerrit. CHRIS: Always so interesting how our tools shape our work. STEPH: And it made me think back to the listener who asked the question about ensuring that CI runs for each commit. Well, here you go, Gerrit. [chuckles] Gerrit does it for you. It ensures that every commit gets split into its own change request. CHRIS: I mean, as you said earlier, not my cup of tea but... [laughs] STEPH: Yeah, I'm still lukewarm. I'm still discovering Gerrit and how we get along. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. What else is going on in your world? CHRIS: In my world, we keep adding new users to the system. We keep doing more stuff. These are all wonderful things, the direction you certainly want to be heading. But as we're doing that, I've recognized that we had a lack of process and a lack of formalization of certain things. And a lot of the noise of the work was just coming to me because I was the person that everybody knew. I can ask a question; Chris will know the answer, et cetera. And then there were things that we needed to keep an eye on. But because it was everyone's job, it was no one's job. So we've introduced the idea of a point person on the engineering team. So this is a role that will rotate each week. I think you and I have worked on a handful of projects that had something similar to this. There was a team that we worked with that had an ad hoc list, which were just little tasks that needed to be done by developers. So there was one person who would run with that. I've heard it called captain before, the sprint captain. We're not really doing sprints. So for various reasons, that title didn't work for me. But point person is what I went with here. And so the idea is rather than having product management or anyone else in the organization just individually reaching out to developers, we want to try and choke that off, have a single point of communication. And so just today, I introduced into Slack, a group, but it's a group of one person. So @pointdev is technically the handle for this person. It's a group in Slack. And each week, we'll rotate who the members of that team are. And technically, you could add multiple, but the idea is this is just one person. So we'll rotate the person. And what ends up happening is if anyone...say the product manager says, "@pointdev, what's the status on..." blah, blah, blah, that will notify the person who is the point person that week. So that's a nice feature in Slack so that we can condense it down and say rather than asking individuals, ask this alias. We're introducing one layer of abstraction in our communication tools, much like we do in our software. So I'm drafting now the list of like, here's all the stuff that I think this person...because we're trying to push all of the quote, unquote, "other work" the non-product feature development work into this person's purview for a given week. So it's monitor Sentry for any new errors as they come up, triage them, and figure out what we want to do. Ideally, and this is perhaps aspirational, I would like to keep inbox zero in Sentry. I know how you feel about that more generally and perhaps even more specifically within the world of errors, but that's my dream. We're going to see how it goes. STEPH: I don't know if people know I am the opposite of inbox zero. This is the life that I'm living. CHRIS: What about with errors, though? What about something like Sentry? STEPH: I want to say that I would be a better human with my email. But I'm going, to be honest [laughs] and say that I would probably have the same approach where I am not an inbox zero person. I've come to terms with it. I used to really strive and think I needed to change. But I have reached a point of comfort with this is who I am. There are many like us, so shout out to all y'all. CHRIS: Oh yeah, by far the more common approach, I think. So specifically with the errors, I struggle a bit with it because what ends up happening is we are implicitly ignoring the errors. And if we're doing that, I would rather just sit around and have a conversation and be like, let's just explicitly ignore them. There's a button in the UI. We can ignore them. If this is not a real error, we can add it to the list of things that we do not report on. We can ignore that error. We can ignore it for a week and add a card to Trello that has a due date that says, "Hey, we got to work on this." But let's take that implicit indifference to that particular error mode of our application and make it explicit. Let's draw that line in the sand such that when I see a new error pop up, I'm like, oh, that seems like something I should do something about. I really want high signal-to-noise when I'm seeing errors coming. And so I'm willing to work for that. But it is a trade-off, and it does take effort. And it's noisy, especially browser extensions, and whatnot, just fighting the page. Facebook showed up one day. I don't know how Facebook got in there. Someone was browsing our website from within Facebook's browser, which I didn't know was a thing, but they had their own thing. And it fires a bunch of events, and Sentry was just like, let me slurp all of those up. Those seem fun. That was noisy. So we had to turn those off, but we explicitly turned them off. STEPH: I do like the approach that you're taking where it's one person, and then it's a rotating shift because I think that makes it more reasonable for someone's who's like, hey, this is going to be noisy for a week. And then you're going to look through these emails and check all these errors, and then either silence them because you don't think that they're interesting or mute them for now. Or if you're going to convert it into a ticket, set a due date, whatever the triage approach is going to be. But that feels more achievable versus inbox zero for life is just exhausting. But I feel like if you're doing it rotating week by week, that seems like a nice approach and also easier to keep it at inbox zero because that way, you are keeping up with all the errors. Because I agree; otherwise, what's the point of tracking all the errors if you're just going to ignore them? CHRIS: Yeah, definitely the rotating, I think, is critical. I think the other thing that's been critical specifically on the error front is we've had now a handful of meetings where we triage the backlog together, the backlog of errors. So like, what all is coming into Sentry? What's going on? And we go through the process of determining is this a real thing? Should we fix this? Should we ignore it? And we do that together so that it becomes not just one person's intuition about whether or not this is important or not or what the source of it might be but a shared intuition such that now any one of us, when it's our week, can ideally represent the team in that way and be like, never mind, never tell us about this again because it's very easy to silence things in Sentry that you would actually like to know about when they become real. But right now, we have this edge case that is an ignorable version. So trying to get there that's been fun. But yeah, once again, Sentry, that's one of the things on this person's list. There are ad hoc support tickets for our operations team. So anything that needs to happen on a user's behalf that currently needs a developer to console, let's funnel all of those to this one individual, respond to any new questions. So this is where that Slack handle will be useful. Check for any stuck jobs in Sidekiq. So is there anything that's been retrying for a while? Because it probably shouldn't. Maybe one or two retries is cool, but past that, something has gone wrong. And we should either get in there and fix it or just kill that job because it's never going to succeed, which is quite often the case but go in there and keep an eye on those and then look for anything. We're starting to use due dates within Trello, which is currently our project management system. We'll see. Someday we're definitely going to grow out of that. But for now, it's good enough and checking for anything that's overdue or coming up in the next week in terms of due dates and just making sure that we're being responsive to that. And so, I really like the idea of having this be a named set of things and a singular focus for one individual. Because again, that idea of like, if it's everybody's job, it's nobody's job. Or if it's nobody's job, then it's my job, and I don't want it to exclusively be my job. [chuckles] So I'm trying to make it not exclusively my job and to share the knowledge about it and make sure that these are skills that we all have and ideas and et cetera. But also, I would be fine to answer fewer questions in Slack each day. STEPH: I have to admit, as soon as you were telling me that you had established this role, I was quietly congratulating you on helping delegate some of these responsibilities to the team. Because like you said, you are then the person that takes on all these tasks. CHRIS: There's a laziness to that. Like, it's easy for me to just answer the questions. It's harder for me to put up a wall and say, "No, no, we have a process for this." And quite possibly, what's going to happen behind the scenes is that questions are going to come in to whoever is this point person. They're not going to know the answer. They're going to reach out to me, and then that conversation is still going to happen. But even by doing that now, now that person will see that answer, will understand the thinking or the background, the context that I have. And so it's that weird thing of like, it would be so much easier for me to just answer one question. But to answer all the questions, well, I can't do that. And so I'm working to try and do more of the delegation to try and hand things off when they're in a known state and to identify this sort of stuff so that the team broadly can be stronger and better able to support everyone else in the organization. So that's the dream. We'll see how it goes. STEPH: Yeah, I love that approach. I'm also thinking how interesting this role is because I'm imagining a mix between someone who is like the front point person at like an ER. So like, things are coming in, and they're in a tragic state and need help and need to be diagnosed. But at the same time, you mentioned they're going around. They're checking Sidekiq. They're looking at some email errors. So they're also that night shift guard that's walking around with a flashlight just poking in each room. So it seems like a very stressful and low-key role all at the same time, all mixed up into one week. That person probably needs a beer at the end of the week. CHRIS: There is a version of the story in my head that is...I wouldn't say this feels like a failure mode, but I would rather this not have to exist at all. I would rather things to be calmly humming along and not require a dedicated person each week to deal with the noise. I don't think that's realistic, certainly not as early on as we are in our organization. But I do wonder, is this a crutch? Is this something that we should be paying more attention to? And I know in teams that you and I have worked with in the past that has been a recognition of like, this is a crutch. But it's a costly crutch. Like, we're taking an entire...in our case, it's not requiring the entirety of a developer's week. They're able to do this pretty easily and then still get a bunch...like, 75% of their time is still feature work. But we're just choking down who's the person that will be responding to questions when they pop up so that fewer individuals are interrupted? But I have seen organizations where this definitely filled an entire week and spilled out more than. And then there was the recognition of that and the addition of another person that comes along and tries to fix stuff along the way as opposed to just responding. And so I want to make sure this isn't a band-aid but is, in fact, a necessary layer that we then try and shore up, you know, we should have fewer errors. That feels true. Okay, cool. Let's fix the bugs in the app. And these ad hoc things that an admin needs to have done can that be a button in the UI? Can they actually self-serve in those cases? And we're slowly moving towards those. Ideally, fewer jobs get stuck in Sidekiq. And so, my hope is that this isn't a job that gets harder and harder over time. It's a job that potentially, if we're being honest, probably stays about this hard. I don't think it's ever going to be just like, nope, nobody needs to do anything. The app just runs, and it's great. And it never has bugs. But that is a question in my mind as I start to embrace this thing of like one person is dedicated for a week to this. And if right now it's only 25% of their time, okay, that's probably fine. But if suddenly it's 50% of their time or 75% or 100% of their time for that whole week, that becomes too high of a bar in my mind. And I want to keep a close eye on it and make sure it's not trending in that direction. And I will be one of the people on the rotation. So I'll get to be in the trenches. STEPH: I appreciate all the thoughtfulness that you're putting into it. And I'm thinking back on a project where we had a similar rotation because we had an issue Slack channel. And so anytime there was an issue, then it would get posted in there. And before, it was going out to everyone, or there was one particular person that was always picking it up and then trying to delegate it to others as they needed to. But then we started a similar rotation. And one of the key benefits that I found from that is it signaled to the team, hey, this person might get pulled away. They can pick another ticket or two, but we need to give them lower priority tickets because there's a chance that they're going to get pulled away to work on something else. And that's okay, and we're going to plan for it. Versus without this role in mind, then you had people all taking on high priority tickets, but then someone had to be the one that's like, well, I'm going to punt on my high priority and feel stressed about the fact that I've got this other thing to deal with. But then, I didn't actually do the work that I planned for. So I feel like you're helping introduce calmness into the week, even if it is a stressful role. But then there's the goal that this becomes less of a stressful role, and if you see it trending in the opposite direction, then that's something to investigate. But I also feel like triage and communication is such an important part of being a developer that it also feels very relevant upskilling for the whole team to go through. So there's also that benefit of where this approach also empowers the rest of the team to also experiences, build empathy, look for additional fixes, and then also build these important skills. Overall, I really applaud your thoughtfulness. And I think it's a really good idea. And it will be interesting to see which direction that this role trends if it gets easier or if it's getting harder over time. CHRIS: Well, thanks. I appreciate that. And I'll certainly report back as we develop this but hopefully, it stays about where it is. That feels right. And I think I'll probably...that's one of those things that I will monitor. And if I feel it moving in the wrong direction, then step in and try and get it back to this space because this feels like a maintainable reasonable amount. And we shouldn't be fixing every bug and adding every button to the UI. That's just actually not how it works, unfortunately, would love to. That's not true. You shouldn't have every button in the UI. That's so many buttons. But broadly, I hope we can maintain roughly this, and I think identifying it and laying it out now I'm feeling good about having that structure. So yeah, we'll see how it goes. Will report back. But again, thank you for the kind words. With that tour of a bunch of different things, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeee!!!!! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Episode Notes Hopfield neural network Grace Hopper Alan Turing Ada Lovelace Donald Knuth Black Jack Game implementation by "Mel" The New Hacker's Dictionary by MIT press Cognitect open source initiative Structure and Interpretation of Computer Programs SICP Semantic Web Clojure literals The keep function in Clojure Sunshine coast in Queensland Australia Datomic Datascript Datalevin XTDB Datalog introduction on Wikipedia. Early Stuart Halloway talks about Datomic and Datalog

On this week's episode, Chris and Steph discuss testing webhooks, the challenges in replicating third-party data, and troubleshooting unexpected side effects. They also respond to a listener question about secrets management, touring popular solutions and discussing the trade-offs. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy webhook.site (https://webhook.site) git-secret (https://git-secret.io/) Datomic (https://www.datomic.com/) 1Password Secrets (https://1password.com/secrets/) Hashicorp Vault (https://www.vaultproject.io/) Heroku Secure Key (https://devcenter.heroku.com/articles/securekey)

Jakson 4 aiheena ovat tapahtumapohjaiset arkkitehtuurit. Tällä kertaa meillä mukana keskustelemassa aiheesta Sharetriben CTO Olli Vanhapiha. Keskusteluissa käymme läpi mitä tapahtumapohjainen arkkitehtuuri tarkoittaa ja minkälaista käytännön hyötyä siitä on devaajan työkalupakissa.Linkkejä Tapahtumapohjainen arkkitehtuuri: https://en.wikipedia.org/wiki/Event-driven_architectureChange Data Capture (CDC): https://en.wikipedia.org/wiki/Change_data_captureMartin Kleppmann: Designing Data Intensive Applications: https://dataintensive.net/Datomic: https://www.datomic.com/Kafka: https://kafka.apache.org/Debezium: https://debezium.io/Sharetribe: https://www.sharetribe.com/ Vieras Olli Vanhapiha: @vanhaol Juontajat Markus Hjort: @mhjortYrjö Kari-Koskinen: @ykarikos Seuraa podcastia https://koodiapinnanalla.fi/@KoodiPinnanAllaAnna palautetta podcastistaTule mukaan kehittämään Ykän ja Markuksen kanssa DIASia https://dias.fi/jobs.html

In this episode of Clean Coders, guest Micah Martin and Chuck discuss how he’s working to refactor the codebase into “clean code” and how he’s worked with apprentices in the past to teach them to write and refactor to clean code. Sponsors Cloud Academy | Get 50% off with promo code CODERS Audible.com CacheFly Host Charles Max Wood Guest Micah Martin Links Datomic Email Micah at micah@cleancoders.com, follow him on Twitter @slagyr Micah’s Website Check out Micah Martin’s and Robert “Uncle Bob” Martin’s “Java Case Study” video course

V novém díle pokračuje náš seriál o programovacích principech, a proto jsme si pozvali opravdu speciálního hosta Aleše Roubíčka z firmy TopMonks, který je mimo jiné odborníkem na reaktivní programování. Kromě základních principů a jeho využití v .NET, jsme zabrousili i do vod neprobádaných, takže se dozvíte něco o jazyce Clojure nebo databázi Datomic. A co vy? Vstoupili jste do reaktivního programování, nebo vám přijde spíš nepoužitelné? Těšíme se na vaše komentáře, přání i připomínky, které můžete psát na info@dotnetpodcast.cz. A pokud se vám díl líbil, budeme rádi, když nám koupíte kávu na https://www.buymeacoffee.com/dotnetcezet. Nově nás najdete i na Instagramu https://www.instagram.com/dotnetpodcastcz. Odkazy: - Clojure: https://clojure.org - Datomic: https://www.datomic.com/ - Reactive extensions: https://github.com/dotnet/reactive a http://reactivex.io/ - re-frame: https://github.com/day8/re-frame - polymer: https://github.com/polymer/lit-html - qlkit: https://github.com/forward-blockchain/qlkit - Channel 9 - Eric Mayer: https://channel9.msdn.com/Shows/Going+Deep/Bart-De-Smet-Rx-and-Cortana - Channel 9 - Going Deep show: https://channel9.msdn.com/Shows/Going+Deep - Alešovy články: https://www.rarous.net/weblog/2010/03/23/casovy-vypis-s-aktualizaci.html a https://www.rarous.net/weblog/2010/03/24/aktualizace-vypisu-na-strance-pomoci-rx.html - OpenSilver: https://www.opensilver.net/ Twittery atd.: - https://twitter.com/alesroubicek (Aleš) - https://twitter.com/deeedx (Martin) - https://twitter.com/madrvojt (Vojta) Pokud nechcete, aby vám unikla nová epizoda, odebírejte RSS: https://bit.ly/netcz-podcast-rss, sledujte nás na Twitteru: https://twitter.com/dotnetcezet nebo na Apple Podcasts a také na Spotify. Hudba pochází od Little Glass Men: https://freemusicarchive.org/music/Little_Glass_Men/

Datomic is a database system based on an append-only record keeping system. Datomic users can query the complete history of the database, and Datomic has ACID transactional support. The data within Datomic is stored in an underlying database system such as Cassandra or Postgres. The database is written in Clojure, and was co-authored by the The post Datomic Architecture with Marshall Thompson appeared first on Software Engineering Daily.

Datomic is a database system based on an append-only record keeping system. Datomic users can query the complete history of the database, and Datomic has ACID transactional support. The data within Datomic is stored in an underlying database system such as Cassandra or Postgres. The database is written in Clojure, and was co-authored by the The post Datomic Architecture with Marshall Thompson appeared first on Software Engineering Daily.

Datomic is a database system based on an append-only record keeping system. Datomic users can query the complete history of the database, and Datomic has ACID transactional support. The data within Datomic is stored in an underlying database system such as Cassandra or Postgres. The database is written in Clojure, and was co-authored by the The post Datomic Architecture with Marshall Thompson appeared first on Software Engineering Daily.

Datomic is a database system based on an append-only record keeping system. Datomic users can query the complete history of the database, and Datomic has ACID transactional support. The data within Datomic is stored in an underlying database system such as Cassandra or Postgres. The database is written in Clojure, and was co-authored by the creator of Clojure, Rich Hickey.Datomic has a unique architecture, with a component called a Peer, which gets embedded in an application backend. A Peer stores a subset of the database data in memory in this application backend, improving the latency of database queries that hit this caching layer.Marshall Thompson works at Cognitect, the company that supports and sells the Datomic database. Marshall joins the show to talk about the architecture of Datomic, its applications, and the life of a query against the database.We're looking for new show ideas, so if you have any interesting topics, please feel free to reach out via twitter or email us at  jeff@softwareengineeringdaily.com

Wherein we discuss a sweeping array of topics - the history of Cognitect - the story of Spec - past and future of Datomic - maybe Clojure isn't quite dead yet Phew! Thanks very much to Stu for giving his time to us and the community and for his openness to both ours and community questions

Show Notes: 01:11 - Doing Dumb Stuff aka “Throwaway Projects” 06:06 - Combatting Burnout 10:01 - Dumb Projects That Pay You Back 17:00 - Brainstorming and Abstraction 25:19 - chillestmonkey.com 20:19 - “The Iron Triangle”: Creativity, Accomplishment, and Learning Resources: React Native and Chill: A tale of stupid made fast by Charles Lowell Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 59. We're getting up there, 59. That's like, I don't know, it's not a milestone but it's something. ROBERT: It's like one away from 60. CHARLES: Yeah, it is. It's past middle age. It's like elderly. ROBERT: Start thinking about retirement. CHARLES: Yeah, exactly. JEFFREY: These are our golden years. [Laughter] CHARLES: Welcome to the golden years. ROBERT: All right. Possibly, we need to go and watch the Golden Girls. [Laughter] CHARLES: Actually, I think it was only five or six episodes, maybe 10 episodes, we were singing The Golden Girls theme so it all comes back around. We're here with a very special guest and that guest is nobody. It's just folks from The Frontside -- JEFFREY: I was hoping you would say it was Betty White. [Laughter] CHARLES: We're going to fly it solo or like tri-lo or like trio. ROBERT: Trello? CHARLES: Trello. I, of course, am Charles Lowell. With me is Jeffrey Cherewaty and Robert DeLuca. Hey, guys. JEFFREY & ROBERT: Hey, what's up? CHARLES: We were kicking ideas around and something that's been kind of percolating around the offices is a theme for 2017 is doing dumb stuff, just stuff that has no apparent value but that you can learn from. I think, we each have a bunch of these experiences where we've done something a very little import that ends up being really, really helpful, either both in the short-term and the near-term. JEFFREY: And who knows, maybe this episode will turn out the same way. ROBERT: Oh, how meta. This could become a black mirror episode. I'm start to questioning my values. CHARLES: I know for me, I recently did some explorations into React Native, which I found to be very edifying. I could obviously talk about that experience quite a bit I did on a blog post but I'm curious, if you guys recently had something that was a throw away, something that you did that wouldn't really matter if it had come into existence or it didn't but it's just so happens that in this thread of reality, it did. ROBERT: You know, I have. It's always been centered around the impagination library that we wrote here. I was always kind of intimidated by impagination for some reason because it was this big library that I didn't necessarily understand. I was like, "You know what? I'm just going to go for it. I'm going to go do something dumb with it," and then I just decided to implement the most useless infinite scroll. It solved absolutely nothing and as you're paginating through 500 records of robots from Faker, I sat down and spent six days and wrote some code and implemented it React Native and it was actually the most informative and fun thing I've ever did. I don't feel tied to it. CHARLES: Yeah, so what kind of inspired to do that? Because usually, it feels like there's this pressure to ship something. Ship something is like just go build something but the idea is that you're going to build something that people actually might use. ROBERT: Yeah, I always had that idea. Maybe you can think about it as like feeling getting cornered, like the pressure of shipping sort of pushing me into a corner. Then eventually, I just kind of lash it out like, "No, screw this. I'm out." I'm going to go do something that's not even useful. I don't care. I'm not going to try and support people or make it to something that other people can use. If that is what falls out of this, that's cool but I'm going to totally sidestep and this needs to be something that other people can use. Sometimes, when I go to build a project, I start thinking, "This is going to be in my GitHub public profile. What if somebody comes and finds it? What are they going to think about my code?" And I just shed all of that fear away, then what happened is I learned a ton. After that experience, I was like, "Whoa. This is massively valuable." CHARLES: Yeah, like hearing you talk about it makes me think about one time I went to a Picasso art exhibit and they had all these sketches that he'd made just in pencil from when he was younger and they were in studies. I guess, apparently artists do this a lot where it was like just a goat's leg. Or some old man's nose. You know, just in pencil or charcoal and these are little tropes that he later integrated into all of his painting -- ROBERT: That is an amazing way to put. JEFFREY: It's funny. When you see engineering tutorials are like, "This is how you learn to make software." A lot of times that is the way they're structured it is around studies. Like, "Make this little tiny thing that by itself is worthless but can be part of a greater whole." ROBERT: Yeah, take that impagination infinite scroll thing, I think three months later, it turned into a full on talk about co-chairing between React and React Native but it started with this dumb little project that I decided, "If I don't finish it, nothing bad happens. It just kind of sits there and rots." I feel no guilt. No pressure. JEFFREY: Would you say that was part of your blue period? [Laughter] CHARLES: Yeah, I like you [inaudible] point to like ship it. It's like we have a culture of ship it or don't. In any way, it's entirely up to you. ROBERT: I kind of thought to think about it as the extreme of ship it. Literally, just ship it even if it doesn't work. CHARLES: Right, ship it even if it's wrong. ROBERT: The other thing that I figured out was who is to determine what's wrong or right. I figured out that no one like I figured that out and I choose if it's wrong or right. CHARLES: Right, and it's like whether I learned something or whether I didn't or whether I get to be the arbiter of what I get out of this experience. ROBERT: And you almost always learn something. Always. CHARLES: Yeah, you definitely do. I think it can pay off, both in the short term and in the long term too. I know with my recent experience, I was feeling extreme burnout. I don't know... You feel like the code that you're working on or the things that you're doing have become a burden. I guess that's kind of to your point, Rob like when you are building something that it creates users. It creates code. It creates maintenance cost. It creates contributors. There's all this mass and inertia and momentum that are for it and that can be great if you own something massive, you can have a lot of momentum and it can be extremely energizing. But it can also be a burden, if it's something that you have to carry and you feel obligated to carry. ROBERT: Yeah and when you have those huge successful projects, things that come to mind like Ember or React or Babel or things like that, those are awesome. But I was always experiencing that responsibility with things where I had big plans for them but nobody knew that just by looking at the projects like it was still very much a work in progress. But I felt that feeling in my gut. CHARLES: Right and that mass and that inertia can come completely and totally from an internal source. It's both important for the project to be like these throwaway projects to be completely and totally free from all attachment, especially from your own dreams and your own ego and things like that. ROBERT: And when I learn to let go, that's when I learn that I'll learn. [Laughter] ROBERT: I'm going to learn-learn. CHARLES: I guess, the kind of greater point that I was making is that when you are able to approach a project like that, then it can be a really intense cure for burnout because you are just allowing yourself to create, you're allowing yourself to feel creative and actually deliver something whose success parameters you define entirely. I think, Brandon actually talked about this almost like two years ago with that robot. That project that he did where he was kind of in a similar situation and he really, really needed to do something that was not a web app. I think there was a series of talks that came out of it but that was primarily for the burnout case. ROBERT: I think I can agree with that. I might have been in the similar situation where I was starting to think about the feeling cornered. It was maybe because of burnout. CHARLES: Maybe those are one of the same. ROBERT: Because I felt like I wasn't producing anything and I was like, "I should be doing this stuff but I feel like I should be but I'm not," and the things that I'm doing aren't great enough because the things that I have done in the past and that's a bad way to think about it. JEFFREY: There's something so refreshing about being able to switch contexts of I've been working on this same app for a few months and doing kind of similar tasks over and over and that's such a nice way to create at really recharge like, "I'm just going to do something completely different and see how that feels." ROBERT: Yeah, I've gotten really good at writing computer properties but I want to write something else. JEFFREY: Just like anyone who does a lot of Ember, they're great at computer properties. CHARLES: It really is the equivalent of throwing a dart into a map. If you're feeling burnt out and you're looking for what to do, There are so many things like you actually aren't cornered. You have the universe of possibilities and the dumber the better. Choose something random that you can do in five minutes, do something random that you can do in an hour or a week or something like that so it has that payoff for being an answer to burnout. I've experienced where these types of activities come back and pay you back down the road. ROBERT: It doesn't have to solve a problem. I was always looking for the next project that I could build that would solve a problem. I always felt like I needed to solve a problem and I was just looking at it backwards. You should also be looking at things like it solve a problem. That's cool. But why not take a piece of technology and like, "How can I bend this? What can I do?" And exercise the different corners of this framework or do just something that's totally useless. CHARLES: I remember actually, that was something that Ryan, when he first started coming to the Ember meetups, he was asking questions about it and I think he was coming from Backbone and was -- ROBERT: Just Ryan from [inaudible]? CHARLES: Yeah, [Ryan Ralph?] from [inaudible] and he was asking questions and like, "Yeah, it's pretty good. The only disadvantage right now is you can't have multiple apps inside of a single tab," so literally he comes back the next month with a talk of how I embedded more than one app in a tab and here's what I had to do it. First thing was like, "Let's see how does it break." Let me prod at it and poke it in and just see what happens. I know I had an experience recently where I had done something really, really stupid with Amazon Lambda and I just very recently came back like the fact that I had actually gone through the process of just deploying a very dumb -- ROBERT: How dumb, Charles? Tell me how dumb? CHARLES: Remember when I was going on and on about badges and how we needed to have our own custom badges. I kept on trying to get everybody excited -- JEFFREY: I don't know that we need that. CHARLES: That was pretty much the response that I got from, I think in a poll of nine out of ten. It was 9.11 or something like that. ROBERT: -- That was cool but -- CHARLES: It was cool but no one wanted to put it anywhere. The badge was just a static SPG that was served on top of the Amazon Lambda but as part of that, I had to go through all of the steps through actually getting it to deploy. While that thing was completely useless and it was thrown away, that knowledge ended up becoming useful almost a year later or maybe six months later, something like that. I feel like it was sunny so it had to have been at least six months ago and so -- ROBERT: You know, that it's always sunny here. CHARLES: Uhh... Ish. I mean -- JEFFREY: It's not Philadelphia. ROBERT: I was trying to work somewhere. CHARLES: It was warm but it's a practice that often has long term payoffs. I guess that's just the learning aspect of it, the fact that you're going to learn something. ROBERT: The thing I want to stress here is you don't have to go into it expecting that. CHARLES: Yes, that actually is critical. ROBERT: Yeah, that absolutely is critical because then if you expect that, then the problem with all the things for me started with setting expectations. It was always I had expectations. You take them and throw them out. Toss those things out the window. CHARLES: Zero expectations. JEFFREY: Really, it's an adjustment of your expectations to where at any point, you can say, "No, I'm kind of done with this. I learned something but it's not going to turn into anything," versus the expectation of, "I'm going to make something amazing that thousands of people are going to use." ROBERT: Yeah, that's the way I always start out as like, "Here we go." CHARLES: "I'm going to take over the world." [Laughter] ROBERT: "I'm writing another JavaScript frameworks. Next step, world domination." CHARLES: Yeah, I know it's absolutely important to make sure that if this thing that you're doing just cease to exist, you wouldn't feel good or bad. It wouldn't make any difference. Very Zen, I think. Some people try to approach every aspect of their life that way. I'm not sure if that's healthy. ROBERT: That's another podcast. [Laughter] CHARLES: But I certainly think it is, if you at least allocate a portion of your projects to be that way. I think that applies to any creative endeavor that you try to undertake. Jeffrey, you had some actually some non-programming examples that you were talking about earlier. ROBERT: It ties in nicely to the Picasso thing. JEFFREY: Yeah, actually I was I'm moving right now to a new apartment and I have no architectural background at all but I am comfortable with vector graphics in Illustrator and doing things mathematically precisely in there. I do have a little bit of problem solving that comes out of this. It's not purely exploration but I've been like, "I'm moving to this new place. These are the pieces of furniture I have. How can I rearrange them and play and --" ROBERT: Did you actually set the scale correctly to your -- JEFFREY: Oh, absolutely. ROBERT: Oh, that's amazing. [Laughter] JEFFREY: --Otherwise it's worthless. ROBERT: This is a whole new world. This is awesome. CHARLES: -- Like there's an atomic gauge on the couch. [Laughter] JEFFREY: My couch is six feet, three inches and 24 angstroms. I have not reached that level -- [Laughter] ROBERT: Does Illustrator have that level precision? JEFFREY: It can go pretty far. But yeah, it's just an opportunity to play around and like in a situation where actually moving those pieces of furniture in 30 different ways would be a pain and just unrealistic but thinking about it more in the abstract and just being able to play with it at a scale that's playable with, turns it into something fun and creative. CHARLES: Yeah, I guess that's a luxury that we have, I guess in the modern era of being able to simulate so much and be able to apply this practice of total creativity in a consequence free zone where people might not have been able to do so before. Before the advent of computer-aided design, I don't think that would've been a possibility. ROBERT: There will be a lot of manual hand-drawing and sketches and stuff. JEFFREY: And now software it's at point where -- CHARLES: Or you just get your children to do it. [Laughter] CHARLES: "Move it over there." You guys are sweating but man, I'm feeling really creative. JEFFREY: Yeah, really making stuff happen here. But software has kind of reach the point where we have similar abstractions there to be able to do it, move pieces around like that. Maybe not as fluidly as I'm going to move all these squares around in Illustrator but we're at the point where we can kind of plug in pieces and see how it performs and plug in another piece and see how that performs in a way that feels maybe more creative and less scientific than getting lower down in the code. ROBERT: Honestly, I wonder if this is where React began because the idea of rerendering the entire dom every time was more performant like you just throw something at the wall. See if it sticks. I don't know but -- CHARLES: Yeah, you have to wonder. I'm actually become surprised at the origin story is not more widely known. ROBERT: Yeah, I also don't really know it. I kind of heard of it like -- CHARLES: I remember hearing about it the first time I was like, "That's crazy." ROBERT: Yeah, that sounds like it'd be massive performance hit. That sounds really slow. Why would you rerender everything? CHARLES: Right but then again, it's always getting into pre-[inaudible] optimization. We always fall down these paths of optimizing in our heads. Of course, we want to do incremental rendering. Why? Because it's faster but nobody's actually measured then realized that it's actually the dom that's slow. ROBERT: It's like opening up your world to this. It's just like you explore everything. JEFFREY: That's another thing we can take from design thinking and the philosophies around the design field that maybe aren't as recognized in engineering is the idea of simply brainstorming of being open to dozens of ideas, trying out dozens of ideas and seeing what feels right and being able to have so many ideas that you can throw most of them away. In software, so many times we get to the point where maybe we'll have two or three ideas but none of them are worth throwing away. We feel uncomfortable throwing out any work. CHARLES: Part of it is you were so busy. You have so much invested in your current track that it's very easy because your current track is on Rails. It goes forward, there's clearly a path forward and to hop off of those Rails, it require some sort of energy and are you going to be leaping into like a chasm? I don't know. ROBERT: Or in Jeffrey's case, if your computer dies and you're forced to think without a computer -- JEFFREY: That actually happened the other day. CHARLES: That was amazing. That was worth a story. JEFFREY: I forgot to bring my charger to the office so I have one of those new [inaudible] MacBook with the USB-C charger and we didn't have any backups in the office. I was hacking along on some configuration devops kind of stuff and just kept running experiments and eventually my battery died. Then I was forced to whiteboard out by what I was doing and I came way over to conclusion that I would have ever come to, if I had just been sitting on my computer the whole time. It was another case of where I needed that abstraction away from looking at the code to be able to rearrange the blocks in a way that made sense. ROBERT: Pull yourself out of the [inaudible]. JEFFREY: Yeah, definitely. CHARLES: I really like that idea. Again, I'm not being too familiar with the way that the design world works. Is that kind of like a modus operandis to have too many ideas that you can throw a bunch of them away at any given point? ROBERT: Where you start stealing pieces from all of them and you make one master design. In my digital design class -- shout out to Miss McDaniel -- she would always make us start off -- JEFFREY: Check for that in the show notes. [Laughter] CHARLES: -- She would always make us start off in a sketch book and I remember because I'm not an artist at all. If you know me, I draw even the worst stick figures: my arms and stick figures don't line up. That's how bad it is. She would always make us start off in a sketch book and it drove me nuts. But after doing it for two months, I finally realized the value because she would make us come up with five or six different design concepts. Then after I did the process a couple more times, I realized, "This actually has a ton of value." I sort of picking things from one of the other. It makes you think outside the box. The first couple of ones that I would turn into her she would be like, "You actually have three of almost the same design here. You need to think more outside the box. Think of something that's completely different." Seriously, it's just like you're throwing things at the wall. Whatever freestyle off top of the brain and just let it go. JEFFREY: I'm thinking of a concept side of exercise where maybe you're playing around with layouts for selling a magazine or something and you'll sketch them out and you'll sketch out maybe a few dozen of them but you don't get into the nitty-gritty details. You do it at a very-low fidelity where it's just pencil and some boxes and rearranging those boxes and maybe mark what that box is but you don't worry about the details of that box until you mix and match like, "That layout is not going to be great. This layout seems like it might be along the right track. I like this piece of this one. Let's combine them and make something completely different." Then once you have that high-level view, that make sense to you and you've gone through lots and lots of iterations, then you can start honing in on the high-fidelity details. CHARLES: This conversation makes me feel like there's definite poverty in our processes as software developers in the sense that what I'm hearing is that these things are just taken for granted, that these are the activities that you're going to be doing as part of design and what are we doing if not design. Each of us has these experiences that are kind of these one off things where we actually experience this creative space. It seemed very special and it seemed revelatory but really, it almost sounds like you need to make sure that it's something that you're revisiting again and again and you're doing it as integrated with your work. But I feel like it would be hard to pitch that -- JEFFREY: That's not understood to be part of the software design process. CHARLES: Maybe that's a little bit of what happens when we've put together our design documents -- ROBERT: Yeah, it just occurred to me like looking back through my history of how I landed to be a software developer, I actually wanted to be a designer first. That's why I was in digital design and stuff. I rejected design so much because I thought it was super... What's the word I'm looking for? Flighty? CHARLES: Wishy-washy? Non-committal? [Laughter] ROBERT: Anybody could walk in and say, "I don't like that design. It looks ugly. It doesn't look good," and I thought I was going to programming because it was more black and white like, "This is the right solution. That's not the right solution." As I've worked my way into my career, I actually realized they're actually really similar because you're designing software and software is abstract. As much as you want to try to think about as it's not, you start to develop this mental picture of the programs that you're developing. You're designing these things. It's just a different form of design and design is problem solving. CHARLES: In digital design, it's not artwork. It is measured by some quality. It's just hard to put your finger on but there is some kind of external measure of, "Does this fit the purpose for me, which it was made?" JEFFREY: "Does this solve the problem?" Usually, there are some expectations just like there are software of, "There's been best practices established. Did you stick to those best practices? And if you didn't, Why not?" Because sometimes there is a good reason to break those best practices. CHARLES: Right. I wonder if it would be interesting at integrating into our process like what we think of as the ideal pull request or issue reporting or design document have. It kind of similar to some of the RFC processes out there. It's like, "What are some crazy alternatives?" Not just any alternative -- JEFFREY: I don't just need viable alternative. CHARLES: Yeah, I don't need viable. Give me the in-viable. Give me the ones that are like, "What crack are you smoking? Oh, wait a second... Hmmm..." [Laughter] ROBERT: "All right. Here we go. I got it. It's got to be powered by nuclear --" No. [Laughter] CHARLES: Curious. I'm very, very, very curious. ROBERT: Let the curiosity fly. JEFFREY: Charles, do you had a blog post recently about a dumb project you built. Would you tell us about that? CHARLES: Sometimes, it gets stressful around here. Sometimes it gets stressful in life. Sometimes you just feel stress and there are a lot of things you can do to deal with it. Everybody has their coping mechanisms. For me, one of my secret weapon coping mechanisms -- ROBERT: Not a secret anymore. CHARLES: It's not secret anymore. [Laughter] CHARLES: This also will be in the show notes but I'll go ahead and say it right now is ChillestMonkey.com. If you need to enhance your chill, you can just go to ChillestMonkey.com and I guarantee you will not be disappointed. You will feel instantaneously better. I was in the point where I was feeling a lot of stress. I don't know exactly how it came up but I was actually with Stephanie and she was like, "Charles, you just got to do something stupid. You just got to do exactly what it is that we've been talking about on this podcast. You've got to just do it and you've got to do it fast and you've got to not look back and look forward." I was like, "Oh, my God. You're right." That planted the seed in my brain but then, I think it was the next day, I was talking about ChillestMonkey.com -- go check it out. You can pause the podcast right now and go have a look at it. It's really awesome -- And I was showing it to everybody and then I think Rob were like, "Oh, my goodness. We've got to have this on the Apple TV." ROBERT: It just lands itself perfectly. CHARLES: Yeah, I was like, "Yes. Absolutely we need it on the Apple TV. We need it on the Apple Watch. I need this on my iPhone," so right that minute, I hearken back to the conversation I had with Stephanie and I was like. "This is it. This is perfect scope." I have been looking to build something in React Native. Something that I can just completely and totally throw away, something that fits in a small time box and I also have this opportunity to build this thing that I really need but if it doesn't work out, it's fantastic. I went home. I think that was that very night and started hacking on React Native and took the Chillest Monkey, then put it first into an npm package. You can include it in any React Native application. Then once that was accomplished, I went out and checked the support for Apple TV had dropped literally ten days before, maybe even less. I was like, "It's a sign and this has got to happen." It was a little bit of a slog but we were able to get it up on our Apple TV and with a remote and feel that glassy touchpad, move it over to the Chillest Monkey and open it up and just see those wisps of hair and those tranquil eyes up there and six feet across. It was just such a great feeling. But it was something that was accomplishable within a day or two. I don't think it was more than that but it serve the purpose that I was able to learn a lot about React Native. I was able to learn about packaging, shared components. ROBERT: Actually, I remember we fought about flex box and what not for a little while. CHARLES: Yeah, that's right. I learned about laying out images and kind of the best practice around there. Also, I think this is important as I got to experience a win and it felt good to be able to experience that win. It felt like if I hadn't experienced it, it probably wouldn't have been that big of a deal. But the fact that I was able, it was a low-hanging target but it felt like a big-hanging target. It's hard because there's no such thing as a free lunch but kind of there is, when it comes to little projects like this because when you see something totally stupid come together and it works exactly you wanted it to work, then it feels like you've accomplished something major. I don't know if that's some sort of brain hackery or some sort of life hack or what but that was extremely good for my internal morale. JEFFREY: This is an example of a project where, maybe you didn't get as much creative juices flowing out of it. CHARLES: No. JEFFREY: But you've got a high accomplishment and learning value, which I guess are all, I call that the iron triangle of building dumb stuff. [Laughter] JEFFREY: You can have two of the three. CHARLES: On one side is creativity, on the other side is what? JEFFREY: Accomplishment. CHARLES: -- Is accomplishment, just shipping it and then on the third is time? It's the iron sticks -- [Laughter] JEFFREY: The third side was learning. That's creativity, accomplishment and learning. You can't have all three, sorry. It doesn't work that way. CHARLES: It doesn't work that way. Okay. [Laughter] ROBERT: Then you'll take on a big project, that's how you'll get all three. CHARLES: I like that. JEFFREY: In a particular project where you're having to throw tons of ideas at the wall, You're probably going to be learning, you're probably have to be very creative but your chance of shipping here is much lower. CHARLES: It's almost a detriment. ROBERT: Yeah. CHARLES: Whereas in this case it was take something that is easily accomplishable and accomplished it. JEFFREY: And you learned something from it. CHARLES: You learn and you accomplish but you're not particularly creative. But it's still a feather in your cap. I like that. It's a good way to categorize it. ROBERT: And the accomplishment is how you define it. In this case, you actually finished this project. CHARLES: Yeah. I finished it. We have it on Apple TV. ROBERT: Yeah, and like you said, you have to do that. For me, after I did a couple of these things, actually what I just do, a newsletter has come in and somebody was like, "Look at this new thing," and I'm just going to put it off to the side and then eventually, I'll stack two or three of those things together and decide, "We're going to take all three of these things, we're going to put them all together and see what happens," and that's how GraphQL and dove in to create React app. CHARLES: That's actually a good idea. I like the random newsletter driven development -- [Laughter] CHARLES: -- You're like, "I'm going to subscribe to this newsletter. I'm going to pick one thing from each week and after I have five things, I'm going to build something with those things. ROBERT: Wait. I have a dumb app idea. We could make this just a random app idea generator. It takes ten packages and you see like -- JEFFREY: A bunch are required to build the Hackernews clone. Isn't that a classic newsletter driven development? ROBERT: Or the Reddit clone? This feel like that's the React thing -- the Reddit clone. CHARLES: Yeah. I think it's more like Frankenstein driven development like you've got GraphQL, Vue.js and I don't know... Datomic. JEFFREY: Like a GRD stack -- CHARLES: No, like a rando stack. [Laughter] CHARLES: Rando.js, that would actually be a good -- ROBERT: You hear it first. It's our new JavaScript framework. CHARLES: A stack generator. JEFFREY: It's going to be a high on learning and not so much on accomplishment. ROBERT: You won't ship anything but damn will you learn? Every week! CHARLES: What is an example then? We've talked about the one where the accomplishment. I'm wondering if there's an affinity between those sides of the triangle. What would be an example of a project that was high on creativity, low on shipping? How do you approach projects like that and then make it okay to fail? Because I think, one of the things that was great about the Chillest Monkey Native was I did get to ship it. It wasn't much but it felt great. How do you prepare yourself for those projects which are high on creativity that you're not going to ship? What is one of those look like? JEFFREY: I think those kinds of projects are usually tend to be ones where you're more comfortable with the tools already so that you do have the space to be creative and you're not having to fight against, "I don't know how to do this." The learning is already been done, at least to a point to where you're comfortable enough to go, to feel loose and creative and be able to brainstorm without having to bump up against walls over and over. CHARLES: I guess, tender love is a master of that, where it's really has a deep knowledge of Ruby and systems programming and does some fun and creative. Do I say zany? ROBERT: The Ember example of this, I think it's Alex Matchneer. Matchneer? CHARLES: Matchneer, yeah. ROBERT: Sorry, I cannot pronounce names. The Photoshops, I mean those aren't exactly -- [Laughter] ROBERT: -- Those aren't exactly programming related but -- JEFFREY: High on creativity and accomplishment, low on learning. [Laughter] ROBERT: And then the Ember Twiddle is the one that I laughed out and I was like, "Can React router do this?" CHARLES: I don't actually see that one. ROBERT: Actually, it was broken when I went to look at it but the responses were hilarious. They're like, "Actually, no. I'm happy. I can't." [Laughter] ROBERT: But he always has the Twiddle and he's like, "What about this? It's like the programming equivalent of his Photoshops. [Laughter] JEFFREY: I'm wondering if there are particular, out of those kind of three different types of dumb projects that we've identified. If there are particular types that people gravitate toward like I know that I am higher on the, "Just go, do something creative with tools you already know side," versus, "I enjoy learning," but I'm more likely to want to accomplishment up things and be loosen in my creativity. I'm wondering what the breakdown is among different engineers of those different profiles. ROBERT: It's quite interesting and I wouldn't think of myself as an explorer but I feel like I'm driven by FOMO -- fear of missing out. That's where this comes from for me. All this technology that I hear so many good things about that I haven't even done anything with. I don't even have Hello, World or anything. That's usually where I start picking things up the shelf and I'm like, "What if I did redux, Vue.js and whatever else. Let's see if we can make all these things work together." CHARLES: Do you feel like you can, at least always be kind of touching? ROBERT: Yeah. CHARLES: Pinging different areas of the ecosystem? ROBERT: Yeah, I really like to see what they're doing because they all have different takes on things. I really like what Chris Freeman said, he's like, "I feel like programming is just gaining experience points." Like it's video games where you're just going through and you're getting experience points with different things. That's kind of the approach that I've been taken for the past five months. Since I discovered this, this is just like, "Oh, that look shiny." Maybe that's also driven because of our JavaScript-type cycle or whatever you want to call it, where something new is always coming out. Somebody is always reinventing the wheel. CHARLES: Whenever I see a cool demo or whenever I read a really provocative blog post that guides my exploration a lot, which I guess those things usually are extensions of some activity like what we're talking about that someone did. A lot of really good blog posts are just like, "I've been doing this stuff for five years and I have gained an absurd level of expertise on it. Let me take you to school." I definitely love those but a lot of it is like, "Look at this cool thing that I've done." Without talking about murdering names, what is it? Hakim...? Gosh, I can't remember his last name. The guy who does Slides. Some of his demos for CSS and JavaScript animations back in the day we're just like, "Woah, someone has just revealed a huge power source," and so I want to go do it. But most of that came from him just having to play. ROBERT: Jeffrey, you've actually got my brain ticking here. I'm thinking about where people fall in applying this like just go do something dumb and it doesn't have to mean anything. This makes me starting to think, "Maybe I need to go do something really creative in Ember." JEFFREY: It's making me think that I need to go do some learning -- [Laughter] JEFFREY: -- Just try some new stuff so I have new tools to play with. ROBERT: Because that's the whole purpose of this, right? I just recognized that I am not doing very creative things and the tool sets that I am comfortable with. CHARLES: Yeah, it is harmonious. The more learning projects you do, you acquire tools and then with familiarity with those tools, engenders creativity so you can see how the process feeds in to itself. ROBERT: Now, I'm going to build something creative. CHARLES: All right everybody. There you have it. Go out, build something useless, build something creative, build something that will help you learn and acquire new tools, new techniques and take you [inaudible] and do it quickly.

A roving tour of Datomic with the pioneering Mr Stuttaford. For detailed show notes please check the web site https://defn.audio/2016/08/10/episode-7-datomic-with-robert-stuttaford/