Podcasts about dsls

Python has many string formatting styles which have been added to the language over the years. Early Python used the % operator to injected formatted values into strings. And we have string.format() which offers several powerful styles. Both were verbose and indirect, so f-strings were added in Python 3.6. But these f-strings lacked security features (think little bobby tables) and they manifested as fully-formed strings to runtime code. Today we talk about the next evolution of Python string formatting for advanced use-cases (SQL, HTML, DSLs, etc): t-strings. We have Paul Everitt, David Peck, and Jim Baker on the show to introduce this upcoming new language feature. Episode sponsors Posit Auth0 Talk Python Courses Links from the show Guests: Paul on X: @paulweveritt Paul on Mastodon: @pauleveritt@fosstodon.org Dave Peck on Github: github.com Jim Baker: github.com PEP 750 – Template Strings: peps.python.org tdom - Placeholder for future library on PyPI using PEP 750 t-strings: github.com PEP 750: Tag Strings For Writing Domain-Specific Languages: discuss.python.org How To Teach This: peps.python.org PEP 501 – General purpose template literal strings: peps.python.org Python's new t-strings: davepeck.org PyFormat: Using % and .format() for great good!: pyformat.info flynt: A tool to automatically convert old string literal formatting to f-strings: github.com Examples of using t-strings as defined in PEP 750: github.com htm.py issue: github.com Exploits of a Mom: xkcd.com pyparsing: github.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to Talk Python on YouTube: youtube.com Talk Python on Bluesky: @talkpython.fm at bsky.app Talk Python on Mastodon: talkpython Michael on Bluesky: @mkennedy.codes at bsky.app Michael on Mastodon: mkennedy

Did you know that adding a simple Code Interpreter took o3 from 9.2% to 32% on FrontierMath? The Latent Space crew is hosting a hack night Feb 11th in San Francisco focused on CodeGen use cases, co-hosted with E2B and Edge AGI; watch E2B's new workshop and RSVP here!We're happy to announce that today's guest Samuel Colvin will be teaching his very first Pydantic AI workshop at the newly announced AI Engineer NYC Workshops day on Feb 22! 25 tickets left.If you're a Python developer, it's very likely that you've heard of Pydantic. Every month, it's downloaded >300,000,000 times, making it one of the top 25 PyPi packages. OpenAI uses it in its SDK for structured outputs, it's at the core of FastAPI, and if you've followed our AI Engineer Summit conference, Jason Liu of Instructor has given two great talks about it: “Pydantic is all you need” and “Pydantic is STILL all you need”. Now, Samuel Colvin has raised $17M from Sequoia to turn Pydantic from an open source project to a full stack AI engineer platform with Logfire, their observability platform, and PydanticAI, their new agent framework.Logfire: bringing OTEL to AIOpenTelemetry recently merged Semantic Conventions for LLM workloads which provides standard definitions to track performance like gen_ai.server.time_per_output_token. In Sam's view at least 80% of new apps being built today have some sort of LLM usage in them, and just like web observability platform got replaced by cloud-first ones in the 2010s, Logfire wants to do the same for AI-first apps. If you're interested in the technical details, Logfire migrated away from Clickhouse to Datafusion for their backend. We spent some time on the importance of picking open source tools you understand and that you can actually contribute to upstream, rather than the more popular ones; listen in ~43:19 for that part.Agents are the killer app for graphsPydantic AI is their attempt at taking a lot of the learnings that LangChain and the other early LLM frameworks had, and putting Python best practices into it. At an API level, it's very similar to the other libraries: you can call LLMs, create agents, do function calling, do evals, etc.They define an “Agent” as a container with a system prompt, tools, structured result, and an LLM. Under the hood, each Agent is now a graph of function calls that can orchestrate multi-step LLM interactions. You can start simple, then move toward fully dynamic graph-based control flow if needed.“We were compelled enough by graphs once we got them right that our agent implementation [...] is now actually a graph under the hood.”Why Graphs?* More natural for complex or multi-step AI workflows.* Easy to visualize and debug with mermaid diagrams.* Potential for distributed runs, or “waiting days” between steps in certain flows.In parallel, you see folks like Emil Eifrem of Neo4j talk about GraphRAG as another place where graphs fit really well in the AI stack, so it might be time for more people to take them seriously.Full Video EpisodeLike and subscribe!Chapters* 00:00:00 Introductions* 00:00:24 Origins of Pydantic* 00:05:28 Pydantic's AI moment * 00:08:05 Why build a new agents framework?* 00:10:17 Overview of Pydantic AI* 00:12:33 Becoming a believer in graphs* 00:24:02 God Model vs Compound AI Systems* 00:28:13 Why not build an LLM gateway?* 00:31:39 Programmatic testing vs live evals* 00:35:51 Using OpenTelemetry for AI traces* 00:43:19 Why they don't use Clickhouse* 00:48:34 Competing in the observability space* 00:50:41 Licensing decisions for Pydantic and LogFire* 00:51:48 Building Pydantic.run* 00:55:24 Marimo and the future of Jupyter notebooks* 00:57:44 London's AI sceneShow Notes* Sam Colvin* Pydantic* Pydantic AI* Logfire* Pydantic.run* Zod* E2B* Arize* Langsmith* Marimo* Prefect* GLA (Google Generative Language API)* OpenTelemetry* Jason Liu* Sebastian Ramirez* Bogomil Balkansky* Hood Chatham* Jeremy Howard* Andrew LambTranscriptAlessio [00:00:03]: Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:12]: Good morning. And today we're very excited to have Sam Colvin join us from Pydantic AI. Welcome. Sam, I heard that Pydantic is all we need. Is that true?Samuel [00:00:24]: I would say you might need Pydantic AI and Logfire as well, but it gets you a long way, that's for sure.Swyx [00:00:29]: Pydantic almost basically needs no introduction. It's almost 300 million downloads in December. And obviously, in the previous podcasts and discussions we've had with Jason Liu, he's been a big fan and promoter of Pydantic and AI.Samuel [00:00:45]: Yeah, it's weird because obviously I didn't create Pydantic originally for uses in AI, it predates LLMs. But it's like we've been lucky that it's been picked up by that community and used so widely.Swyx [00:00:58]: Actually, maybe we'll hear it. Right from you, what is Pydantic and maybe a little bit of the origin story?Samuel [00:01:04]: The best name for it, which is not quite right, is a validation library. And we get some tension around that name because it doesn't just do validation, it will do coercion by default. We now have strict mode, so you can disable that coercion. But by default, if you say you want an integer field and you get in a string of 1, 2, 3, it will convert it to 123 and a bunch of other sensible conversions. And as you can imagine, the semantics around it. Exactly when you convert and when you don't, it's complicated, but because of that, it's more than just validation. Back in 2017, when I first started it, the different thing it was doing was using type hints to define your schema. That was controversial at the time. It was genuinely disapproved of by some people. I think the success of Pydantic and libraries like FastAPI that build on top of it means that today that's no longer controversial in Python. And indeed, lots of other people have copied that route, but yeah, it's a data validation library. It uses type hints for the for the most part and obviously does all the other stuff you want, like serialization on top of that. But yeah, that's the core.Alessio [00:02:06]: Do you have any fun stories on how JSON schemas ended up being kind of like the structure output standard for LLMs? And were you involved in any of these discussions? Because I know OpenAI was, you know, one of the early adopters. So did they reach out to you? Was there kind of like a structure output console in open source that people were talking about or was it just a random?Samuel [00:02:26]: No, very much not. So I originally. Didn't implement JSON schema inside Pydantic and then Sebastian, Sebastian Ramirez, FastAPI came along and like the first I ever heard of him was over a weekend. I got like 50 emails from him or 50 like emails as he was committing to Pydantic, adding JSON schema long pre version one. So the reason it was added was for OpenAPI, which is obviously closely akin to JSON schema. And then, yeah, I don't know why it was JSON that got picked up and used by OpenAI. It was obviously very convenient for us. That's because it meant that not only can you do the validation, but because Pydantic will generate you the JSON schema, it will it kind of can be one source of source of truth for structured outputs and tools.Swyx [00:03:09]: Before we dive in further on the on the AI side of things, something I'm mildly curious about, obviously, there's Zod in JavaScript land. Every now and then there is a new sort of in vogue validation library that that takes over for quite a few years and then maybe like some something else comes along. Is Pydantic? Is it done like the core Pydantic?Samuel [00:03:30]: I've just come off a call where we were redesigning some of the internal bits. There will be a v3 at some point, which will not break people's code half as much as v2 as in v2 was the was the massive rewrite into Rust, but also fixing all the stuff that was broken back from like version zero point something that we didn't fix in v1 because it was a side project. We have plans to move some of the basically store the data in Rust types after validation. Not completely. So we're still working to design the Pythonic version of it, in order for it to be able to convert into Python types. So then if you were doing like validation and then serialization, you would never have to go via a Python type we reckon that can give us somewhere between three and five times another three to five times speed up. That's probably the biggest thing. Also, like changing how easy it is to basically extend Pydantic and define how particular types, like for example, NumPy arrays are validated and serialized. But there's also stuff going on. And for example, Jitter, the JSON library in Rust that does the JSON parsing, has SIMD implementation at the moment only for AMD64. So we can add that. We need to go and add SIMD for other instruction sets. So there's a bunch more we can do on performance. I don't think we're going to go and revolutionize Pydantic, but it's going to continue to get faster, continue, hopefully, to allow people to do more advanced things. We might add a binary format like CBOR for serialization for when you'll just want to put the data into a database and probably load it again from Pydantic. So there are some things that will come along, but for the most part, it should just get faster and cleaner.Alessio [00:05:04]: From a focus perspective, I guess, as a founder too, how did you think about the AI interest rising? And then how do you kind of prioritize, okay, this is worth going into more, and we'll talk about Pydantic AI and all of that. What was maybe your early experience with LLAMP, and when did you figure out, okay, this is something we should take seriously and focus more resources on it?Samuel [00:05:28]: I'll answer that, but I'll answer what I think is a kind of parallel question, which is Pydantic's weird, because Pydantic existed, obviously, before I was starting a company. I was working on it in my spare time, and then beginning of 22, I started working on the rewrite in Rust. And I worked on it full-time for a year and a half, and then once we started the company, people came and joined. And it was a weird project, because that would never go away. You can't get signed off inside a startup. Like, we're going to go off and three engineers are going to work full-on for a year in Python and Rust, writing like 30,000 lines of Rust just to release open-source-free Python library. The result of that has been excellent for us as a company, right? As in, it's made us remain entirely relevant. And it's like, Pydantic is not just used in the SDKs of all of the AI libraries, but I can't say which one, but one of the big foundational model companies, when they upgraded from Pydantic v1 to v2, their number one internal model... The metric of performance is time to first token. That went down by 20%. So you think about all of the actual AI going on inside, and yet at least 20% of the CPU, or at least the latency inside requests was actually Pydantic, which shows like how widely it's used. So we've benefited from doing that work, although it didn't, it would have never have made financial sense in most companies. In answer to your question about like, how do we prioritize AI, I mean, the honest truth is we've spent a lot of the last year and a half building. Good general purpose observability inside LogFire and making Pydantic good for general purpose use cases. And the AI has kind of come to us. Like we just, not that we want to get away from it, but like the appetite, uh, both in Pydantic and in LogFire to go and build with AI is enormous because it kind of makes sense, right? Like if you're starting a new greenfield project in Python today, what's the chance that you're using GenAI 80%, let's say, globally, obviously it's like a hundred percent in California, but even worldwide, it's probably 80%. Yeah. And so everyone needs that stuff. And there's so much yet to be figured out so much like space to do things better in the ecosystem in a way that like to go and implement a database that's better than Postgres is a like Sisyphean task. Whereas building, uh, tools that are better for GenAI than some of the stuff that's about now is not very difficult. Putting the actual models themselves to one side.Alessio [00:07:40]: And then at the same time, then you released Pydantic AI recently, which is, uh, um, you know, agent framework and early on, I would say everybody like, you know, Langchain and like, uh, Pydantic kind of like a first class support, a lot of these frameworks, we're trying to use you to be better. What was the decision behind we should do our own framework? Were there any design decisions that you disagree with any workloads that you think people didn't support? Well,Samuel [00:08:05]: it wasn't so much like design and workflow, although I think there were some, some things we've done differently. Yeah. I think looking in general at the ecosystem of agent frameworks, the engineering quality is far below that of the rest of the Python ecosystem. There's a bunch of stuff that we have learned how to do over the last 20 years of building Python libraries and writing Python code that seems to be abandoned by people when they build agent frameworks. Now I can kind of respect that, particularly in the very first agent frameworks, like Langchain, where they were literally figuring out how to go and do this stuff. It's completely understandable that you would like basically skip some stuff.Samuel [00:08:42]: I'm shocked by the like quality of some of the agent frameworks that have come out recently from like well-respected names, which it just seems to be opportunism and I have little time for that, but like the early ones, like I think they were just figuring out how to do stuff and just as lots of people have learned from Pydantic, we were able to learn a bit from them. I think from like the gap we saw and the thing we were frustrated by was the production readiness. And that means things like type checking, even if type checking makes it hard. Like Pydantic AI, I will put my hand up now and say it has a lot of generics and you need to, it's probably easier to use it if you've written a bit of Rust and you really understand generics, but like, and that is, we're not claiming that that makes it the easiest thing to use in all cases, we think it makes it good for production applications in big systems where type checking is a no-brainer in Python. But there are also a bunch of stuff we've learned from maintaining Pydantic over the years that we've gone and done. So every single example in Pydantic AI's documentation is run on Python. As part of tests and every single print output within an example is checked during tests. So it will always be up to date. And then a bunch of things that, like I say, are standard best practice within the rest of the Python ecosystem, but I'm not followed surprisingly by some AI libraries like coverage, linting, type checking, et cetera, et cetera, where I think these are no-brainers, but like weirdly they're not followed by some of the other libraries.Alessio [00:10:04]: And can you just give an overview of the framework itself? I think there's kind of like the. LLM calling frameworks, there are the multi-agent frameworks, there's the workflow frameworks, like what does Pydantic AI do?Samuel [00:10:17]: I glaze over a bit when I hear all of the different sorts of frameworks, but I like, and I will tell you when I built Pydantic, when I built Logfire and when I built Pydantic AI, my methodology is not to go and like research and review all of the other things. I kind of work out what I want and I go and build it and then feedback comes and we adjust. So the fundamental building block of Pydantic AI is agents. The exact definition of agents and how you want to define them. is obviously ambiguous and our things are probably sort of agent-lit, not that we would want to go and rename them to agent-lit, but like the point is you probably build them together to build something and most people will call an agent. So an agent in our case has, you know, things like a prompt, like system prompt and some tools and a structured return type if you want it, that covers the vast majority of cases. There are situations where you want to go further and the most complex workflows where you want graphs and I resisted graphs for quite a while. I was sort of of the opinion you didn't need them and you could use standard like Python flow control to do all of that stuff. I had a few arguments with people, but I basically came around to, yeah, I can totally see why graphs are useful. But then we have the problem that by default, they're not type safe because if you have a like add edge method where you give the names of two different edges, there's no type checking, right? Even if you go and do some, I'm not, not all the graph libraries are AI specific. So there's a, there's a graph library called, but it allows, it does like a basic runtime type checking. Ironically using Pydantic to try and make up for the fact that like fundamentally that graphs are not typed type safe. Well, I like Pydantic, but it did, that's not a real solution to have to go and run the code to see if it's safe. There's a reason that starting type checking is so powerful. And so we kind of, from a lot of iteration eventually came up with a system of using normally data classes to define nodes where you return the next node you want to call and where we're able to go and introspect the return type of a node to basically build the graph. And so the graph is. Yeah. Inherently type safe. And once we got that right, I, I wasn't, I'm incredibly excited about graphs. I think there's like masses of use cases for them, both in gen AI and other development, but also software's all going to have interact with gen AI, right? It's going to be like web. There's no longer be like a web department in a company is that there's just like all the developers are building for web building with databases. The same is going to be true for gen AI.Alessio [00:12:33]: Yeah. I see on your docs, you call an agent, a container that contains a system prompt function. Tools, structure, result, dependency type model, and then model settings. Are the graphs in your mind, different agents? Are they different prompts for the same agent? What are like the structures in your mind?Samuel [00:12:52]: So we were compelled enough by graphs once we got them right, that we actually merged the PR this morning. That means our agent implementation without changing its API at all is now actually a graph under the hood as it is built using our graph library. So graphs are basically a lower level tool that allow you to build these complex workflows. Our agents are technically one of the many graphs you could go and build. And we just happened to build that one for you because it's a very common, commonplace one. But obviously there are cases where you need more complex workflows where the current agent assumptions don't work. And that's where you can then go and use graphs to build more complex things.Swyx [00:13:29]: You said you were cynical about graphs. What changed your mind specifically?Samuel [00:13:33]: I guess people kept giving me examples of things that they wanted to use graphs for. And my like, yeah, but you could do that in standard flow control in Python became a like less and less compelling argument to me because I've maintained those systems that end up with like spaghetti code. And I could see the appeal of this like structured way of defining the workflow of my code. And it's really neat that like just from your code, just from your type hints, you can get out a mermaid diagram that defines exactly what can go and happen.Swyx [00:14:00]: Right. Yeah. You do have very neat implementation of sort of inferring the graph from type hints, I guess. Yeah. Is what I would call it. Yeah. I think the question always is I have gone back and forth. I used to work at Temporal where we would actually spend a lot of time complaining about graph based workflow solutions like AWS step functions. And we would actually say that we were better because you could use normal control flow that you already knew and worked with. Yours, I guess, is like a little bit of a nice compromise. Like it looks like normal Pythonic code. But you just have to keep in mind what the type hints actually mean. And that's what we do with the quote unquote magic that the graph construction does.Samuel [00:14:42]: Yeah, exactly. And if you look at the internal logic of actually running a graph, it's incredibly simple. It's basically call a node, get a node back, call that node, get a node back, call that node. If you get an end, you're done. We will add in soon support for, well, basically storage so that you can store the state between each node that's run. And then the idea is you can then distribute the graph and run it across computers. And also, I mean, the other weird, the other bit that's really valuable is across time. Because it's all very well if you look at like lots of the graph examples that like Claude will give you. If it gives you an example, it gives you this lovely enormous mermaid chart of like the workflow, for example, managing returns if you're an e-commerce company. But what you realize is some of those lines are literally one function calls another function. And some of those lines are wait six days for the customer to print their like piece of paper and put it in the post. And if you're writing like your demo. Project or your like proof of concept, that's fine because you can just say, and now we call this function. But when you're building when you're in real in real life, that doesn't work. And now how do we manage that concept to basically be able to start somewhere else in the in our code? Well, this graph implementation makes it incredibly easy because you just pass the node that is the start point for carrying on the graph and it continues to run. So it's things like that where I was like, yeah, I can just imagine how things I've done in the past would be fundamentally easier to understand if we had done them with graphs.Swyx [00:16:07]: You say imagine, but like right now, this pedantic AI actually resume, you know, six days later, like you said, or is this just like a theoretical thing we can go someday?Samuel [00:16:16]: I think it's basically Q&A. So there's an AI that's asking the user a question and effectively you then call the CLI again to continue the conversation. And it basically instantiates the node and calls the graph with that node again. Now, we don't have the logic yet for effectively storing state in the database between individual nodes that we're going to add soon. But like the rest of it is basically there.Swyx [00:16:37]: It does make me think that not only are you competing with Langchain now and obviously Instructor, and now you're going into sort of the more like orchestrated things like Airflow, Prefect, Daxter, those guys.Samuel [00:16:52]: Yeah, I mean, we're good friends with the Prefect guys and Temporal have the same investors as us. And I'm sure that my investor Bogomol would not be too happy if I was like, oh, yeah, by the way, as well as trying to take on Datadog. We're also going off and trying to take on Temporal and everyone else doing that. Obviously, we're not doing all of the infrastructure of deploying that right yet, at least. We're, you know, we're just building a Python library. And like what's crazy about our graph implementation is, sure, there's a bit of magic in like introspecting the return type, you know, extracting things from unions, stuff like that. But like the actual calls, as I say, is literally call a function and get back a thing and call that. It's like incredibly simple and therefore easy to maintain. The question is, how useful is it? Well, I don't know yet. I think we have to go and find out. We have a whole. We've had a slew of people joining our Slack over the last few days and saying, tell me how good Pydantic AI is. How good is Pydantic AI versus Langchain? And I refuse to answer. That's your job to go and find that out. Not mine. We built a thing. I'm compelled by it, but I'm obviously biased. The ecosystem will work out what the useful tools are.Swyx [00:17:52]: Bogomol was my board member when I was at Temporal. And I think I think just generally also having been a workflow engine investor and participant in this space, it's a big space. Like everyone needs different functions. I think the one thing that I would say like yours, you know, as a library, you don't have that much control of it over the infrastructure. I do like the idea that each new agents or whatever or unit of work, whatever you call that should spin up in this sort of isolated boundaries. Whereas yours, I think around everything runs in the same process. But you ideally want to sort of spin out its own little container of things.Samuel [00:18:30]: I agree with you a hundred percent. And we will. It would work now. Right. As in theory, you're just like as long as you can serialize the calls to the next node, you just have to all of the different containers basically have to have the same the same code. I mean, I'm super excited about Cloudflare workers running Python and being able to install dependencies. And if Cloudflare could only give me my invitation to the private beta of that, we would be exploring that right now because I'm super excited about that as a like compute level for some of this stuff where exactly what you're saying, basically. You can run everything as an individual. Like worker function and distribute it. And it's resilient to failure, et cetera, et cetera.Swyx [00:19:08]: And it spins up like a thousand instances simultaneously. You know, you want it to be sort of truly serverless at once. Actually, I know we have some Cloudflare friends who are listening, so hopefully they'll get in front of the line. Especially.Samuel [00:19:19]: I was in Cloudflare's office last week shouting at them about other things that frustrate me. I have a love-hate relationship with Cloudflare. Their tech is awesome. But because I use it the whole time, I then get frustrated. So, yeah, I'm sure I will. I will. I will get there soon.Swyx [00:19:32]: There's a side tangent on Cloudflare. Is Python supported at full? I actually wasn't fully aware of what the status of that thing is.Samuel [00:19:39]: Yeah. So Pyodide, which is Python running inside the browser in scripting, is supported now by Cloudflare. They basically, they're having some struggles working out how to manage, ironically, dependencies that have binaries, in particular, Pydantic. Because these workers where you can have thousands of them on a given metal machine, you don't want to have a difference. You basically want to be able to have a share. Shared memory for all the different Pydantic installations, effectively. That's the thing they work out. They're working out. But Hood, who's my friend, who is the primary maintainer of Pyodide, works for Cloudflare. And that's basically what he's doing, is working out how to get Python running on Cloudflare's network.Swyx [00:20:19]: I mean, the nice thing is that your binary is really written in Rust, right? Yeah. Which also compiles the WebAssembly. Yeah. So maybe there's a way that you'd build... You have just a different build of Pydantic and that ships with whatever your distro for Cloudflare workers is.Samuel [00:20:36]: Yes, that's exactly what... So Pyodide has builds for Pydantic Core and for things like NumPy and basically all of the popular binary libraries. Yeah. It's just basic. And you're doing exactly that, right? You're using Rust to compile the WebAssembly and then you're calling that shared library from Python. And it's unbelievably complicated, but it works. Okay.Swyx [00:20:57]: Staying on graphs a little bit more, and then I wanted to go to some of the other features that you have in Pydantic AI. I see in your docs, there are sort of four levels of agents. There's single agents, there's agent delegation, programmatic agent handoff. That seems to be what OpenAI swarms would be like. And then the last one, graph-based control flow. Would you say that those are sort of the mental hierarchy of how these things go?Samuel [00:21:21]: Yeah, roughly. Okay.Swyx [00:21:22]: You had some expression around OpenAI swarms. Well.Samuel [00:21:25]: And indeed, OpenAI have got in touch with me and basically, maybe I'm not supposed to say this, but basically said that Pydantic AI looks like what swarms would become if it was production ready. So, yeah. I mean, like, yeah, which makes sense. Awesome. Yeah. I mean, in fact, it was specifically saying, how can we give people the same feeling that they were getting from swarms that led us to go and implement graphs? Because my, like, just call the next agent with Python code was not a satisfactory answer to people. So it was like, okay, we've got to go and have a better answer for that. It's not like, let us to get to graphs. Yeah.Swyx [00:21:56]: I mean, it's a minimal viable graph in some sense. What are the shapes of graphs that people should know? So the way that I would phrase this is I think Anthropic did a very good public service and also kind of surprisingly influential blog post, I would say, when they wrote Building Effective Agents. We actually have the authors coming to speak at my conference in New York, which I think you're giving a workshop at. Yeah.Samuel [00:22:24]: I'm trying to work it out. But yes, I think so.Swyx [00:22:26]: Tell me if you're not. yeah, I mean, like, that was the first, I think, authoritative view of, like, what kinds of graphs exist in agents and let's give each of them a name so that everyone is on the same page. So I'm just kind of curious if you have community names or top five patterns of graphs.Samuel [00:22:44]: I don't have top five patterns of graphs. I would love to see what people are building with them. But like, it's been it's only been a couple of weeks. And of course, there's a point is that. Because they're relatively unopinionated about what you can go and do with them. They don't suit them. Like, you can go and do lots of lots of things with them, but they don't have the structure to go and have like specific names as much as perhaps like some other systems do. I think what our agents are, which have a name and I can't remember what it is, but this basically system of like, decide what tool to call, go back to the center, decide what tool to call, go back to the center and then exit. One form of graph, which, as I say, like our agents are effectively one implementation of a graph, which is why under the hood they are now using graphs. And it'll be interesting to see over the next few years whether we end up with these like predefined graph names or graph structures or whether it's just like, yep, I built a graph or whether graphs just turn out not to match people's mental image of what they want and die away. We'll see.Swyx [00:23:38]: I think there is always appeal. Every developer eventually gets graph religion and goes, oh, yeah, everything's a graph. And then they probably over rotate and go go too far into graphs. And then they have to learn a whole bunch of DSLs. And then they're like, actually, I didn't need that. I need this. And they scale back a little bit.Samuel [00:23:55]: I'm at the beginning of that process. I'm currently a graph maximalist, although I haven't actually put any into production yet. But yeah.Swyx [00:24:02]: This has a lot of philosophical connections with other work coming out of UC Berkeley on compounding AI systems. I don't know if you know of or care. This is the Gartner world of things where they need some kind of industry terminology to sell it to enterprises. I don't know if you know about any of that.Samuel [00:24:24]: I haven't. I probably should. I should probably do it because I should probably get better at selling to enterprises. But no, no, I don't. Not right now.Swyx [00:24:29]: This is really the argument is that instead of putting everything in one model, you have more control and more maybe observability to if you break everything out into composing little models and changing them together. And obviously, then you need an orchestration framework to do that. Yeah.Samuel [00:24:47]: And it makes complete sense. And one of the things we've seen with agents is they work well when they work well. But when they. Even if you have the observability through log five that you can see what was going on, if you don't have a nice hook point to say, hang on, this is all gone wrong. You have a relatively blunt instrument of basically erroring when you exceed some kind of limit. But like what you need to be able to do is effectively iterate through these runs so that you can have your own control flow where you're like, OK, we've gone too far. And that's where one of the neat things about our graph implementation is you can basically call next in a loop rather than just running the full graph. And therefore, you have this opportunity to to break out of it. But yeah, basically, it's the same point, which is like if you have two bigger unit of work to some extent, whether or not it involves gen AI. But obviously, it's particularly problematic in gen AI. You only find out afterwards when you've spent quite a lot of time and or money when it's gone off and done done the wrong thing.Swyx [00:25:39]: Oh, drop on this. We're not going to resolve this here, but I'll drop this and then we can move on to the next thing. This is the common way that we we developers talk about this. And then the machine learning researchers look at us. And laugh and say, that's cute. And then they just train a bigger model and they wipe us out in the next training run. So I think there's a certain amount of we are fighting the bitter lesson here. We're fighting AGI. And, you know, when AGI arrives, this will all go away. Obviously, on Latent Space, we don't really discuss that because I think AGI is kind of this hand wavy concept that isn't super relevant. But I think we have to respect that. For example, you could do a chain of thoughts with graphs and you could manually orchestrate a nice little graph that does like. Reflect, think about if you need more, more inference time, compute, you know, that's the hot term now. And then think again and, you know, scale that up. Or you could train Strawberry and DeepSeq R1. Right.Samuel [00:26:32]: I saw someone saying recently, oh, they were really optimistic about agents because models are getting faster exponentially. And I like took a certain amount of self-control not to describe that it wasn't exponential. But my main point was. If models are getting faster as quickly as you say they are, then we don't need agents and we don't really need any of these abstraction layers. We can just give our model and, you know, access to the Internet, cross our fingers and hope for the best. Agents, agent frameworks, graphs, all of this stuff is basically making up for the fact that right now the models are not that clever. In the same way that if you're running a customer service business and you have loads of people sitting answering telephones, the less well trained they are, the less that you trust them, the more that you need to give them a script to go through. Whereas, you know, so if you're running a bank and you have lots of customer service people who you don't trust that much, then you tell them exactly what to say. If you're doing high net worth banking, you just employ people who you think are going to be charming to other rich people and set them off to go and have coffee with people. Right. And the same is true of models. The more intelligent they are, the less we need to tell them, like structure what they go and do and constrain the routes in which they take.Swyx [00:27:42]: Yeah. Yeah. Agree with that. So I'm happy to move on. So the other parts of Pydantic AI that are worth commenting on, and this is like my last rant, I promise. So obviously, every framework needs to do its sort of model adapter layer, which is, oh, you can easily swap from OpenAI to Cloud to Grok. You also have, which I didn't know about, Google GLA, which I didn't really know about until I saw this in your docs, which is generative language API. I assume that's AI Studio? Yes.Samuel [00:28:13]: Google don't have good names for it. So Vertex is very clear. That seems to be the API that like some of the things use, although it returns 503 about 20% of the time. So... Vertex? No. Vertex, fine. But the... Oh, oh. GLA. Yeah. Yeah.Swyx [00:28:28]: I agree with that.Samuel [00:28:29]: So we have, again, another example of like, well, I think we go the extra mile in terms of engineering is we run on every commit, at least commit to main, we run tests against the live models. Not lots of tests, but like a handful of them. Oh, okay. And we had a point last week where, yeah, GLA is a little bit better. GLA1 was failing every single run. One of their tests would fail. And we, I think we might even have commented out that one at the moment. So like all of the models fail more often than you might expect, but like that one seems to be particularly likely to fail. But Vertex is the same API, but much more reliable.Swyx [00:29:01]: My rant here is that, you know, versions of this appear in Langchain and every single framework has to have its own little thing, a version of that. I would put to you, and then, you know, this is, this can be agree to disagree. This is not needed in Pydantic AI. I would much rather you adopt a layer like Lite LLM or what's the other one in JavaScript port key. And that's their job. They focus on that one thing and they, they normalize APIs for you. All new models are automatically added and you don't have to duplicate this inside of your framework. So for example, if I wanted to use deep seek, I'm out of luck because Pydantic AI doesn't have deep seek yet.Samuel [00:29:38]: Yeah, it does.Swyx [00:29:39]: Oh, it does. Okay. I'm sorry. But you know what I mean? Should this live in your code or should it live in a layer that's kind of your API gateway that's a defined piece of infrastructure that people have?Samuel [00:29:49]: And I think if a company who are well known, who are respected by everyone had come along and done this at the right time, maybe we should have done it a year and a half ago and said, we're going to be the universal AI layer. That would have been a credible thing to do. I've heard varying reports of Lite LLM is the truth. And it didn't seem to have exactly the type safety that we needed. Also, as I understand it, and again, I haven't looked into it in great detail. Part of their business model is proxying the request through their, through their own system to do the generalization. That would be an enormous put off to an awful lot of people. Honestly, the truth is I don't think it is that much work unifying the model. I get where you're coming from. I kind of see your point. I think the truth is that everyone is centralizing around open AIs. Open AI's API is the one to do. So DeepSeq support that. Grok with OK support that. Ollama also does it. I mean, if there is that library right now, it's more or less the open AI SDK. And it's very high quality. It's well type checked. It uses Pydantic. So I'm biased. But I mean, I think it's pretty well respected anyway.Swyx [00:30:57]: There's different ways to do this. Because also, it's not just about normalizing the APIs. You have to do secret management and all that stuff.Samuel [00:31:05]: Yeah. And there's also. There's Vertex and Bedrock, which to one extent or another, effectively, they host multiple models, but they don't unify the API. But they do unify the auth, as I understand it. Although we're halfway through doing Bedrock. So I don't know about it that well. But they're kind of weird hybrids because they support multiple models. But like I say, the auth is centralized.Swyx [00:31:28]: Yeah, I'm surprised they don't unify the API. That seems like something that I would do. You know, we can discuss all this all day. There's a lot of APIs. I agree.Samuel [00:31:36]: It would be nice if there was a universal one that we didn't have to go and build.Alessio [00:31:39]: And I guess the other side of, you know, routing model and picking models like evals. How do you actually figure out which one you should be using? I know you have one. First of all, you have very good support for mocking in unit tests, which is something that a lot of other frameworks don't do. So, you know, my favorite Ruby library is VCR because it just, you know, it just lets me store the HTTP requests and replay them. That part I'll kind of skip. I think you are busy like this test model. We're like just through Python. You try and figure out what the model might respond without actually calling the model. And then you have the function model where people can kind of customize outputs. Any other fun stories maybe from there? Or is it just what you see is what you get, so to speak?Samuel [00:32:18]: On those two, I think what you see is what you get. On the evals, I think watch this space. I think it's something that like, again, I was somewhat cynical about for some time. Still have my cynicism about some of the well, it's unfortunate that so many different things are called evals. It would be nice if we could agree. What they are and what they're not. But look, I think it's a really important space. I think it's something that we're going to be working on soon, both in Pydantic AI and in LogFire to try and support better because it's like it's an unsolved problem.Alessio [00:32:45]: Yeah, you do say in your doc that anyone who claims to know for sure exactly how your eval should be defined can safely be ignored.Samuel [00:32:52]: We'll delete that sentence when we tell people how to do their evals.Alessio [00:32:56]: Exactly. I was like, we need we need a snapshot of this today. And so let's talk about eval. So there's kind of like the vibe. Yeah. So you have evals, which is what you do when you're building. Right. Because you cannot really like test it that many times to get statistical significance. And then there's the production eval. So you also have LogFire, which is kind of like your observability product, which I tried before. It's very nice. What are some of the learnings you've had from building an observability tool for LEMPs? And yeah, as people think about evals, even like what are the right things to measure? What are like the right number of samples that you need to actually start making decisions?Samuel [00:33:33]: I'm not the best person to answer that is the truth. So I'm not going to come in here and tell you that I think I know the answer on the exact number. I mean, we can do some back of the envelope statistics calculations to work out that like having 30 probably gets you most of the statistical value of having 200 for, you know, by definition, 15% of the work. But the exact like how many examples do you need? For example, that's a much harder question to answer because it's, you know, it's deep within the how models operate in terms of LogFire. One of the reasons we built LogFire the way we have and we allow you to write SQL directly against your data and we're trying to build the like powerful fundamentals of observability is precisely because we know we don't know the answers. And so allowing people to go and innovate on how they're going to consume that stuff and how they're going to process it is we think that's valuable. Because even if we come along and offer you an evals framework on top of LogFire, it won't be right in all regards. And we want people to be able to go and innovate and being able to write their own SQL connected to the API. And effectively query the data like it's a database with SQL allows people to innovate on that stuff. And that's what allows us to do it as well. I mean, we do a bunch of like testing what's possible by basically writing SQL directly against LogFire as any user could. I think the other the other really interesting bit that's going on in observability is OpenTelemetry is centralizing around semantic attributes for GenAI. So it's a relatively new project. A lot of it's still being added at the moment. But basically the idea that like. They unify how both SDKs and or agent frameworks send observability data to to any OpenTelemetry endpoint. And so, again, we can go and having that unification allows us to go and like basically compare different libraries, compare different models much better. That stuff's in a very like early stage of development. One of the things we're going to be working on pretty soon is basically, I suspect, GenAI will be the first agent framework that implements those semantic attributes properly. Because, again, we control and we can say this is important for observability, whereas most of the other agent frameworks are not maintained by people who are trying to do observability. With the exception of Langchain, where they have the observability platform, but they chose not to go down the OpenTelemetry route. So they're like plowing their own furrow. And, you know, they're a lot they're even further away from standardization.Alessio [00:35:51]: Can you maybe just give a quick overview of how OTEL ties into the AI workflows? There's kind of like the question of is, you know, a trace. And a span like a LLM call. Is it the agent? It's kind of like the broader thing you're tracking. How should people think about it?Samuel [00:36:06]: Yeah, so they have a PR that I think may have now been merged from someone at IBM talking about remote agents and trying to support this concept of remote agents within GenAI. I'm not particularly compelled by that because I don't think that like that's actually by any means the common use case. But like, I suppose it's fine for it to be there. The majority of the stuff in OTEL is basically defining how you would instrument. A given call to an LLM. So basically the actual LLM call, what data you would send to your telemetry provider, how you would structure that. Apart from this slightly odd stuff on remote agents, most of the like agent level consideration is not yet implemented in is not yet decided effectively. And so there's a bit of ambiguity. Obviously, what's good about OTEL is you can in the end send whatever attributes you like. But yeah, there's quite a lot of churn in that space and exactly how we store the data. I think that one of the most interesting things, though, is that if you think about observability. Traditionally, it was sure everyone would say our observability data is very important. We must keep it safe. But actually, companies work very hard to basically not have anything that sensitive in their observability data. So if you're a doctor in a hospital and you search for a drug for an STI, the sequel might be sent to the observability provider. But none of the parameters would. It wouldn't have the patient number or their name or the drug. With GenAI, that distinction doesn't exist because it's all just messed up in the text. If you have that same patient asking an LLM how to. What drug they should take or how to stop smoking. You can't extract the PII and not send it to the observability platform. So the sensitivity of the data that's going to end up in observability platforms is going to be like basically different order of magnitude to what's in what you would normally send to Datadog. Of course, you can make a mistake and send someone's password or their card number to Datadog. But that would be seen as a as a like mistake. Whereas in GenAI, a lot of data is going to be sent. And I think that's why companies like Langsmith and are trying hard to offer observability. On prem, because there's a bunch of companies who are happy for Datadog to be cloud hosted, but want self-hosted self-hosting for this observability stuff with GenAI.Alessio [00:38:09]: And are you doing any of that today? Because I know in each of the spans you have like the number of tokens, you have the context, you're just storing everything. And then you're going to offer kind of like a self-hosting for the platform, basically. Yeah. Yeah.Samuel [00:38:23]: So we have scrubbing roughly equivalent to what the other observability platforms have. So if we, you know, if we see password as the key, we won't send the value. But like, like I said, that doesn't really work in GenAI. So we're accepting we're going to have to store a lot of data and then we'll offer self-hosting for those people who can afford it and who need it.Alessio [00:38:42]: And then this is, I think, the first time that most of the workloads performance is depending on a third party. You know, like if you're looking at Datadog data, usually it's your app that is driving the latency and like the memory usage and all of that. Here you're going to have spans that maybe take a long time to perform because the GLA API is not working or because OpenAI is kind of like overwhelmed. Do you do anything there since like the provider is almost like the same across customers? You know, like, are you trying to surface these things for people and say, hey, this was like a very slow span, but actually all customers using OpenAI right now are seeing the same thing. So maybe don't worry about it or.Samuel [00:39:20]: Not yet. We do a few things that people don't generally do in OTA. So we send. We send information at the beginning. At the beginning of a trace as well as sorry, at the beginning of a span, as well as when it finishes. By default, OTA only sends you data when the span finishes. So if you think about a request which might take like 20 seconds, even if some of the intermediate spans finished earlier, you can't basically place them on the page until you get the top level span. And so if you're using standard OTA, you can't show anything until those requests are finished. When those requests are taking a few hundred milliseconds, it doesn't really matter. But when you're doing Gen AI calls or when you're like running a batch job that might take 30 minutes. That like latency of not being able to see the span is like crippling to understanding your application. And so we've we do a bunch of slightly complex stuff to basically send data about a span as it starts, which is closely related. Yeah.Alessio [00:40:09]: Any thoughts on all the other people trying to build on top of OpenTelemetry in different languages, too? There's like the OpenLEmetry project, which doesn't really roll off the tongue. But how do you see the future of these kind of tools? Is everybody going to have to build? Why does everybody want to build? They want to build their own open source observability thing to then sell?Samuel [00:40:29]: I mean, we are not going off and trying to instrument the likes of the OpenAI SDK with the new semantic attributes, because at some point that's going to happen and it's going to live inside OTEL and we might help with it. But we're a tiny team. We don't have time to go and do all of that work. So OpenLEmetry, like interesting project. But I suspect eventually most of those semantic like that instrumentation of the big of the SDKs will live, like I say, inside the main OpenTelemetry report. I suppose. What happens to the agent frameworks? What data you basically need at the framework level to get the context is kind of unclear. I don't think we know the answer yet. But I mean, I was on the, I guess this is kind of semi-public, because I was on the call with the OpenTelemetry call last week talking about GenAI. And there was someone from Arize talking about the challenges they have trying to get OpenTelemetry data out of Langchain, where it's not like natively implemented. And obviously they're having quite a tough time. And I was realizing, hadn't really realized this before, but how lucky we are to primarily be talking about our own agent framework, where we have the control rather than trying to go and instrument other people's.Swyx [00:41:36]: Sorry, I actually didn't know about this semantic conventions thing. It looks like, yeah, it's merged into main OTel. What should people know about this? I had never heard of it before.Samuel [00:41:45]: Yeah, I think it looks like a great start. I think there's some unknowns around how you send the messages that go back and forth, which is kind of the most important part. It's the most important thing of all. And that is moved out of attributes and into OTel events. OTel events in turn are moving from being on a span to being their own top-level API where you send data. So there's a bunch of churn still going on. I'm impressed by how fast the OTel community is moving on this project. I guess they, like everyone else, get that this is important, and it's something that people are crying out to get instrumentation off. So I'm kind of pleasantly surprised at how fast they're moving, but it makes sense.Swyx [00:42:25]: I'm just kind of browsing through the specification. I can already see that this basically bakes in whatever the previous paradigm was. So now they have genai.usage.prompt tokens and genai.usage.completion tokens. And obviously now we have reasoning tokens as well. And then only one form of sampling, which is top-p. You're basically baking in or sort of reifying things that you think are important today, but it's not a super foolproof way of doing this for the future. Yeah.Samuel [00:42:54]: I mean, that's what's neat about OTel is you can always go and send another attribute and that's fine. It's just there are a bunch that are agreed on. But I would say, you know, to come back to your previous point about whether or not we should be relying on one centralized abstraction layer, this stuff is moving so fast that if you start relying on someone else's standard, you risk basically falling behind because you're relying on someone else to keep things up to date.Swyx [00:43:14]: Or you fall behind because you've got other things going on.Samuel [00:43:17]: Yeah, yeah. That's fair. That's fair.Swyx [00:43:19]: Any other observations just about building LogFire, actually? Let's just talk about this. So you announced LogFire. I was kind of only familiar with LogFire because of your Series A announcement. I actually thought you were making a separate company. I remember some amount of confusion with you when that came out. So to be clear, it's Pydantic LogFire and the company is one company that has kind of two products, an open source thing and an observability thing, correct? Yeah. I was just kind of curious, like any learnings building LogFire? So classic question is, do you use ClickHouse? Is this like the standard persistence layer? Any learnings doing that?Samuel [00:43:54]: We don't use ClickHouse. We started building our database with ClickHouse, moved off ClickHouse onto Timescale, which is a Postgres extension to do analytical databases. Wow. And then moved off Timescale onto DataFusion. And we're basically now building, it's DataFusion, but it's kind of our own database. Bogomil is not entirely happy that we went through three databases before we chose one. I'll say that. But like, we've got to the right one in the end. I think we could have realized that Timescale wasn't right. I think ClickHouse. They both taught us a lot and we're in a great place now. But like, yeah, it's been a real journey on the database in particular.Swyx [00:44:28]: Okay. So, you know, as a database nerd, I have to like double click on this, right? So ClickHouse is supposed to be the ideal backend for anything like this. And then moving from ClickHouse to Timescale is another counterintuitive move that I didn't expect because, you know, Timescale is like an extension on top of Postgres. Not super meant for like high volume logging. But like, yeah, tell us those decisions.Samuel [00:44:50]: So at the time, ClickHouse did not have good support for JSON. I was speaking to someone yesterday and said ClickHouse doesn't have good support for JSON and got roundly stepped on because apparently it does now. So they've obviously gone and built their proper JSON support. But like back when we were trying to use it, I guess a year ago or a bit more than a year ago, everything happened to be a map and maps are a pain to try and do like looking up JSON type data. And obviously all these attributes, everything you're talking about there in terms of the GenAI stuff. You can choose to make them top level columns if you want. But the simplest thing is just to put them all into a big JSON pile. And that was a problem with ClickHouse. Also, ClickHouse had some really ugly edge cases like by default, or at least until I complained about it a lot, ClickHouse thought that two nanoseconds was longer than one second because they compared intervals just by the number, not the unit. And I complained about that a lot. And then they caused it to raise an error and just say you have to have the same unit. Then I complained a bit more. And I think as I understand it now, they have some. They convert between units. But like stuff like that, when all you're looking at is when a lot of what you're doing is comparing the duration of spans was really painful. Also things like you can't subtract two date times to get an interval. You have to use the date sub function. But like the fundamental thing is because we want our end users to write SQL, the like quality of the SQL, how easy it is to write, matters way more to us than if you're building like a platform on top where your developers are going to write the SQL. And once it's written and it's working, you don't mind too much. So I think that's like one of the fundamental differences. The other problem that I have with the ClickHouse and Impact Timescale is that like the ultimate architecture, the like snowflake architecture of binary data in object store queried with some kind of cache from nearby. They both have it, but it's closed sourced and you only get it if you go and use their hosted versions. And so even if we had got through all the problems with Timescale or ClickHouse, we would end up like, you know, they would want to be taking their 80% margin. And then we would be wanting to take that would basically leave us less space for margin. Whereas data fusion. Properly open source, all of that same tooling is open source. And for us as a team of people with a lot of Rust expertise, data fusion, which is implemented in Rust, we can literally dive into it and go and change it. So, for example, I found that there were some slowdowns in data fusion's string comparison kernel for doing like string contains. And it's just Rust code. And I could go and rewrite the string comparison kernel to be faster. Or, for example, data fusion, when we started using it, didn't have JSON support. Obviously, as I've said, it's something we can do. It's something we needed. I was able to go and implement that in a weekend using our JSON parser that we built for Pydantic Core. So it's the fact that like data fusion is like for us the perfect mixture of a toolbox to build a database with, not a database. And we can go and implement stuff on top of it in a way that like if you were trying to do that in Postgres or in ClickHouse. I mean, ClickHouse would be easier because it's C++, relatively modern C++. But like as a team of people who are not C++ experts, that's much scarier than data fusion for us.Swyx [00:47:47]: Yeah, that's a beautiful rant.Alessio [00:47:49]: That's funny. Most people don't think they have agency on these projects. They're kind of like, oh, I should use this or I should use that. They're not really like, what should I pick so that I contribute the most back to it? You know, so but I think you obviously have an open source first mindset. So that makes a lot of sense.Samuel [00:48:05]: I think if we were probably better as a startup, a better startup and faster moving and just like headlong determined to get in front of customers as fast as possible, we should have just started with ClickHouse. I hope that long term we're in a better place for having worked with data fusion. We like we're quite engaged now with the data fusion community. Andrew Lam, who maintains data fusion, is an advisor to us. We're in a really good place now. But yeah, it's definitely slowed us down relative to just like building on ClickHouse and moving as fast as we can.Swyx [00:48:34]: OK, we're about to zoom out and do Pydantic run and all the other stuff. But, you know, my last question on LogFire is really, you know, at some point you run out sort of community goodwill just because like, oh, I use Pydantic. I love Pydantic. I'm going to use LogFire. OK, then you start entering the territory of the Datadogs, the Sentrys and the honeycombs. Yeah. So where are you going to really spike here? What differentiator here?Samuel [00:48:59]: I wasn't writing code in 2001, but I'm assuming that there were people talking about like web observability and then web observability stopped being a thing, not because the web stopped being a thing, but because all observability had to do web. If you were talking to people in 2010 or 2012, they would have talked about cloud observability. Now that's not a term because all observability is cloud first. The same is going to happen to gen AI. And so whether or not you're trying to compete with Datadog or with Arise and Langsmith, you've got to do first class. You've got to do general purpose observability with first class support for AI. And as far as I know, we're the only people really trying to do that. I mean, I think Datadog is starting in that direction. And to be honest, I think Datadog is a much like scarier company to compete with than the AI specific observability platforms. Because in my opinion, and I've also heard this from lots of customers, AI specific observability where you don't see everything else going on in your app is not actually that useful. Our hope is that we can build the first general purpose observability platform with first class support for AI. And that we have this open source heritage of putting developer experience first that other companies haven't done. For all I'm a fan of Datadog and what they've done. If you search Datadog logging Python. And you just try as a like a non-observability expert to get something up and running with Datadog and Python. It's not trivial, right? That's something Sentry have done amazingly well. But like there's enormous space in most of observability to do DX better.Alessio [00:50:27]: Since you mentioned Sentry, I'm curious how you thought about licensing and all of that. Obviously, your MIT license, you don't have any rolling license like Sentry has where you can only use an open source, like the one year old version of it. Was that a hard decision?Samuel [00:50:41]: So to be clear, LogFire is co-sourced. So Pydantic and Pydantic AI are MIT licensed and like properly open source. And then LogFire for now is completely closed source. And in fact, the struggles that Sentry have had with licensing and the like weird pushback the community gives when they take something that's closed source and make it source available just meant that we just avoided that whole subject matter. I think the other way to look at it is like in terms of either headcount or revenue or dollars in the bank. The amount of open source we do as a company is we've got to be open source. We're up there with the most prolific open source companies, like I say, per head. And so we didn't feel like we were morally obligated to make LogFire open source. We have Pydantic. Pydantic is a foundational library in Python. That and now Pydantic AI are our contribution to open source. And then LogFire is like openly for profit, right? As in we're not claiming otherwise. We're not sort of trying to walk a line if it's open source. But really, we want to make it hard to deploy. So you probably want to pay us. We're trying to be straight. That it's to pay for. We could change that at some point in the future, but it's not an immediate plan.Alessio [00:51:48]: All right. So the first one I saw this new I don't know if it's like a product you're building the Pydantic that run, which is a Python browser sandbox. What was the inspiration behind that? We talk a lot about code interpreter for lamps. I'm an investor in a company called E2B, which is a code sandbox as a service for remote execution. Yeah. What's the Pydantic that run story?Samuel [00:52:09]: So Pydantic that run is again completely open source. I have no interest in making it into a product. We just needed a sandbox to be able to demo LogFire in particular, but also Pydantic AI. So it doesn't have it yet, but I'm going to add basically a proxy to OpenAI and the other models so that you can run Pydantic AI in the browser. See how it works. Tweak the prompt, et cetera, et cetera. And we'll have some kind of limit per day of what you can spend on it or like what the spend is. The other thing we wanted to b

Can a combo of Large Language Models (LLMs) and Domain-Specific Languages (DSLs) streamline development by automating repetitive patterns across teams? In this Mob Mentality Show episode, we dive deep into the intersection of AI-driven automation, code generation, and lean software development. Join us as we explore: ✅ The "Generator for the Generator" Concept – How AI-powered tools and Mob Programming can create DSLs that automate code generation at scale. ✅ Handling Cross-Domain Development with DSLs – How DSL arguments can be leveraged to generate applications across multiple domains while maintaining usability. ✅ Serverless Infrastructure as Code (IaC) & Auto-Generated Apps – How to use DSLs to automate cloud deployment with Angular or Streamlit apps. ✅ The Challenge of UI/UX in Generated Code – When UI is too generic, does it hurt usability? Can a DSL strike the right balance between automation and user experience? ✅ Regeneration vs. Continuous Development – Should teams work exclusively in the DSL, or also refine the code it generates? How to handle sync issues when regenerating applications. ✅ Turning Docs into Code with a DSL Converter – Automating workflows by transforming team documentation into executable code. ✅ Mob Automationist Role Inception – Is the next evolution of Mob Programming automating the automation? ✅ ZOMBIE Test Generation & Nested Python Dictionaries – How automated testing fits into the DSL-driven workflow and whether a DSL can be as simple as a structured Python dictionary.

Join us for this conversation on the vital issue of Online Child Protection, spotlighting the leadership and efforts of key figures from the Council of International Schools (CIS). Jane Larson, Executive Director of CIS, alongside Dan Furness, Head of Safeguarding and Wellbeing at CIS, are at the forefront of this work, shaping policies and providing guidance to international schools. We also hear from Leila Holmyard, Global Safeguarding Consultant, researcher and current Safeguarding Lead at Frankfurt International School, who shares practical insights from her PhD research and experience. Together, they address the current challenges in safeguarding children online, tips for prevention and response, and how school leaders can create safer digital environments within their communities. About Jane Larsson Executive Director, CIS Jane Larsson has led the Council of International Schools (CIS) as Executive Director since her appointment in 2010. Over the past 25 years, Jane has led the international education community with a focus on the development of collaborative partnerships to enable and support educational exchange and the development of international and intercultural perspective. Prior to her appointment at CIS, Jane was Direc­tor of International Partnerships with the Visiting International Faculty Program (VIF) in Chapel Hill, North Carolina, where she led outreach to promote international educational exchange, establishing relationships with minis­tries of education, universities, internation­al schools and educational associations.  She began her career in international education as the Director of Educational Staffing and Publications for International Schools Services (ISS) providing recruitment services and resources to international schools. Jane lends her voice to key topics shaping the future of international education, those which enable school and university communities to provide socially responsible leadership as they continually develop their programs. She currently serves as Chair of the International Taskforce on Child Protection and on the Board of Directors of the International Commission Advancing Independent School Accreditation (ICAISA). LinkedIn: https://www.linkedin.com/in/janelarssoncis/  About Leila Holmyard Safeguarding Lead, Frankfurt International School Leila Holmyard has extensive professional experience in safeguarding and child protection in international schools. She is a safeguarding consultant for a number of international schools and organisations, including the United World Colleges, Council of International Schools and Faria Education Group, as well as being Safeguarding Lead at Frankfurt International School. Leila has worked with international schools across the world and conducted her PhD research on safeguarding in international schools in Europe, Asia and Africa. She is also a volunteer for the International Task Force on Child Protection, WomenEd Germany, and the ISS Diversity Collaborative.  LinkedIn: https://www.linkedin.com/in/leila-holmyard-04767995/    About Dan Furness Head of Safeguarding and Well-being, CIS Dan Furness joined CIS in September 2023. Dan's primary responsibility as Head of Safeguarding and Well-being is to support the CIS membership community as it identifies and addresses child protection and student well-being challenges. This includes designing and delivering professional learning opportunities such as the Foundation and Deep Dive workshops in Child Protection and Safeguarding. Dan is available to support schools to strengthen their culture and systems, developing resources to educate and promote effective practices, and providing thought leadership and partnership across the international education sector. Prior to joining CIS, Dan worked in international schools in South Africa, South Korea, Germany and the Netherlands leading boarding, student support and safeguarding. Dan has also worked as an independent consultant in safeguarding and has a history of supporting staff professional development over a range of safeguarding-related areas including the following: child protection and safeguarding; safer handling and restraint; restorative justice and shared concern; response to intervention (a tiered approach to school support); and inclusion, diversity, equity and anti-racism. He has also provided supervision for other DSLs and school counsellors. Dan is a qualified counsellor and social worker, with an undergraduate degree and masters in social work from the University of Bath, and a second masters in educational leadership and management from the University of Buckingham. LinkedIn: https://www.linkedin.com/in/dan-furness/?originalSubdomain=nl   Resources https://www.cois.org/about-cis/child-protection/resources https://www.icmec.org/icmec-resources/ https://www.cois.org/about-cis/child-protection/resources https://www.childnet.com/help-and-advice/sextortion/ https://www.childnet.com/safer-internet-day/ https://takeitdown.ncmec.org/  https://www.nspcc.org.uk/keeping-children-safe/online-safety/online-reporting/report-remove/  Generative AI: A whole school approach to safeguarding children John Mikton on Social Media LinkedIn: https://www.linkedin.com/in/jmikton/ Twitter: https://twitter.com/jmikton Web: beyonddigital.org Dan Taylor on social media: LinkedIn: https://www.linkedin.com/in/appsevents  Twitter: https://twitter.com/appdkt  Web: www.appsedu.com  Listen on: iTunes / Podbean / Stitcher / Spotify / YouTube Would you like to have a free 1 month trial of the new Google Workspace Plus (formerly G Suite Enterprise for Education)? Just fill out this form and we'll get you set up bit.ly/GSEFE-Trial

On today's episode we talk about the Big German's trip to the Big E without us and he talks about his experience including what he ate. Also we talk about Tyler's little outburst during what was supposed to be a friendly game of wiffle ball and we talk about Ohtani's impact on the DP Show. Enjoy! Hosted on Acast. See acast.com/privacy for more information.

The gang gets together to discuss a number of topics, including the bizarre Warminster UFO abduction case. Also, the Case of the Vanishing Punk Star, Raven explains what “DSLs” are plus more reasons to hate cats. (Adult content). Special guest: Susy BastilleBecome a supporter of this podcast: https://www.spreaker.com/podcast/paranormal-uk-radio-network--4541473/support.

The gang gets together to discuss a number of topics, including the bizarre Warminster UFO abduction case. Also, the Case of the Vanishing Punk Star, Raven explains what “DSLs” are plus more reasons to hate cats. (Adult content). Special guest: Susy Bastille. Mack Maloney Online: Website - https://www.mackmaloney.com/ Facebook - https://www.facebook.com/WingmanMack/ Twitter - https://twitter.com/MilitaryXFiles Twitter - https://twitter.com/WingmanMack Amazon – https://amzn.to/2IlFRkq  

Today on the show Erick's long time friend Ryan Gonyon stopped by. Erick didn't know what to cook because Ryan been on the West Coast for awhile. How will you pick up the soap? Plus Erick would might some DSLs at the 10 year mark. Drugs in the family, the comic book movies and so much more on the show today.   Links: Erick Feiling IG Zack Stack IG Comedian Erick Feiling Ryan Gonyon

An airhacks.fm conversation with Erik C. Thauvin (@ethauvin) about: previously Erik on "#287 How Linkblog Happened", from Rife to bld, Gert on "#284 No Dependencies--Or How Rife 2 and Bld Happened", the simplicity and power of bld compared to Gradle and Maven, using Java as the build language without any DSLs or plugins, the advantages of a direct approach to building and running tools, converting projects from Gradle to bld and the resulting simplification, creating extensions for bld to integrate with various tools and libraries, the benefits of using pure Java for build files and the flexibility it provides, the speed of bld and the underlying Java compilers, ideas for future improvements and features in bld, the philosophy behind bld and its focus on simplicity and developer productivity, the potential for using bld as a scripting tool and automation platform, the extension mechanism in bld and how it leverages the builder pattern, the performance gains of using bld over traditional build tools, the aesthetics and user experience of bld, the history of Java compilers and the evolution of Java desktop applications Erik C. Thauvin on twitter: @ethauvin

This week: The Lost Boys, Edward Herrmann, Joel Schumacher, The Frog Brothers, Wolf of Wall Street, Baseball Movies, Brad Pitt, DSLs, The Matrix, Schindler's List, The Zone of Interest, Surf Nazis, A Particular Anti-Semite, The World's Largest Telephone, New Hampshire BBQ?, Avocado Salad, Moose Collisions, Eclipse 2024.  Recorded April 7th, 2024 We would be honored by your support: https://anchor.fm/sushi-jackknife/support or buy us a beer via Paypal: sushijackknife@gmail.com  Nathan and Justin's Music: https://judystruckstop.bandcamp.com/ As Always:  Twitter: @SushiJackknife @badlandsbadley @Bob_ThangPod Email: sushijackknife@gmail.com instagram: justindrakecroft, siddandthefinches --- Support this podcast: https://podcasters.spotify.com/pod/show/sushi-jackknife/support

Dr. Paul Lessard and his collaborators have written a paper on "Categorical Deep Learning and Algebraic Theory of Architectures". They aim to make neural networks more interpretable, composable and amenable to formal reasoning. The key is mathematical abstraction, as exemplified by category theory - using monads to develop a more principled, algebraic approach to structuring neural networks. We also discussed the limitations of current neural network architectures in terms of their ability to generalise and reason in a human-like way. In particular, the inability of neural networks to do unbounded computation equivalent to a Turing machine. Paul expressed optimism that this is not a fundamental limitation, but an artefact of current architectures and training procedures. The power of abstraction - allowing us to focus on the essential structure while ignoring extraneous details. This can make certain problems more tractable to reason about. Paul sees category theory as providing a powerful "Lego set" for productively thinking about many practical problems. Towards the end, Paul gave an accessible introduction to some core concepts in category theory like categories, morphisms, functors, monads etc. We explained how these abstract constructs can capture essential patterns that arise across different domains of mathematics. Paul is optimistic about the potential of category theory and related mathematical abstractions to put AI and neural networks on a more robust conceptual foundation to enable interpretability and reasoning. However, significant theoretical and engineering challenges remain in realising this vision. Please support us on Patreon. We are entirely funded from Patreon donations right now. https://patreon.com/mlst If you would like to sponsor us, so we can tell your story - reach out on mlstreettalk at gmail Links: Categorical Deep Learning: An Algebraic Theory of Architectures Bruno Gavranović, Paul Lessard, Andrew Dudzik, Tamara von Glehn, João G. M. Araújo, Petar Veličković Paper: https://categoricaldeeplearning.com/ Symbolica: https://twitter.com/symbolica https://www.symbolica.ai/ Dr. Paul Lessard (Principal Scientist - Symbolica) https://www.linkedin.com/in/paul-roy-lessard/ Interviewer: Dr. Tim Scarfe TOC: 00:00:00 - Intro 00:05:07 - What is the category paper all about 00:07:19 - Composition 00:10:42 - Abstract Algebra 00:23:01 - DSLs for machine learning 00:24:10 - Inscrutibility 00:29:04 - Limitations with current NNs 00:30:41 - Generative code / NNs don't recurse 00:34:34 - NNs are not Turing machines (special edition) 00:53:09 - Abstraction 00:55:11 - Category theory objects 00:58:06 - Cat theory vs number theory 00:59:43 - Data and Code are one in the same 01:08:05 - Syntax and semantics 01:14:32 - Category DL elevator pitch 01:17:05 - Abstraction again 01:20:25 - Lego set for the universe 01:23:04 - Reasoning 01:28:05 - Category theory 101 01:37:42 - Monads 01:45:59 - Where to learn more cat theory

In this episode of the TTS Talking Early Years podcast, Alistair Bryce-Clegg continues the conversation around safeguarding in the Early Years with Ann-Marie Christian, a safeguarding consultant, speaker, and author.  Ann-Marie and Alistair delve into the importance of safeguarding policies, emphasising the need for practitioners to be aware of national and local legislation, guidance, and procedures. Ann-Marie highlights the significance of the document "Keeping Children Safe in Education", as it provides a legal framework for safeguarding practices. She stresses the importance of clear and transparent safeguarding policies that should be regularly reviewed and updated.  The episode also explores the role of designated safeguarding leads (DSLs) and the responsibilities they carry, such as managing referrals, attending meetings, and ensuring that safeguarding remains a top priority within the setting.  

Stephanie shares about her vacation at Disney World, particularly emphasizing the technological advancements in the park's mobile app that made her visit remarkably frictionless. Joël had a conversation about a topic he loves: units of measure, and he got to go deep into the idea of dimensional analysis with someone this week. Together, Joël and Stephanie talk about module documentation within software development. Joël shares his recent experience writing module docs for a Ruby project using the YARD documentation system. He highlights the time-consuming nature of crafting good documentation for each public method in a class, emphasizing that while it's a demanding task, it significantly benefits those who will use the code in the future. They explore the attributes of good documentation, including providing code examples, explaining expected usage, suggesting alternatives, discussing edge cases, linking to external resources, and detailing inputs, outputs, and potential side effects. Multidimensional numbers episode (https://bikeshed.thoughtbot.com/416) YARD docs (https://yardoc.org/) New factory_bot documentation (https://thoughtbot.com/blog/new-docs-for-factory_bot) Dash (https://kapeli.com/dash) Solargraph (https://solargraph.org/) Transcript:  JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn, and together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I recently was on vacation, and I'm excited [chuckles] to tell our listeners all about it. I went to Disney World [laughs]. And honestly, I was especially struck by the tech that they used there. As a person who works in tech, I always kind of have a little bit of a different experience knowing a bit more about software, I suppose, than just your regular person [laughs], citizen. And so, at Disney World, I was really impressed by how seamlessly the like, quote, unquote, "real life experience" integrated with their use of their branded app to pair with, like, your time at the theme park. JOËL: This is, like, an app that runs on your mobile device? STEPHANIE: Yeah, it's a mobile app. I haven't been to Disney in a really long time. I think the last time I went was just as a kid, like, this was, you know, pre-mobile phones. So, I recall when you get into the line at a ride, you can skip the line by getting what's called a fast pass. And so, you kind of take a ticket, and it tells you a designated time to come back so that you could get into the fast line, and you don't have to wait as long. And now all this stuff is on your mobile app, and I basically did not wait in [laughs] a single line for more than, like, five minutes to go on any of the rides I wanted. It just made a lot of sense that all these things that previously had more, like, physical touchstones, were made a bit more convenient. And I hesitate to use the word frictionless, but I would say that accurately describes the experience. JOËL: That's kind of amazing; the idea that you can use tech to make a place that's incredibly busy also feel seamless and where you don't have to wait in line. STEPHANIE: Yeah and, actually, I think the coolest part was it blended both your, like, physical experience really well with your digital one. I think that's kind of a gripe I have as a technologist [laughs] when I'm just kind of too immersed in my screen as opposed to the world around me. But I was really impressed by the way that they managed to make it, like, a really good supplement to your experience being there. JOËL: So, you're not hyped for a future world where you can visit Disney in VR? STEPHANIE: I mean, I just don't think it's the same. I rode a ride [laughs] where it was kind of like a mini roller coaster. It was called Expedition Everest. And there's a moment, this is, like, mostly indoors, but there's a moment where the roller coaster is going down outside, and you're getting that freefall, like, drop feeling in your stomach. And it also happened to be, like, drizzling that day that we were out there, and I could feel it, you know, like, pelting my head [laughs]. And until VR can replicate that experience [chuckles], I still think that going to Disney is pretty fun. JOËL: Amazing. STEPHANIE: So, Joël, what's new in your world? JOËL: I'm really excited because I had a conversation about a topic that I like to talk about: units of measure. And I got to go deep into the idea of dimensional analysis with someone this week. This is a technique where you can look at a calculation or a function and sort of spot-check whether it's correct by looking at whether the unit for the measure that would come out match what you would expect. So, you do math on the units and ignore the numbers coming into your formula. And, you know, let's say you're calculating the speed of something, and you get a distance and the amount of time it took you to take to go that distance. And let's say your method implements this as distance times time. Forget about doing the actual math with the numbers here; just look at the units and say, okay, we've got our meters, and we've got our seconds, and we're multiplying them together. The unit that comes out of this method is meters times seconds. You happen to know that speeds are not measured in meters times seconds. They're measured in meters divided by seconds or meters per second. So, immediately, you get a sense of, like, wait a minute, something's wrong here. I must have a bug in my function. STEPHANIE: Interesting. I'm curious how you're representing that data to, like, know if there's a bug or not. In my head, when you were talking about that, I'm like, oh yeah, I definitely recall doing, like, math problems for homework [laughs] where I had, you know, my meters per second. You have your little fractions written out, and then when you multiply or divide, you know how to, like, deal with the units on your piece of paper where you're showing your work. But I'm having a hard time imagining what that looks like as a programmer dealing with that problem. JOËL: You could do it just all in your head based off of maybe some comments that you might have or the name of the variable or something. So, you're like, okay, well, I have a distance in meters and a time in seconds, and I'm multiplying the two. Therefore, what should be coming out is a value that is in meters times seconds. If you want to get fancier, you can do things with value objects of different types. So, you say, okay, I have a distance, and I have a time. And so, now I have sort of a multiplication of a distance and a time, and sort of what is that coming out as? That can sometimes help you prevent from having some of these mistakes because you might have some kind of error that gets raised at runtime where it's like, hey, you're trying to multiply two units that shouldn't be multiplied, or whatever it is. You can also, in some languages, do this sort of thing automatically at the type level. So, instead of looking at it yourself and sort of inferring it all on your own based off of the written code, languages like F# have built-in unit-of-measure systems where once you sort of tag numbers as just being of a particular unit of measure, any time you do math with those numbers, it will then tag the result with whatever compound unit comes from that operation. So, you have meters, and you have seconds. You divide one by the other, and now the result gets tagged as meters per second. And then, if you have another calculation that takes the output of the first one and it comes in, you can tell the compiler via type signature, hey, the input for this method needs to be in meters per second. And if the other calculation sort of automatically builds something that's of a different unit, you'll get a compilation error. So, it's really cool what it can do. STEPHANIE: Yeah, that is really neat. I like all of those built-in guardrails, I suppose, to help you, you know, make sure that your answer is correct. Definitely could have used that [chuckles]. Turns out I just needed a calculator to take my math test with [laughs]. JOËL: I think what I find valuable more than sort of the very rigorous approach is the mindset. So, anytime you're dealing with numbers, thinking in your mind, what is the unit of this number? When I do math with it with a different number, is it the same unit? Is it a different unit? What is the unit of the thing that's coming out? Does this operation make sense in the domain of my application? Because it's easy to sometimes think you're doing a math operation that makes sense, and then when you look at the unit, you're like, wait a minute, this does not make sense. And I would go so far as to say that, you know, you might think, oh, I'm not doing a physics app. I don't care about units of measure. Most numbers in your app that are actually numbers are going to have some kind of unit of measure associated to them. Occasionally, you might have something where it's just, like, a straight-up, like, quantity or something like that. It's a dimensionless number. But most things will have some sort of unit. Maybe it's a number of dollars. Maybe it is an amount of time, a duration. It could be a distance. It could be all sorts of things. Typically, there is some sort of unit that should attach to it. STEPHANIE: Yeah. That makes sense that you would want to be careful about making sure that your mathematical operations that you're doing when you're doing objects make sense. And we did talk about this in the last episode about multidimensional numbers a little bit. And I suppose I appreciate you saying that because I think I have mostly benefited from other people having thought in that mindset before and encoding, like I mentioned, those guardrails. So, I can recall an app where I was working with, you know, some kind of currency or money object, and that error was raised when I would try to divide by zero because rather than kind of having to find out later with some, not a number or infinite [laughs] amount of money bug, it just didn't let me do that. And that wasn't something that I had really thought about, you know, I just hadn't considered that zero value edge case when I was working on whatever feature I was building. JOËL: Yeah, or even just generally the idea of dividing money. What does that even mean? Are you taking an amount of money and splitting it into two equivalent piles to split among multiple people? That kind of makes sense. Are you dividing money by another money value? That's now asking a very different kind of question. You're asking, like, what is the ratio between these two, I guess, piles of money if we want to make it, you know, in the physical world? Is that a thing that makes sense in your application? But also, realize that that ratio that you get back is not itself an amount of money. And so, there are some subtle bugs that can happen around that when you don't keep track of what your quantities are. So, this past week, I've been working on a project where I ended up having to write module docs for the code in question. This is a Ruby project, so I'm writing docs using the YARD documentation system, where you effectively just write code comments at the sort of high level covering the entire class and then, also, individual documentation comments on each of the methods. And that's been really interesting because I have done this in other languages, but I'd never done it in Ruby before. And this is a piece of code that was kind of gnarly and had been tricky for me to figure out. And I figured that a couple of these classes could really benefit from some more in-depth documentation. And I'm curious, in your experience, Stephanie, as someone who's writing code, using code from other people, and who I assume occasionally reads documentation, what are the things that you like to see in good sort of method-level docs? STEPHANIE: Personally, I'm really only reading method-level docs when, you know, at this point, I'm, like, reaching for a method. I want to figure out how to use it in my use case right now [laughs]. So, I'm going to search API documentation for it. And I really am just scanning for inputs, especially, I think, and maybe looking at, you know, some potential various, like, options or, like, variations of how to use the method. But I'm kind of just searching for that at a glance and then moving on [laughs] with my day. That is kind of my main interaction with module docs like that, and especially ones for Ruby and Rails methods. JOËL: And for clarity's sake, I think when we're talking about module docs here, I'm generally thinking of, like, any sort of documentation that sort of comments in code meant to document. It could be the whole modular class. It could be on a per-method level, things like RDoc or YARD docs on Ruby classes. You used the word API docs here. I think that's a pretty similar idea. STEPHANIE: I really haven't given the idea of writing this kind of documentation a lot of thought because I've never had to do too much of it before, but I know, recently, you have been diving deep into it because, you know, like you said, you found these classes that you were working with a bit ambiguous, I suppose, or just confusing. And I'm wondering what kind of came out of that journey. What are some of the most interesting aspects of doing this exercise? JOËL: And one of the big ones, and it's not a fun one, but it is time-consuming. Writing good docs per method for a couple of classes takes a lot of time, and I understand why people don't do it all the time. STEPHANIE: What kinds of things were you finding warranted that time? Like, you know, you had to, at some point, decide, like, whether or not you're going to document any particular method. And what were some of the things you were looking out for as good reasons to do it? JOËL: I was making the decisions to document or not document on a class level, and then every public method gets documentation. If there's a big public API, that means every single one of those methods is getting some documentation comments, explaining what they do, how they're meant to be used, things like that. I think my kind of conclusion, having worked with this, is that the sort of sweet spot for this sort of documentation is for anything that is library-like, so a lot of things that maybe would go into a Rails lib directory might make sense. Anything you're turning into a gem that probably makes sense. And sometimes you have things in your Rails codebase that are effectively kind of library-like, and that was the case for the code that I was dealing with. It was almost like a mini ORM style kind of ActiveRecord-inspired series of base classes that had a bunch of metaprogramming to allow you to write models that were backed by not a database but a headless CMS, a content management system. And so, these classes are not extracted to the lib directory or, like, made into a gem, but they feel very library-esque in that way. STEPHANIE: Library-like; I like that descriptor a lot because it immediately made me think of another example of a time when I've used or at least, like, consumed this type of documentation in a, like, SaaS repo. Rather, you know, I'm not really seeing that level of documentation around domain objects, but I noticed that they really did a lot of extending of the application record class because they just had some performance needs that they needed to write some, like, custom code to handle. And so, they ended up kind of writing a lot of their own ORM-like methods for just some, like, custom callbacks on persisting and some just, like, bulk insertion functionality. And those came with a lot of different ways to use them. And I really appreciated that they were heavily documented, kind of like you would expect those ActiveRecord methods to be as well. JOËL: So, I've been having some conversations with other members at thoughtbot about when they like to use the style of module doc. What are some of the alternatives? And one that kept coming up for different people that they would contrast with this is what they would call the big README approach, and this could be for a whole gem, or it could be maybe some directory with a few classes in your application that's got a README in the root of the directory. And instead of documenting each method, you just write a giant README trying to answer sort of all of the questions that you anticipate people will ask. Is that something that you've seen, and how do you feel about that as a tool when you're looking for help? STEPHANIE: Yes. I actually really like that style of documentation. I find that I just want examples to get me started, especially; I guess this is especially true for libraries that I'm not super familiar with but need to just get a working knowledge about kind of immediately. So, I like to see examples, the getting started, the just, like, here's what you need to know. And as I start to use them, that will get me rolling. But then, if I find I need more details, then I will try to seek out more specific information that might come in the form of class method documentation. But I'm actually thinking about how FactoryBot has one of the best big README-esque [laughs] style of documentation, and I think they did a really big refresh of the docs not too long ago. It has all that high-level stuff, and then it has more specific information on how to use, you know, the most common methods to construct your factories. But those are very detailed, and yet they do sit, like, separately from inline, like, code documentation in the style of module docs that we're talking about. So, it is kind of an interesting mix of both that I think is helpful for me personally when I want both the “what do I need to know now?” And the, “like, okay, I know where to look for if I need something a little more detailed.” JOËL: Yeah. The two don't need to be mutually exclusive. I thought it was interesting that you mentioned how much examples are valuable to you because...I don't know if this is controversial, but an opinion that I have about sort of per-method documentation is that you should always default to having a code example for every method. I don't care how simple it is or how obvious it is what it does. Show me a code example because, as a developer, examples are really, really helpful. And so, seeing that makes documentation a lot more valuable than just a couple of lines that explain something that was maybe already obvious from the title of the method. I want to see it in action. STEPHANIE: Interesting. Do you want to see it where the method definition is? JOËL: Yes. Because sometimes the method definition, like, the implementation, might be sort of complex. And so, just seeing a couple of examples, like, oh, you call with this input, you get that. Call with this other input; you get this other thing. And we see this in, you know, some of the core docs for things like the enumerable methods where having an example there to be like, oh, so that's how map works. It returns this thing under these circumstances. That sort of thing is really helpful. And then, I'll try to do it at a sort of a bigger level for that class itself. You have a whole paragraph about here's the purpose of the class. Here's how you should use it. And then, here's an example of how you might use it. Particularly, if this is some sort of, like, base class you're meant to inherit from, here's the circumstances you would want to subclass this, and then here's the methods you would likely want to override. And maybe here are the DSLs you might want to have and to kind of package that in, like, a little example of, in this case, if you wanted a model that read from the headless CMS, here's what an example of such a little model might look like. So, it's kind of that putting it all together, which I think is nice in the module docs. It could probably also live in the big README at some level. STEPHANIE: Yeah. As you are saying that, I also thought about how I usually go search for tests to find examples of usage, but I tend to get really overwhelmed when I see inline, like, that much inline documentation. I have to, like, either actively ignore it, choose to ignore it, or be like, okay, I'm reading this now [laughs]. Because it just takes up so much visual space, honestly. And I know you put a lot of work into it, a lot of time, but maybe it's because of the color of my editor theme where comments are just that, like, light gray [laughs]. I find them quite easy to just ignore. But I'm sure there will be some time where I'm like, okay, like, if I need them, I know they're there. JOËL: Yeah, that is, I think, a downside, right? It makes it harder to browse the code sometimes because maybe your entire screen is almost taken up by documentation, and then, you know, you have one method up, and you've got to, like, scroll through another page of documentation before you hit the next method, and that makes it harder to browse. And maybe that's something that plays into the idea of that separation between library-esque code versus application code. When you browse library-esque code, when you're actually browsing the source, you're probably doing it for different reasons than you would for code in your application because, at that point, you're effectively source diving, sometimes being like, oh, I know this class probably has a method that will do the thing I want. Where is it? Or you're like, there's an edge case I don't understand on this method. I wonder what it does. Let me look at the implementation. Or even some existing code in the app is using this library method. I don't know what it does, but they call this method, and I can't figure out why they're using it. Let me look at the source of the library and see what it does under the hood. STEPHANIE: Yeah. I like the distinction of it is kind of a different mindset that you're reading the code at, where, like, sometimes my brain is already ready to just read code and try to figure out inputs and outputs that way. And other times, I'm like, oh, like, I actually can't parse this right now [chuckles]. Like, I want to read just English, like, telling me what to expect or, like, what to look out for, especially when, like you said, I'm not really, like, trying to figure out some strange bug that would lead me to diving deep in the source code. It's I'm at the level where I'm just reaching for a method and wanting to use it. We're writing these YARD docs. I think I also heard you mention that you gave some, like, tips or maybe some gotchas about how to use certain methods. I'm curious why that couldn't have been captured in a more, like, self-documenting way. Or was there a way that you could have written the code for that not to have been needed as a comment or documented as that? And was there a way that method names could have been clear to signal, like, the intention that you were trying to convey through your documentation? JOËL: I'm a big fan of using method names as a form of documentation, but they're frequently not good enough. And I think comments, whether they're just regular inline comments or more official documentation, can be really good to help avoid sort of common pitfalls. And one that I was working with was, there were two methods, and one would find by a UID, so it would search up a document by UID. And another one would search by ID. And when I was attempting to use these before I even started documenting, I used the wrong one, and it took me a while to realize, oh wait, these things have both UIDs and IDs, and they're slightly different, and sometimes you want to use one or the other. The method names, you know, said like, "Find by ID" or "Find by UID." I didn't realize there were both at the time because I wasn't browsing the source. I was just seeing a place where someone had used it. And then, when I did find it in the source, I'm like, well, what is the difference? And so, something that I did when I wrote the docs was sort of call out on both of those methods; by the way, there is also find by UID. If you're searching by UID, consider using the other one. If you don't know what the difference is, here's a sentence summarizing the difference. And then, here's a link to external documentation if you want to dive into the nitty gritty of why there are two and what the differences are. And I think that's something you can't capture in just a method name. STEPHANIE: Yeah, that's true. I like that a lot. Another use case you can think of is when method names are aliased, and it's like, I don't know how I would have possibly known that until I, you know, go through the journey of realizing [laughs] that these two methods do the same thing or, like, stumbling upon where the aliasing happens. But if that were captured in, like, a little note when I'm in, like, a documentation viewer or something, it's just kind of, like, a little tidbit of knowledge [laughs] that I get to gain along the way that ends up, you know, being useful later because I will have just kind of...I will likely remember having seen something like that. And I can at least start my search with a little bit more context than when you don't know what you don't know. JOËL: I put a lot of those sorts of notes on different methods. A lot of them are probably based on a personal story where I made a mistaken assumption about this method, and then it burned me. But I'm like, okay, nobody else is going to make that mistake. By the way, if you think this is what the method does, it does something slightly different and, you know, here's why you need to know that. STEPHANIE: Yeah, you're just looking out for other devs. JOËL: And, you know, trying to, like, take my maybe negative experience and saying like, "How can I get value out of that?" Maybe it doesn't feel great that I lost an hour to something weird about a method. But now that I have spent that hour, can I get value out of it? Is the sort of perspective I try to have on that. So, you mentioned kind of offhand earlier the idea of a documentation viewer, which would be separate than just reading these, I guess, code comments directly in your code editor. What sort of documentation viewers do you like to use? STEPHANIE: I mostly search in my browser, you know, just the official documentation websites for Rails, at least. And then I know that there are also various options for Ruby as well. And I think I had mentioned it before but using DuckDuckGo as my search engine. I have nice bang commands that will just take me straight to the search for those websites, which is really nice. Though, I have paired with people before who used various, like, macOS applications to do something similar. I think Alfred might have some built-in workflows for that. And then, a former co-worker used to use one called Dash, that I have seen before, too. So, it's another one of those just handy just, like, search productivity extensions. JOËL: You mentioned the Rails documentation, and this is separate from the guides. But the actual Rails docs are generated from comments like this inline in code. So, all the different ActiveRecord methods, when you search on the Rails documentation you're like, oh yeah, how does find_by work? And they've got a whole, like, paragraph explaining how it works with a couple of examples. That's this kind of documentation. If you open up that particular file in the source code, you'll find the comments. And it makes sense for Rails because Rails is more of, you know, library-esque code. And you and I search these docs pretty frequently, although we don't tend to do it, like, by opening the Rails gem and, like, grepping through the source to find the code comment. We do it through either a documentation site that's been compiled from that source or that documentation that's been extracted into an offline tool, like you'd mentioned, Dash. STEPHANIE: Yeah, I realized how conflicting, I suppose, it is for me to say that I find inline documentation really overwhelming or visually distracting, whereas I recognize that the only reason I can have that nice, you know, viewing experience is because documentation viewers use the code comments in that format to be generated. JOËL: I wonder if there's like a sort of...I don't know what this pattern is called, but a bit of a, like, middle-quality trap where if you're going to source dive, like, you'd rather just look at the code and not have too much clutter from sort of mediocre comments. But if the documentation is really good and you have the tooling to read it, then you don't even need to source dive at all. You can just read the documentation, and that's sufficient. So, both extremes are good, but that sort of middle kind of one foot in each camp is sort of the worst of both worlds experience. Because I assume when you look for Rails documentation, you never open up the actual codebase to search. The documentation is good enough that you don't even need to look at the files with the comments and the code. STEPHANIE: Yeah, and I'm just recalling now there's, like, a UI feature to view the source from the documentation viewer page. JOËL: Yes. STEPHANIE: I use that actually quite a bit if the comments are a little bit sparse and I need just the code to supplement my understanding, and that is really nice. But you're right, like, I very rarely would be source diving, unless it's a last resort [laughs], let's be honest. JOËL: So, we've talked about documentation viewers and how that can make things nice, and you're able to read documentation for things. But a lot of other tooling can benefit from this sort of model documentation as well, and I'm thinking, in particular, Solargraph, which is Ruby's language server protocol. And it has plugins for VS Code, for Vim, for a few different editors, takes advantage of that to provide all sorts of things. So, you can get smart expansion of code and good suggestions. You can get documentation for what's under your cursor. Maybe you're reading somebody else's code that they've written, and you're like, why are they calling this parameterized method here? What does that even do? Like, in VS Code, you could just hover over it, and it will pop up and show you documentation, including the, like, inputs and return types, and things like that. That's pretty nifty. STEPHANIE: Yeah, that is cool. I use VS Code, but I've not seen that too much yet because I don't think I've worked in enough codebases with really comprehensive [laughs] YARD docs. I'm actually wondering, tooling-wise, did you use any helpful tools when you were writing them or were you hand-documenting each? JOËL: I was hand-documenting everything. STEPHANIE: Class. Okay. JOËL: The thing that I did use is the YARD gem, which you don't need to have the gem to write YARD-style documentation. But if you have the gem, you can run a local server and then preview a documentation site that is generated from your comments that has everything in there. And that was incredibly helpful for me as I was trying to sort of see an overview of, okay, what would someone who's looking at the docs generated from this see when they're trying to look for what the documentation of a particular method does? STEPHANIE: Yeah, and that's really nice. JOËL: Something that I am curious about that I've not really had a lot of experience with is whether or not having extra documentation like that can help AI tools give us better suggestions. STEPHANIE: Yeah, I don't know the answer to that either, but I would be really curious to know if that is already something that happens with something like Copilot. JOËL: Do better docs help machines, or are they for humans only? STEPHANIE: Whoa, that's a very [laughs] philosophical question, I think. It would make sense, though, that if we already have ways to parse and compile this kind of documentation, then I can see that incorporating them into the types of, like, generative problems that AI quote, unquote "solves" [chuckles] would be really interesting to find out. But anyone listening who kind of knows the answer to that or has experience working with AI tools and various types of code comment documentation would be really curious to know what your experience is like and if it improves your development workflow. So, for people who might be interested in getting better at documenting their code in the style of module docs, what would you say are some really great attributes of good documentation in this form? JOËL: I think, first of all, you have to write from the motivation of, like, if you were confused and wanting to better understand what a method does, what would you like to see? And I think coming from that perspective, and that was, in my case, I had been that person, and then I was like, okay, now that I've figured it out, I'm going to write it so that the next person is not confused. I have five or six things that I think were really valuable to add to the docs, a few of which we've already mentioned. But rapid fire, first of all, code example. I love code examples. I want a code example on every method. An explanation of expected usage. Here's what the method does. Here's how we expect you to use this method in any extra context about sort of intended use. Callouts for suggested alternatives. If there are methods that are similar, or there's maybe a sort of common mistake that you would reach for this method, put some sort of call out to say, "Hey, you probably came here trying to do X. If that's what you were actually trying to do, you should use method Y." Beyond that, a discussion of edge cases, so any sort of weird ways the method behaves. You know, when you pass nil to it, does it behave differently? If you call it in a different context, does it behave differently? I want to know that so that I'm not totally surprised. Links to external resources–really great if I want to, like, dig deeper. Is this method built on some sort of, like, algorithm that's documented elsewhere? Please link to that algorithm. Is this method integrating with some, like, third-party API? You know, they have some documentation that we could link to to go deeper into, like, what these search options do. Link to that. External links are great. I could probably find it by Googling myself, but you are going to make me very happy as a developer if you already give me the link. You'd mentioned capturing inputs and outputs. That's a great thing to scan for. Inputs and outputs, though, are more sometimes than just the arguments and return values. Although if we're talking about arguments, any sort of options hash, please document the keys that go in that because that's often not obvious from the code. And I've spent a lot of time source diving and jumping between methods trying to figure out like, what are the options I can pass to this hash? Beyond the explicit inputs and outputs, though, anything that is global state that you rely on. So, do you need to read something from an environment variable or even a global variable or something like that that might make this method behave differently in different situations? Please document that. Any situations where you might raise an error that I might not expect or that I might want to rescue from, let me know what are the potential errors that might get raised. And then, finally, any sorts of side effects. Does this method make a network call? Are you writing to the file system? I'd like to know that, and I'd have to, like, figure it out by trial and error. And sometimes, it will be obvious in just the description of the method, right? Oh, this method pulls data from a third-party API. That's pretty clear. But maybe it does some sort of, like, caching in the background or something to a file that's not really important. But maybe I'm trying to do a unit test that involves this, and now, all of a sudden, I have to do some weird stubbing. I'd like to know that upfront. So, those are kind of all the things I would love to have in my sort of ideal documentation comment that would make my life easier as a developer when trying to use some code. STEPHANIE: Wow. What a passionate plea [laughs]. I was very into listening to you list all of that. You got very animated. And it makes a lot of sense because I feel like these are kind of just the day-to-day developer issues we run into in our work and would be so awesome if, especially as the, you know, author where you have figured all of this stuff out, the author of a, you know, a method or a class, to just kind of tell us these things so we don't have to figure it out ourselves. I guess I also have to respond to that by saying, on one hand, I totally get, like, you want to be saved [chuckles] from those common pitfalls. But I think that part of our work is just going through that and playing around and exploring with the code in front of us, and we learn all of that along the way. And, ultimately, even if that is all provided to you, there is something about, like, going through it yourself that gives you a different perspective on it. And, I don't know, maybe it's just my bias against [laughs] all the inline text, but I've also seen a lot of that type of information captured at different levels of documentation. So, maybe it is a Confluence doc or in a wiki talking about, you know, common gotchas for this particular problem that they were trying to solve. And I think what's really cool is that, you know, everyone can kind of be served and that people have different needs that different styles of documentation can meet. So, for anyone diving deep in the source code, they can see all of those examples inline. But, for me, as a big Googler [laughs], I want to see just a nice, little web app to get me the information that I need to find. I'm happy having that a little bit more, like, extracted from my source code. JOËL: Right. You don't want to have to read the source code with all the comments in it. I think that's a fair criticism and, yeah, probably a downside of this. And I'm wondering, there might be some editor tooling that allows you to just collapse all comments and hide them if you wanted to focus on just the code. STEPHANIE: Yeah, someone, please build that for me. That's my passionate plea [laughs]. And on that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Bye. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Six hundred consecutive weeks is a long time and we had every intention of celebrating this milestone with dignity and class unlike the previous 599 episodes, but then we invited a washed up game show host to hang out with us and somewhere along the way, it all went horribly wrong. On Episode 600 of Trick or Treat Radio we are joined by Rocky to play a new spin on a classic game show, we induct our first entrants into the Trick or Treat Radio Pantheon, and we put our friendships to the test. So grab a lump of coke, help us #ReleaseTheExtendedTuck, and strap on for the world's most dangerous podcast!Stuff we talk about: No IT on Mount Olympus, Uncrustables, Szandora LeVay, Tuck Dance, MZ's DSLs, Buffalo Bill, the sweltering hot old studio, MZ Untucked, TSL, Powder, Lex Luthor, Zack Snyder's Extended Tuck, #ReleaseTheExtendedTuck, Vince McMahon is the lowest form of human, RIP Jesse Jane, RIP David Emge, Basket Case 2, Camel Decapitation, Ted Levine, Cannibal Run, Jeff Spicoli, Kraven Buttstuff, Dixon Bawls, The Nearlydead Game, Two Joint Conversion, Marry F*ck Kill, Leatherface, Pinhead, baby bjorn, Ravenshadow's shopping spree, Jumpin Jack Buttstuff, the first entrants into the Trick or Treat Radio Pantheon, my Blood Pigs sense is tingling, The Void, Miami Connection, Neon Maniacs, Astron-6, Kurando Mitsutake, Manborg, Father's Day, Barry Keoghan, Vader CPAP Variant, Watch This with Rick Ramos, Slaygoth, Air Sharkie, Bananafingaz, Everyone Will Burn, Everybody Burns, send our regards to Craven Buttstuff, a lump of coke, 1,452 podcast episodes, the Pinnacle of Podcasting, Untucked: The Trick or Treat Radio Story, Nub Snubbed, Hard to Jerk Off When You Have Hooves, You Are Your Own Cuck, Bodega Beefpie, Throwing Hands with Kraven Buttstuff, and Release the Extended Tuck.Support us on Patreon: https://www.patreon.com/trickortreatradioJoin our Discord Community: discord.trickortreatradio.comSend Email/Voicemail: mailto:podcast@trickortreatradio.comVisit our website: http://trickortreatradio.comStart your own podcast: https://www.buzzsprout.com/?referrer_id=386Use our Amazon link: http://amzn.to/2CTdZzKFB Group: http://www.facebook.com/groups/trickortreatradioTwitter: http://twitter.com/TrickTreatRadioFacebook: http://facebook.com/TrickOrTreatRadioYouTube: http://youtube.com/TrickOrTreatRadioInstagram: http://instagram.com/TrickorTreatRadioSupport the show

Pucker up — we're making out with luscious lipped actor's actor Val Kilmer and his 2020 memoir, “I'm Your Huckleberry.” From the mythology of the American West to Marlon Brando in a muumuu, this book has it all. We talk pranking Tom Cruise, dying in a hot tub, New Mexico divorce law, dating Cher, and—say it with us!—Cindy Crawford's simple salmon recipe. Call the CBC Loveline at 929-266-7044 for our V-Day special!!!!!See omnystudio.com/listener for privacy information.

We are running an end of year survey for our listeners. Let us know any feedback you have for us, what episodes resonated with you the most, and guest requests for 2024! RAG has emerged as one of the key pieces of the AI Engineer stack. Jerry from LlamaIndex called it a “hack”, Bryan from Hex compared it to “a recommendation system from LLMs”, and even LangChain started with it. RAG is crucial in any AI coding workflow. We talked about context quality for code in our Phind episode. Today's guests, Beyang Liu and Steve Yegge from SourceGraph, have been focused on code indexing and retrieval for over 15 years. We locked them in our new studio to record a 1.5 hours masterclass on the history of code search, retrieval interfaces for code, and how they get SOTA 30% completion acceptance rate in their Cody product by being better at the “bin packing problem” of LLM context generation. Google Grok → SourceGraph → CodyWhile at Google in 2008, Steve built Grok, which lives on today as Google Kythe. It allowed engineers to do code parsing and searching across different codebases and programming languages. (You might remember this blog post from Steve's time at Google) Beyang was an intern at Google at the same time, and Grok became the inspiration to start SourceGraph in 2013. The two didn't know eachother personally until Beyang brought Steve out of retirement 9 years later to join him as VP Engineering. Fast forward 10 years, SourceGraph has become to best code search tool out there and raised $223M along the way. Nine months ago, they open sourced SourceGraph Cody, their AI coding assistant. All their code indexing and search infrastructure allows them to get SOTA results by having better RAG than competitors:* Code completions as you type that achieve an industry-best Completion Acceptance Rate (CAR) as high as 30% using a context-enhanced open-source LLM (StarCoder)* Context-aware chat that provides the option of using GPT-4 Turbo, Claude 2, GPT-3.5 Turbo, Mistral 7x8B, or Claude Instant, with more model integrations planned* Doc and unit test generation, along with AI quick fixes for common coding errors* AI-enhanced natural language code search, powered by a hybrid dense/sparse vector search engine There are a few pieces of infrastructure that helped Cody achieve these results:Dense-sparse vector retrieval system For many people, RAG = vector similarity search, but there's a lot more that you can do to get the best possible results. From their release:"Sparse vector search" is a fancy name for keyword search that potentially incorporates LLMs for things like ranking and term expansion (e.g., "k8s" expands to "Kubernetes container orchestration", possibly weighted as in SPLADE): * Dense vector retrieval makes use of embeddings, the internal representation that LLMs use to represent text. Dense vector retrieval provides recall over a broader set of results that may have no exact keyword matches but are still semantically similar. * Sparse vector retrieval is very fast, human-understandable, and yields high recall of results that closely match the user query. * We've found the approaches to be complementary.There's a very good blog post by Pinecone on SPLADE for sparse vector search if you're interested in diving in. If you're building RAG applications in areas that have a lot of industry-specific nomenclature, acronyms, etc, this is a good approach to getting better results.SCIPIn 2016, Microsoft announced the Language Server Protocol (LSP) and the Language Server Index Format (LSIF). This protocol makes it easy for IDEs to get all the context they need from a codebase to get things like file search, references, “go to definition”, etc. SourceGraph developed SCIP, “a better code indexing format than LSIF”:* Simpler and More Efficient Format: SCIP utilizes Protobuf instead of JSON, which is used by LSIF. Protobuf is more space-efficient, simpler, and more suitable for systems programming. * Better Performance and Smaller Index Sizes: SCIP indexers, such as scip-clang, show enhanced performance and reduced index file sizes compared to LSIF indexers (10%-20% smaller)* Easier to Develop and Debug: SCIP's design, centered around human-readable string IDs for symbols, makes it faster and more straightforward to develop new language indexers. Having more efficient indexing is key to more performant RAG on code. Show Notes* Sourcegraph* Cody* Copilot vs Cody* Steve's Stanford seminar on Grok* Steve's blog* Grab* Fireworks* Peter Norvig* Noam Chomsky* Code search* Kelly Norton* Zoekt* v0.devSee also our past episodes on Cursor, Phind, Codeium and Codium as well as the GitHub Copilot keynote at AI Engineer Summit.Timestamps* [00:00:00] Intros & Backgrounds* [00:05:20] How Steve's work on Grok inspired SourceGraph for Beyang* [00:08:10] What's Cody?* [00:11:22] Comparison of coding assistants and the capabilities of Cody* [00:16:00] The importance of context (RAG) in AI coding tools* [00:21:33] The debate between Chomsky and Norvig approaches in AI* [00:30:06] Normsky: the Norvig + Chomsky models collision* [00:36:00] The death of the DSL?* [00:40:00] LSP, Skip, Kythe, BFG, and all that fun stuff* [00:53:00] The SourceGraph internal stack* [00:58:46] Building on open source models* [01:02:00] SourceGraph for engineering managers?* [01:12:00] Lightning RoundTranscriptAlessio: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO-in-Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI. [00:00:16]Swyx: Hey, and today we're christening our new podcast studio in the Newton, and we have Beyang and Steve from Sourcegraph. Welcome. [00:00:25]Beyang: Hey, thanks for having us. [00:00:26]Swyx: So this has been a long time coming. I'm very excited to have you. We also are just celebrating the one year anniversary of ChatGPT yesterday, but also we'll be talking about the GA of Cody later on today. We'll just do a quick intros of both of you. Obviously, people can research you and check the show notes for more. Beyang, you worked in computer vision at Stanford and then you worked at Palantir. I did, yeah. You also interned at Google. [00:00:48]Beyang: I did back in the day where I get to use Steve's system, DevTool. [00:00:53]Swyx: Right. What was it called? [00:00:55]Beyang: It was called Grok. Well, the end user thing was Google Code Search. That's what everyone called it, or just like CS. But the brains of it were really the kind of like Trigram index and then Grok, which provided the reference graph. [00:01:07]Steve: Today it's called Kythe, the open source Google one. It's sort of like Grok v3. [00:01:11]Swyx: On your podcast, which you've had me on, you've interviewed a bunch of other code search developers, including the current developer of Kythe, right? [00:01:19]Beyang: No, we didn't have any Kythe people on, although we would love to if they're up for it. We had Kelly Norton, who built a similar system at Etsy, it's an open source project called Hound. We also had Han-Wen Nienhuys, who created Zoekt, which is, I think, heavily inspired by the Trigram index that powered Google's original code search and that we also now use at Sourcegraph. Yeah. [00:01:45]Swyx: So you teamed up with Quinn over 10 years ago to start Sourcegraph and you were indexing all code on the internet. And now you're in a perfect spot to create a code intelligence startup. Yeah, yeah. [00:01:56]Beyang: I guess the backstory was, I used Google Code Search while I was an intern. And then after I left that internship and worked elsewhere, it was the single dev tool that I missed the most. I felt like my job was just a lot more tedious and much more of a hassle without it. And so when Quinn and I started working together at Palantir, he had also used various code search engines in open source over the years. And it was just a pain point that we both felt, both working on code at Palantir and also working within Palantir's clients, which were a lot of Fortune 500 companies, large financial institutions, folks like that. And if anything, the pains they felt in dealing with large complex code bases made our pain points feel small by comparison. So that was really the impetus for starting Sourcegraph. [00:02:42]Swyx: Yeah, excellent. Steve, you famously worked at Amazon. And you've told many, many stories. I want every single listener of Latent Space to check out Steve's YouTube because he effectively had a podcast that you didn't tell anyone about or something. You just hit record and just went on a few rants. I'm always here for your Stevie rants. And then you moved to Google, where you also had some interesting thoughts on just the overall Google culture versus Amazon. You joined Grab as head of eng for a couple of years. I'm from Singapore, so I have actually personally used a lot of Grab's features. And it was very interesting to see you talk so highly of Grab's engineering and sort of overall prospects. [00:03:21]Steve: Because as a customer, it sucked? [00:03:22]Swyx: Yeah, no, it's just like, being from a smaller country, you never see anyone from our home country being on a global stage or talked about as a startup that people admire or look up to, like on the league that you, with all your legendary experience, would consider equivalent. Yeah. [00:03:41]Steve: Yeah, no, absolutely. They actually, they didn't even know that they were as good as they were, in a sense. They started hiring a bunch of people from Silicon Valley to come in and sort of like fix it. And we came in and we were like, Oh, we could have been a little better operational excellence and stuff. But by and large, they're really sharp. The only thing about Grab is that they get criticized a lot for being too westernized. Oh, by who? By Singaporeans who don't want to work there. [00:04:06]Swyx: Okay. I guess I'm biased because I'm here, but I don't see that as a problem. If anything, they've had their success because they were more westernized than the Sanders Singaporean tech company. [00:04:15]Steve: I mean, they had their success because they are laser focused. They copy to Amazon. I mean, they're executing really, really, really well for a giant. I was on a slack with 2,500 engineers. It was like this giant waterfall that you could dip your toe into. You'd never catch up. Actually, the AI summarizers would have been really helpful there. But yeah, no, I think Grab is successful because they're just out there with their sleeves rolled up, just making it happen. [00:04:43]Swyx: And for those who don't know, it's not just like Uber of Southeast Asia, it's also a super app. PayPal Plus. [00:04:48]Steve: Yeah. [00:04:49]Swyx: In the way that super apps don't exist in the West. It's one of the enduring mysteries of B2C that super apps work in the East and don't work in the West. We just don't understand it. [00:04:57]Beyang: Yeah. [00:04:58]Steve: It's just kind of curious. They didn't work in India either. And it was primarily because of bandwidth reasons and smaller phones. [00:05:03]Swyx: That should change now. It should. [00:05:05]Steve: And maybe we'll see a super app here. [00:05:08]Swyx: You retired-ish? I did. You retired-ish on your own video game? Mm-hmm. Any fun stories about that? And that's also where you discovered some need for code search, right? Mm-hmm. [00:05:16]Steve: Sure. A need for a lot of stuff. Better programming languages, better databases. Better everything. I mean, I started in like 95, right? Where there was kind of nothing. Yeah. Yeah. [00:05:24]Beyang: I just want to say, I remember when you first went to Grab because you wrote that blog post talking about why you were excited about it, about like the expanding Asian market. And our reaction was like, oh, man, how did we miss stealing it with you? [00:05:36]Swyx: Hiring you. [00:05:37]Beyang: Yeah. [00:05:38]Steve: I was like, miss that. [00:05:39]Swyx: Tell that story. So how did this happen? Right? So you were inspired by Grok. [00:05:44]Beyang: I guess the backstory from my point of view is I had used code search and Grok while at Google, but I didn't actually know that it was connected to you, Steve. I knew you from your blog posts, which were always excellent, kind of like inside, very thoughtful takes from an engineer's perspective on some of the challenges facing tech companies and tech culture and that sort of thing. But my first introduction to you within the context of code intelligence, code understanding was I watched a talk that you gave, I think at Stanford, about Grok when you're first building it. And that was very eye opening. I was like, oh, like that guy, like the guy who, you know, writes the extremely thoughtful ranty like blog posts also built that system. And so that's how I knew, you know, you were involved in that. And then, you know, we always wanted to hire you, but never knew quite how to approach you or, you know, get that conversation started. [00:06:34]Steve: Well, we got introduced by Max, right? Yeah. It was temporal. Yeah. Yeah. I mean, it was a no brainer. They called me up and I had noticed when Sourcegraph had come out. Of course, when they first came out, I had this dagger of jealousy stabbed through me piercingly, which I remember because I am not a jealous person by any means, ever. But boy, I was like, but I was kind of busy, right? And just one thing led to another. I got sucked back into the ads vortex and whatever. So thank God Sourcegraph actually kind of rescued me. [00:07:05]Swyx: Here's a chance to build DevTools. Yeah. [00:07:08]Steve: That's the best. DevTools are the best. [00:07:10]Swyx: Cool. Well, so that's the overall intro. I guess we can get into Cody. Is there anything else that like people should know about you before we get started? [00:07:18]Steve: I mean, everybody knows I'm a musician. I can juggle five balls. [00:07:24]Swyx: Five is good. Five is good. I've only ever managed three. [00:07:27]Steve: Five is hard. Yeah. And six, a little bit. [00:07:30]Swyx: Wow. [00:07:31]Beyang: That's impressive. [00:07:32]Alessio: So yeah, to jump into Sourcegraph, this has been a company 10 years in the making. And as Sean said, now you're at the right place. Phase two. Now, exactly. You spent 10 years collecting all this code, indexing, making it easy to surface it. Yeah. [00:07:47]Swyx: And also learning how to work with enterprises and having them trust you with their code bases. Yeah. [00:07:52]Alessio: Because initially you were only doing on-prem, right? Like a lot of like VPC deployments. [00:07:55]Beyang: So in the very early days, we're cloud only. But the first major customers we landed were all on-prem, self-hosted. And that was, I think, related to the nature of the problem that we're solving, which becomes just like a critical, unignorable pain point once you're above like 100 devs or so. [00:08:11]Alessio: Yeah. And now Cody is going to be GA by the time this releases. So congrats to your future self for launching this in two weeks. Can you give a quick overview of just what Cody is? I think everybody understands that it's a AI coding agent, but a lot of companies say they have a AI coding agent. So yeah, what does Cody do? How do people interface with it? [00:08:32]Beyang: Yeah. So how is it different from the like several dozen other AI coding agents that exist in the market now? When we thought about building a coding assistant that would do things like code generation and question answering about your code base, I think we came at it from the perspective of, you know, we've spent the past decade building the world's best code understanding engine for human developers, right? So like it's kind of your guide as a human dev if you want to go and dive into a large complex code base. And so our intuition was that a lot of the context that we're providing to human developers would also be useful context for AI developers to consume. And so in terms of the feature set, Cody is very similar to a lot of other assistants. It does inline autocompletion. It does code base aware chat. It does specific commands that automate, you know, tasks that you might rather not want to do like generating unit tests or adding detailed documentation. But we think the core differentiator is really the quality of the context, which is hard to kind of describe succinctly. It's a bit like saying, you know, what's the difference between Google and Alta Vista? There's not like a quick checkbox list of features that you can rattle off, but it really just comes down to all the attention and detail that we've paid to making that context work well and be high quality and fast for human devs. We're now kind of plugging into the AI coding assistant as well. Yeah. [00:09:53]Steve: I mean, just to add my own perspective on to what Beyang just described, RAG is kind of like a consultant that the LLM has available, right, that knows about your code. RAG provides basically a bridge to a lookup system for the LLM, right? Whereas fine tuning would be more like on the job training for somebody. If the LLM is a person, you know, and you send them to a new job and you do on the job training, that's what fine tuning is like, right? So tuned to our specific task. You're always going to need that expert, even if you get the on the job training, because the expert knows your particular code base, your task, right? That expert has to know your code. And there's a chicken and egg problem because, right, you know, we're like, well, I'm going to ask the LLM about my code, but first I have to explain it, right? It's this chicken and egg problem. That's where RAG comes in. And we have the best consultants, right? The best assistant who knows your code. And so when you sit down with Cody, right, what Beyang said earlier about going to Google and using code search and then starting to feel like without it, his job was super tedious. Once you start using these, do you guys use coding assistants? [00:10:53]Swyx: Yeah, right. [00:10:54]Steve: I mean, like we're getting to the point very quickly, right? Where you feel like almost like you're programming without the internet, right? Or something, you know, it's like you're programming back in the nineties without the coding assistant. Yeah. Hopefully that helps for people who have like no idea about coding systems, what they are. [00:11:09]Swyx: Yeah. [00:11:10]Alessio: I mean, going back to using them, we had a lot of them on the podcast already. We had Cursor, we have Codium and Codium, very similar names. [00:11:18]Swyx: Yeah. Find, and then of course there's Copilot. [00:11:22]Alessio: You had a Copilot versus Cody blog post, and I think it really shows the context improvement. So you had two examples that stuck with me. One was, what does this application do? And the Copilot answer was like, oh, it uses JavaScript and NPM and this. And it's like, but that's not what it does. You know, that's what it's built with. Versus Cody was like, oh, these are like the major functions. And like, these are the functionalities and things like that. And then the other one was, how do I start this up? And Copilot just said NPM start, even though there was like no start command in the package JSON, but you know, most collapse, right? Most projects use NPM start. So maybe this does too. How do you think about open source models? Because Copilot has their own private thing. And I think you guys use Starcoder, if I remember right. Yeah, that's correct. [00:12:09]Beyang: I think Copilot uses some variant of Codex. They're kind of cagey about it. I don't think they've like officially announced what model they use. [00:12:16]Swyx: And I think they use a range of models based on what you're doing. Yeah. [00:12:19]Beyang: So everyone uses a range of model. Like no one uses the same model for like inline completion versus like chat because the latency requirements for. Oh, okay. Well, there's fill in the middle. There's also like what the model's trained on. So like we actually had completions powered by Claude Instant for a while. And but you had to kind of like prompt hack your way to get it to output just the code and not like, hey, you know, here's the code you asked for, like that sort of text. So like everyone uses a range of models. We've kind of designed Cody to be like especially model, not agnostic, but like pluggable. So one of our kind of design considerations was like as the ecosystem evolves, we want to be able to integrate the best in class models, whether they're proprietary or open source into Cody because the pace of innovation in the space is just so quick. And I think that's been to our advantage. Like today, Cody uses Starcoder for inline completions. And with the benefit of the context that we provide, we actually show comparable completion acceptance rate metrics. It's kind of like the standard metric that folks use to evaluate inline completion quality. It's like if I show you a completion, what's the chance that you actually accept the completion versus you reject it? And so we're at par with Copilot, which is at the head of that industry right now. And we've been able to do that with the Starcoder model, which is open source and the benefit of the context fetching stuff that we provide. And of course, a lot of like prompt engineering and other stuff along the way. [00:13:40]Alessio: And Steve, you wrote a post called cheating is all you need about what you're building. And one of the points you made is that everybody's fighting on the same axis, which is better UI and the IDE, maybe like a better chat response. But data modes are kind of the most important thing. And you guys have like a 10 year old mode with all the data you've been collecting. How do you kind of think about what other companies are doing wrong, right? Like, why is nobody doing this in terms of like really focusing on RAG? I feel like you see so many people. Oh, we just got a new model. It's like a bit human eval. And it's like, well, but maybe like that's not what we should really be doing, you know? Like, do you think most people underestimate the importance of like the actual RAG in code? [00:14:21]Steve: I think that people weren't doing it much. It wasn't. It's kind of at the edges of AI. It's not in the center. I know that when ChatGPT launched, so within the last year, I've heard a lot of rumblings from inside of Google, right? Because they're undergoing a huge transformation to try to, you know, of course, get into the new world. And I heard that they told, you know, a bunch of teams to go and train their own models or fine tune their own models, right? [00:14:43]Swyx: Both. [00:14:43]Steve: And, you know, it was a s**t show. Nobody knew how to do it. They launched two coding assistants. One was called Code D with an EY. And then there was, I don't know what happened in that one. And then there's Duet, right? Google loves to compete with themselves, right? They do this all the time. And they had a paper on Duet like from a year ago. And they were doing exactly what Copilot was doing, which was just pulling in the local context, right? But fundamentally, I thought of this because we were talking about the splitting of the [00:15:10]Swyx: models. [00:15:10]Steve: In the early days, it was the LLM did everything. And then we realized that for certain use cases, like completions, that a different, smaller, faster model would be better. And that fragmentation of models, actually, we expected to continue and proliferate, right? Because we are fundamentally, we're a recommender engine right now. Yeah, we're recommending code to the LLM. We're saying, may I interest you in this code right here so that you can answer my question? [00:15:34]Swyx: Yeah? [00:15:34]Steve: And being good at recommender engine, I mean, who are the best recommenders, right? There's YouTube and Spotify and, you know, Amazon or whatever, right? Yeah. [00:15:41]Swyx: Yeah. [00:15:41]Steve: And they all have many, many, many, many, many models, right? For all fine-tuned for very specific, you know. And that's where we're heading in code, too. Absolutely. [00:15:50]Swyx: Yeah. [00:15:50]Alessio: We just did an episode we released on Wednesday, which we said RAG is like Rexis or like LLMs. You're basically just suggesting good content. [00:15:58]Swyx: It's like what? Recommendations. [00:15:59]Beyang: Recommendations. [00:16:00]Alessio: Oh, got it. [00:16:01]Steve: Yeah, yeah, yeah. [00:16:02]Swyx: So like the naive implementation of RAG is you embed everything, throw it in a vector database, you embed your query, and then you find the nearest neighbors, and that's your RAG. But actually, you need to rank it. And actually, you need to make sure there's sample diversity and that kind of stuff. And then you're like slowly gradient dissenting yourself towards rediscovering proper Rexis, which has been traditional ML for a long time. But like approaching it from an LLM perspective. Yeah. [00:16:24]Beyang: I almost think of it as like a generalized search problem because it's a lot of the same things. Like you want your layer one to have high recall and get all the potential things that could be relevant. And then there's typically like a layer two re-ranking mechanism that bumps up the precision and tries to get the relevant stuff to the top of the results list. [00:16:43]Swyx: Have you discovered that ranking matters a lot? Oh, yeah. So the context is that I think a lot of research shows that like one, context utilization matters based on model. Like GPT uses the top of the context window, and then apparently Claude uses the bottom better. And it's lossy in the middle. Yeah. So ranking matters. No, it really does. [00:17:01]Beyang: The skill with which models are able to take advantage of context is always going to be dependent on how that factors into the impact on the training loss. [00:17:10]Swyx: Right? [00:17:10]Beyang: So like if you want long context window models to work well, then you have to have a ton of data where it's like, here's like a billion lines of text. And I'm going to ask a question about like something that's like, you know, embedded deeply into it and like, give me the right answer. And unless you have that training set, then of course, you're going to have variability in terms of like where it attends to. And in most kind of like naturally occurring data, the thing that you're talking about right now, the thing I'm asking you about is going to be something that we talked about recently. [00:17:36]Swyx: Yeah. [00:17:36]Steve: Did you really just say gradient dissenting yourself? Actually, I love that it's entered the casual lexicon. Yeah, yeah, yeah. [00:17:44]Swyx: My favorite version of that is, you know, how we have to p-hack papers. So, you know, when you throw humans at the problem, that's called graduate student dissent. That's great. It's really awesome. [00:17:54]Alessio: I think the other interesting thing that you have is this inline assist UX that I wouldn't say async, but like it works while you can also do work. So you can ask Cody to make changes on a code block and you can still edit the same file at the same time. [00:18:07]Swyx: Yeah. [00:18:07]Alessio: How do you see that in the future? Like, do you see a lot of Cody's running together at the same time? Like, how do you validate also that they're not messing each other up as they make changes in the code? And maybe what are the limitations today? And what do you think about where the attack is going? [00:18:21]Steve: I want to start with a little history and then I'm going to turn it over to Bian, all right? So we actually had this feature in the very first launch back in June. Dominic wrote it. It was called nonstop Cody. And you could have multiple, basically, LLM requests in parallel modifying your source [00:18:37]Swyx: file. [00:18:37]Steve: And he wrote a bunch of code to handle all of the diffing logic. And you could see the regions of code that the LLM was going to change, right? And he was showing me demos of it. And it just felt like it was just a little before its time, you know? But a bunch of that stuff, that scaffolding was able to be reused for where we're inline [00:18:56]Swyx: sitting today. [00:18:56]Steve: How would you characterize it today? [00:18:58]Beyang: Yeah, so that interface has really evolved from a, like, hey, general purpose, like, request anything inline in the code and have the code update to really, like, targeted features, like, you know, fix the bug that exists at this line or request a very specific [00:19:13]Swyx: change. [00:19:13]Beyang: And the reason for that is, I think, the challenge that we ran into with inline fixes, and we do want to get to the point where you could just fire and forget and have, you know, half a dozen of these running in parallel. But I think we ran into the challenge early on that a lot of people are running into now when they're trying to construct agents, which is the reliability of, you know, working code generation is just not quite there yet in today's language models. And so that kind of constrains you to an interaction where the human is always, like, in the inner loop, like, checking the output of each response. And if you want that to work in a way where you can be asynchronous, you kind of have to constrain it to a domain where today's language models can generate reliable code well enough. So, you know, generating unit tests, that's, like, a well-constrained problem. Or fixing a bug that shows up as, like, a compiler error or a test error, that's a well-constrained problem. But the more general, like, hey, write me this class that does X, Y, and Z using the libraries that I have, that is not quite there yet, even with the benefit of really good context. Like, it definitely moves the needle a lot, but we're not quite there yet to the point where you can just fire and forget. And I actually think that this is something that people don't broadly appreciate yet, because I think that, like, everyone's chasing this dream of agentic execution. And if we're to really define that down, I think it implies a couple things. You have, like, a multi-step process where each step is fully automated. We don't have to have a human in the loop every time. And there's also kind of like an LM call at each stage or nearly every stage in that [00:20:45]Swyx: chain. [00:20:45]Beyang: Based on all the work that we've done, you know, with the inline interactions, with kind of like general Codyfeatures for implementing longer chains of thought, we're actually a little bit more bearish than the average, you know, AI hypefluencer out there on the feasibility of agents with purely kind of like transformer-based models. To your original question, like, the inline interactions with CODI, we actually constrained it to be more targeted, like, you know, fix the current error or make this quick fix. I think that that does differentiate us from a lot of the other tools on the market, because a lot of people are going after this, like, shnazzy, like, inline edit interaction, whereas I think where we've moved, and this is based on the user feedback that we've gotten, it's like that sort of thing, it demos well, but when you're actually coding day to day, you don't want to have, like, a long chat conversation inline with the code base. That's a waste of time. You'd rather just have it write the right thing and then move on with your life or not have to think about it. And that's what we're trying to work towards. [00:21:37]Steve: I mean, yeah, we're not going in the agent direction, right? I mean, I'll believe in agents when somebody shows me one that works. Yeah. Instead, we're working on, you know, sort of solidifying our strength, which is bringing the right context in. So new context sources, ways for you to plug in your own context, ways for you to control or influence the context, you know, the mixing that happens before the request goes out, etc. And there's just so much low-hanging fruit left in that space that, you know, agents seems like a little bit of a boondoggle. [00:22:03]Beyang: Just to dive into that a little bit further, like, I think, you know, at a very high level, what do people mean when they say agents? They really mean, like, greater automation, fully automated, like, the dream is, like, here's an issue, go implement that. And I don't have to think about it as a human. And I think we are working towards that. Like, that is the eventual goal. I think it's specifically the approach of, like, hey, can we have a transformer-based LM alone be the kind of, like, backbone or the orchestrator of these agentic flows? Where we're a little bit more bearish today. [00:22:31]Swyx: You want the human in the loop. [00:22:32]Beyang: I mean, you kind of have to. It's just a reality of the behavior of language models that are purely, like, transformer-based. And I think that's just like a reflection of reality. And I don't think people realize that yet. Because if you look at the way that a lot of other AI tools have implemented context fetching, for instance, like, you see this in the Copilot approach, where if you use, like, the at-workspace thing that supposedly provides, like, code-based level context, it has, like, an agentic approach where you kind of look at how it's behaving. And it feels like they're making multiple requests to the LM being like, what would you do in this case? Would you search for stuff? What sort of files would you gather? Go and read those files. And it's like a multi-hop step, so it takes a long while. It's also non-deterministic. Because any sort of, like, LM invocation, it's like a dice roll. And then at the end of the day, the context it fetches is not that good. Whereas our approach is just like, OK, let's do some code searches that make sense. And then maybe, like, crawl through the reference graph a little bit. That is fast. That doesn't require any sort of LM invocation at all. And we can pull in much better context, you know, very quickly. So it's faster. [00:23:37]Swyx: It's more reliable. [00:23:37]Beyang: It's deterministic. And it yields better context quality. And so that's what we think. We just don't think you should cargo cult or naively go like, you know, agents are the [00:23:46]Swyx: future. [00:23:46]Beyang: Let's just try to, like, implement agents on top of the LM that exists today. I think there are a couple of other technologies or approaches that need to be refined first before we can get into these kind of, like, multi-stage, fully automated workflows. [00:24:00]Swyx: It makes sense. You know, we're very much focused on developer inner loop right now. But you do see things eventually moving towards developer outer loop. Yeah. So would you basically say that they're tackling the agent's problem that you don't want to tackle? [00:24:11]Beyang: No, I would say at a high level, we are after maybe, like, the same high level problem, which is like, hey, I want some code written. I want to develop some software and can automate a system. Go build that software for me. I think the approaches might be different. So I think the analogy in my mind is, I think about, like, the AI chess players. Coding, in some senses, I mean, it's similar and dissimilar to chess. I think one question I ask is, like, do you think producing code is more difficult than playing chess or less difficult than playing chess? More. [00:24:41]Swyx: I think more. [00:24:41]Beyang: Right. And if you look at the best AI chess players, like, yes, you can use an LLM to play chess. Like, people have showed demos where it's like, oh, like, yeah, GPT-4 is actually a pretty decent, like, chess move suggester. Right. But you would never build, like, a best in class chess player off of GPT-4 alone. [00:24:57]Swyx: Right. [00:24:57]Beyang: Like, the way that people design chess players is that you have kind of like a search space and then you have a way to explore that search space efficiently. There's a bunch of search algorithms, essentially. We were doing tree search in various ways. And you can have heuristic functions, which might be powered by an LLM. [00:25:12]Swyx: Right. [00:25:12]Beyang: Like, you might use an LLM to generate proposals in that space that you can efficiently explore. But the backbone is still this kind of more formalized tree search based approach rather than the LLM itself. And so I think my high level intuition is that, like, the way that we get to more reliable multi-step workflows that do things beyond, you know, generate unit test, it's really going to be like a search based approach where you use an LLM as kind of like an advisor or a proposal function, sort of your heuristic function, like the ASTAR search algorithm. But it's probably not going to be the thing that is the backbone, because I guess it's not the right tool for that. Yeah. [00:25:50]Swyx: I can see yourself kind of thinking through this, but not saying the words, the sort of philosophical Peter Norvig type discussion. Maybe you want to sort of introduce that in software. Yeah, definitely. [00:25:59]Beyang: So your listeners are savvy. They're probably familiar with the classic like Chomsky versus Norvig debate. [00:26:04]Swyx: No, actually, I wanted, I was prompting you to introduce that. Oh, got it. [00:26:08]Beyang: So, I mean, if you look at the history of artificial intelligence, right, you know, it goes way back to, I don't know, it's probably as old as modern computers, like 50s, 60s, 70s. People are debating on like, what is the path to producing a sort of like general human level of intelligence? And kind of two schools of thought that emerged. One is the Norvig school of thought, which roughly speaking includes large language models, you know, regression, SVN, basically any model that you kind of like learn from data. And it's like data driven. Most of machine learning would fall under this umbrella. And that school of thought says like, you know, just learn from the data. That's the approach to reaching intelligence. And then the Chomsky approach is more things like compilers and parsers and formal systems. So basically like, let's think very carefully about how to construct a formal, precise system. And that will be the approach to how we build a truly intelligent system. I think Lisp was invented so that you could create like rules-based systems that you would call AI. As a language. Yeah. And for a long time, there was like this debate, like there's certain like AI research labs that were more like, you know, in the Chomsky camp and others that were more in the Norvig camp. It's a debate that rages on today. And I feel like the consensus right now is that, you know, Norvig definitely has the upper hand right now with the advent of LMs and diffusion models and all the other recent progress in machine learning. But the Chomsky-based stuff is still really useful in my view. I mean, it's like parsers, compilers, basically a lot of the stuff that provides really good context. It provides kind of like the knowledge graph backbone that you want to explore with your AI dev tool. Like that will come from kind of like Chomsky-based tools like compilers and parsers. It's a lot of what we've invested in in the past decade at Sourcegraph and what you build with Grok. Basically like these formal systems that construct these very precise knowledge graphs that are great context providers and great kind of guard rails enforcers and kind of like safety checkers for the output of a more kind of like data-driven, fuzzier system that uses like the Norvig-based models. [00:28:03]Steve: Jang was talking about this stuff like it happened in the middle ages. Like, okay, so when I was in college, I was in college learning Lisp and prologue and planning and all the deterministic Chomsky approaches to AI. And I was there when Norvig basically declared it dead. I was there 3,000 years ago when Norvig and Chomsky fought on the volcano. When did he declare it dead? [00:28:26]Swyx: What do you mean he declared it dead? [00:28:27]Steve: It was like late 90s. [00:28:29]Swyx: Yeah. [00:28:29]Steve: When I went to Google, Peter Norvig was already there. He had basically like, I forget exactly where. It was some, he's got so many famous short posts, you know, amazing. [00:28:38]Swyx: He had a famous talk, the unreasonable effectiveness of data. Yeah. [00:28:41]Steve: Maybe that was it. But at some point, basically, he basically convinced everybody that deterministic approaches had failed and that heuristic-based, you know, data-driven statistical approaches, stochastic were better. [00:28:52]Swyx: Yeah. [00:28:52]Steve: The primary reason I can tell you this, because I was there, was that, was that, well, the steam-powered engine, no. The reason was that the deterministic stuff didn't scale. [00:29:06]Swyx: Yeah. Right. [00:29:06]Steve: They're using prologue, man, constraint systems and stuff like that. Well, that was a long time ago, right? Today, actually, these Chomsky-style systems do scale. And that's, in fact, exactly what Sourcegraph has built. Yeah. And so we have a very unique, I love the framing that Bjong's made, that the marriage of the Chomsky and the Norvig, you know, sort of models, you know, conceptual models, because we, you know, we have both of them and they're both really important. And in fact, there, there's this really interesting, like, kind of overlap between them, right? Where like the AI or our graph or our search engine could potentially provide the right context for any given query, which is, of course, why ranking is important. But what we've really signed ourselves up for is an extraordinary amount of testing. [00:29:45]Swyx: Yeah. [00:29:45]Steve: Because in SWIGs, you were saying that, you know, GPT-4 tends to the front of the context window and maybe other LLMs to the back and maybe, maybe the LLM in the middle. [00:29:53]Swyx: Yeah. [00:29:53]Steve: And so that means that, you know, if we're actually like, you know, verifying whether we, you know, some change we've made has improved things, we're going to have to test putting it at the beginning of the window and at the end of the window, you know, and maybe make the right decision based on the LLM that you've chosen. Which some of our competitors, that's a problem that they don't have, but we meet you, you know, where you are. Yeah. And we're, just to finish, we're writing tens of thousands. We're generating tests, you know, fill in the middle type tests and things. And then using our graph to basically sort of fine tune Cody's behavior there. [00:30:20]Swyx: Yeah. [00:30:21]Beyang: I also want to add, like, I have like an internal pet name for this, like kind of hybrid architecture that I'm trying to make catch on. Maybe I'll just say it here. Just saying it publicly kind of makes it more real. But like, I call the architecture that we've developed the Normsky architecture. [00:30:36]Swyx: Yeah. [00:30:36]Beyang: I mean, it's obviously a portmanteau of Norvig and Chomsky, but the acronym, it stands for non-agentic, rapid, multi-source code intelligence. So non-agentic because... Rolls right off the tongue. And Normsky. But it's non-agentic in the sense that like, we're not trying to like pitch you on kind of like agent hype, right? Like it's the things it does are really just developer tools developers have been using for decades now, like parsers and really good search indexes and things like that. Rapid because we place an emphasis on speed. We don't want to sit there waiting for kind of like multiple LLM requests to return to complete a simple user request. Multi-source because we're thinking broadly about what pieces of information and knowledge are useful context. So obviously starting with things that you can search in your code base, and then you add in the reference graph, which kind of like allows you to crawl outward from those initial results. But then even beyond that, you know, sources of information, like there's a lot of knowledge that's embedded in docs, in PRDs or product specs, in your production logging system, in your chat, in your Slack channel, right? Like there's so much context is embedded there. And when you're a human developer, and you're trying to like be productive in your code base, you're going to go to all these different systems to collect the context that you need to figure out what code you need to write. And I don't think the AI developer will be any different. It will need to pull context from all these different sources. So we're thinking broadly about how to integrate these into Codi. We hope through kind of like an open protocol that like others can extend and implement. And this is something else that should be accessible by December 14th in kind of like a preview stage. But that's really about like broadening this notion of the code graph beyond your Git repository to all the other sources where technical knowledge and valuable context can live. [00:32:21]Steve: Yeah, it becomes an artifact graph, right? It can link into your logs and your wikis and any data source, right? [00:32:27]Alessio: How do you guys think about the importance of, it's almost like data pre-processing in a way, which is bring it all together, tie it together, make it ready. Any thoughts on how to actually make that good? Some of the innovation you guys have made. [00:32:40]Steve: We talk a lot about the context fetching, right? I mean, there's a lot of ways you could answer this question. But, you know, we've spent a lot of time just in this podcast here talking about context fetching. But stuffing the context into the window is, you know, the bin packing problem, right? Because the window is not big enough, and you've got more context than you can fit. You've got a ranker maybe. But what is that context? Is it a function that was returned by an embedding or a graph call or something? Do you need the whole function? Or do you just need, you know, the top part of the function, this expression here, right? You know, so that art, the golf game of trying to, you know, get each piece of context down into its smallest state, possibly even summarized by another model, right, before it even goes to the LLM, becomes this is the game that we're in, yeah? And so, you know, recursive summarization and all the other techniques that you got to use to like stuff stuff into that context window become, you know, critically important. And you have to test them across every configuration of models that you could possibly need. [00:33:32]Beyang: I think data preprocessing is probably the like unsexy, way underappreciated secret to a lot of the cool stuff that people are shipping today. Whether you're doing like RAG or fine tuning or pre-training, like the preprocessing step matters so much because it's basically garbage in, garbage out, right? Like if you're feeding in garbage to the model, then it's going to output garbage. Concretely, you know, for code RAG, if you're not doing some sort of like preprocessing that takes advantage of a parser and is able to like extract the key components of a particular file of code, you know, separate the function signature from the body, from the doc string, what are you even doing? Like that's like table stakes. It opens up so much more possibilities with which you can kind of like tune your system to take advantage of the signals that come from those different parts of the code. Like we've had a tool, you know, since computers were invented that understands the structure of source code to a hundred percent precision. The compiler knows everything there is to know about the code in terms of like structure. Like why would you not want to use that in a system that's trying to generate code, answer questions about code? You shouldn't throw that out the window just because now we have really good, you know, data-driven models that can do other things. [00:34:44]Steve: Yeah. When I called it a data moat, you know, in my cheating post, a lot of people were confused, you know, because data moat sort of sounds like data lake because there's data and water and stuff. I don't know. And so they thought that we were sitting on this giant mountain of data that we had collected, but that's not what our data moat is. It's really a data pre-processing engine that can very quickly and scalably, like basically dissect your entire code base in a very small, fine-grained, you know, semantic unit and then serve it up. Yeah. And so it's really, it's not a data moat. It's a data pre-processing moat, I guess. [00:35:15]Beyang: Yeah. If anything, we're like hypersensitive to customer data privacy requirements. So it's not like we've taken a bunch of private data and like, you know, trained a generally available model. In fact, exactly the opposite. A lot of our customers are choosing Cody over Copilot and other competitors because we have an explicit guarantee that we don't do any of that. And that we've done that from day one. Yeah. I think that's a very real concern in today's day and age, because like if your proprietary IP finds its way into the training set of any model, it's very easy both to like extract that knowledge from the model and also use it to, you know, build systems that kind of work on top of the institutional knowledge that you've built up. [00:35:52]Alessio: About a year ago, I wrote a post on LLMs for developers. And one of the points I had was maybe the depth of like the DSL. I spent most of my career writing Ruby and I love Ruby. It's so nice to use, but you know, it's not as performant, but it's really easy to read, right? And then you look at other languages, maybe they're faster, but like they're more verbose, you know? And when you think about efficiency of the context window, that actually matters. [00:36:15]Swyx: Yeah. [00:36:15]Alessio: But I haven't really seen a DSL for models, you know? I haven't seen like code being optimized to like be easier to put in a model context. And it seems like your pre-processing is kind of doing that. Do you see in the future, like the way we think about the DSL and APIs and kind of like service interfaces be more focused on being context friendly, where it's like maybe it's harder to read for the human, but like the human is never going to write it anyway. We were talking on the Hacks podcast. There are like some data science things like spin up the spandex, like humans are never going to write again because the models can just do very easily. Yeah, curious to hear your thoughts. [00:36:51]Steve: Well, so DSLs, they involve, you know, writing a grammar and a parser and they're like little languages, right? We do them that way because, you know, we need them to compile and humans need to be able to read them and so on. The LLMs don't need that level of structure. You can throw any pile of crap at them, you know, more or less unstructured and they'll deal with it. So I think that's why a DSL hasn't emerged for sort of like communicating with the LLM or packaging up the context or anything. Maybe it will at some point, right? We've got, you know, tagging of context and things like that that are sort of peeking into DSL territory, right? But your point on do users, you know, do people have to learn DSLs like regular expressions or, you know, pick your favorite, right? XPath. I think you're absolutely right that the LLMs are really, really good at that. And I think you're going to see a lot less of people having to slave away learning these things. They just have to know the broad capabilities and the LLM will take care of the rest. [00:37:42]Swyx: Yeah, I'd agree with that. [00:37:43]Beyang: I think basically like the value profit of DSL is that it makes it easier to work with a lower level language, but at the expense of introducing an abstraction layer. And in many cases today, you know, without the benefit of AI cogeneration, like that totally worth it, right? With the benefit of AI cogeneration, I mean, I don't think all DSLs will go away. I think there's still, you know, places where that trade-off is going to be worthwhile. But it's kind of like how much of source code do you think is going to be generated through natural language prompting in the future? Because in a way, like any programming language is just a DSL on top of assembly, right? And so if people can do that, then yeah, like maybe for a large portion of the code [00:38:21]Swyx: that's written, [00:38:21]Beyang: people don't actually have to understand the DSL that is Ruby or Python or basically any other programming language that exists. [00:38:28]Steve: I mean, seriously, do you guys ever write SQL queries now without using a model of some sort? At least a draft. [00:38:34]Swyx: Yeah, right. [00:38:36]Steve: And so we have kind of like, you know, past that bridge, right? [00:38:39]Alessio: Yeah, I think like to me, the long-term thing is like, is there ever going to be, you don't actually see the code, you know? It's like, hey, the basic thing is like, hey, I need a function to some two numbers and that's it. I don't need you to generate the code. [00:38:53]Steve: And the following question, do you need the engineer or the paycheck? [00:38:56]Swyx: I mean, right? [00:38:58]Alessio: That's kind of the agent's discussion in a way where like you cannot automate the agents, but like slowly you're getting more of the atomic units of the work kind of like done. I kind of think of it as like, you know, [00:39:09]Beyang: do you need a punch card operator to answer that for you? And so like, I think we're still going to have people in the role of a software engineer, but the portion of time they spend on these kinds of like low-level, tedious tasks versus the higher level, more creative tasks is going to shift. [00:39:23]Steve: No, I haven't used punch cards. [00:39:25]Swyx: Yeah, I've been talking about like, so we kind of made this podcast about the sort of rise of the AI engineer. And like the first step is the AI enhanced engineer. That is that software developer that is no longer doing these routine, boilerplate-y type tasks, because they're just enhanced by tools like yours. So you mentioned OpenCodeGraph. I mean, that is a kind of DSL maybe, and because we're releasing this as you go GA, you hope for other people to take advantage of that? [00:39:52]Beyang: Oh yeah, I would say so OpenCodeGraph is not a DSL. It's more of a protocol. It's basically like, hey, if you want to make your system, whether it's, you know, chat or logging or whatever accessible to an AI developer tool like Cody, here's kind of like the schema by which you can provide that context and offer hints. So I would, you know, comparisons like LSP obviously did this for kind of like standard code intelligence. It's kind of like a lingua franca for providing fine references and codefinition. There's kind of like analogs to that. There might be also analogs to kind of the original OpenAI, kind of like plugins, API. There's all this like context out there that might be useful for an LM-based system to consume. And so at a high level, what we're trying to do is define a common language for context providers to provide context to other tools in the software development lifecycle. Yeah. Do you have any critiques of LSP, by the way, [00:40:42]Swyx: since like this is very much, very close to home? [00:40:45]Steve: One of the authors wrote a really good critique recently. Yeah. I don't think I saw that. Yeah, yeah. LSP could have been better. It just came out a couple of weeks ago. It was a good article. [00:40:54]Beyang: Yeah. I think LSP is great. Like for what it did for the developer ecosystem, it was absolutely fantastic. Like nowadays, like it's much easier now to get code navigation up and running in a bunch of editors by speaking this protocol. I think maybe the interesting question is like looking at the different design decisions comparing LSP basically with Kythe. Because Kythe has more of a... How would you describe it? [00:41:18]Steve: A storage format. [00:41:20]Beyang: I think the critique of LSP from a Kythe point of view would be like with LSP, you don't actually have an actual symbolic model of the code. It's not like LSP models like, hey, this function calls this other function. LSP is all like range-based. Like, hey, your cursor's at line 32, column 1. [00:41:35]Swyx: Yeah. [00:41:35]Beyang: And that's the thing you feed into the language server. And then it's like, okay, here's the range that you should jump to if you click on that range. So it kind of is intentionally ignorant of the fact that there's a thing called a reference underneath your cursor, and that's linked to a symbol definition. [00:41:49]Steve: Well, actually, that's the worst example you could have used. You're right. But that's the one thing that it actually did bake in is following references. [00:41:56]Swyx: Sure. [00:41:56]Steve: But it's sort of hardwired. [00:41:58]Swyx: Yeah. [00:41:58]Steve: Whereas Kythe attempts to model [00:42:00]Beyang: like all these things explicitly. [00:42:02]Swyx: And so... [00:42:02]Steve: Well, so LSP is a protocol, right? And so Google's internal protocol is gRPC-based. And it's a different approach than LSP. It's basically you make a heavy query to the back end, and you get a lot of data back, and then you render the whole page, you know? So we've looked at LSP, and we think that it's a little long in the tooth, right? I mean, it's a great protocol, lots and lots of support for it. But we need to push into the domain of exposing the intelligence through the protocol. Yeah. [00:42:29]Beyang: And so I would say we've developed a protocol of our own called Skip, which is at a very high level trying to take some of the good ideas from LSP and from Kythe and merge that into a system that in the near term is useful for Sourcegraph, but I think in the long term, we hope will be useful for the ecosystem. Okay, so here's what LSP did well. LSP, by virtue of being like intentionally dumb, dumb in air quotes, because I'm not like ragging on it, allowed language servers developers to kind of like bypass the hard problem of like modeling language semantics precisely. So like if all you want to do is jump to definition, you don't have to come up with like a universally unique naming scheme for each symbol, which is actually quite challenging because you have to think about like, okay, what's the top scope of this name? Is it the source code repository? Is it the package? Does it depend on like what package server you're fetching this from? Like whether it's the public one or the one inside your... Anyways, like naming is hard, right? And by just going from kind of like a location to location based approach, you basically just like throw that out the window. All I care about is jumping definition, just make that work. And you can make that work without having to deal with like all the complex global naming things. The limitation of that approach is that it's harder to build on top of that to build like a true knowledge graph. Like if you actually want a system that says like, okay, here's the web of functions and here's how they reference each other. And I want to incorporate that like semantic model of how the code operates or how the code relates to each other at like a static level. You can't do that with LSP because you have to deal with line ranges. And like concretely the pain point that we found in using LSP for source graph is like in order to do like a find references [00:44:04]Swyx: and then jump definitions, [00:44:04]Beyang: it's like a multi-hop process because like you have to jump to the range and then you have to find the symbol at that range. And it just adds a lot of latency and complexity of these operations where as a human, you're like, well, this thing clearly references this other thing. Why can't you just jump me to that? And I think that's the thing that Kaith does well. But then I think the issue that Kaith has had with adoption is because it is more sophisticated schema, I think. And so there's basically more things that you have to implement to get like a Kaith implementation up and running. I hope I'm not like, correct me if I'm wrong about any of this. [00:44:35]Steve: 100%, 100%. Kaith also has a problem, all these systems have the problem, even skip, or at least the way that we implemented the indexers, that they have to integrate with your build system in order to build that knowledge graph, right? Because you have to basically compile the code in a special mode to generate artifacts instead of binaries. And I would say, by the way, earlier I was saying that XREFs were in LSP, but it's actually, I was thinking of LSP plus LSIF. [00:44:58]Swyx: Yeah. That's another. [00:45:01]Steve: Which is actually bad. We can say that it's bad, right? [00:45:04]Steve: It's like skip or Kaith, it's supposed to be sort of a model serialization, you know, for the code graph, but it basically just does what LSP needs, the bare minimum. LSIF is basically if you took LSP [00:45:16]Beyang: and turned that into a serialization format. So like you build an index for language servers to kind of like quickly bootstrap from cold start. But it's a graph model [00:45:23]Steve: with all of the inconvenience of the API without an actual graph. And so, yeah. [00:45:29]Beyang: So like one of the things that we try to do with skip is try to capture the best of both worlds. So like make it easy to write an indexer, make the schema simple, but also model some of the more symbolic characteristics of the code that would allow us to essentially construct this knowledge graph that we can then make useful for both the human developer through SourceGraph and through the AI developer through Cody. [00:45:49]Steve: So anyway, just to finish off the graph comment, we've got a new graph, yeah, that's skip based. We call it BFG internally, right? It's a beautiful something graph. A big friendly graph. [00:46:00]Swyx: A big friendly graph. [00:46:01]Beyang: It's a blazing fast. [00:46:02]Steve: Blazing fast. [00:46:03]Swyx: Blazing fast graph. [00:46:04]Steve: And it is blazing fast, actually. It's really, really interesting. I should probably have to do a blog post about it to walk you through exactly how they're doing it. Oh, please. But it's a very AI-like iterative, you know, experimentation sort of approach. We're building a code graph based on all of our 10 years of knowledge about building code graphs, yeah? But we're building it quickly with zero configuration, and it doesn't have to integrate with your build. And through some magic tricks that we have. And so what just happens when you install the plugin, that it'll be there and indexing your code and providing that knowledge graph in the background without all that build system integration. This is a bit of secret sauce that we haven't really like advertised it very much lately. But I am super excited about it because what they do is they say, all right, you know, let's tackle function parameters today. Cody's not doing a very good job of completing function call arguments or function parameters in the definition, right? Yeah, we generate those thousands of tests, and then we can actually reuse those tests for the AI context as well. So fortunately, things are kind of converging on, we have, you know, half a dozen really, really good context sources, and we mix them all together. So anyway, BFG, you're going to hear more about it probably in the holidays? [00:47:12]Beyang: I think it'll be online for December 14th. We'll probably mention it. BFG is probably not the public name we're going to go with. I think we might call it like Graph Context or something like that. [00:47:20]Steve: We're officially calling it BFG. [00:47:22]Swyx: You heard it here first. [00:47:24]Beyang: BFG is just kind of like the working name. And so the impetus for BFG was like, if you look at like current AI inline code completion tools and the errors that they make, a lot of the errors that they make, even in kind of like the easy, like single line case, are essentially like type errors, right? Like you're trying to complete a function call and it suggests a variable that you defined earlier, but that variable is the wrong type. [00:47:47]Swyx: And that's the sort of thing [00:47:47]Beyang: where it's like a first year, like freshman CS student would not make that error, right? So like, why does the AI make that error? And the reason is, I mean, the AI is just suggesting things that are plausible without the context of the types or any other like broader files in the code. And so the kind of intuition here is like, why don't we just do the basic thing that like any baseline intelligent human developer would do, which is like click jump to definition, click some fine references and pull in that like Graph Context into the context window and then have it generate the completion. So like that's sort of like the MVP of what BFG was. And turns out that works really well. Like you can eliminate a lot of type errors that AI coding tools make just by pulling in that context. Yeah, but the graph is definitely [00:48:32]Steve: our Chomsky side. [00:48:33]Swyx: Yeah, exactly. [00:48:34]Beyang: So like this like Chomsky-Norvig thing, I think pops up in a bunch of differ

Single Guy Tip  Single Guy Tip review  Wireless headphones - overrated? Jana Hocking on DSLsSubscribe on LiSTNR: https://play.listnr.com/podcast/mike-e-and-emmaSee omnystudio.com/listener for privacy information.

Multiple Barbie parties later, we've finally released a new episode of Bay Area Weekend! In this one we discuss food poisoning, large sailboats, disc golf, AI girlfriends, and getting paid to produce BAWCAST! Your boys are finally getting paid to talk, so listen closely. Events - Pancakes and Booze Art Show August 3/4 - BAW Tiki Party August 5 - Outside Lands! - Bay to Lake Relay Race September 16th

Angenommen, man will ein Softwaresystem bauen, mit dem Mediziner Medikamentenstudien beschreiben können, oder Steuerexperten das komplette deutsche Steuerrecht “programmieren” können. Was sind die richtigen Abstraktionen und Konzepte, um diese Domänen zu beschreiben? Das Ziel einer Domänenanalyse ist genau dies: die Abstraktionen zu finden, mit denen eine Domäne so präzise beschrieben werden kann, dass die damit erstellten Beschreibungen direkt ausführbar sind. In dieser Ausgabe von Software Architektur im Stream spricht Eberhard Wolff dazu mit Markus Völter. Er hat zu dem Thema kürzlich das Buch “How to Understand Almost Anything” geschrieben. Die beiden sprechen darüber, wie man bei einer Domänenanalyse vorgeht, und warum man die Idee von “ausführbarer Fachlogik” überhaupt verfolgen sollte. Links Markus Buch “How to Understand Almost Anything” 35% Rabatt für Online-Version (via Leanpub) Sketchnotes Training Software Architektur Kickstart Training Advanced Microservices (1 Tag) Training Microservices: Architektur, Implementierung und Produktion (1 Tag) Episode zu Fachliche Architekturen mit DSL (Domain Specific Languages) mit Markus Völter Episode zu Domain Prototyping mit Tobias Goeschel Episode zu Wiederverwendung omega tau podcast Völter, Komarov. Streamlining der Steuersoftware-Entwicklung bei DATEV mittels DSLs, OOP 2021.

Today we're going to introduce a game changer in the dental practice management software world...‍‍This is an innovative, all-in-one, cloud-based practice management software, and it offers an array of powerful features that are custom built for dentists by dentists ready to revolutionize the way you work. ‍If you are a start-up and decide to sign up with Oryx, they will NOT charge you a single dime, until you reached 200 active patients!⁠⁠They are partnering up with all startup practice owners and making sure you succeed, fast!⁠⁠ Click this link to schedule a FREE personalized demo and to see more on their exclusive deal!⁠‍‍Guest: Rania SalehBusiness Name: Oryx Dental SoftwareCheck out Rania's Media:Website: https://www.oryxdentalsoftware.com/Email: hello@oryxdentalsoftware.com‍Other Mentions and Links:InvisalignKois CenterThe Making OfOrange is the New BlackZoomPearlDr. Sana Yusuf‍The Happiness Advantage - Shawn Achor‍Host: Michael Arias‍Website: The Dental Marketer Join my newsletter: https://thedentalmarketer.lpages.co/newsletter/‍Join this podcast's Facebook Group: The Dental Marketer Society‍‍My Key Takeaways:Do your best to educate patients, and then let them decide whether or not to move forward with treatment. This will give patients a more inviting atmosphere!Your brand reputation starts before patients even enter your practice. Be sure your forms and online presence is as updated and clean as your practice!Sometimes a visual representation of risk areas is just what patients need to understand the treatment plan.Promoting patients with NO dental problems is a great way to attract new patients!Don't focus on just the negative areas in a patient's mouth, be sure to show them what is looking great too!‍Please don't forget to share with us on Instagram when you are listening to the podcast AND if you are really wanting to show us love, then please leave a 5 star review on iTunes! [Click here to leave a review on iTunes]‍p.s. Some links are affiliate links, which means that if you choose to make a purchase, I will earn a commission. This commission comes at no additional cost to you. Please understand that we have experience with these products/ company, and I recommend them because they are helpful and useful, not because of the small commissions we make if you decide to buy something. Please do not spend any money unless you feel you need them or that they will help you with your goals.‍Episode Transcript (Auto-Generated - Please Excuse Errors)Michael: Ranya. How's it going? Doing great. Thank you. That's wonderful. I spoke with you and I met you in the first making of Demo Startup retreat, and you gave one of the best speeches there, not because of like, you know, oryx obviously it's wonderful and it's great and everything like that.But because you touched a lot of our hearts, my heart, my wife's heart, everybody's heart, right? And I kind of wanted to backtrack a little bit and tell us a little bit about your past from that point on your present. How'd you get to where you are today? Rania: So I started as a general dentist. Uh, practicing right outside of Washington, DC and I was an associate for a couple of years, then decided to have my own practice, and that worked well for me.So it grew into a larger practice, multiple locations. I was doing really well. I was really happy, and I got pregnant with twins, had to be on bed dressed, and my practice went downhill very quick. and I couldn't understand why that was happening. And I started looking into our systems and into what the associates are doing, and it was all the same.So the same associates, the same front desk, the same marketing. Uh, how did we go from doing so well to doing so poorly? And I realized that we weren't implementing the systems the same way we were when I was in the practice. And I realized that a lot of the system were just in my head. I wasn't translating that to everyone.Um, and I started creating a little system just to, uh, put my practice back on track. Um, and I had gone through the Coy Center, so I loved John's systematic approach. I loved how you can look at the patient, gather some data, and you always come up to the same diagnosis. Started showing it to other people. They liked it, and this is how Orx was Michael: created. Nice. So you are the one who created it cuz of the pain points that you were experiencing? Yeah, Rania: in a way with a large group behind me, but Gotcha, gotcha. Michael: If we rewind a little bit, Rania, um, talk to me about your process of becoming a dentist.Rania: So, um, my parents are dentists, so it was kind of an easy choice. Uh, my brother is an orthodontist, my sister is a pediatric dentist, so they always, my parents always pushed us towards dentistry. Like it's the best profession. it was a bit of a no-brainer for me to go to go Michael: into dentistry.And so you came into dentistry and then from that point on, you always thought to yourself, I'm gonna own my own practice. Or how did that come up? Um, Rania: yeah, I dunno. No. I started as an associate not really knowing what I was doing. And, uh, I went to a very insurance heavy practice. and I didn't like the systems.I didn't like how fast paced, extremely fast paced it was. Um, I didn't agree with some, some of the treatment protocols that we had, but I was in a way doing my job. Mm-hmm. Uh, And that was like maybe 2007 when the economy was collapsing, everything was going so bad and we didn't have access to podcasts, like cures to the dental startup, to all that information about opening a practice.And of course, the owner of the practice I was at was always discouraging me. Like, it's a lot of money. I didn't know you could take a loan from the bank. Mm-hmm. Like we didn't have access to all that information, so I was always discouraged to, to open my own practice. Um, but then when I started going to the coy center and I'm like, I want to implement a different level of care, I found it was really, really hard to do if and to change systems if you are doing it in someone else's practice.and this is when I decided like, That's it. I'm opening a startup and I don't know how Yeah. Michael: To any of it. Were you looking for immediately a startup, like from the ground up or were you looking for an acquisition? Rania: I looked for an acquisition a little like for a short, wide, um, and I didn't find any good fit.there weren't that many in the area where I was like, right outside of Washington, DC I didn't want to drive too far. so I'm like, okay, I'll just do a startup and I'll do it the way I want. And everything I looked at was like, now you see all these amazing startups, super modern, like on the grade decor.But when I did my office and looking at offices, they were very ugly. And I couldn't picture my, I mean, it's silly like now if I'm evaluating a practice, I, I would look at numbers, I would look at product, I would look at a lot of different things. But back then I was just looking, oh, I, I really hate this space.Michael: so you were looking more at the outside of it, the interior design, things like that. Yeah. I was thinking Rania: like, if I want to create that vision for a practice, if I want my. Patients to have this amazing experience, it has to be done in a really nice space. Michael: Mm-hmm. Yeah, that's true. And then, so fast forward a little bit more.You mentioned you started running your dental practice and was it around the time where you're like, okay, my practice is going down, was when you gave birth to your twins? Rania: No, so, so I started the practice and, um, I'll backtrack a bit. Uh, as I said, like I had the vision for the practice. So a friend who's an architect, had also a vision of how a practice should be, and they had a really amazing location.Uh, we were featured in architecture and magazines. Google Ads were not very popular at the time, so we started, so Google ads, we got so busy, so quick, like we were, uh, breaking even by the second month or third month we were profitable. Very early on, we hit a million on the first year, we were doing really well and this is when my brother came and started doing one day of Ortho with me.That turned into several days of, uh, a month, and then my, we had, um, a periodontist come and join us, uh, my sister-in-law. Mm-hmm. And then we had, uh, and the practice started growing into having associates. Then I started looking at another location. and after that I got pregnant. I had to be on bed dressed, and this is when the office started losing a lot of money.Okay. It was not a hundred thousand alone that we were losing. Michael: Wow. Why? What was going on? Where it was specifically losing? So, Rania: um, the way we had the system in our practices, I was doing a lot of the exams and treatment planning. and then the patients would see different providers for the treatment. So they would see some of my associates fulfilling.So, so I was in way screening the patient. Mm-hmm. if someone needed ortho first and then some Pero treatment and then maybe, A couple of implants, if it was a cosmetic case and we're, we're going through all of that, I would coordinate the whole case and they were going through the department.and if they were fillings and, uh, some smaller treatments, some of the, uh, younger associates were doing, if they were more complex treatment, it was the more senior associates doing that. So, so we had all of this organized and I fear that when I wasn't in the practice, that piece went missing. So I was in a way the project manager.Yeah. Yeah. and when that went missing, uh, we were looking at patients and new patients were coming in and it, and they were just seen in hygiene and see you in six months, were gonna watch this, this, and that, and that's it. So people were not, presented with a comprehensive vision for their treatment and for their health.So, I think that was the biggest difference. Michael: Gotcha. How long did that last For? A few Rania: months. and then I started asking my associates to come to the hospital. So half my bedrest was in a hospital bed. Really Michael: horrible. So it was, I'm sorry, you were in bed rest for how long? The whole Rania: pregnancy. Oh wow. Like on week 12, I think I went on bed dress until I delivered.Michael: Really? Yeah, it was, uh, man, Ryan, that's pretty tough. Like that's a lot. You know what I mean? Like, uh, yeah. That, and then on top of, how much were you stressing out when you saw these numbers? Rania: Lot. You know, at the time I was watching Oranges, the New Black, and I was thinking to myself like, Jane is easier. At least you socialize with other people Michael: is easier.Rania: You know, you're not worried about the practice. Choose and bed dress. Maybe Jane. Michael: Oh. it's funny how our mind thinks though, when you're thinking that, you're like, my gosh, it's going down. And so you're stressing out about that. You're stressing out about, I mean, your, your pregnancy. how are you guys and your husband and everybody, how's like the family handling everything in this situation?Especially since you're, you know, orthos your family too and everything like that. Rania: So like everyone was trying to help anyway they could. Uh, Because we did well early on I had some resources in the bank, but like seeing this depleted month after month was really stressful. And we were try, like I would speak to the office manager and she's like, I.Our numbers are good. We're still getting the same, uh, amount of new patients. We're still very booked. And we s like I started looking at every piece of the puzzle, where aren't we doing well? And then I started looking at the treatment plan. So this is when I started inviting the associates. Let's review every chart and I would go through it systematically the way I learned at the COI Center.So let's look at the four different areas your gums. Uh, your, teeth hugged, bite, jaw, joint, and smile. And I would give a patient a summary of their health in the four different categories. And this is where it sparks ideas for the patient. Where if I would say a patient might not be thinking about Invisalign, I might say something like, uh, You mentioned that you are happy with your smile.I see a little bit of crowding, but since you're happy, we're good with that. And they might think about it and say, oh, you know, this bothers me a bit. Mm-hmm. Can it be done quickly, and this is where the Invisalign conversation comes, or I. Sometimes patients might have these very large restorations that they're not very concerned about, but maybe they're grinding also, or they have some bite issues.So I would look at that and I would say, um, you have these structurally compromised teeth, because of these large restorations. It could be a concern because of your grinding or because of this. So that puts you into a higher risk, and now it's up to them if they want to do it or not. And most of them would do it.So this was the type of conversations I was having with the patients that were my associates were not having, and this is going through the very systematic exam. and this was basically the basis of orex is I took the co exam. There is very systematic, very standardized, not like if you examine your patients that way, if you present to them the findings in these four different areas, it becomes.A lot easier for them to say yes, to your treatment. And it becomes, and they become more aware of their health. in a way you're educating the patient, uh, and you're giving them the power to make more informed decisions. So I told you about this. Now it's up to you. Do you want to. Replace these structurally compromised, fillings, um, with crowns or onlays, or do you wanna wait and see?Mm-hmm. It's your decision, but I'm giving you all the information that I can to make better decisions about your health, but ultimately it's up to you. I think this is the reason my practice true, and I realize that a lot of dentists don't go about mm-hmm. Treating their patients that way. and this is what Orex does, is it basically helps dentists do a very systematic examination in seven minutes and it generates a report for the patient.So everything I was telling the patient is in one report. That they can go think about review. yeah, like one thing that we do is we always examine four problems and we never reward hun. And even for very healthy patients, it's good to t them, like your gums and bones are exactly where we want them to be.At your age. Your teeth are doing great. we don't have any issues. You had two feelings in the past and we don't see any other issues. Your python judgment are great. You're happy with your smile, so we're really proud of this and we find that these are the people that take this report and put it on social media and share it with everyone.And these grow the practice more than the patients with a lot of problems. Because at first I would print that report and hand it to patients that had a lot of issues thinking they need to go review it, process it, understand what's going on to say yes to treatment. realized that the promoters are the one that got like the A plus.Michael: Great. Yeah. Yeah, that's true. Okay, so then. When you were teaching this to your associates, could they have just gone to the COI Center and learned it on their own? That way you didn't have to stress out so much? Rania: Yeah, I mean the, the COI Center is amazing and it's a long journey. but even John would tell you the issue he was having with a lot of the students coming through the co center is, it's a lot of information that you get and it's.And a lot of paperwork that people go to the practice and go and fall back into their own habits. It's a lot easy. Like you go, you, you learn something and you are so excited about it, and you're like, Monday morning we're gonna start inventing this. And Monday morning you have this emergency coming in and you have this unhappy patient and this insurance that got rejected and now this person wrote a bad review and mm-hmm.You're dealing with all of this and Tuesday is the same and. That's it. Yeah. Okay. By next week you forgot everything and you forgot that you wanted to implement this. Um, that's true. Yeah. So having it in your software where you don't have to think about it almost forces you to be more organized and more systematic.Michael: Mm-hmm. Yeah. I was speaking with Dr. Sauna Yusif. Um, and she tells me her favorite thing about orex among many other things. But is the, the wheel, the new patient wheel, and I'm assuming that's what this is, right? Yeah. Is where like they get the comprehen and then they're able to actually take it home or see it and say like, okay, look, this is everything going great where I need improvement.You know what I mean? They get their whole visual of it. Is that what that is? Rania: Yeah. Yeah. It, it's a personalized risk assessment. So patients started calling in the wheel. So, so that became the name. And, uh, we would get patients calling the office and saying, I want the exam. That gives me the wheel, because like patients, and especially the happy ones that have, it's all green, as I said, would, would take it to the office and show, show patient, uh, show their coworkers.Look, I got, I was just at the dentist and look at this and it's, it's a really nice presentation and it, we found that printing it out adds more value because patients are happy about it. We put it in a really nice folder. They take it, they show it to other, uh, to coworkers, to friends, to family members.And people are, how come my dentist never gives me this? and they would just, call and ask about it. Yeah, Michael: it's, it's almost the same concept that you were, that John was talking about, right? Like, you, we tell you all this information, you're excited, and then life happens, right? So same thing, kind of like you tell the patient all this information, maybe they're thinking about it, they get home, kids got hurt, they're in trouble, they gotta pick 'em up at school, h, husband, wife, all these things, right?Work. And they tend to forget about it. But if they have that thing there, you know what I mean with them, and super simple and easy for them to read and, and share. It's better. It's better. It's on top of mine for sure. For Rania: sure. And a lot of times they're sitting in your office and they're not truly listening.Mm-hmm. Like, I wanna get outta you. Mm-hmm. Like, just go on with it. And they go home and, and I've had so many patients that said, okay, okay, okay. And then they go home and they're looking like, uh, is scaling and truth planting scam? Yeah. And because by now we're telling them this is what you need, but now they have this information and they're reviewing that information, so.it's really a good way, but also, like, one thing that we don't really think about is the medical legal perspective. anything you say to the p anything that is not documented does not exist. Mm-hmm. And this is doing all the documentation for you. So you do your exam, we auto generate your progress note.We also auto generate that that goes to the patient. So that's almost their consent form. We also have consent forms in this system. But, but in a way, we told you that you needed that restoration and you decided not to do it. We told you you have an infection, you didn't come back for the treatment. so it's all documented.Michael: Gotcha. So then the new patient visit, how long does that normally take with this for you? Rania: So we time dentists doing the exam seven to 10 minutes. Michael: So it's really like, Rania: it's way more comprehensive, but it's very systematic and the exam is, would expand and collapse the way you need it. So if you say, uh, The patient has, um, jaw problems.The, uh, the T M J exam is gonna expand, but if the patient answered no to, to all the jaw questions, and you have like no problems, it's gonna collapse. So, and this is how you want it to be, to go quick on patients that have no issues, but to really dig deeper with patients that have more issues. Michael: Yeah.Okay. So that's really good. So then rewind a little bit, you went, explain this to your associates, you created this process. How long did it take you to start? All right. ORIC is live now. It's, it's happening everybody. So, Rania: on the twin first birthday is when I showed it to John. Oh, okay. For the first time, like, I created something that I want to share with you.can I come and see you? I actually, a friend facilitated this. It's not that easy to get access to John. Michael: Yeah. People gonna contact him. Hey John. Yeah. Rania: Like, now I forget. Like now I can text day. It was, um, and John gets. Pitched these ideas every day. So he wanted to be polite and he's like, okay, let's do a Zoom meeting.Like that's before Zoom was popular. I think it was something else like go to meeting or something. Mm-hmm. And he's like, don't fly to Seattle, because he was like 90% sure he was gonna say no. People pitch him crazy stuff every day. And I present this to him and he goes, I love it. Let's do something out of it.He's like, what do we do next? Mm-hmm. And I'm like, I didn't think it through. I didn't think. Yes. Michael: Yeah. Rania: And I'll back to you. And this is how the company really started. because before it was just, Forms and, I asked my husband to develop a couple of things to make it easier, but nothing was integrated into our system.Michael: Gotcha. Okay. And then, so how old is Orex? Rania: so we started the company in 2016. took about two years to have the first version, and it was only patient forms at the beginning, and then we did the clinical. And then we created the full software, Michael: the cloud, all in one platform, cloud. Mm-hmm. Based management software.Nice. Okay. And then, so right now, are you still rono working in your practice clinically? No. You sold it or I sold it. Rania: Oh man. When did you sell it? Soon after we started the company. It was taking way, like most of my time and most of my focus. Mm-hmm. So, Michael: How did you feel selling it? Were you like, is this, could I just do associates and do one clinical Rania: or, I thought about that and I realized I needed to focus.You know, having people think it's so easy to have associates and run the show from from afar. Yeah. But I tried it when I was on bed dressed and it's not that easy and it still takes you a lot of time and dedication. You cannot be on a beach or doing something else and have people working at everything goes smoothly.So I realized I had to decide, do I want to focus a hundred percent on Orx or 50% on orx, 55% on a practice. And I saw the potential in Orex. So, so I decided that it was the right choice. What made it really easy is one of the associates that came to work with us, um, was a perio pro. and he was an amazing clinician.And like at first when I thought about selling the practice and I spoke to, uh, a broker, everyone he presented to me, I was, I'm not too sure. I'm not too sure. But then when, Dr. Han said I'm interested in buying, it was a very easy decision. Like, he's gonna take great care of my patients, so Michael: and so he bought it.Okay, nice. So since then it's been, Man, all in with Oryx. and what I like about Oryx too is, You are open to everybody, right? DSLs and everything, but it's Yeah. Based off of a private practice, right? Where it's like, this is who created it for solo practitioner. Right. Like the private practice too, who can, can make it happen. Rania: Yeah. I think I, I was recently looking at, the practices that we get and our fastest growing segment is the startups.because for a startup it's really a no-brainer. I mean, no one is, no startup is going with the server, I hope. Mm-hmm. And they're getting on the tools that they need in one practice management software. They're getting the clinical and they're also getting a company with a forward vision. So, Anyone that looks at, at our software three years ago would think it's a tool to be new software now.So we're constantly evolving. Like we just added AI for radio graphs. every month we have a lot of new releases. Mm-hmm. Um, up to this date we spend most of our, money on development and engineering. So, We didn't think, okay, now we have a great product. Let's do all marketing and all sales, which most companies do.we still do a lot of development. I still think, that the software could be Michael: a lot. Like a lot of research and development in that process. Interesting. Talk to me about that ai, you, you're starting to implement that into. Rania: Yeah. Yeah. So, so we had a, uh, recent partnership with Pearl ai. we worked on the integration and we made it native.Uh, and I'm very careful with any integration I do because, Everyone wants to partner with everyone, but then, yeah, and then these integrations are clunky and they don't work and they're not part of the flow. So a big part of the decision with, which AI company we go with was, Who's gonna put enough resources to have a very, very seamless integration.Like, I don't want you to click on an image and take you to another software, and now wait for it to load. And now look and now see if mm-hmm there's decay or where the bone level is. I want it to happen immediately. and Pearl was one of the companies that worked with us, around that vision, and they were willing to put.Enough resources. So for each partnership, you need the two sides to be willing to put, enough engineering hours to make it an amazing integration. Michael: Yeah. No, wow. That's fantastic. That's news for me. I didn't know that. Pearl's fantastic. Like I spoke with Kyle not that long ago, and he's, highly about it, so we looked into it and it's, they're doing amazing things over there too.Yeah. So for both you guys to be partnering up, it's gonna be, it's new, you know. It's like, um, I guess like innovative, but at the same time, like it's uh, I mean, you know, it hasn't been done, so it's fantastic. Yeah, you're right. You are doing a lot of development in Oryx. I like that. So then what have you seen with startups right now where you can give us some good advice as far as within their year one to year five?Where maybe they did go with the server. Maybe they are paying an IT company, but also like they're also doing marketing, all this other stuff and they're kind of feeling like they're hitting a, a roadblock here somewhere. So, Rania: I dunno, like if you started with the server, it's not a good idea because if you're thinking to, it's not gonna grow with you the way you want.I mean, this is not the trend, this is not how the industry is moving I see a lot of the young startups thinking about having multiple locations, about growing. you need to start on cloud for that vision to happen. So, and we already have seen like, started with us two years ago now are on their third or fourth location, like Wow.Already. So I see that everyone is moving a lot faster than things were moving when I had my practice. in terms of marketing, I see that a lot of startups focus at the beginning on the external marketing and then they rely a lot on orgs for their internal marketing. and I always think about it this way, a and this is kind of what I did in my practice in the very early days.So the first 90 days we were spending 10 to $20,000 on AdWords, which was cra like Google did an article on us. Yeah. It was, back then it was crazy. Not a lot, much money. Yeah. Now it's more the trend. But back then was like, who's that crazy dentist? Yeah. Spending all that money. But this is what got patients in the door.And then having a great experience is what got the patients to come back. and I find with orgs, like they go, they do their online scheduling. It's already an amazing way of doing things. Um, they complete their patients forms. They're very interactive. We surveyed patients and they said that they thought that the office is more technologically advanced and they had more trust in the dentist before even visiting the practice.just because all the forms are picture based, very, very interactive. So patients are already getting that great experience. and then when the patients come in, they have this amazing exam. They have the report, all the, tools that they need are integrated. So it's very easy to pay. They're getting a tax to pay.they're signing their consent forms before coming online. So they feel that this experience carries through and these great experiences is what leads to giving the office a five star review. and it keeps growing that way. so we see a lot of our users telling us that Orex helps with their vision because it's that organized and it gives that patient that amazing experience start to finish.Michael: that's really good. Wow. Okay. So then, Orx right now is basically for everyone, but especially if you're looking to do a startup, it's the best starting point for you right now. Rania: I believe so. I believe, uh, not because I created it, but I believe it has a lot of tools that are so helpful for someone starting out.So let's say I was starting out and I hadn't gone through the Coy Center, I have on that. On the co information is already embedded in the software and it's all, updated every year. so if I'm doing an exam on a patient and I'm not sure about some diagnosis, I click on the information I can, and I have all the literature where this came from.So if a patient challenges me, like. Why are you recommending this treatment? I would just copy and paste the articles, like this is the latest literature, that's why we're recommending this treatment. if I want to send something to the insurance company, I have the latest literature, I have the diagnosis already pre-attached, and we pre-attached the radiograph.So like the whole system makes it so much easier. but for a new dentist, You're getting a software that is preloaded with the latest literatures on the forms that you need on the consent forms. Like basically a practice in a box. Yeah. And then you can customize it to what fits your needs and what fits your vision.But I think the clinical stuff there is in the software that's worth, yeah. Michael: Thousands of dollars. That, and that's what I get when I'm talking to you too, is like, I feel. You're really honed in on the, well, obviously cuz you created it, right? But like on the clinical side, the practical side, right? Like the, where it's like this is what is gonna facilitate your guys' job way much more times a thousand compared to like, we have a better online scheduling button, you wanna click it and it can be on the top left laptop.Right. You know what I mean? Like that's like, okay cool. I'd rather have that, you know what I mean? The clinical side of it, which is interesting. Very, very refreshing. Rania: Yeah. I think I'm more passionate about the clinical side because that's what I know, that's what I live and grieve. But I'm also very passionate about systems.And you see this in the practice management software throughout. So if you talk to one of, uh, of the other team members that were office managers, they would talk a lot more about that side of things. Mm-hmm. Um, And I think creating systems in your practice very early on would avoid some of the problems that I had.So if you're checking in a patient, there's a checklist for checking in a patient and if everything is checked, The appointment turns screen so you know that, the predetermination was sent, or the eligibility was checked. We checked the insurance, the patient is confirmed. I have all the information that I need pre-appointment, and I could customize the list to what my practice is.Same thing. If I'm checking out a patient, the appointment turns dark gray when everything is done. Uh, so I don't have to go to the front end, ask Olivia, did you collect the payment? Did you schedule the next appointment? Did you do this? Whatever is my checkout checklist. I know it's done when the appointment is dark gray.So at the end of the day, I wanna look at my screen and see it's all dark gray and. Blood pressure drop, so I know everything was Michael: done. You're like, maybe gel isn't that good right now. You know, Rania: easy, like, you know, these little systems and coming from the clinical perspective, like if you start thinking about it, I'm sending an insurance claim, everything auto attaches, like why am I having Mary in the front go and.Grab Tracy and ask her which one is number three. I need to attach it for Crown because we have, the radiographic system native to us. We know that this is the radiograph for number three. So now if I have a root can add that I'm sending to the insurance company, I'm auto attaching all of this. So we remove a lot of the barriers. Michael: Yeah. Increase more efficiency. Than anything else. Yeah. For you, Rania, I mean, I, I'm gonna ask a lot of, uh, Orex users this, but like for you, what was the thing that excited you the most right now from this point on to before? I know like every time there's something new that comes on, you're like, oh yeah.But right now, from this point on that you absolutely love utilize from Orex.Every Rania: month I have a new feature that I love and sometimes I even forget some features that we, and I'm like, oh, we have this. It's so cool. Uh, but I honestly think the risk assessment that we is the most valuable tool. just because gives you so much information about the patient. It. Excites your team.Like now your team understands why you do what you do. The team member reads this and at the front, you know how you get sometimes some team members that feel, oh, this doctor is pushing more treatment than they should. I don't like that. And now they understand or they're, they think they're trying to save the patient by saying, it's okay.You can do a filling, you don't need that crown, or mm-hmm. Let's do a trophy instead of the scaling. now your home team is on the same page. I find that, like, this is amazing for the team members because they understand the risk of the patient. It's amazing for the patient because they're educated and they're happy and they're referring you more, uh, patients, and it's easier for you because it makes you proud of your practice.Like this is what you're communicating to your patients. So I think that's the strongest tool or the one that I'm the most proud of. Yeah, Michael: the wheel, what the patient's term coined it, right. And they call it the wheel, but yeah, they call it theum, which is cool. Like, you know what I mean? They get it, they kind of give you the own nickname and then they're like, yeah, I wanna see the wheel.So I think that's fantastic too. If people wanted to see it, let's just say it right now. There's people who are like, oh man, I don't have orx, but what is the wheel all about? Can they go mind that somewhere? Rania: Yeah. I mean on our website or external software.com, and they can book a demo there. Rania Saleh DRAFT: okay. Michael: Yeah, guys, go do that.Thank you so much, Ranya, for being with us. It's been a pleasure. But before we say goodbye, can you tell our listeners where they can find you if they have any more questions or concerns? Rania: yeah, sure. Uh, hello@orexdentalsoftware.com and I'll answer you Michael: Uhhuh. Awesome. So guys go in Tolo, reach out to her, and at the same time, schedule a free personalized demo with Oryx.Check out the wheel, but check out every single thing that Rona's talking about, everything that they're developing, that they're doing, uh, for your practice. So I highly recommend it's gonna be the first link in the show notes below. So go check that out. And Ronya, thank you for being with us. It's been a pleasure and we'll hear from you soon.Thank you.‍‍

An airhacks.fm conversation with Ceki Guelcue (@ceki) about: cava the Turkish Java, PC XT 8080, 360 kB floppy disk, using Turbo Pascal, developing a board game in Turbo Pascal, learning MS-DOS, studying physics, using Smaky, EPFL Logitech is based in Lausanne, programming over physics, CDMA algorithm, OSI model, ping pong the simplest possible transport protocol, ping pong protocol is also known as Time-division multiplexing, TCP is a very simple protocol, easy of implementation is an interesting property, SLF4j a simple logging framework, learning C and struggling with pointers, the division algorithm is magical, Mix Network, developing mix-based email system, the beginnings of tor, the tor project, enjoying operator overloading in C++, DSLs might be a waste of time, the LogBack DS, Log4j vs. java.util.logging, anonymity and freedom, using traffic analysis to analyse tor, onion routing and tor, tor's honeypots, Ceki's paper: Mixing Email with Babel, Ceki's company: qos.ch Ceki Guelcue on twitter: @ceki

Does synthesizing a database sound like magic to you? In this episode of Talking Kotlin, we discuss how Synthesized uses Kotlin together with custom DSLs and OpenAPI to do just that! ––––––––––––––––––––––––––– SYNTHESIZED – https://www.synthesized.io/ Hurdy-Gurdy – https://github.com/CourseOrchestra/hurdy-gurdy KotlinPoet – https://github.com/square/kotlinpoet Swagger Parser – https://github.com/swagger-api/swagger-parser

Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language. Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about: CanCanCan vs Pundit RSpec DSL When is a DSL helpful? Why not use both DSLs & Object APIs? Extensibility When does a DSL become a framework? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyKaigi 2023 (https://rubykaigi.org/2023/) Mystified by RSpec's DSL? by Jason Swett (https://www.codewithjason.com/mystified-rspecs-dsl-parentheses-can-add-clarity/) Building Custom RSpec Matchers with Regular Objects (https://thoughtbot.com/blog/building-custom-rspec-matchers-with-regular-objects) FactoryBot (https://github.com/thoughtbot/factory_bot) Writing a Domain-Specific Language in Ruby by Gabe Berke-Williams (https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby) Capybara (https://teamcapybara.github.io/capybara/) Acceptance Tests at a Single Level of Abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) CanCanCan (https://github.com/CanCanCommunity/cancancan) Pundit (https://www.capvidia.com/products/pundit) Discrete Math and Functional Programming (https://www.amazon.com/Discrete-Mathematics-Functional-Programming-VanDrunen/dp/1590282604) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess. Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works. And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again. We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug. STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was. JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point. STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier? JOËL: I think having fewer scripts in this chain. STEPHANIE: [laughs] That's fair. JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there. STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code. JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception. So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying. STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well. JOËL: So my week has been up and down with all of this debugging. What's been new in your world? STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan. JOËL: Whoa. STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan. So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work. JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself? STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted. So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things. JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited? STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there. JOËL: Have you done much TypeScript? STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think. JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience. STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it. JOËL: That's the fun of going to a conference. STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me. JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language. And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application? STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code. JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea? STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English. And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests. JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on. STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before. JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README. STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks. JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby. STEPHANIE: I agree; it is ironic. [laughs] MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible. STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make. JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people. STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve? JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism. And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL. So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table. STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized. I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right? JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs. STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures. JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with? STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value. And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself. JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction? So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things? STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this? JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods. To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something. STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain. JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call. STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods. JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work. STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well. JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails. STEPHANIE: Why is that? JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested. STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it. JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL. STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever. JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization. Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems? STEPHANIE: I did use the CanCanCan gem a while ago. JOËL: What was your experience with that style of authorization? STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here? JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things. If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world. STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases. JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all. On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand. STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object. JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be. So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview. STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend. JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules. If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend. STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place. JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other. So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James. STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm. JOËL: On that note. Shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Listener, some of these articles are fun, and some are just plain bummers. Sure, we have a laugh here and there making fun of the author's absolutely dogshit prose and remarking on God seeing fit to equip Ian with an absolutely knock-out pair of DSLs, but it's hard to hide the genuine, seething anger the Brother's feel reading the latest piece about why transphobic billionaires are the real victims. Seriously though those lips God Damn.

Subscribe to Changelog++: https://changelog.com/podcast/519/discussFeaturing Shawn Wang – Twitter, GitHub, Website Adam Stacoviak – Mastodon, Twitter, GitHub, LinkedIn, Website Jerod Santo – Mastodon, Twitter, GitHub, LinkedIn Notes and Links AI Notes Why “Prompt Engineering” and “Generative AI” are overhyped Multiverse, not Metaverse The Particle/Wave Duality Theory of Knowledge OpenRAIL: Towards open and responsible AI licensing frameworks Open-ish from Luis Villa ChatGPT for Google The Myth of The Infrastructure Phase ChatGPT examples in the wild Debugging code TypeScript answer is wrong Fix code and explain fix dynamic programming Translating/refactoring Wasplang DSL AWS IAM policies Code that combines multiple cloud services Solving a code problem Explain computer networks homework Rewriting code from elixir to PHP Turning ChatGPT into an interpreter for a custom language, and then generating code and executing it, and solving Advent of Code correctly Including getting #1 place “I haven't done a single google search or consulted any external documentation to do it and I was able to progress faster than I have ever did before when learning a new thing.” Build holy grail website and followup with framework, copy, repsonsiveness For ++ subscribers Getting Senpai To Notice You Moving to Obsidian as a Public Second Brain Transcript**Jerod Santo:** Alright, well we have Sean Wang here again. Swyx, welcome back to the show.**Shawn Wang:** Thanks for having me back on. I have lost count of how many times, but I need to track my annual appearance on the Changelog.**Adam Stacoviak:** Is that twice this year on this show, and then once on JS Party at least, right?**Shawn Wang:** Something like that, yeah. I don't know, it's a dream come true, because, I changed careers into tech listening to the Changelog, so every time I'm asked on, I'm always super-grateful. So yeah, here to chat about all the hottest, latest things, right?**Adam Stacoviak:** Yeah.**Jerod Santo:** That's right, there's so much going on right now. It seems like things just exploded this fall. So we had Stable Diffusion back in late August; it really blew up at the end of August. And then in September is when we had Simon Willison on the show to talk about Stable Diffusion breaking the internet. You've been tracking this stuff really closely. You even have a Substack, and you've got Obsidian notes out there in the wild, and then of course, you're learning in public, so whenever Swyx is learning something, we're all kind of learning along with you... Which is why we brought you back on. I actually included your Stable Diffusion 2.0 summary stuff in our Changelog News episode a couple of weeks back, and a really interesting part of that post that you have, that I didn't talk about much, but I touched on and I want you to expand upon here is this idea of prompt engineering, not as a cool thing, but really as a product smell. And when I first saw it, I was like, "No, man, it's cool." And then I read your explainer and I'm like, "No, he's right. This is kind of a smell."**Adam Stacoviak:** "Dang it, he's right again."**Jerod Santo:** Yeah. We just learned about prompt engineering back in September, with Simon, and talking about casting spells and all this, and now it's like, well, you think it's overhyped. I'll stop prompting you, and I'll just let you engineer an answer.**Jerod Santo:** Well, so I don't know if you know, but the Substack itself got its start because I listened to the Simon episode, and I was like, "No, no, no. Spellcasting is not the way to view this thing. It's not something we glorify." And that's why I wrote "Multiverse, not Metaverse", because the argument was that prompting is -- you can view prompting as a window into a different universe, with a different seed, and every seed is a different universe. And funny enough, there's a finite number of seeds, because basically, Stable Diffusion has a 512x512 space that determines the total number of seeds.So yeah, prompt engineering [unintelligible 00:04:23.23] is not my opinion. I'm just reporting on what the AI thought leaders are already saying, and I just happen to agree with it, which is that it's very, very brittle. The most interesting finding in the academic arena about prompt engineering is that default GPT-3, they ran it against some benchmarks and it came up with like a score of 17 out of 100. So that's a pretty low benchmark of like just some logical, deductive reasoning type intelligence tests. But then you add the prompt "Let's think step by step" to it, and that increases the score from 17 to 83... Which is extremely -- like, that sounds great. Like I said, it's a magic spell that I can just kind of throw onto any problems and make it think better... But if you think about it a little bit more, like, would you actually use this in a real work environment, if you said the wrong thing and it suddenly deteriorates in quality - that's not good, and that's not something that you want to have in any stable, robust product; you want robustness, you want natural language understanding, to understand what you want, not to react to random artifacts and keywords that you give.Since then, we actually now know why "Let's think step by step" is a magic keyword, by the way, because -- and this is part of transformer architecture, which is that the neural network has a very limited working memory, and if you ask a question that requires too many steps to calculate the end result, it doesn't have the working memory to store the result, therefore it makes one up. But if you give it the working memory, which is to ask for a longer answer, the longer answer stores the intermediate steps, therefore giving you the correct result.**Jerod Santo:** [06:00] Talk about implementation detail, right?**Shawn Wang:** It's yeah, it's leaking implementation detail, it's not great, and that's why a lot of the thought leaders - I think I quoted Andrej Karpathy, who was head of AI at Tesla, and now he's a YouTuber... [laughter] And Sam Altman, who is the CEO of -- yeah, he quit Tesla to essentially pursue an independent creator lifestyle, and now he's a YouTuber.**Jerod Santo:** I did not know that.**Adam Stacoviak:** All roads lead to creator land, you know what I'm saying? You'll be an expert in something for a while, and eventually you'll just eject and be like "I want to own my own thing, and create content, and educate people around X."**Shawn Wang:** So at my day job I'm a head of department now, and I work with creators, and some of them have very valuable side hustles... And I just had this discussion yesterday, of like "Why do you still have a job if you're an independent creator? Like, isn't total independence great." And I had to remind them, "No. Like, career progression is good. You're exposed to new things etc." but that's just me trying to talk him out of quitting. [laughter] No, I have a serious answer, but we're not here to talk about that.**Jerod Santo:** Right.**Shawn Wang:** So I'll read out this quote... So Sam Altman, CEO of OpenAI, says "I don't think we'll still be doing prompt engineering in five years. It's not about figuring out how to hack the prompt by adding one magic word to the end that changes everything else. What will matter is the quality of ideas and the understanding that you want." I think that is the prevailing view, and I think as people change models, they are understanding the importance of this.So when Stable Diffusion 1 came out, everyone was like, "Alright, we know how to do this. I'm going to build an entire business on this" etc. And then Stable Diffusion 2 came out and everything broke. All the [unintelligible 00:07:40.21] stopped working, because they just expected a different model, and you have to increase your negative prompting, and people are like "What is negative prompting?" etc. These are all new techniques that arise out of the model, and this is going to happen again and again and again, because you're relying on a very, very brittle foundation.Ultimately, what we want to get people to is computers should understand what we want. And if we haven't specified it well enough, they should be able to ask us what we want, and we should be able to tell them in some capacity, and eventually, they should produce something that we like. That is the ultimate alignment problem.We talk about AI a lot, and you hear about this alignment problem, which is basically some amount of getting it to do what we want it to do, which is a harder problem than it sounds until you work with a programmer, and try to give them product specs and see how many different ways they can get it wrong. But yeah, this is an interesting form of the alignment problem, and it interestingly has a very strong tie with Neuralink as well, because the problem, ultimately, is the amount of bandwidth that we can transfer from our brain to an artificial brain. And right now it's prompts. But why does it have to be prompts? It could be images. That's why you have image-to-image in Stable Diffusion. And it could also be brain neural connections. So there's a lot in there; I'll give you time to pick on whatever you respond to...**Jerod Santo:** Well, I went from -- so I was super-excited about prompting after talking with Simon a few months back, and I was super-excited about Stable Diffusion. And I went from like giddy schoolboy who's just like "Gonna learn all the spells" very quickly to like aggravated end user who's like "Nah, I don't want to go to this other website and copy and paste this paragraph of esoterica in order to get a result that I like." And so I wonder what's so exciting about the whole prompt engineering thing to us nerds, and I think maybe there's like a remnant of "Well, I still get to have esoteric knowledge" or "I still get to be special somehow if I can learn this skill..."[09:46] But in reality, what we're learning, I think, by all the people using ChatGPT - the ease of use of it, as opposed to the difficulty of getting an image out of Stable Diffusion 1.0 at least, is quite a bit different. And it goes from aggravating and insider baseball kind of terms, keywords, spells, to plain English, explain what you want, and maybe modify that with a follow-up, which we'll get into ChatGPT, but we don't necessarily have to go into the depths of that right now... But I changed very quickly, even though I still thought prompt engineering was pretty rad... And then when you explain to me how Stable Diffusion 2 completely broke all the prompts, I'm like, "Oh yeah, this is a smell. This doesn't work. You can't just completely change the way it works on people..." That doesn't scale.**Shawn Wang:** Yeah. And then think about all the businesses that have been built already. There haven't been any huge businesses built on Stable Diffusion, but GPT-3 has internal models as well. So Jasper recently raised like a 1.5 billion valuation, and then ChatGPT came out, basically validating Jasper... So all the people who bought stock are probably not feeling so great right now. [laughs]That's it. So I don't want to overstate my position. There are real moats to be built around AI, and I think that the best entrepreneurs are finding that regardless of all these flaws. The fact that there are flaws right now is the opportunity, because so many people are scared off by it. They're like, "AI has no moats. You're just a thin wrapper around OpenAI." But the people who are real entrepreneurs figure it out. So I think it's just a really fascinating case study in technology and entrepreneurship, because here's a new piece of technology nobody knows how to use and productize, and the people who figure out the playbook are the ones who win.**Adam Stacoviak:** Yeah. Are we back to this -- I mean, it was like this years ago, when big data became a thing... But are we back to this whole world where -- or maybe we never left, where "Data is the new oil", is the quote... Because to train these models, you have to have data. So you could be an entrepreneur, you could be a technologist, you could be a developer, you could be in ML, you could be whatever it might take to build these things, but at some point you have to have a dataset, right? Like, how do you get access to these datasets? It's the oil; you've got to have money to get these things, you've got to have money to run the hardware to enable... Jerod, you were saying before the call, there was speculation of how much it costs to run ChatGPT daily, and it's just expensive. But the data is the new oil thing - how does that play into training these models and being able to build the moat?**Shawn Wang:** Yeah. So one distinction we must make there is there is a difference between running the models, which is just inferences, which is probably a few orders of magnitude cheaper than training the models, which are essentially a one-time task. Not that many people continuously train, which is nice to have, but I don't think people actually care about that in reality.So the training of the models ranges between -- and let's just put some bounds for people. I love dropping numbers in podcasts, by the way, because it helps people contextualize. You made an oblique reference to how much ChatGPT costs, but let's give real numbers. I think the guy who did an estimate said it was running at $3 million a month. I don't know if you heard any different, but that's...**Jerod Santo:** I heard a different estimate, that would have been more expensive, but I think yours is probably more reliable than mine... So let's just go with that.**Shawn Wang:** I went through his stuff, and I was like, "Yeah, okay, this is on the high end." I came in between like one to three as well. It's fine. And then for training the thing - so it's widely known or widely reported that Stable Diffusion cost 600k for a single run. People think the full thing, including R&D and stuff, was on the order of 10 million. And GPT-3 also costs something on the order of tens of millions. So I think that is the cost, but then also that is training; that is mostly like GPU compute. We're not talking about data collection, which is a whole other thing, right?[13:46] And I think, basically, there's a towering stack of open source contributions to this data collective pool that we have made over time. I think the official numbers are like 100,000 gigabytes of data that was trained for Stable Diffusion... And it's basically pooled from like Flickr, from Wikipedia, from like all the publicly-available commons of photos. And that is obviously extremely valuable, because -- and another result that came out recently that has revolutionized AI thinking is the concept of Chinchilla Laws. Have you guys covered that on the show, or do I need to explain that?**Adam Stacoviak:** Chinchilla Laws misses the mark for me. Please tell. I like the idea though; it sounds cool, so please...**Shawn Wang:** Yeah, they just had a bunch of models, and the one that won happened to be named Chinchilla, so they kind of went with it. It's got a cute name. But the main idea is that we have discovered scaling laws for machine learning, which is amazing.So in the sort of classical understanding of machine learning, you would have a point at which there's no further point to train. You're sort of optimizing for a curve, and you get sort of like diminishing returns up to a certain point, and then that's about it. You would typically conclude that you have converged on a global optimum, and you kind of just stop there. And mostly, in the last 5 to 10 years, the very depressing discovery is that this is a mirage. This is not a global optimum, this is a local optimum... And this is called the Double Dissent Problem. If you google it, on Wikipedia you'll find it... Which is you just throw more data at it, it levels off for a bit, and then it continues improving. And that's amazing for machine learning, because that basically precipitated the launch of all these large models. Because essentially, what it concludes is that there's essentially no limit to how good these models are, as long as you can throw enough data at it... Which means that, like you said, data is the new oil again, but not for the old reason, which is like "We're gonna analyze it." No, we're just gonna throw it into all these neural nets, and let them figure it out.**Adam Stacoviak:** Yeah. Well, I think there's a competitive advantage though if you have all the data. So if you're the Facebooks, or if you're the Google, or X, Y, or Z... Instagram, even. Like, Instagram ads are so freakin relevant that --**Jerod Santo:** Apple...**Adam Stacoviak:** Yeah, Apple for sure.**Jerod Santo:** TikTok...**Adam Stacoviak:** Yeah. Gosh... Yeah, TikTok. Yeah, the point is, these have a competitive advantage, because they essentially have been collecting this data, would-be to analyze, potentially to advertise to us more, but what about in other ways that these modes can be built? I just think like, when you mentioned the entrepreneurial mind, being able to take this idea, this opportunity as this new AI landscape, to say, "Let me build a moat around this, and not just build a thin layer on top of GPT, but build my own thing on all together", I've gotta imagine there's a data problem at some point, right? Obviously, there's a data problem at some point.**Shawn Wang:** So obviously, the big tech companies have a huge headstart. But how do you get started collecting this data as a founder? I think the story of Midjourney is actually super-interesting. So between Midjourney, Stability AI and OpenAI, as of August, who do you think was making the most money? I'll give you the answer, it was Midjourney.**Jerod Santo:** Oh, I was gonna guess that. You can't just give us the answer...**Shawn Wang:** Oh... [laughs]**Jerod Santo:** I had it.**Shawn Wang:** But it's not obvious, right? Like, the closed source one, that is not the big name, that doesn't have all the industry partnerships, doesn't have the celebrity CEO, that's the one that made the most money.**Jerod Santo:** Yeah. But they launched with a business model immediately, didn't they? They had a subscription out of the box.**Shawn Wang:** Yeah, they did. But also, something that they've been doing from the get-go is that you can only access Midjourney through Discord. Why is that?**Jerod Santo:** Right. Because it's social, or... I don't know. What do you think? That's my guess, because they're right in front of everybody else.**Shawn Wang:** Data.**Adam Stacoviak:** Data.**Jerod Santo:** Oh...**Adam Stacoviak:** Please tell us more, Shawn.**Shawn Wang:** Because the way that you experience Midjourney is you put in a prompt, it gives you four images, and you pick the ones that you like for enhancing. So the process of using Midjourney generates proprietary data for Midjourney to improve Midjourney. So from v3 to v4 of Midjourney they improved so much that they have carved out a permanent space for their kind of visual AI-driven art, that is so much better than everyone else because they have data that no one else has.**Jerod Santo:** [17:55] That's really cool.**Adam Stacoviak:** And that's relevance, or is it like quality takes? What is the data they actually get?**Shawn Wang:** Preference, right?**Jerod Santo:** What's good.**Shawn Wang:** Yeah. Literally, you type in a prompt, unstructuredly it tells you -- they give you four low-res images, and you have to pick one of the four to upscale it. By picking that four, they now have the data that says "Okay, out of these four, here's what a human picks." And it's and it's proprietary to them, and they paid nothing for it, because it's on Discord. It's amazing.**Jerod Santo:** That is awesome.**Shawn Wang:** They didn't build a UI, they just used Discord. I don't know if Discord knows this, or cares... But it's pretty freakin' phenomenal...**Jerod Santo:** That's pretty smart.**Shawn Wang:** ...because now they have this--**Adam Stacoviak:** It's the ultimate in scrappy, right? It's like, by any means necessary. That's the ultimate binding that's necessary, right? You'll make a beat however you can to put up the track and become the star.**Jerod Santo:** Right.**Adam Stacoviak:** That's amazing.**Jerod Santo:** That's really cool.**Shawn Wang:** So just to close this out, the thing I was saying about Chinchilla was "More data is good, we've found the double descent problem. Now let's go get all the data that's possible." I should make a mention about the open source data attempts... So people understand the importance of data, and basically Luther.AI is kind of the only organization out there that is collecting data that anyone can use to train anything. So they have two large collections of data called The Stack and The Pile, I think is what it's called. Basically, the largest collection of open source permissively-licensed text for you to train whatever language models you want, and then a similar thing for code. And then they are training their open source equivalents of GPT-3 and Copilot and what have you. But I think those are very, very important steps to have. Basically, researchers have maxed out the available data, and part of why Open AI Whisper is so important for OpenAI is that it's unlocking sources of text that are not presently available in the available training data. We've basically exhausted, we're data-constrained in terms of our ability to improve our models. So the largest source of untranscribed text is essentially on YouTube, and there's a prevailing theory that the primary purpose of Whisper is to transcribe all video, to get text, to train the models... [laughs] Because we are so limited on data.**Adam Stacoviak:** Yeah. We've helped them already with our podcasts. Not that it mattered, but we've been transcribing our podcasts for a while, so we just gave them a leg up.**Shawn Wang:** You did.**Adam Stacoviak:** And that's open source on GitHub, too. They probably -- I mean, ChatGPT knows about Changelog. They know that -- Jerod, I don't know if I told you this yet, but I prompted that; I said "Complete the sentence "Who's the hosts of the Changelog podcast?" "Well, that's the dynamic duo, Jerod Santo and Adam Stacoviak." It knows who we are. I mean, maybe it's our transcripts, I don't know, but it knows...**Jerod Santo:** Please tell me it called us "the dynamic duo"... [laughs]**Adam Stacoviak:** I promise you!**Jerod Santo:** It said that?**Adam Stacoviak:** I promise you it said that. "The dynamic duo..."**Jerod Santo:** Oh, [unintelligible 00:20:34.05]**Adam Stacoviak:** It actually reversed the order. It said Adams Stacoviak first and then Jerod Santo... Because usually, my name is, I guess, first, because - I have no clue why it's ever been that way, but... It said "The dynamic duo, Adam Stacoviak and Jerod Santo..."**Jerod Santo:** That's hilarious.**Adam Stacoviak:** ...hosts of the Changelog Podcast.**Jerod Santo:** It already understands flattery.**Adam Stacoviak:** Yeah, it does. Well, actually, the first prompt didn't include us, and I said "Make it better, and include the hosts." And that's all I said, was "Make it better and include the hosts." So in terms of re-prompting, or refining the response that you get from the prompts - that to me is like the ultimate human way to conjure the next available thing, which is try again, or do it better by giving me the hosts, too. And the next one was flattery, and actually our names in the thing. So... It's just crazy. Anyways...**Shawn Wang:** Yeah, so that is the big unlock that ChatGPT enabled.**Jerod Santo:** Totally.**Shawn Wang:** Which is why usually I take a few weeks for my takes to marinate, for me to do research, and then for me to write something... But I had to write something immediately after ChatGPT to tell people how important this thing is. It is the first real chat AI, which means that you get to give human feedback. And this theme of reinforcement learning through human feedback is - the low-res version of it was Midjourney. Actually, the lowest-res version of it was TikTok, because every swipe is human feedback. And being able to incorporate that into your -- and same for Google; every link click is a is human feedback. But the ability to incorporate that and to improve the recommendations and the generations is essentially your competitive advantage, and being able to build that as part of your UI... Which is why, by the way, I have been making the case that frontend engineers should take this extremely seriously, because guess who's very good at making a UI?**Adam Stacoviak:** Yeah, for sure.**Shawn Wang:** But yeah, ChatGPT turns it from a one-off zero-shot experience where you prompt the thing, and then you get the result, and it's good or bad, that's about the end of the story - now it's an interactive conversation between you and the bot, and you can shape it to whatever you want... Which is a whole different experience.**Break:** [22:31]**Adam Stacoviak:** "Complete the sentence" has been a hack for me to use, particularly with ChatGPT. "Complete the sentence" is a great way to easily say "Just give me somebody long, given these certain constraints."**Jerod Santo:** Well, that's effectively what these models are, right? They're auto-complete on steroids. Like, they are basically auto-completing with a corpus of knowledge that's massive, and guessing what words semantically should come next, kind of a thing... In layman's terms; it's more complicated than that, of course, but they are basically auto-completers.**Adam Stacoviak:** Yeah. On that note though, we have a show coming out... So we're recording this on a Friday, the same day we release the same podcast, but it's the week before. So we had Christina Warren on, and so I was like "You know what? I'm gonna use ChatGPT to give me a leg up. Let me make my intro maybe a little easier, and just spice it up a little bit." So I said "Complete the sentence "This week on the Changelog we're talking to Christina Warren about..." and then I ended the quote, and I said "and mention her time at Mashable, film and pop culture, and now being a developer advocate at GitHub." And I've gotta say, most of, 50% of the intro for the episode with Christina is thanks to ChatGPT. I don't know if I break the terms of service by doing that or not, but like -- do I? I don't know. If I do, sue me. I'm sorry. But... Don't sue me. Don't sue us. We'll take it down. We'll axe it out.**Jerod Santo:** We'll rewrite it.**Adam Stacoviak:** Yeah, we'll rewrite it. But, I mean, it's basically what I would have said. So...**Shawn Wang:** There's a nice poetry -- there's a YouTuber who's been on this forever, Two Minute Papers, and what he often says is, "What a time to be alive." And this is very much what a time to be alive. But not just because we're seeing this evolve live, but because we get to be part of the training data. And there was a very interesting conversation between Lex Fridman and Andrej Andrej Karpathy; he was inviting him on to the show... He said, "Our conversation will be immortalized in the training data. This is a form of immortality, because we get to be the first humans essentially baked in." [laughter]**Jerod Santo:** Essentially baked in... Hello, world.**Shawn Wang:** Like, 100-200 years from now, if someone has the Changelog podcast, they will keep having Jerod and Adam pop up, because they're in the goddamn training data. [laughs]**Jerod Santo:** They're like "Come on, these guys have been dead for a long time."**Adam Stacoviak:** [26:05] Let them go. Give them their RIP. [laughter]**Shawn Wang:** Which is poetic and nice. Yeah.**Adam Stacoviak:** Yeah, it is a good time to be alive... I think it is interesting, too... I just wonder -- I mean, this might be jumping the shark a little bit, but I often wonder, at what point does humanity stop creating? And at some point, 100 years from now, or maybe more, I don't know, we're gonna be -- maybe sooner, given how fast this is advancing, that we'll create only through what was already created. "At what point is the snake eating the snake?" kind of thing. Like, is there an end to human creativity at some point, because we are just so reliant, at some point, shape, or form, on [unintelligible 00:26:45.20] because of training data, and this just kind of like morphing to something much, much bigger in the future?**Shawn Wang:** So I have an optimistic attitude to that... This question basically is asking, "Can we exhaust infinity?" And so my obvious answer is no. There is a more concrete stat I can give you, which is I think - this is floating around out there. Don't quote me on the exact number, but apparently, 10% of all Google searches every single year have never been asked before. And Google's been around for like 20 years.**Adam Stacoviak:** That's a big percentage.**Shawn Wang:** It's still true. So it's on that order; it might be like 7%, it might be 13%.**Adam Stacoviak:** Well, is it trending down though? Is it trending down? Is it 10% per year, but is it like trending down to like 8%?**Jerod Santo:** Is it because we put the year in our searches? [laughter]**Adam Stacoviak:** Yeah, it's true, Jerod. Good one.**Shawn Wang:** Yeah. But anyway, so that's what the SEO people talk about when they talk about long tail... The amount of infinity is always bigger than our capability of creating to fill it.**Jerod Santo:** I mean, I feel like if you look at us in an abstract way, humans, we are basically taking in inputs and then generating outputs. But that's creativity, right? So I think what we're just doing is adding more to the inputs. Now we have computers that also take in inputs and generate outputs, but like, everything's already a remix, isn't it? Our life experience and everything that goes into us, and then something else produces a brand new thing, which isn't really new, but it's a remix of something else that we experienced... So I feel like we're just going to keep doing that, and we'll have computer aid at doing that, and the computer eventually maybe will just do the actual outputting part, but we somehow instruct it. I'm with Swyx on this one; I don't think there's going to be an end to human creativity, as the AI gets more and more output... What's the word? When you're just -- not notorious. What's it called when you just can't stop outputting stuff?**Adam Stacoviak:** I don't know.**Jerod Santo:** Prolific!**Adam Stacoviak:** Prolific.**Jerod Santo:** As the AI gets more and more output-prolific, and overwhelms us with output, I think we're still going to be doing our thing.**Adam Stacoviak:** Yeah. It's the ultimate reduction in latency to new input, right? Think of 100 years ago - creative folks were few and far between. They had miles between them, depending on your system; maybe it's kilometers. No offense. But there's distance of some sort of magnitude, and the lack of connection and shared ideas. So that's the latency, right? And now, the latency to the next input is just so small in comparison, and will get reduced to basically nothing. So we'll just constantly be inputting and outputting creativity, we'll just become like a creative [unintelligible 00:29:31.17] system with zero latency, nonstop creativity... Go, go, go...**Shawn Wang:** Well, I think this is where you start -- I don't know about you, but I feel a little bit uncomfortable with that, right? Entropy is always increasing in the universe; we're contributing to increasing noise and not signal. And that is a primary flaw of all these language models, is just they are very confidently incorrect. They have no sense of physics, no sense of logic; they will confidently assert things that are not true, and they're trained on sounding plausible, rather than being true.**Jerod Santo:** Right. They're kind of like me when I was in college, you know?**Shawn Wang:** Exactly. [laughter]**Jerod Santo:** [30:10] Just so much confidence, but wrong most of the time. [laughs]**Shawn Wang:** Exactly. Which happens to Galactica, which is this sort of science LLM from Meta, where Yann LeCun, who is one of the big names in tech, was like "This thing will generate papers for you." And within three days, the internet tore it apart, and they had to take it down. It was a very, very dramatic failure, this kind of tech... Because you're talking about biology, and science, and medicine, and you can't just make stuff up like that. [laughs]**Jerod Santo:** Right. So like in the world where chat GPT operates today, which is really in the world of fiction, and kind of BS-ing, for lack of a better term, like writing intros to a podcast - you know, like, it doesn't have to be correct necessarily; it can be like close enough to correct, and then you can massage it, of course, you can cherry pick to get the one that you like... But when the rubber hits the road, like on serious things, like science, or "How many of these pills do I need to take?" I guess that is also -- that's health science. So science, and other things... It's like, it can't be correct 60% of the time, or 80%, or even like 95%. It's gotta reach that point where you actually can trust it. And because we're feeding it all kinds of information that's not correct, de facto... Like, how much of the internet's wrong? Most of it, right?**Adam Stacoviak:** I mean, medicine though has evolved too, and it hasn't always been correct, though it's also very serious... You'd get advice from a doctor 10-15 years ago, they'd say it with full confidence and full accuracy, but it's only based on that current dataset.**Jerod Santo:** But you can sue them for malpractice and stuff, right? Like, how do we take recourse against--**Adam Stacoviak:** You can if they actually have malpractice; they can be wrong, because it's as much science as possible to make the most educated guess. It's malpractice when there's negligence; it's not malpractice when they're wrong.**Jerod Santo:** A good doctor will actually go up to the fringe and say, "You know what - I'm not 100% sure about this. It's beyond my knowledge."**Adam Stacoviak:** Sure. For sure.**Jerod Santo:** "Here's what you can do. Here's the risks of doing that." Whereas the chat bots, the ChatGPT thing is like, "The answer is 7", and you're like, "It actually was 12." And it's like, "Ah, shoot..." [laughter]**Adam Stacoviak:** Well, I think when there's mortality involved, maybe there's going to be a timeframe when we actually begin to trust the future MedGPT, for example; I don't know if that's a thing in the future, but something that gives you medical results or responses based upon data, real data, potentially, that you get there, but it's not today.**Jerod Santo:** Well, I think this goes back to the data point that you made, and I think where we go from like the 95 -- I'm making up numbers here, but like 95% accuracy, to get it to like 98.5%, or 99%. Like, that's gonna require niche, high-value, high-signal data that maybe this medical facility has, because they've been collecting it for all these years. And they're the only ones who have it. And so maybe that's where you like carve out proprietary datasets that take these models from a baseline of accuracy, to like, in this particular context of health it's this much accuracy. And then maybe eventually you combine all those and have a super model. I don't know... Swyx, what do you think?**Shawn Wang:** I love the term super-model. I think the term [unintelligible 00:33:23.10] in the industry is ensemble. But that just multiplies the costs, right? Like if you want to run a bank of five models, and pick the best one, that obviously 6x-es your cost. So not super-interesting; good for academic papers, but not super-interesting in practice, because it's so expensive.There's so many places to go with this stuff... Okay, there's one law that I love, which is Brandolini's Law. I have this tracking list of eponymous laws... Brandolini's law is people's ability to create bulls**t far exceeds the ability of people to refute it. Basically, if all of these results of this AI stuff is that we create better bulls***t engines, it's not great. And what you're talking about, the stuff with like the 90% correct, 95% correct - that is actually a topic of discussion. It's pretty interesting to have the SRE type conversation of "How many nines do you need for your use case, and where are we at right now?" Because the number of nines will actually improve. We are working on -- sorry, "we" as in the collective human we, not me personally...**Adam Stacoviak:** [34:32] The royal we, yes.**Shawn Wang:** The role royal we... Like, humanity is working on ways to improve, to get that up. It's not that great right now, so that's why it's good for creativity and not so much for precision, but it will get better. One of the most viral posts on Hacker News is something that you featured, which is the ability to simulate virtual machines instead of ChatGPT-3, where people literally opened -- I mean, I don't know how crazy you have to be, but open ChatGPT-3, type in LS, and it gives you a file system. [laughter]**Jerod Santo:** But that only exists -- it's not a real file system, it's just one that's [unintelligible 00:35:00.05]**Shawn Wang:** It's not a real file system, for now. It's not a real set file system for now, because they hallucinate some things... Like, if you ask it for a Git hash, it's gonna make up a Git hash that's not real, because you can verify [unintelligible 00:35:10.25] MD5. But like, how long before it learns MD5? And how long before it really has a virtual machine inside of the language model? And if you go that far, what makes you so confident that we're not in one right now? [laughs]**Jerod Santo:** Now I'm uncomfortable... That actually is a very short hop into the simulation hypothesis, because we are effectively simulating a brain... And if you get good enough at simulating brains, what else can you simulate?**Adam Stacoviak:** What else WOULD you want to simulate? I mean, that's the Holy Grail, a brain.**Shawn Wang:** Yeah. So Emad Mostaque is the CEO of Stability AI. He's like, "We're completely unconcerned with the AGI. We don't know when it'll get here. We're not working on it. But what we're concerned about is the ability to augment human capability. People who can't draw now can draw; people who can't write marketing texts or whatever, now can do that." And I think that's a really good way to approach this, which is we don't know what the distant future is gonna hold, but in the near future, this can help a lot of people.**Adam Stacoviak:** It's the ultimate tool in equality, right? I mean, if you can do --**Shawn Wang:** Yeah, that's a super-interesting use case. So there was a guy who was like sort of high school-educated, not very professional, applying for a job. And what he used ChatGPT to do was like "Here's what I want to say, and please reward this in a professional email." And it basically helped to pass the professional class status check. Do you know about the status checks? All the other sort of informal checks that people have, like "Oh, we'll fly you in for your job interview... Just put the hotel on your credit card." Some people don't have credit cards. And likewise, when people email you, you judge them by their email, even though some haven't been trained to write professionally, right? And so yeah, GPT is helping people like that, and it's a huge enabler for those people.**Adam Stacoviak:** Hmm... That is -- I mean, I like that idea, honestly, because it does enable more people who are less able... It's a net positive.**Shawn Wang:** Yeah. I mean, I seem generally capable, but also, I have RSI on my fingers, and sometimes I can't type. And so what Whisper is enabling me to do, and Copilot... So GitHub, at their recent GitHub Universe, recently announced voice-enabled Copilot... And it is good enough for me to navigate VS Code, and type code with Copilot and voice transcription. Those are the two things that you need; and they're now actually good enough that I don't have to learn a DSL for voice coding, like you would with Talon, or the prior solutions.**Adam Stacoviak:** You know, it's the ultimate -- if you're creative enough, it's almost back to the quote that Sam had said, that you liked... Well, I'm gonna try and go back to it; he says "At the end, because they were just able to articulate it with a creative eye that I don't have." So that to me is like insight, creativity; it's not skill, right? It's the ability to dream, which is the ultimate human skill, which is - since the beginning of time, we've been dreamers.**Shawn Wang:** [38:01] This is a new brush. Some artists are learning to draw with it. There'll be new kinds of artists created.**Adam Stacoviak:** Provided that people keep making the brush, though. It's a new brush...**Shawn Wang:** Well, the secret's out; the secret's out that you can make these brushes.**Jerod Santo:** Right.**Adam Stacoviak:** Yeah, but you still have to have the motivation to maintain the brush, though.**Jerod Santo:** What about access, too? I mean, right now you're talking about somebody who's made able, that isn't otherwise, with let's just say ChatGPT, which is free for now. But OpenAI is a for profit entity, and they can't continue to burn money forever; they're gonna have to turn on some sort of a money-making machine... And that's going to inevitably lock some people out of it. So now all of a sudden, access becomes part of the class, doesn't it? Like, you can afford an AI and this person cannot. And so that's gonna suck. Like, it seems like open source could be for the win there, but like you said, Swyx, there's not much moving and shaking in that world.**Adam Stacoviak:** Well, I haven't stopped thinking about what Swyx said last time we talked, which was above or below the API, which is almost the same side of the coin that we talked about last time, which is like, this the same thing.**Jerod Santo:** Yeah. Well, ChatGPT is an API, isn't it?**Shawn Wang:** Nice little callback. Nice. [laughter]**Adam Stacoviak:** I really haven't been able to stop thinking about it. Every time I use any sort of online service to get somebody to do something for me that I don't want to do, because I don't have the time for it, or I'd rather trade dollars for my time, I keep thinking about that above or below the API, which is what we talked about. And that's what Jerod has just brought up; it's the same exact thing.**Shawn Wang:** Yep, it is. One more thing I wanted to offer, which is the logical conclusion to generative. So that post where we talked about why prompt engineering is overrated - the second part of it is why you shouldn't think about this as generative... Because right now, the discussion we just had was only thinking about it as a generative type of use case. But really, what people want to focus on going forward is -- well, two things. One is the ability for it to summarize and understand and reason, and two, for it to perform actions. So the emerging focuses on agentic AI; AI agents that can perform actions on your behalf. Essentially, hooking it up to -- giving it legs and legs and arms and asking it to do stuff autonomously.So I think that's super-interesting to me, because then you get to have it both ways. You get AI to expand bullet points into prose, and then to take prose into bullet points. And there's a very funny tweet from Josh Browder, who is the CEO DoNotPay, which is kind of like a --**Adam Stacoviak:** Yeah, I'm a fan of him.**Shawn Wang:** Yeah. Fantastic, right? So what DoNotPay does is they get rid of annoying payment UX, right? Like, sometimes it was parking tickets, but now they are trying to sort of broaden out into different things. So he recently tweeted that DoNotPay is working on a way to talk to Comcast to negotiate your cable bill down. And since Comcast themselves are going to have a chat bot as well, it's going to be chat bots talking to each other to resolve this... [laughter]**Adam Stacoviak:** Wow, man...**Jerod Santo:** It's like a scene out of Futurama, or something...**Shawn Wang:** Yeah. So I'm very excited about the summarization aspects, right? One of the more interesting projects that came out of this recent wave was Explained Paper, which is - you can throw any academic paper at it and it explains the paper to you in approachable language, and you can sort of query it back and forth. I think those are super-interesting, because that starts to reverse Brandolini is law. Instead of generating bulls**t, you're taking bulls**it in, getting into some kind of order. And that's very exciting.**Adam Stacoviak:** Yeah. 17 steps back, it makes me think about when I talk to my watch, and I say "Text my wife", and I think about like who is using this to their betterment? And I'm thinking like, we're only talking about adults, for the most part. My kid, my son, Eli - he talks to Siri as if like she knows everything, right? But here's me using my watch to say "Text my wife." I say it, it puts it into the phone... And the last thing it does for me, which I think is super-interesting for the future, as like this AI assistant, is "Send it" is the final prompt back to me as the human; should I send this? And if I say no, Siri doesn't send it. But if I say "Send it", guess what she does? She sends it. But I love this idea of the future, like maybe some sort of smarter AI assistant like that. I mean, to me, that's a dream. I'd love that.**Shawn Wang:** [42:21] Yeah, I was watching this clip of the first Iron Man, when Robert Downey Jr. is kind of working with his bot to work on his first suit... And he's just talking to the bot, like "Here's what I want you to do." Sometimes it gets it wrong and he slaps it on the ahead... But more often than not, he gets it right. And this is why I've been -- you know, Wes Boss recently tweeted -- this is actually really scary. "Should we be afraid as engineers, like this is going to come for our jobs?" And I'm like, "No. All of us just got a personal junior developer." That should excite you.**Jerod Santo:** Yeah. And it seems like it's particularly good at software development answers. You'd think it's because there's lots of available text... I mean, think about like things that it's good at; it seems like it knows a lot about programming.**Shawn Wang:** I have a list. Do you want a list?**Jerod Santo:** Yeah.**Shawn Wang:** So writing tutorials - it's very good. Literally, tables of contents, section by section, explaining "First you should npm install. Then you should do X. Then you should do Y." Debugging code - just paste in your error, and paste in the source code, and it tells you what's wrong with it. Dynamic programming, it does really well. Translating DSLs. I think there'll be a thousand DSLs blooming, because the barrier to adoption of a DSL has just disappeared. [laughs] So why would you not write a DSL? No one needs to learn your DSL.**Adam Stacoviak:** What is this, Copilot you're using, or ChatGPT, that you're--**Shawn Wang:** ChatGPT-3. I have a bunch of examples here I can drop in the show notes. AWS IAM policies. "Hey, I want to do X and Y in AWS." Guess what? There's tons of documentation. ChatGPT knows AWS IAM policies. Code that combines multiple cloud services. This one comes from Corey Quinn. 90% of our jobs is hooking up one service to another service. You could just tell it what to do, and it just does it, right? There a guy who was like, "I fed my college computer network's homework to it, and they gave the right result", which is pretty interesting.Refactoring code from Elixir to PHP is another one that has been has been done... And obviously, Advent of Code, which - we're recording this in December now. The person who won -- so Advent of Code for the first 100 people is a race; whoever submits the correct answer first, wins it. And the number one place in the first Advent of Code this year was a ChatGPT guy. So it broke homework. Like, this thing has broken homework and take-home interviews, basically. [laughs]**Jerod Santo:** Completely. It's so nice though; like, I've only used it a little bit while coding, but it's two for two, of just like drilling my exact questions. And just stuff like "How do you match any character that is not an [unintelligible 00:44:43.28] regular expression?"**Shawn Wang:** Oh, yeah. Explaining regexes.**Jerod Santo:** Yeah. That was my question. Like, I know exactly what I want, but I can't remember which is the character, and so I just asked it, and it gave me the exact correct answer, and an example, and explained it in more detail, if I wanted to go ahead and read it. And it warned me, "Hey, this is not the best way to test against email addresses... But here it is." So I was like, "Alright..." This is a good thing for developers, for sure.**Shawn Wang:** Yeah. But you can't trust it -- so you have a responsibility as well. You can't write bad code, have something bad happen, and go, "Oh, it wasn't my fault. It was ChatGPT."**Jerod Santo:** Well, you can't paste Stack Overflow answers into your code either.**Shawn Wang:** You have the responsibility. Exactly.**Jerod Santo:** Yeah. I mean, you can, but you're gonna get fired, right? Like, if the buck stops at you, not at the Stack Overflow answer person, you can't go find them and be like, "Why were you wrong?" Right? It stops at you.**Shawn Wang:** Yeah. So I think the way I phrased it was -- do you know about this trade offer meme that is going around? So it's "Trade offer - you receive better debugging, code explanation, install instructions, better documentation, elimination of your breaking of flow from copy and pasting in Stack Overflow - you receive all these benefits, in exchange for more code review." There is a cost, which is code review. You have to review the code that your junior programmer just gave you. But hey, that's better and easier than writing code yourself.**Jerod Santo:** [46:04] Yeah, because you've got a free junior programmer working for you now. [laughter]**Shawn Wang:** There's a guy that says, "I haven't done a single Google search or consulted any external documentation for the past few days, and I was able to progress faster than I ever had when delivering a new thing." I mean, it's just... It's amazing, and Google should be worried.**Jerod Santo:** Yeah, that's what I was gonna say - is this an immediate threat to Google? Now, I did see a commenter on Hacker News - Swyx, I'm not sure if you saw this one - from inside of Google, talking about the cost of integration?**Shawn Wang:** Yes. Yeah, I've read basically every thread... [laughter] Which is a full-time job, but... This is so important. Like, I don't do this for most things, right? Like, I think this is big enough that I had to drop everything and go read up on it... And not be an overnight expert, but at least try to be informed... And that's all I'm doing here, really. But yeah, do you want to read it up?**Jerod Santo:** Yeah. So in summary, they were responding... This is on a thread about ChatGPT, and they say -- this is a Googler, and they say "It's one thing to put up a demo that interested nerds can play with, but it's quite another thing to try to integrate it deeply in a system that serves billions of requests a day, when you take into account serving costs, added latency, and the fact that average revenue on something like a Google search is close to infinitesimal (which is the word I can't say out loud) already. I think I remember the presenter saying something like they'd want to reduce the cost by at least 10 times before it could be feasible to integrate models like this in products like Google search. A 10x or even 100x improvement is obviously an attainable target in the next few years, so I think technology like this is coming in the next few years."So that's one insider's take on where Google stands. Obviously, Google has tons of resources dedicated to these areas of expertise, right? It's not like Google's asleep at the wheel, and is going to completely have their lunch eaten by OpenAI. But right now, there's a lot of people who are training new habits, right? They're like, "I'm not gonna use Google anymore. I'm gonna start using OpenAI." I think it's something on the order of one million users in their first few days have signed up... How long can Google potentially bleed people before it becomes an actual problem? I don't know. I don't know the answer to these things.**Shawn Wang:** So there's one way in which you can evaluate for yourself right now, and I think that's the most helpful, constructive piece of advice that we can give on this podcast, which is -- we're covering something that is moving very live, very fast. Everything that we say could be invalidated tomorrow by something new. But you could just run ChatGPT-3 alongside of all your Google searches. That's a very, very simple way to evaluate if this would replace Google for you; just run it twice, every single time. And so there's a Google extension - and I'll link it - [unintelligible 00:48:47.04] ChatGPT Google extension; I'll put it in the show notes. And yeah, I have it running; it's not that great. [laughs] Surprisingly. So ChatGPT is optimized for answering questions. Sometimes I don't put questions in there. I just put the thing I'm looking for, and Google's pretty good at that, it turns out... [laughs]**Jerod Santo:** Right. See, because you are an expert-level Google prompt engineer, right? Like, you know how to talk to Google.**Shawn Wang:** We have optimized to Google prompting, yes.**Jerod Santo:** Exactly.**Shawn Wang:** If I need to search within a certain date range, I know how to do that in Google. I can't do that in ChatGPT-3. If I need to look for PDFs, I know how to do that. If I want to look for Reddit, and constrain the site to Reddit, I know how to do that. ChatGPT-3 has no concept of attribution, no concept of date ranges, and stuff like that.**Jerod Santo:** Right.**Shawn Wang:** But yeah, it is just like better at some things, and worse at other things, and that is the nature of all new technology. It just has to be better at one thing, that you cannot get anywhere else, and it has a permanent hold in your mind. Whenever you need that thing done, you will turn to ChatGPT-3, or any other new technology.[49:53] I love this sort of meta philosophy about technology adoption, because all new toys just generally are worse than the things that they replace, except in one area, and that's the area needs to matter. And if it does matter, it will win, because they will fix the bugs.**Jerod Santo:** Yeah, oftentimes with disruption, that area is cost; like acquisition cost. Sometimes it's convenience, and maybe I guess sometimes it's accuracy. There's different metrics, but it's got to be the one that matters. If it's marginally better at things that don't matter, you're not going to disrupt. But if it's a lot better at one thing that matters a lot, even if everything else sucks, you'll use that thing.**Shawn Wang:** Yeah, exactly. So it's interesting, because -- you know, Google has a few things going for it. By the way, it has one of the largest training repositories of text that no one else has, which is Gmail. But the most impressive thing it's being able to ship with Gmail is the little autocomplete, like, "Looks good", Okay", the little buttons that you see in the smart replies.**Jerod Santo:** Do you guys ever use those? Do you ever click on those?**Shawn Wang:** I use that. I use that. Save some typing.**Adam Stacoviak:** Yeah, well, I used to actually use Gmail directly to compose my emails, or respond. I would tap to complete all the time, if the response was like, "Yeah, I was gonna say that."**Shawn Wang:** There's a billion little ways that AI is built into Google right now, that we just take for granted, because we don't feel it, because there's no prompts. [laughter]**Jerod Santo:** We need a prompt!**Adam Stacoviak:** Even if OpenAI did eat Google's lunch, Google would just acquire it, or something...**Shawn Wang:** You would think so...**Jerod Santo:** Maybe...**Shawn Wang:** But I would say that probably OpenAI is not for sale. Like, they have this world-conquering ambition that would just not let them settle for anything less than global domination... Which is a little bit scary, right?**Jerod Santo:** Yeah, I think they're probably going the distance, is their plan, it seems like...**Shawn Wang:** Well, if anything, Microsoft should have bought them when they had the chance, because that was Bing's opportunity, and I don't think that ever came to pass... Probably because Sam Altman was smart enough not to do that deal. But yeah, so let's take that line of thinking to its logical conclusion. What would you feel if Google started autocompleting your entire email for you, and not just like individual, like two or three words? You would feel different, you would feel creeped out. So Google doesn't have the permission to innovate.**Adam Stacoviak:** I wouldn't freak out if I opted in, though. If I was like, "This technology exists, and it's helpful. I'll use that." Now, if it just suddenly started doing it, yeah, creeped out. But if I'm like, "Yeah, this is kind of cool. I opt into this enhanced AI, or this enhanced autocompletion", or whatever, simplifies the usage of it, or whatever.**Shawn Wang:** Yeah, so there's actually some people working on the email client that does that for you. So Evan Conrad is working on EveryPrompt email, which is essentially you type a bunch of things that you want to say, and you sort of batch answer all your emails with custom generated responses from GPT-3. It's a really smart application of this tech to email that I've seen. But I just think, like, you would opt in; the vast majority of people never opt into anything.**Jerod Santo:** Yeah, most people don't opt in.**Shawn Wang:** Like, that's just not the default experience. So I'm just saying, one reason that Google doesn't do it is "Yeah, we're just too big." Right? That is essentially the response that you read out from that engineer; like, "This doesn't work at Google scale. We can't afford it. It would be too slow", whatever. That's kind of a cop out, I feel like... Because Google should be capable. These are the best engineers in the world, they should they should be able to do it.**Jerod Santo:** Well, he does say he thinks it's coming in the next few years. So he's not saying it's impossible, he's saying they're not there yet. And I will say, I'm giving ChatGPT the benefit of my wait time that I do not afford to Google. I do not wait for Google to respond. I will give ChatGPT three to five seconds, because I know it's like a new thing that everyone's hitting hard... But like, if they just plugged that in, it would be too slow. I wouldn't wait three to five seconds for a Google search.**Shawn Wang:** Yeah. By the way, that's a fascinating cloud story that you guys have got to have on - find the engineer at OpenAI that scaled ChatGPT-3 in one week from zero to one million users?**Jerod Santo:** Yeah, totally.**Adam Stacoviak:** [53:58] Well, if you're listening, or you know the person, this is an open invite; we'd love to have that conversation.**Shawn Wang:** Yeah. I've seen the profile of the guy that claimed to [unintelligible 00:54:04.00] so that he would know... But I don't know who would be responsible for that. That is one of the most interesting cloud stories probably of the year. And Azure should be all over this. Azure should be going like, "Look, they handled it no problem. This is most successful consumer product of all time come at us", right?**Jerod Santo:** That's true. They should.**Shawn Wang:** They're the number three cloud right now. This is like their one thing, this is their time to shine. They've got to do it.**Jerod Santo:** And does anybody even know that Azure is behind OpenAI? I'm sure you can find out, but like, is that well known? I didn't know that.**Shawn Wang:** Oh, it's very public. Microsoft invested a billion dollars in OpenAI.**Jerod Santo:** Okay. Did you know that, Adam?**Adam Stacoviak:** No.**Jerod Santo:** So I'm trying to gauge the public knowledge...**Shawn Wang:** What we didn't know was that it was at a valuation of $20 billion, which... So OpenAI went from like this kind of weird research lab type thing into one of the most highly valued startups in the world. [laughs]**Jerod Santo:** Do you think Microsoft got their money's worth?**Shawn Wang:** I think so... It's awash right now, because --**Jerod Santo:** Too early.**Shawn Wang:** ...they probably cut them a lot of favorable deals for training, and stuff... So it's more about like being associated with one of the top AI names. Like, this is the play that Microsoft has been doing for a long time, so it's finally paying off... So I'm actually pretty happy for that. But then they have to convert into like getting people who are not [unintelligible 00:55:21.00] onto this thing.**Break:** [55:26]**Adam Stacoviak:** What's the long-term play here though? I mean, if Microsoft invested that kind of money, and we're using ChatGPT right now, we're willing to give it extra seconds, potentially even a minute if the answer is that important to you, that you wouldn't afford to Google... Like, what's the play for them? Will they turn this into a product? How do you make billions from this? Do you eventually just get absorbed by the FAANGs of the world, and next thing you know now this incredible future asset to humanity is now owned by essentially folks we try to like host our own services for? Like, we're hosting Nextcloud locally, so we can get off the Google Drives and whatnot... And all this sort of anti-whatever. I mean, what's the endgame here?**Shawn Wang:** Am I supposed to answer that? [laughs]**Adam Stacoviak:** Do you have an answer? I mean, that's what I think about...**Jerod Santo:** Let's ask ChatGPT what the endgame is... No, I mean, short-term it doesn't seem like OpenAI becomes the API layer for every AI startup that's gonna start in the next 5 or 10 years, right? Like, aren't they just charging their fees to everybody who wants to integrate AI into their products, pretty much? That's not an end game, but that's a short-term business model, right?**Shawn Wang:** That is a short-term business model, yeah. I bet they have much more up their sleeves... I don't actually know. But they did just hire their first developer advocate, which is interesting, because I think you'll start to hear a lot more from them.[58:12] Well, there's two things I will offer for you. One, it's a very common view or perception that AI is a centralizing force, right? Which is, Adam, what you're talking about, which is, "Does this just mean that the big always get bigger?" Because the big have the scale and size and data advantage. And one of the more interesting blog posts - sorry, I can't remember who I read this from - was that actually one of the lessons from this year is that it's not necessarily true, because AI might be a more decentralized force, because it's more amenable to open source... And crypto, instead of being decentralized, turned out to be more centralized than people thought.So the two directions of centralized versus decentralized - the common perception is that AI is very centralized, and crypto very decentralized. The reality was that it's actually the opposite, which is fascinating to me as a thesis. Like, is that the end game, that AI eventually gets more decentralized, because people want this so badly that there are enough researchers who go to NeurIPS to present their research papers and tweet out all this stuff, that diffuses these techniques all over the place? And we're seeing that happen, helped in large probably by Stability AI. The proof that Stability as an independent, outsider company, like not a ton of connections in the AI field, did this humongous achievement I think is just a remarkable encouragement that anyone could do it... And that's a really encouraging thing for those people who are not FAANG and trying to make some extra headroom in this world. So that's one way to think about the future.The second way to think about who monetizes and who makes the billion dollars on this... There's a very influential post that I was introduced to recently from Union Square Ventures, called "The myth of the infrastructure phase", which is directly tackling this concept that everyone says "When you have a gold rush, sell picks and shovels", right? And it's a very common thing, and presumably AI being the gold rush right now, you should sell picks and shovels, which is you should build AI infrastructure companies. But really, there are tons of AI infrastructure companies right now, they're a dime a dozen; really, they're all looking for use cases, and basically, the argument, the myth of the infrastructure phase is that technology swings back and forth between app constraint and infra constraint. And right now, we're not infrastructure-constrained, we're app-constrained. And really, it's the builders of AI-enabled products like TikTok that know what to do with the AI infrastructure tha

Victor is a software consultant in Tokyo who describes himself as a yak shaver. He writes on his blog at vadosware and curates Awesome F/OSS, a mailing list of open source products. He's also a contributor to the Open Core Ventures blog. Before our conversation Victor wrote a structured summary of how he works on projects. I recommend checking that out in addition to the episode. Topics covered: Most people should use Dokku or CapRover But he uses Kubernetes anyways Hosting a Database in Kubernetes Learning technology You don't really know a thing until something goes wrong History of Frontend Development Context from lower layers of the stack and historical projects Good project pages have comparisons to other products Choosing technologies Language choice affects maintainability Knowing an ecosystem Victor's preferred stack Technology bake offs Posting findings means you get free corrections Why people use medium instead of personal sites Victor VADOSWARE - Blog How Victor works on Projects - Companion post for this episode Awesome FOSS - Curated list of OSS projects NimbusWS - Hosted OSS built on top of budget cloud providers Unvalidated Ideas - Startup ideas for side project inspiration PodcastSaver - Podcast index that allows you to choose Postgres or MeiliSearch and compare performance and results of each Victor's preferred stack Docker - Containers Kubernetes - Container provisioning (Though at the beginning of the episode he suggests Dokku for single server or CapRover for multiple) TypeScript - JavaScript with syntax for types. Victor's default choice. Rust - Language he uses if doing embedded work, performance is critical, or more correctness is desired Haskell - Language he uses if correctness and type system is the most important for the project Postgresql - General purpose database that's good enough for most use cases including full text search. KeyDB - Redis compatible database for caching. Acquired by Snap and then made open source. Victor uses it over Redis because it is multi threaded and supports flash storage without a Redis Enterprise license. Pulumi - Provision infrastructure with the languages you're already using instead of a specialized one or YAML Svelte and SvelteKit - Preferred frontend stack. Previously used Nuxt. Search engines Postgres Full Text Search vs the rest Optimizing Postgres Text Search with Trigrams OpenSearch - Amazon's fork of Elasticsearch typesense meilisearch sonic Quickwit JavaScript build tools Babel SWC Webpack esbuild parcel Vite Turbopack JavaScript frameworks React Vue Svelte Ember Frameworks built on top of frameworks Next - React Nuxt - Vue SvelteKit - Svelte Astro - Multiple Historical JavaScript tools and frameworks Underscore jQuery MooTools Backbone AngularJS Knockout Aurelia GWT Bower - Frontend package manager Grunt - Task runner Gulp - Task runner Related Links Dokku - Open source single-host alternative to Heroku Cloud Native Buildpacks - Buildpacks created by Heroku and Pivotal and used by Dokku CapRover - An open source PaaS-like abstraction built on top of Docker Swarm Kelsey Hightower's tweet about being cautious about running databases on Kubernetes Settling the Myth of Transparent HugePages for Databases Kubernetes Container Storage Interface (CSI) Kubernetes Local Persistent Volumes Longhorn - Distributed block storage for Kubernetes Postgres docs Postgres TOAST Everything I've seen on optimizing Postgres on ZFS Kubernetes Workload Resources Kubernetes Network Plugins Kubernetes Ingress Traefik Kubernetes the Hard Way (Setting up a cluster in a way that optimizes for learning) How does TLS work Let's Encrypt Cert manager for Kubernetes Choose Boring Technology A Linux user's guide to Logical Volume Management Docker networking overview Kubernetes Scheduler Tauri - Build desktop applications with web technology and Rust ripgrep - CLI tool to recursively search directory for a regex pattern (Meant to be a rust replacement for grep) angle-grinder / ag - CLI tool to parse and process log files written in rust Object.observe ECMAScript Proposal to be Withdrawn Ruby on Rails - Ruby web framework Django - Python web framework Laravel - PHP web framework Adonis - JavaScript NestJS - JavaScript What is a NullPointerException, and how do I fix it? Mastodon Clap - CLI argument parser for Rust AWS CDK - Provision AWS infrastructure using programming languages Terraform - Provision infrastructure with terraform language URL canonicalization of duplicate pages and the use of the canonical tag - Used by dev.to to send google traffic to the original blogpost instead of dev.to Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: This episode, I talk to Victor Adossi who describes himself as a yak shaver. Someone who likes trying a whole bunch of different technologies, seeing the different options. We talk about what he uses, the evolution of front end development, and his various projects. Talking to just different people it's always good to get where they're coming from because something that works for Google at their scale is going to be different than what you're doing with one of your smaller projects. [00:00:31] Victor: Yeah, the context. Of course in direct conflict with that statement, I definitely use Google technology despite not needing to at all right? Like, you know, 99% of people who are doing like people like to call it indiehacking or building small products could probably get by with just Dokku. If you know Dokku or like CapRover. Are two projects that'll be like, Oh, you can just push your code here, we'll build it up like a little mini Heroku PaaS thing and just go on one big server, right? Like 99% of the people could just use that. But of course I'm not doing that. So I'm a bit of a hypocrite in that sense. I know what I should be doing, but I'm not doing that. I am writing a Kubernetes cluster with like five nodes for no reason. Uh, yeah, I dunno, people don't normally count the controllers. [00:01:24] Jeremy: Dokku and CapRover, I think those are where it's supposed to create a heroku like experience I think it's based off of the heroku buildpacks right? At least Dokku is? [00:01:36] Victor: Yeah Buildpacks has actually been spun out into like a community thing so like pivotal and heroku, it's like buildpacks.io, they're trying to build a wider standard around it so that more people can get involved. And buildpacks are actually obviously fantastic as a technology and as a a process piece. There's not much else like them and you know, that's obvious from like Heroku's success and everything. I know Dokku uses that. I don't know that Caprover does, but I haven't, I haven't really run Caprover that much. They, they probably do. Like at this point if you're going to support building from code, it seems silly to try and build your own buildpacks. Cause that's what you will do, eventually. So you might as well use what's there. Anyway, this is like just getting to like my personal opinions at this point, but like, if you think containers are a bad idea in 2022, You're wrong, you should, you should stop. Like you should, you should stop. Think about it. I mean, obviously there's not, um, I got a really great question at an interview once, which is, where are containers a bad idea? That's probably one of the best like recent interview questions I've ever gotten cause I was like, Oh yeah, I mean, like, you can't, it can't be perfect everywhere, right? Nothing's perfect everywhere. So it's like, where is it? Uh, and of course the answer was networking, right? (unintelligible) So if you need absolute performance, but like for just about everything else. Containers are kind of it at this point. Like, time has born it out, I think. So yeah, I always just like bias at taking containers at this point. So I'm probably more of a CapRover person than a Dokku person, even though I have not used, I don't use CapRover. [00:03:09] Jeremy: Well, like something that I've heard with containers, and maybe it's changed recently, but, but something that was kind of holdout was when people would host a database sometimes they would oh we just don't wanna put this in a container and I wonder if like that matches with your thinking or if things have changed. [00:03:27] Victor: I am not a database administrator right like I read postgres docs and I read the, uh, the Postgres documentation, and I think I know a bit about postgres but I don't commit right like so and I also haven't, like, oh, managed X terabytes on one server that you are making sure never goes down kind of deal. But the stickiness for me, at least from when I've run, So I've done a lot of tests with like ZFS and Postgres and like, um, and also like just trying to figure out, and I run Postgres in Kubernetes of course, like on my cluster and a lot of the stuff I found around is, is like fiddly kernel things like sort of base kernel settings that you need to have set. Like, you know, stuff like should you be using transparent huge pages, like stuff like that. But once you have that settled. Containers are just processes with name spacing and resource control, right? Like, that's it. there are some other ins and outs, but for the most part, if you're fine running a process, so people ran processes, right? And they were just completely like unprotected. Then people made users for the processes and they limited the users and ran the processes, right? Then the next step is now you can run a process and then do the limiting the name spaces in cgroups dynamically. Like there, there's, there's sort of not a humongous difference, unless you're hitting something very specific. Uh, but yeah, databases have been a point of contention, but I think, Kelsey Hightower had that tweet yeah. That was like, um, don't run databases in Kubernetes. And I think he called it back. [00:04:56] Victor: I don't know, but I, I know that was uh, was one of those things that people were really unsure about at first, but then after people sort of like felt it out, they were like, Oh, it's actually fine. Yeah. [00:05:06] Jeremy: Yeah I vaguely remember one of the concerns having to do with persistent storage. Like there were challenges with Kubernetes and needing to keep that storage around and I don't know if that's changed yeah or if that's still a concern. [00:05:18] Victor: Uh, I'd say that definitely has changed. Uh, and it was, it was a concern, depending on where you were. Mostly people who are running AKS or EKS or you know, all those other managed Kubernetes, they're just using EBS or like whatever storage provider is like offering for storage. Most of those people don't actually have that much of a problem with, storage in general. Now, high performance storage is obviously different, right? So like, so you'll, you're gonna have to start doing manual, like local volume management and stuff like that. it was a problem, because obviously CSI (Kubernetes Container Storage Interface) didn't exist for some period of time, and like there was, it was hard to know what to do for if you were just running a Kubernetes cluster. I think a lot of people were just using local, first of all, local didn't even exist for a bit. Um, they were just using host path, right? And just like, Oh, it's on the disk somewhere. Where do we, we have to go get it right? Or we have to like, sort of manage that. So that was something most people weren't ready for, especially if you were just, if you weren't like sort of a, a, a traditional sysadmin and used to doing that stuff. And then of course local volumes came out, but I think they still had to be, um, pre-provisioned. So that's sysadmin stuff that most people, you know, maybe aren't, aren't necessarily ready for. Uh, and then most of the general solutions were slow. So like, I used Longhorn (https://longhorn.io) for a long time and Longhorn, Longhorn's great. And super easy to set up, but it can be slower and you can have some, like, delays in mount time. it wasn't ideal for, for most people. So yeah, I, overall it's true. Databases, Databases in Kubernetes were kind of fraught with peril for a while, but it wasn't for the reason that, it wasn't for the fundamental reason that Kubernetes was just wrong or like, it wasn't the reason most people think of, which is just like, Oh, you're gonna break your database. It's more like, running a database is hard and Kubernetes hasn't solved all the hard problems. Like, cuz that's what Kubernetes does. It basically solves a lot of problems in a very generic way. Right. So it just hadn't solved all those problems yet at this point. I think it's got decent answers on a lot of them. So I, I mean, I don't know. I I do it. Don't, don't take what I'm saying to your, you know, PM meeting or your standup meeting, uh, anyone who's listening. But it's more like if you could solve the problems with databases in the sense before. You could probably solve 'em on Kubernetes now with a good understanding of Kubernetes. Cause at the end of the day, it's all the same stuff. Just Kubernetes makes it a little easier to, uh, do it dynamically. [00:07:50] Jeremy: It sounds like you could do it before, but some of the, I guess the tools or the ways of doing persistent storage were not quite there yet, or they were difficult to use. And so that was why people at the start were like, Okay, maybe it's not a good idea, but, now maybe there's some established practices for how you should run a database in Kubernetes. And I, I suppose the other aspect too is that, like you were saying, Kubernetes is its own thing. You gotta learn Kubernetes and all its intricacies. And then running a database is also its own challenge. So if you stack the two of them together and, and the path was not really clear then maybe at the start it wasn't the best idea. Um, uh, if somebody was going to try it out now, was there like a specific resource you looked at or a specific path to where like okay this is is how I'm going to do it. [00:08:55] Victor: I'll just say what I normally recommend to everybody. Cause it depends on which path you wanna go right? If you wanna go down like running a database path first and figure that out, fill out that skill tree. Like go read the Postgres docs. Well, first of all, use Postgres. That's the first tip there. But like, read those documents. And obviously you don't have to understand everything. You won't understand everything. But knowing the big pieces and sort of letting your brain see the mention of like a whole bunch of things, like what is toast? Oh, you can do compression on columns. Like, you can do some, some things concurrently. Um, you know, what ALTER TABLE looks like. You get all that stuff kind of in your head. Um, and then I personally really believe in sort of learning by building and just like iterating. you won't get it right the first time. It's just like, it's not gonna happen. You're get, you can, you can get better the first time, right? By being really prepared and like, and leave yourself lots of outs, but you kind of have to like, get it out there. Do do your best to make sure that you can't fail, uh, catastrophically, right? So this is like, goes back to that decision to like use ZFS as the bottom of this I'm just like, All right, well, I, I'm not a file systems expert, but if I. I could delegate some of that, you know, some of that, I can get some of that knowledge from someone else. Um, and I can make it easier for me to not fail catastrophically. For the database side, actually read documentation on Postgres or the whatever database you're going to use, make sure you at least understand that. Then start running it like locally or whatever. Again, Docker use, use Docker locally. It's, it's, it's fine. and then, you know, sort of graduate to running sort of more progressively, more complicated versions. what I would say for the Kubernetes side is actually similar. the Kubernetes docs are really good. they're very large. but they're good. So you can actually go through and know all the, like, workload, workload resources, know, like what a config map is, what a secret is, right? Like what etcd is doing in this whole situation. you know, what a kublet is versus an API server, right? Like the, the general stuff, like if you go through all that, you should have like a whole bunch of ideas at least floating around in your head. And then once you try and start setting up a server, they will all start to pop up again, right? And they'll all start to like, you, like, Oh, okay, I need a CNI (Container Networking) plugin because something needs to make the services available, right? Or something needs to power the ingress, right? Like, if I wanna be able to get traffic, I need an ingress object. But what listens, what does that, what makes that ingress object do anything? Oh, it's an ingress controller. nginx, you know, almost everyone's heard of nginx, so they're like, okay. Um, nginx, has an ingress control. Actually there's, there used to be two, I assume there's still two, but there's like one that's maintained by Kubernetes, one that's maintained by nginx, the company or whatever. I use traefik, it's fantastic. but yeah, so I think those things kind of fall out and that is almost always my first way to explain it and to start building. And tinkering iteratively. So like, read the documentation, get a good first grasp of it, and then start building yourself because you'll, you'll get way more questions that way. Like, you'll ask way more questions, you won't be able to make progress. Uh, and then of course you can, you know, hop into slacks or like start looking around and, and searching on the internet. oh, one of the things that really helped me out early learning Kubernetes was, Kelsey Hightower's, um, learn Kubernetes the hard way. I'm also a big believer in doing things the hard way, at least knowing what you're choosing to not know, right? distributing file system, Deltas, right? Or like changes to a file system over the network is not a new problem. Other people have solved it. There's a lot of complexity there. but if you at least know the sort of surface level of what the thing does and what it's supposed to do and how it's supposed to do it, you can make a decision on, Oh, how deep am I going to go? Right? To prevent yourself from like, making a mistake or going too deep in the rabbit hole. If you have an idea of the sort of ecosystem and especially like, Oh, here, like the basics of how I can use this thing, that's generally very good. And doing things the hard way is a great way to get a, a feel for that, right? Cause if you take some chunk and like, you know, the first level of doing things the hard way, uh, or, you know, Kelsey Hightower's guide is like, get a machine, right? Like, so, like, if you somehow were like, Oh, I wanna run a Kubernetes cluster. but, you know, I don't want use necessarily EKS and you wanna learn it the hard way. You have to go get a machine, right? If you, if you're not familiar, if you run on Heroku the whole time, like you didn't manage your own machines, you gotta go like, figure out EC2, right? Or, I personally use, hetzner I love hetzner, so you have to go figure out hetzner, digital ocean, whatever. Right. And then the next thing's like, you know, the guide's changed a lot, and I haven't, I haven't looked at it in like, in years, actually a while since I, since I've sort of been, I guess living it, but it's, it's like generate certificates, right? So if you've never dealt with SSL and like, sort of like, or I should say TLS uh, and generating certificates and how that whole dance works, right? Which is fascinating because it's like, oh, right, nothing's secure on the internet, except that we distribute root certificates on computers that are deployed in every OS, right? Like, that's a sort of fundamental understanding you may not go deep enough to realize, but if you are fascinated by it, trying to do it manually would lead you down that path. You'd be like, Oh, what, like what is this thing? What is a CSR? Like, why, who is signing my request? Right? And it's like, why do we trust those people? Right? And it's like, you know, that kind of thing comes out and I feel like you can only get there from trying to do it, you know, answering the questions you can. Right. And again, it takes some judgment to know when you should not go down a rabbit hole. uh, and then iterating. of course there are people who are excellent at explaining. you can find some resources that are shortcuts. But, uh, I think particularly my bread and butter has been just to try and do it the hard way. Avoid pitfalls or like rabbit holes when you can. But know that the rabbit hole is there, and then keep going. And sometimes if something's just too hard, you're not gonna get it the first time. Like maybe you'll have to wait like another three months, you'll try again and you'll know more sort of ambiently about everything else. You get a little further that time. that's how I feel about that. Anyway. [00:15:06] Jeremy: That makes sense to me. I think sometimes when people take on a project, they try to learn too many things at the same time. I, I think the example of Kubernetes and Postgres is pretty good example, where if you're not familiar with how do I install Postgres on bare metal or a vm, trying to make sense of that while you're trying to into is probably gonna be pretty difficult. So, so splitting them up and learning them individually, that makes a lot of sense to me. And the whole deciding how deep you wanna go. That's interesting too, because I think that's very specific to the person right because sometimes you wanna go a little deeper because otherwise you don't understand how the two things connect together. But other times it's just like with the example with certificates, some people they may go like, I just put in let's encrypt it gives me my cert I don't care right then, and then, and some people they wanna know like okay how does the whole certificate infrastructure work which I think is interesting, depending on who you are, maybe you go ahh maybe it doesn't really matter right. [00:16:23] Victor: Yeah, and, you know, shout out to Let's Encrypt . It's, it's amazing, right? think Singlehandedly the most, most of the deployment of HTTPS that happens these days, right? so many so many of like internet providers and uh, sort of service providers will use it right? Under the covers. Like, Hey, we've got you free SSL through Let's Encrypt, right? Like, kind of like under the, under the covers. which is awesome. And they, and they do it. So if you're listening to this, donate to them. I've done it. So now that, now the pressure is on whoever's listening, but yeah, and, and I, I wanna say I am that person as well, right? Like, I use, Cert Manager on my cluster, right? So I'm just like, I don't wanna think about it, but I, you know, but I, I feel like I thought about it one time. I have a decent grasp. If something changes, then I guess I have to dive back in. I think it, you've heard the, um, innovation tokens idea, right? I can't remember the site. It's like, um, do, like do boring tech or something.com (https://boringtechnology.club/) . Like it shows up on sort of hacker news from time to time, essentially. But it's like, you know, you have a certain amount of tokens and sort of, uh, we'll call them tokens, but tolerance for complexity or tolerance for new, new ideas or new ways of doing things, new processes. Uh, and you spend those as you build any project, right? you can be devastatingly effective by just sticking to the stack, you know, and not introducing anything new, even if it's bad, right? and there's nothing wrong with LAMP stack, I don't wanna annoy anybody, but like if you, if you're running LAMP or if you run on a hostgator, right? Like, if you run on so, you know, some, some service that's really old but really works for you isn't, you know, too terribly insecure or like, has the features you need, don't learn Kubernetes then, right? Especially if you wanna go fast. cuz you, you're spending tokens, right? You're spending, essentially brain power, right? On learning whatever other thing. So, but yeah, like going back to that, databases versus databases on Kubernetes thing, you should probably know one of those before you, like, if you're gonna do that, do that thing. You either know Kubernetes and you like, at least feel comfortable, you know, knowing Kubernetes extremely difficult obviously, but you feel comfortable and you feel like you can debug. Little bit of a tangent, but maybe that's even a better, sort of watermark if you know how to debug a thing. If, if it's gone wrong, maybe one or five or 10 or 20 times and you've gotten out. Not without documentation, of course, cuz well, if you did, you're superhuman. But, um, but you've been able to sort of feel your way out, right? Like, Oh, this has gone wrong and you have enough of a model of the system in your head to be like, these are the three places that maybe have something wrong with them. Uh, and then like, oh, and then of course it's just like, you know, a mad dash to kind of like, find, find the thing that's wrong. You should have confidence about probably one of those things before you try and do both when it's like, you know, complex things like databases and distributed systems management, uh, and orchestration. [00:19:18] Jeremy: That's, that's so true in, in terms of you are comfortable enough being able to debug a problem because it's, I think when you are learning about something, a lot of times you start with some kind of guide or some kind of tutorial and you follow the steps. And if it all works, then great. Right? But I think it's such a large leap from that to something went wrong and I have to figure it out. Right. Whether it's something's not right in my Dockerfile or my postgres instance uh, the queries are timing out. so many things that could go wrong, that is the moment where you're forced to figure out, okay, what do I really know about this not thing? [00:20:10] Victor: Exactly. Yeah. Like the, the rubber's hitting the road it's uh you know the car's about to crash or has already crashed like if I open the bonnet, do I know what's happening right or am I just looking at (unintelligible). And that's, it's, I feel sort a little sorry or sad for, for devs that start today because there's so much. Complexity that's been built up. And a lot of it has a point, but you need to kind of have seen the before to understand the point, right? So I like, I like to use front end as an example, right? Like the front end ecosystem is crazy, and it has been crazy for a very long time, but the steps are actually usually logical, right? Like, so like you start with, you know, HTML, CSS and JavaScript, just plain, right? And like, and you can actually go in lots of directions. Like HTML has its own thing. CSS has its own sort of evolution sort of thing. But if we look at JavaScript, you're like, you're just writing JavaScript on every page, right? And like, just like putting in script tags and putting in whatever, and it's, you get spaghetti, you get spaghetti, you start like writing, copying the same function on multiple pages, right? You just, it, it's not good. So then people, people make jquery, right? And now, now you've got like a, a bundled set of like good, good defaults that you can, you can go for, right? And then like, you know, libraries like underscore come out for like, sort of like not dom related stuff that you do want, you do want everywhere. and then people go from there and they go to like backbone or whatever. it's because Jquery sort of also becomes spaghetti at some point and it becomes hard to manage and people are like, Okay, we need to sort of like encapsulate this stuff somehow, right? And like the new tools or whatever is around at the same timeframe. And you, you, you like backbone views for example. and you have people who are kind of like, ah, but that's not really good. It's getting kind of slow. Uh, and then you have, MVC stuff comes out, right? Like Angular comes out and it's like, okay, we're, we're gonna do this thing called dirty checking, and it's gonna be, it's gonna be faster and it's gonna be like, it's gonna be less sort of spaghetti and it's like a little bit more structured. And now you have sort of like the rails paradigm, but on the front end, and it takes people to get a while to get adjusted to that, but then that gets too heavy, right? And then dirty checking is realized to be a mistake. And then, you get stuff like MVVM, right? So you get knockout, like knockout js and you got like Durandal, and like some, some other like sort of front end technologies that come up to address that problem. Uh, and then after that, like, you know, it just keeps going, right? Like, and if you come in at the very end, you're just like, What is happening? Right? Like if it, if it, if someone doesn't sort of boil down the complexity and reduce it a little bit, you, you're just like, why, why do we do this like this? Right? and sometimes there's no good reason. Sometimes the complexity is just like, is unnecessary, but having the steps helps you explain it, uh, or helps you understand how you got there. and, and so I feel like that is something younger people or, or newer devs don't necessarily get a chance to see. Cause it just, it would take, it would take very long right? And if you're like a new dev, let's say you jumped into like a coding bootcamp. I mean, I've got opinions on coding boot camps, but you know, it's just like, let's say you jumped into one and you, you came out, you, you made it. It's just, there's too much to know. sure, you could probably do like HTML in one month. Well, okay, let's say like two weeks or whatever, right? If you were, if you're literally brand new, two weeks of like concerted effort almost, you know, class level, you know, work days right on, on html, you're probably decently comfortable with it. Very comfortable. CSS, a little harder because this is where things get hard. Cause if you, if you give two weeks for, for HTML, CSS is harder than HTML kind of, right? Because the interactions are way more varied. Right? Like, and, and maybe it's one of those things where you just, like, you, you get somewhat comfortable and then just like know that in the future you're gonna see something you don't understand and have to figure it out. Uh, but then JavaScript, like, how many months do you give JavaScript? Because if you go through that first like, sort of progression that I, I I, I, I mentioned everyone would have a perfect sort of, not perfect but good understanding of the pieces, right? Like, why did we start transpiling at all? Right? Like, uh, or why did you know, why did we adopt libraries? Like why did Bower exist? No one talks about Bower anymore, obviously, but like, Bower was like a way to distribute front end only packages, right? Um, what is it? Um, Uh, yes, there's grunt. There's like the whole build system thing, right? Once, once we decide we're gonna, we're gonna do stuff to files before we, before we push. So there's grunt, there's, uh, gulp, which is like grunt, but like, Oh, we're gonna do it all in memory. We're gonna pipe, we're gonna use this pipes thing to make sure everything goes fast. then there's like, of course that leads like the insanity that's webpack. And then there's like parcel, which did better. There's vite there's like, there's all this, there's this progression, but how many months would it take to know that progression? It, it's too long. So they end up just like, Hey, you're gonna learn react. Which is the right thing because it's like, that's what people hire for, right? But then you're gonna be in react and be like, What's webpack, right? And it's like, but you can't go down. You can't, you don't have the time. You, you can't sort of approach that problem from the other direction where you, which would give you better understanding cause you just don't have the time. I think it's hard for newer devs to overcome this. Um, but I think there are some, there's some hope on the horizon cuz some things are simpler, right? Like some projects do reduce complexity, like, by watching another project sort of innovate so like react. Wasn't the first component, first framework, right? Like technically, I, I think, I think you, you might have to give that to like, to maybe backbone because like they had views and like marionette also went with that. Like maybe, I don't know, someone, someone I'm sure will get in like, send me an angry email, uh, cuz I forgot you Moo tools or like, you know, Ember Ember. They've also, they've also been around, I used to be a huge Ember fan, still, still kind of am, but I don't use it. but if you have these, if you have these tools, right? Like people aren't gonna know how to use them and Vue was able to realize that React had some inefficiencies, right? So React innovates the sort of component. So Reintroduces the component based model component first, uh, front end development model. Vue sees that and it's like, wait a second, if we just export this like data object, and of course that's not the only innovation of Vue, but if we just export this data object, you don't have to do this fine grained tracking yourself anymore, right? You don't have to tell React or tell your the system which things change when other things change, right? Like you, you don't have to set up this watching and stuff, right? Um, and that's one of the reasons, like Vue is just, I, I, I remember picking up Vue and being like, Oh, I'm done. I'm done with React now. Because it just doesn't make sense to use React because they Vue essentially either, you know, you could just say they learned from them or they, they realize a better way to do things that is simpler and it's much easier to write. Uh, and you know, functionally similar, right? Um, similar enough that it's just like, oh they boil down some of that complexity and we're a step forward and, you know, in other ways, I think. Uh, so that's, that's awesome. Every once in a while you get like a compression in the complexity and then it starts to ramp up again and you get maybe another compression. So like joining the projects that do a compression. Or like starting to adopting those is really, can be really awesome. So there's, there's like, there's some hope, right? Cause sometimes there is a compression in that complexity and you you might be lucky enough to, to use that instead of, the thing that's really complex after years of building on it. [00:27:53] Jeremy: I think you're talking about newer developers having a tough time making sense of the current frameworks but the example you gave of somebody starting from HTML and JavaScript going to jquery backbone through the whole chain, that that's just by nature of you've put in a lot of time right you've done a lot of work working with each of these technologies you see the progression as if someone is starting new just by nature of you being new you won't have been able to spend that time [00:28:28] Victor: Do you think it could work? again, the, the, the time aspect is like really hard to get like how can you just avoid spending time um to to learn things that's like a general problem I think that problem is called education in the general sense. But like, does it make sense for a, let's say a bootcamp or, or any, you know, school right? To attempt to guide people through the previous solutions that didn't work, right? Like in math, you don't start with calculus, right? It just wouldn't, it doesn't make sense, right? But we try and start with calculus in software, right? We're just like, okay, here's the complexity. You've got all of it. Don't worry. Just look at this little bit. If, you know, if the compiler ever spits out a weird error uh oh, like, you're, you're, you're in for trouble cuz you, you just didn't get the. get the basics. And I think that's maybe some of what is missing. And the thing is, it is like the constraints are hard, right? No one has infinite time, right? Or like, you know, even like, just tons of time to devote to learning, learning just front end, right? That's not even all of computing, That's not even the algorithm stuff that some companies love to throw at you, right? Uh, or the computer sciencey stuff. I wonder if it makes more sense to spend some time taking people through the progression, right? Because discovering that we should do things via components, let's say, or, or at least encapsulate our functionality to components and compose that way, is something we, we not everyone knew, right? Or, you know, we didn't know wild widely. And so it feels like it might make sense to touch on that sort of realization and sort of guide the student through, you know, maybe it's like make five projects in a week and you just get progressively more complex. But then again, that's also hard cause effort, right? It's just like, it's a hard problem. But, but I think right now, uh, people who come in at the end and sort of like see a bunch of complexity and just don't know why it's there, right? Like, if you've like, sort of like, this is, this applies also very, this applies to general, but it applies very well to the Kubernetes problem as well. Like if you've never managed nginx on more than one machine, or if you've never tried to set up a, like a, to format your file system on the machine you just rented because it just, you know, comes with nothing, right? Or like, maybe, maybe some stuff was installed, but, you know, if you had to like install LVM (Logical Volume Manager) yourself, if you've never done any of that, Kubernetes would be harder to understand. It's just like, it's gonna be hard to understand. overlay networks are hard for everyone to understand, uh, except for network people who like really know networking stuff. I think it would be better. But unfortunately, it takes a lot of time for people to take a sort of more iterative approach to, to learning. I try and write blog posts in this way sometimes, but it's really hard. And so like, I'll often have like an idea, like, so I call these, or I think of these as like onion, onion style posts, right? Where you either build up an onion sort of from the inside and kind of like go out and like add more and more layers or whatever. Or you can, you can go from the outside and sort of take off like layers. Like, oh, uh, Kubernetes has a scheduler. Why do they need a scheduler? Like, and like, you know, kind of like, go, go down. but I think that might be one of the best ways to learn, but it just takes time. Or geniuses and geniuses who are good at two things, right? Good at the actual technology and good at teaching. Cuz teaching is a skill and it's very hard. and, you know, shout out to teachers cuz that's, it's, it's very difficult, extremely frustrating. it's hard to find determinism in, in like methods and solutions. And there's research of course, but it's like, yeah, that's, that's a lot harder than the computer being like, Nope, that doesn't work. Right? Like, if you can't, if you can't, like if you, if the function call doesn't work, it doesn't work. Right. If the person learned suboptimally, you won't know Right. Until like 10 years down the road when, when they can't answer some question or like, you know, when they, they don't understand. It's a missing fundamental piece anyway. [00:32:24] Jeremy: I think with the example of front end, maybe you don't have time to walk through the whole history of every single library and framework that came but I think at the very least, if you show someone, or you teach someone how to work with css, and you have them, like you were talking about components before you have them build a site where there's a lot of stuff that gets reused, right? Maybe you have five pages and they all have the same nav bar. [00:33:02] Victor: Yeah, you kind of like make them do it. [00:33:04] Jeremy: Yeah. You make 'em do it and they make all the HTML files, they copy and paste it, and probably your students are thinking like, ah, this, this kind of sucks [00:33:16] Victor: Yeah [00:33:18] Jeremy: And yeah, so then you, you come to that realization, and then after you've done that, then you can bring in, okay, this is why we have components. And similarly you brought up, manual dom manipulation with jQuery and things like that. I, I'm sure you could come up with an example of you don't even necessarily need to use jQuery. I think people can probably skip that step and just use the the, the API that comes with the browser. But you can have them go in like, Oh, you gotta find this element by the id and you gotta change this based on this, and let them experience the. I don't know if I would call it pain, but let them experience like how it was. Right. And, and give them a complex enough task where they feel like something is wrong right. Or, or like, there, should be something better. And then you can go to you could go straight to vue or react. I'm not sure if we need to go like, Here's backbone, here's knockout. [00:34:22] Victor: Yeah. That's like historical. Interesting. [00:34:27] Jeremy: I, I think that would be an interesting college course or something that. Like, I remember when, I went through school, one of the classes was programming languages. So we would learn things like, Fortran and stuff like that. And I, I think for a more frontend centered or modern equivalent you could go through, Hey, here's the history of frontend development here's what we used to do and here's how we got to where we are today. I think that could be actually a pretty interesting class yeah [00:35:10] Victor: I'm a bit interested to know you learned fortran in your PL class. I, think when I went, I was like, lisp and then some, some other, like, higher classes taught haskell but, um, but I wasn't ready for haskell, not many people but fortran is interesting, I kinda wanna hear about that. [00:35:25] Jeremy: I think it was more in terms of just getting you exposed to historically this is how things were. Right. And it wasn't so much of like, You can take strategies you used in Fortran into programming as a whole. I think it was just more of like a, a survey of like, Hey, here's, you know, here's Fortran and like you were saying, here's Lisp and all, all these different languages nd like at least you, you get to see them and go like, yeah, this is kind of a pain. [00:35:54] Victor: Yeah [00:35:55] Jeremy: And like, I understand why people don't choose to use this anymore but I couldn't take away like a broad like, Oh, I, I really wish we had this feature from, I think we were, I think we were using Fortran 77 or something like that. I think there's Fortran 77, a Fortran 90, and then there's, um, I think, [00:36:16] Victor: Like old fortran, deprecated [00:36:18] Jeremy: Yeah, yeah, yeah. So, so I think, I think, uh, I actually don't know if they're, they're continuing to, um, you know, add new things or maintain it or it's just static. But, it's, it's more, uh, interesting in terms of, like we were talking front end where it's, as somebody who's learning frontend development who is new and you get to see how, backbone worked or how Knockout worked how grunt and gulp worked. It, it's like the kind of thing where it's like, Oh, okay, like, this is interesting, but let us not use this again. Right? [00:36:53] Victor: Yeah. Yeah. Right. But I also don't need this, and I will never again [00:36:58] Jeremy: yeah, yeah. It's, um, but you do definitely see the, the parallels, right? Like you were saying where you had your, your Bower and now you have NPM and you had Grunt and Gulp and now you have many choices [00:37:14] Victor: Yeah. [00:37:15] Jeremy: yeah. I, I think having he history context, you know, it's interesting and it can be helpful, but if somebody was. Came to me and said hey I want to learn how to build websites. I get into front end development. I would not be like, Okay, first you gotta start moo tools or GWT. I don't think I would do that but it I think at a academic level or just in terms of seeing how things became the way they are sure, for sure it's interesting. [00:37:59] Victor: Yeah. And I, I, think another thing I don't remember who asked or why, why I had to think of this lately. um but it was, knowing the differentiators between other technologies is also extremely helpful right? So, What's the difference between ES build and SWC, right? Again, we're, we're, we're leaning heavy front end, but you know, just like these, uh, sorry for context, of course, it's not everyone a front end developer, but these are two different, uh, build tools, right? For, for JavaScript, right? Essentially you can think of 'em as transpilers, but they, I think, you know, I think they also bundle like, uh, generally I'm not exactly sure if, if ESbuild will bundle as well. Um, but it's like one is written in go, the other one's written in Rust, right? And sort of there's, um, there's, in addition, there's vite which is like vite does bundle and vite does a lot of things. Like, like there's a lot of innovation in vite that has to have to do with like, making local development as fast as possible and also getting like, you're sort of making sure as many things as possible are strippable, right? Or, or, or tree shakeable. Sorry, is is is the better, is the better term. Um, but yeah, knowing, knowing the, um, the differences between projects is often enough to sort of make it less confusing for me. Um, as far as like, Oh, which one of these things should I use? You know, outside of just going with what people are recommending. Cause generally there is some people with wisdom sometimes lead the crowd sometimes, right? So, so sometimes it's okay to be, you know, a crowd member as long as you're listening to the, to, to someone worth listening to. Um, and, and so yeah, I, I think that's another thing that is like the mark of a good project or, or it's not exclusive, right? It's not, the condition's not necessarily sufficient, but it's like a good projects have the why use this versus x right section in the Readme, right? They're like, Hey, we know you could use Y but here's why you should use us instead. Or we know you could use X, but here's what we do better than X. That might, you might care about, right? That's, um, a, a really strong indicator of a project. That's good cuz that means the person who's writing the project is like, they've done this, the survey. And like, this is kind of like, um, how good research happens, right? It's like most of research is reading what's happening, right? To knowing, knowing the boundary you're about to push, right? Or try and sort of like push one, make one step forward in, um, so that's something that I think the, the rigor isn't in necessarily software development everywhere, right? Which is good and bad. but someone who's sort of done that sort of rigor or, and like, and, and has, and or I should say, has been rigorous about knowing the boundary, and then they can explain that to you. They can be like, Oh, here's where the boundary was. These people were doing this, these people were doing this, these people were doing this, but I wanna do this. So you just learned now whether it's right for you and sort of the other points in the space, which is awesome. Yeah. Going to your point, I feel like that's, that's also important, it's probably not a good idea to try and get everyone to go through historical artifacts, but if just a, a quick explainer and sort of, uh, note on the differentiation, Could help for sure. Yeah. I feel like we've skewed too much frontend. No, no more frontend discussion this point. [00:41:20] Jeremy: It's just like, I, I think there's so many more choices where the, the mental thought that has to go into, Okay, what do I use next I feel is bigger on frontend. I guess it depends on the project you're working on but if you're going to work on anything front end if you haven't done it before or you don't have a lot of experience there's so many build tools so many frameworks, so many libraries that yeah, but we [00:41:51] Victor: Iterate yeah, in every direction, like the, it's good and bad, but frontend just goes in every direction at the same time Like, there's so many people who are so enthusiastic and so committed and and it's so approachable that like everyone just goes in every direction at the same time and like a lot of people make progress and then unfortunately you have try and pick which, which branch makes sense. [00:42:20] Jeremy: We've been kind of talking about, some of your experiences with a few things and I wonder if you could explain the the context you're thinking of in terms of the types of projects you typically work on like what are they what's the scale of them that sort of thing. [00:42:32] Victor: So I guess I've, I've gone through a lot of phases, right? In sort of what I use in in my tooling and what I thought was cool. I wrote enterprise java like everybody else. Like, like it really doesn't talk about it, but like, it's like almost at some point it was like, you're either a rail shop or a Java shop, for so many people. And I wrote enterprise Java for a, a long time, and I was lucky enough to have friends who were really into, other kinds of computing and other kinds of programming. a lot of my projects were wrapped around, were, were ideas that I was expressing via some new technology, let's say. Right? So, I wrote a lot of haskell for, for, for a while, right? But what did I end up building with that was actually a job board that honestly didn't go very far because I was spending much more time sort of doing, haskell things, right? And so I learned a lot about sort of what I think is like the pinnacle of sort of like type development in, in the non-research world, right? Like, like right on the edge of research and actual usability. But a lot of my ideas, sort of getting back to the, the ideas question are just things I want to build for myself. Um, or things I think could be commercially viable or like do, like, be, be well used, uh, and, and sort of, and profitable things, things that I think should be built. Or like if, if I see some, some projects as like, Oh, I wish they were doing this in this way, Right? Like, I, I often consider like, Oh, I want, I think I could build something that would be separate and maybe do like, inspired from other projects, I should say, Right? Um, and sort of making me understand a sort of a different, a different ecosystem. but a lot of times I have to say like, the stuff I build is mostly to scratch an itch I have. Um, and or something I think would be profitable or utilizing technology that I've seen that I don't think anyone's done in the same way. Right? So like learning Kubernetes for example, or like investing the time to learn Kubernetes opened up an entire world of sort of like infrastructure ideas, right? Because like the leverage you get is so high, right? So you're just like, Oh, I could run an aws, right? Like now that I, now that I know this cuz it's like, it's actually not bad, it's kind of usable. Like, couldn't I do that? Right? That kind of thing. Right? Or um, I feel like a lot of the times I'll learn a technology and it'll, it'll make me feel like certain things are possible that they, that weren't before. Uh, like Rust is another one of those, right? Like, cuz like Rust will go from like embedded all the way to WASM, which is like a crazy vertical stack. Right? It's, that's a lot, That's a wide range of computing that you can, you can touch, right? And, and there's, it's, it's hard to learn, right? The, the, the, the, uh, the, the ramp to learning it is quite steep, but, it opens up a lot of things you can write, right? It, it opens up a lot of areas you can go into, right? Like, if you ever had an idea for like a desktop app, right? You could actually write it in Rust. There's like, there's, there's ways, there's like is and there's like, um, Tauri is one of my personal favorites, which uses web technology, but it's either I'm inspired by some technology and I'm just like, Oh, what can I use this on? And like, what would this really be good at doing? or it's, you know, it's one of those other things, like either I think it's gonna be, Oh, this would be cool to build and it would be profitable. Uh, or like, I'm scratching my own itch. Yeah. I think, I think those are basically the three sources. [00:46:10] Jeremy: It's, it's interesting about Rust where it seems so trendy, I guess, in lots of people wanna do something with rust, but then in a lot of they also are not sure does it make sense to write in rust? Um, I, I think the, the embedded stuff, of course, that makes a lot of sense. And, uh, you, you've seen a sort of surge in command line apps, stuff ripgrep and ag, stuff like that, and places like that. It's, I think the benefits are pretty clear in terms of you've got the performance and you have the strong typing and whatnot and I think where there's sort of the inbetween section that's kind of unclear to me at least would I build a web application in rust I'm not sure that sort of thing [00:47:12] Victor: Yeah. I would, I characterize it as kind of like, it's a tool toolkit, so it really depends on the problem. And think we have many tools that there's no, almost never a real reason to pick one in particular right? Like there's, Cause it seems like just most of, a lot of the work, like, unless you're, you're really doing something interesting, right? Like, uh, something that like, oh, I need to, I need to, like, I'm gonna run, you know, billions and billions of processes. Like, yeah, maybe you want erlang at that point, right? Like, maybe, maybe you should, that should be, you know, your, your thing. Um, but computers are so fast these days, and most languages have, have sort of borrowed, not borrowed, but like adopted features from others that there's, it's really hard to find a, a specific use case, for one particular tool. Uh, so I often just categorize it by what I want out of the project, right? Or like, either my goals or project goals, right? Depending on, and, or like business goals, if you're, you know, doing this for a business, right? Um, so like, uh, I, I basically, if I want to go fast and I want to like, you know, reduce time to market, I use type script, right? Oh, and also I'm a, I'm a, like a type zealot. I, I'd say so. Like, I don't believe in not having types, right? Like, it's just like there's, I think it's crazy that you would like have a function but not know what the inputs could be. And they could actually be anything, right? , you're just like, and then you have to kind of just keep that in your head. I think that's silly. Now that we have good, we, we have, uh, ways to avoid the, uh, ceremony, right? You've got like hindley Milner type systems, like you have a way to avoid the, you can, you know, predict what types of things will be, and you can, you don't have to write everything everywhere. So like, it's not that. But anyway, so if I wanna go fast, the, the point is that going back to that early, like the JS ecosystem goes everywhere at the same time. Typescript is excellent because the ecosystem goes everywhere at the same time. And so you've got really good ecosystem support for just about everything you could do. Um, uh, you could write TypeScript that's very loose on the types and go even faster, but in general it's not very hard. There's not too much ceremony and just like, you know, putting some stuff that shows you what you're using and like, you know, the objects you're working with. and then generally if I wanna like, get it really right, I I'll like reach for haskell, right? Cause it's just like the sort of contortions, and again, this takes time, this not fast, but, right. the contortions you can do in the type system will make it really hard to write incorrect code or code that doesn't, that isn't logical with itself. Of course interfacing with the outside world. Like if you do a web request, it's gonna fail sometimes, right? Like the network might be down, right? So you have to, you basically pull that, you sort of wrap that uncertainty in your system to whatever degree you're okay with. And then, but I know it'll be correct, right? But and correctness is just not important. Most of like, Oh, I should , that's a bad quote. Uh, it's not that correct is not important. It's like if you need to get to market, you do not necessarily need every single piece of your code to be correct, Right? If someone calls some, some function with like, negative one and it's not an important, it's not tied to money or it's like, you know, whatever, then maybe it's fine. They just see an error and then like you get an error in your back and you're like, Oh, I better fix that. Right? Um, and then generally if I want to be correct and fast, I choose rust these days. Right? Um, these days. and going back to your point, a lot of times that means that I'm going to write in Typescript for a lot of projects. So that's what I'll do for a lot of projects is cuz I'll just be like, ah, do I need like absolute correctness or like some really, you know, fancy sort of type stuff. No. So I don't pick haskell. Right. And it's like, do I need to be like mega fast? No, probably not. Cuz like, cuz so I don't necessarily don't necessarily need rust. Um, maybe it's interesting to me in terms of like a long, long term thing, right? Like if I, if I'm think, oh, but I want x like for example, tight, tight, uh, integration with WASM, for example, if I'm just like, oh, I could see myself like, but that's more of like, you know, for a fun thing that I'm doing, right? Like, it's just like, it's, it's, you don't need it. You don't, that's premature, like, you know, that's a premature optimization thing. But if I'm just like, ah, I really want the ability to like maybe consider refactoring some of this out into like a WebAssembly thing later, then I'm like, Okay, maybe, maybe I'll, I'll pick Rust. Or like, if I, if I like, I do want, you know, really, really fast, then I'll like, then I'll go Rust. But most of the time it's just like, I want a good ecosystem so I don't have to build stuff myself most of the time. Uh, and you know, type script is good enough. So my stack ends up being a lot of the time just in type script, right? Yeah. [00:52:05] Jeremy: Yeah, I think you've encapsulated the reason why there's so many packages on NPM and why there's so much usage of JavaScript and TypeScript in general is that it, it, it fits the, it's good enough. Right? And in terms of, in terms of speed, like you said, most of the time you don't need of rust. Um, and so typescript I think is a lot more approachable a lot of people have to use it because they do front end work anyways. And so that kinda just becomes the I don't know if I should say the default but I would say it's probably the most common in terms of when somebody's building a backend today certainly there's other languages but JavaScript and TypeScript is everywhere. [00:52:57] Victor: Yeah. Uh, I, I, I, another thing is like, I mean, I'm, of ignored the, like, unreasonable effectiveness of like rails Cause there's just a, there's tons of just like rails warriors out there, and that's great. They're they're fantastic. I'm not a, I'm not personally a huge fan of rails but that's, uh, that's to my own detriment, right? In, in some, in some ways. But like, Rails and Django sort of just like, people who, like, I'm gonna learn this framework it's gonna be excellent. It most, they have a, they have carved out a great ecosystem for themselves. Um, or like, you know, even php right? PHP and like Laravel, or whatever. Uh, and so I'm ignoring those, like, those pockets of productivity, right? Those pockets of like intense productivity that people like, have all their needs met in that same way. Um, but as far as like general, general sort of ecosystem size and speed for me, um, like what you said, like applies to me. Like if I, if I'm just like, especially if I'm just like, Oh, I just wanna build a backend, Like, I wanna build something that's like super small and just does like, you know, maybe a few, a couple, you know, endpoints or whatever and just, I just wanna throw it out there. Right? Uh, I, I will pick, yeah. Typescript. It just like, it makes sense to me. I also think note is a better. VM or platform to build on than any of the others as well. So like, like I, by any of the others, I mean, Python, Perl, Ruby, right? Like sort of in the same class of, of tool. So I I am kind of convinced that, um, Node is better, than those as far as core abilities, right? Like threading Right. Versus the just multi-processing and like, you know, other, other, other solutions and like, stuff like that. So, if you want a boring stack, if I don't wanna use any tokens, right? Any innovation tokens I reach for TypeScript. [00:54:46] Jeremy: I think it's good that you brought up. Rails and, and Django because, uh, personally I've done, I've done work with Rails, and you're right in that Rails has so many built in, and the ways to do them are so well established that your ability to be productive and build something really fast hard to compete with, at least in my experience with available in the Node ecosystem. Um, on the other hand, like I, I also see what you mean by the runtimes. Like with Node, you're, you're built on top of V8 and there's so many resources being poured into it to making it fast and making it run pretty much everywhere. I think you probably don't do too much work with managed services, but if you go to a managed service to run your code, like a platform as a service, they're gonna support Node. Will they support your other preferred language? Maybe, maybe not, You know that they will, they'll be able to run node apps so but yeah I don't know if it will ever happen or maybe I'm just not familiar with it, but feel like there isn't a real rails of javascript. [00:56:14] Victor: Yeah, you're, totally right. There are, there are. It's, it's weird. It's actually weird that there, like Uh, but, but, I kind of agree with you. There's projects that are trying it recently. There's like Adonis, um, there is, there are backends that also do, like, will do basic templating, like Nest, NestJS is like really excellent. It's like one of the best sort of backend, projects out there. I I, I but like back in the day, there were projects like Sails, which was like very much trying to do exactly what Rails did, but it just didn't seem to take off and reach that critical mass possibly because of the size of the ecosystem, right? Like, how many alternatives to Rails are there? Not many, right? And, and now, anyway, maybe let's say the rest of 'em sort of like died out over the years, but there's also like, um, hapi HAPI, uh, which is like also, you know, similarly, it was like angling themselves to be that, but they just never, they never found the traction they needed. I think, um, or at least to be as wide, widely known as Rails is for, for, for the, for the Ruby ecosystem, um, but also for people to kind of know the magic, cause. Like I feel like you're productive in Rails only when you imbibe the magic, right? You, you, know all the magic context and you know the incantations and they're comforting to you, right? Like you've, you've, you have the, you have the sort of like, uh, convention. You're like, if you're living and breathing the convention, everything's amazing, right? Like, like you can't beat that. You're just like, you're in the zone but you need people to get in that zone. And I don't think node has, people are just too, they're too frazzled. They're going like, there's too much options. They can't, it's hard to commit, right? Like, imagine if you'd committed to backbone. Like you got, you can't, It's, it's over. Oh, it's not over. I mean, I don't, no, I don't wanna, you know, disparage the backbone project. I don't use it, but, you know, maybe they're still doing stuff and you know, I'm sure people are still working on it, but you can't, you, it's hard to commit and sort of really imbibe that sort of convention or, or, or sort of like, make yourself sort of breathe that product when there's like 10 products that are kind of similar and could be useful as well. Yeah, I think that's, that's that's kind of big. It's weird that there isn't a rails, for NodeJS, but, but people are working on it obviously. Like I mentioned Adonis, there's, there's more. I'm leaving a bunch of them out, but that's part of the problem. [00:58:52] Jeremy: On, on one hand, it's really cool that people are trying so many different things because hopefully maybe they can find something that like other people wouldn't have thought of if they all stick same framework. but on the other hand, it's ... how much time have we spent jumping between all these different frameworks when what we could have if we had a rails. [00:59:23] Victor: Yeah the, the sort of wasted time is, is crazy to think about it uh, I do think about that from time to time. And you know, and personally I waste a lot of my own time. Like, just, just rec

GOOD MORNING CYBERTRON IS AN ADULT SHOW AND NOT MEANT FOR THOSE UNDER THE AGE OF 18. VIEWER DISCRETION IS ADVISED. TREAT YOURSELF TO OUR MERCH https://www.redbubble.com/people/GMCybertron/shop?asc=u SOCIAL MEDIA https://www.facebook.com/groups/GoodMorningCybertron https://www.thingiverse.com/blunghole/designs https://twitter.com/GMCybertron BUY OUR FRIEND'S TOYS! http://sirtoys.com/?a=16​​ PATREON MAKES YOUR MONEY OUR MONEY! https://www.patreon.com/gmcentertainment --- Support this podcast: https://anchor.fm/goodmorningcybertron/support

ZenCon0 was our first-ever summit to celebrate what we have achieved, share ideas for growth, and envision the future of the broader #Horizen ecosystem. We welcomed partners, advisors, and community members on stage to discuss visions and expertise in the area.  In this technical presentation, Horizen Labs' Cryptographic Software Engineer, Nicholas Mainardi takes us through building provable applications and the pros and cons of using DSLs vs zkVMs. Event website: https://zencon.events/ ***** Twitter: https://twitter.com/horizenglobal Facebook: https://www.facebook.com/horizenglobal Instagram: https://www.instagram.com/horizenglobal/ Reddit page: https://www.reddit.com/r/Horizen/ Discord channel: https://horizen.global/invite/discord Telegram channel: https://t.me/horizencommunity Website: https://horizen.io Horizen on CoinMarketCap – https://bit.ly/ZENCoinMarketCap Horizen on CoinGecko – https://bit.ly/ZENCoinGecko

2022-08-16 Weekly News - Episode 161Watch the video version on YouTube at https://youtu.be/tsx07USLyPI Hosts:  Gavin Pickin - Senior Developer at Ortus Solutions Dan Card - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: BUY SOME ITB TICKETS - COME TO THE CONFERENCE - Have a few laughs! Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Patreon SupportGoal 1 - We have 38 patreons providing 100% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. Goal 2 - We are 44% of the way to fully fund the hosting of ForgeBox.io News and AnnouncementsContentBox v5.3.0 ReleasedWe are so excited to bring you the release of ContentBox Hybrid CMS version 5.3.0. This might be the last release in this major series as we are beginning the push of the next major release of ContentBox v6. Here is our what's new guide with our full release notes.https://www.ortussolutions.com/blog/contentbox-v53-released/ CBWire Updated Example AppNow with updated example app - clone the repo and start it up.Building modern CFML apps is a pain. ColdBox makes creating server-side apps easy, but what about the client-side? Front-end JavaScript frameworks like Vue and React are powerful, yet they also introduce complexity and a significant learning curve when creating our apps.What if you could create apps that look and feel like your Vue and React web apps but are written with CFML. Impossible, you say? Nay, we say!Introducing CBWIRE: Power-up your CFML!https://github.com/coldbox-modules/cbwire ICYMI - Lucee Release Roadmap, 6.0, 5.3.9 and 5.3.105.3.9 - Firstly, we have been working on the open regressions 11 with 5.3.9 and hope to release a quick RC this Friday.6.0.0-BETA - There are still a number of blockers which we still need to address, but we are getting very close.https://dev.lucee.org/t/lucee-release-roadmap-6-0-5-3-9-and-5-3-10/10810 ICYMI - WireBox Object Delegators are now born! WireBox Object Delegators are now born!  It's been committed with tests and hopefully this new design pattern will help you create beautiful object DSLs and just allow for less boilerplate in your code.https://ortussolutions.atlassian.net/browse/WIREBOX-131?atlOrigin=eyJpIjoiMGY4OTQwZGE2YTU5NGVkNGI2MDk5YzI1ZDM0MDA0ZGQiLCJwIjoiamlyYS1zbGFjay1pbnQifQ INTO THE BOX - Updates2 weeks left until the start of the Pre-Conf, the Workshop and 2 days of 2 track content. ITB Pre-Conference Schedule Finalized on the Website Last 3 sessions TBA Zac Spitzer - Lucee 5, 6 and beyond Javier Quintero - CBValidation Dan Card  - New Product - CFScribe New Sponsors Silver - TeraTech - Creator of CFAlive Podcast and State of the CF Union Survey Silver - WRIS - WRIS Web Services develops process improving web-based software and applications for businesses looking to expedite workflow and eliminate legacy, paper-based, manual systems.  BIG ANNOUNCEMENT COMING WEDNESDAY AUGUST 17th at 8AM Workshops are starting to fill up - don't miss your chance.https://intothebox.org/ New Releases and UpdatesICYMI - Lucee - Image Extension 1.2.0.1 and 1.0.0.44, isImageFile() invalid file locking fixedBugfix: locked temp image files - isImageFile()https://luceeserver.atlassian.net/browse/LDEV-3931When using isImageFile() for certain formats, if the file wasn't an image, Lucee was leaving the file locked.https://dev.lucee.org/t/image-extension-1-2-0-1-and-1-0-0-44-isimagefile-invalid-file-locking-fixed/10808 Webinar / Meetups and WorkshopsOrtus Webinar - August - Ortus Team - Into the Box Preview and Q&AAugust 26th, 2022: Time 11:00AM Central Time ( US and Canada )Join some of the Ortus HARD Core Team as they discuss all the great things coming to you from Into the Box, with the Pre Conference Online Sessions, Full Day Workshops and then the 2 day 2 track in Person Conference.The session will be informal, with Q&A from the chat, with maybe a couple of last minute surprise announcements.Register now: https://bit.ly/3cW6LlM Hawaii CFUG - OOP & ColdFusion Friday, August 26, 2022 at 12:00 PM - 1:00 PM PDTObject-Oriented Programming is common term in programming languages. It's a vast concept but to sum it up in a single line, it is a set of concepts and techniques that make use of the “object” construct, to write more reusable, maintainable, and organized code. Objects are implemented differently in every language. In ColdFusion, we have ColdFusion Components (CFCs) that can be instantiated to create objects.Anyone who has ever studied OOP must know that there are four main concepts, which are: Abstraction Encapsulation Inheritance Polymorphism https://www.meetup.com/hawaii-coldfusion-meetup-group/events/287606572/ Adobe Workshops & WebinarsJoin the Adobe ColdFusion Workshop to learn how you and your agency can leverage ColdFusion to create amazing web content. This one-day training will cover all facets of Adobe ColdFusion that developers need to build applications that can run across multiple cloud providers or on-premiseWEBINAR - THURSDAY, AUGUST 18, 2022 - THIS WEEK10:00 AM PDTMaking Games with Adobe ColdFusionMark Takatahttps://making-games-with-adobe-coldfusion.meetus.adobeevents.com/ WEBINAR - THURSDAY, SEPTEMBER 22, 202210:00 AM PDTBuilding Custom Adobe Connect Pods with CF2021Mark Takatahttps://building-custom-adobe-connect-pods-cf2021.meetus.adobeevents.com/ FREE :)Full list - https://meetus.adobeevents.com/coldfusion/ CFCasts Content Updateshttps://www.cfcasts.comJust Released LogBox 101 - 1 new videos - https://cfcasts.com/series/logbox-101 Episode 12 - Categories https://www.cfcasts.com/series/logbox-101/videos/categories  2022 ForgeBox Module of the Week Series - 1 new Video https://cfcasts.com/series/2022-forgebox-modules-of-the-week 2022 VS Code Hint tip and Trick of the Week Series - 1 new Video https://cfcasts.com/series/2022-vs-code-hint-tip-and-trick-of-the-week  Coming Soon LogBox 101 from Eric Peterson - 2 more videos left! More ForgeBox and VS Code Podcast snippet videos Box-ifying a 3rd Party Library from Gavin ColdBox Elixir from Eric Conferences and TrainingRedis Hackathon on DevFrom now through August 29th, 2022, DEV has partnered up with Redis for a community hackathon that will give you the chance to build a new application using Redis or simplify a complex backend. Anyone who submits a valid project (including an official submission post, published on DEV) will be automatically entered to win a variety of fantastic prizes (including up to $2,000 USD).If you're familiar with our hackathons here on DEV, you know that the community has a lot of fun with them and gets pretty creative with what they build. Whether you've joined us in the past or not, we hope you'll throw your hat into the ring by participating in the Redis Hackathon on DEV!https://dev.to/devteam/announcing-the-redis-hackathon-on-dev-3248Docker - Community All HandsThursday September 1st, 2022 - 8am -11am PDTJoin us for our next Community All-Hands on September 1, 2022. This event is a unique opportunity for the Docker community and staff to come together. Don't miss out on this special meetup with community news, company and product updates, demos, language-specific tracks, and our first-ever virtual unconference.https://www.docker.com/events/community-all-hands/ Into the Box - Pre ConferenceAug 29th - Sep 2nd, 20222 sessions a day, 5 days in the week - 10 sessions totalConference Website:https://intothebox.orgInto The Box 2022September 6, 7 and 8, 2022 in Houston, TexasOne day workshops before the two day conference!Sign up for the workshops before they fill up - couple are almost filledConference Website:https://intothebox.orgCF Summit - OfficialAt the Mirage in Las Vegas, NVOct 3rd & 4th - CFSummit ConferenceOct 5th - Adobe Certified Professional: Adobe ColdFusion Certification Classes & Testshttps://cfsummit.adobeevents.com/ https://www.adobe.com/products/coldfusion-family/certificate.html Registrations are now open.Speakers are being listed on the Site - Brad, Luis, Gavin and Daniel from Ortus Solutions are in the list of speakers announced.Ortus CF Summit Training WorkshopColdBox Zero to MegaHero : REST APIs + VueJS Mobile AppOct 5th and 6th - After CF Summit ConferenceLead by Luis Majano & Gavin PickinPrice: $799 - Early bird pricinghttps://www.eventbrite.com/e/ortus-cf-summit-training-workshop-tickets-375306340367Location: Aria - In the luxurious Executive Hospitality Suite like 2019Into the Box Latam 2022Dec 5th or 7thMore information is coming very soon.CFCampNo CFCAMP 2022, we're trying again for summer 2023TLDR is that it's just too hard and there's too much uncertainty right now.More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/Blogs, Tweets, and Videos of the Week8/16/22 - Tweet - Grant Copley - CBWire now with Included ExamplesHave you seen how easy reactive form validation is with #CBWIRE? Now you can with our included examples in the CBWIRE repo. github.com/coldbox-module… #CFML #ColdFusion #ColdBoxhttps://twitter.com/GrantCopley/status/1559551004626100224https://twitter.com/GrantCopley8/13/22 - Blog - Ben Nadel - Strangler: Building A Feature Flag System In ColdFusionFor the last month-or-so, I've been quiet on this blog. Much of that is, unfortunately, stress-related; but, much of it is also do to a small rabbit-hole that I fell into: Feature Flags. If you've followed this blog for any period of time, you've no doubt seen me rave about feature flags. At work, I use and love LaunchDarkly; but, LaunchDarkly is too expensive for side-projects (such as this blog). As such, I wanted to see if I could create a LaunchDarkly-inspired feature flag system for my own personal ColdFusion projects. I'm calling this proof-of-concept "Strangler" (as in the Strangler pattern).https://www.bennadel.com/blog/4307-strangler-building-a-feature-flag-system-in-coldfusion.htm 8/10/22 - Blog - Luis Majano - Ortus Solutions - ContentBox v5.3 ReleasedWe are so excited to bring you the release of ContentBox Hybrid CMS version 5.3.0. This might be the last release in this major series as we are beginning the push of the next major release of ContentBox v6. Here is our what's new guide with our full release notes.https://www.ortussolutions.com/blog/contentbox-v53-released/Tweet - Daryl Ginn - Whats a good typeface other than Inter?I asked, "what's a good typeface other than Inter?"I received over 300 replies.Here's the most popular.https://twitter.com/darylginn/status/1559212268532862977https://twitter.com/darylginn 8/5/22 - Blog - Luis Majano - What native Redis Support in Lucee/CFML? Ortus Redis Extension v2.0.0 Released!We are very excited to bring you another release for our Redis Lucee Extension. This is a major release spawning research of over 9 months. We have done great strides in this new extension to not only bring you the best scaling capabilities via Redis, but also now to introduce to the CFML world: Real-Time messaging with Redis Pub/Sub! Here is our full release notes in our brand new documentation book: What's New With 2.0.0!Please note that if you have a license for a 1.x extension, you will need to upgrade your licenses to 2.x!https://www.ortussolutions.com/blog/want-native-redis-support-in-luceecfml-ortus-redis-extension-v200-released/?utm_medium=referral&utm_source=contentstudio.io CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 120 ColdFusion positions from 66 companies across 57 locations in 5 Countries.3 new jobs listed this weekFull-Time - ColdFusion Developer at Remote - Canada Aug 10https://www.getcfmljobs.com/jobs/index.cfm/canada/ColdFusion-Developer-at-Remote/11507Full-Time - ColdFusion Developer (Part Time) at Washington, DC - United States Aug 10https://www.getcfmljobs.com/jobs/index.cfm/united-states/ColdFusion-Developer-Part-Time-at-Washington-DC/11506 Full-Time - Web/Data Developer at Clinton,NY or Remote - United States Aug 09https://www.getcfmljobs.com/viewjob.cfm?jobid=11505 Other Job Links Ortus Solutions https://www.ortussolutions.com/about-us/careers  Tomorrow's Guides - Senior ColdFusion Developer - Remote (UK Based) https://www.tomorrows.co.uk/jobs.cfm  Hamilton https://apply.interfolio.com/110991  There is a jobs channel in the CFML slack team, and in the box team slack now too ForgeBox Module of the WeekOrtus Redis Cache Extension v2.0.0The Ortus Redis Extension is a native Lucee Extension that allows your CFML server to connect to a Redis server/cluster and leverage it for built-in caching, session storage, and NoSQL document storage.Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster. https://forgebox.io/view/5C558CC6-1E67-4776-96A60F9726D580F1 VS Code Hint Tips and Tricks of the WeekPresentation ModeA simple plugin to show your code properly in a presentationhttps://marketplace.visualstudio.com/items?itemName=jspolancor.presentationmode ​ScreencastMode: https://community.vscodetips.com/jonaThank you to all of our Patreon SupportersThese individuals are personally supporting our open source initiatives to ensure the great toolings like CommandBox, ForgeBox, ColdBox,  ContentBox, TestBox and all the other boxes keep getting the continuous development they need, and funds the cloud infrastructure at our community relies on like ForgeBox for our Package Management with CommandBox. You can support us on Patreon here https://www.patreon.com/ortussolutionsDon't forget, we have Annual Memberships, pay for the year and save 10% - great for businesses. Bronze Packages and up, now get a ForgeBox Pro and CFCasts subscriptions as a perk for their Patreon Subscription. All Patreon supporters have a Profile badge on the Community Website All Patreon supporters have their own Private Forum access on the Community Website All Patreon supporters have their own Private Channel access BoxTeam Slack Live Stream Access to streams like “Koding with the Kiwi + Friends” https://community.ortussolutions.com/ New Patreon: Richard HerbetPatreons John Wilson - Synaptrix Jordan Clark Gary Knight Mario Rodrigues Giancarlo Gomez David Belanger   Dan Card Jonathan Perret Jeffry McGee - Sunstar Media Dean Maunder Wil De Bruin Joseph Lamoree   Don Bellamy Jan Jannek   Laksma Tirtohadi   Brian Ghidinelli - Hagerty MotorsportReg Carl Von Stetten Jeremy Adams Didier Lesnicki Matthew Clemente Daniel Garcia Scott Steinbeck - Agri Tracking Systems Ben Nadel  Richard Herbet Brett DeLine Kai Koenig Charlie Arehart Jason Daiger Shawn Oden Matthew Darby Ross Phillips Edgardo Cabezas Patrick Flynn Stephany Monge   Kevin Wright John Whish Peter Amiri You can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors Thanks everyone!!! ★ Support this podcast on Patreon ★

2022-08-09 Weekly News - Episode 160Watch the video version on YouTube at https://youtu.be/LZtoUnLPU38 Hosts:  Eric Peterson - Senior Developer at Ortus Solutions Gavin Pickin - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: BUY SOME ITB TICKETS - COME TO THE CONFERENCE - Have a few laughs! Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips)  Patreon SupportGoal 1 - We have 37 patreons providing 100% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. Goal 2 - We are 44% of the way to fully fund the hosting of ForgeBox.io News and AnnouncementsLucee Release Roadmap, 6.0, 5.3.9 and 5.3.105.3.9 - Firstly, we have been working on the open regressions 11 with 5.3.9 and hope to release a quick RC this Friday.6.0.0-BETA - There are still a number of blockers which we still need to address, but we are getting very close.https://dev.lucee.org/t/lucee-release-roadmap-6-0-5-3-9-and-5-3-10/10810 WireBox Object Delegators are now born! WireBox Object Delegators are now born!  It's been committed with tests and hopefully this new design pattern will help you create beautiful object DSLs and just allow for less boilerplate in your code.https://ortussolutions.atlassian.net/browse/WIREBOX-131?atlOrigin=eyJpIjoiMGY4OTQwZGE2YTU5NGVkNGI2MDk5YzI1ZDM0MDA0ZGQiLCJwIjoiamlyYS1zbGFjay1pbnQifQ Lucee - Allow reducing the Priority of Concurrent RequestsMicha has been working on a new feature which will help to make uncoordinated DDOS attacks less effective against Lucee, by amongst other things reducing the thread priorityIt's been added to the 5.3.9.151-SNAPSHOT and 5.3.10.39-SNAPSHOTshttps://dev.lucee.org/t/allow-reducing-the-priority-of-concurrent-requests/10807/3 ICYMI - 117 ACF and Lucee roundtable (Part 3 – future CFML) with Charlie Arehart, Gert Franz, Mark Drew and Ben NadelCharlie Arehart, Gert Franz, Mark Drew and Ben Nadel talk about “ACF and Lucee roundtable (Part 3 – future CFML)” in this episode of ColdFusion Alive Podcast, with host Michaela Light.“We're gonna be talking about Adobe ColdFusion and Lucee and how they compare and contrast and all cool new features coming in the next five years that we prognosticate future performance. Improvements might be coming CFML engine updates and how you can best approach those confusion security. And we'll wrap up with some other questions about being a good CFML developer and conferences this year.”https://teratech.com/podcast/acf-and-lucee-roundtable-part-3-future-cfml-with-charlie-arehart-gert-franz-mark-drew-and-ben-nadel/INTO THE BOX - Updates1 month left until the start of the Pre-Conf, the Workshop and 2 days of 2 track content. ITB Pre-Conference Schedule Finalized on the Website (3 sessions TBA)Workshops are starting to fill up - don't miss your chance.https://intothebox.org/ New Releases and UpdatesLucee - Image Extension 1.2.0.1 and 1.0.0.44, isImageFile() invalid file locking fixedBugfix: locked temp image files - isImageFile()https://luceeserver.atlassian.net/browse/LDEV-3931When using isImageFile() for certain formats, if the file wasn't an image, Lucee was leaving the file locked.https://dev.lucee.org/t/image-extension-1-2-0-1-and-1-0-0-44-isimagefile-invalid-file-locking-fixed/10808 ICYMI - CFConfig - Now supports Scheduled Tasks in LuceeThanks to a sponsor, CFConfig now supports importing/exporting scheduled tasks for #Lucee Server (Adobe already had support)!  Please give it a test with the latest version and remember, tasks need imported into the web context of Lucee! #CommandBox #CFML #ColdFusionhttps://www.forgebox.io/view/commandbox-cfconfigICYMI - ColdBox 6.8.0 Released!I am incredibly excited to announce the release of ColdBox v6.8.0 and its standalone companion libraries: CacheBox, LogBox and WireBox. This update includes some important fixes and we managed to squeeze some nice improvements!Bug COLDBOX-1134 Router closure responses not marshaling complex content to JSON COLDBOX-1132 New virtual app was always starting up the virtual coldbox app instead of checking if it was running already Improvement COLDBOX-1131 Updated Missing Action Response Code to 404 instead of 405 COLDBOX-1127 All core async proxies should send exceptions to the error log New Feature COLDBOX-1130 New config/ColdBox.cfc global injections: webMapping, coldboxVersion COLDBOX-1126 Funnel all out and err logging on a ColdBox Scheduled Task to LogBox TaskCOLDBOX-1135 Remove HandlerTestCase as it is no longer in usage.https://www.ortussolutions.com/blog/coldbox-680-released/ICYMI - Adobe CFML VS Code Extension released (in Public Beta)https://marketplace.visualstudio.com/items?itemName=com-adobe-coldfusion.adobe-cfml-lspWebinar / Meetups and WorkshopsOrtus Webinar - August - Ortus Team - Into the Box Preview and Q&AAugust 26th, 2022: Time 11:00AM Central Time ( US and Canada )Join some of the Ortus Core Team as they discuss all the great things coming to you from Into the Box, with the Pre Conference Online Sessions, Full Day Workshops and then the 2 day 2 track in Person Conference.The session will be informal, with Q&A from the chat, with maybe a couple of last minute surprise announcements.Register now: https://bit.ly/3cW6LlM Adobe WorkshopsJoin the Adobe ColdFusion Workshop to learn how you and your agency can leverage ColdFusion to create amazing web content. This one-day training will cover all facets of Adobe ColdFusion that developers need to build applications that can run across multiple cloud providers or on-premiseTUESDAY, AUGUST 9, 20229.00 AM - 4.30 PM AESTColdFusion WorkshopBrian Sappeyhttps://coldfusion-1-day-training.meetus.adobeevents.com/ WEBINAR - THURSDAY, AUGUST 18, 202210:00 AM PDTMaking Games with Adobe ColdFusionMark Takatahttps://making-games-with-adobe-coldfusion.meetus.adobeevents.com/ WEBINAR - THURSDAY, SEPTEMBER 22, 202210:00 AM PDTBuilding Custom Adobe Connect Pods with CF2021Mark Takatahttps://building-custom-adobe-connect-pods-cf2021.meetus.adobeevents.com/ FREE :)Full list - https://meetus.adobeevents.com/coldfusion/ CFCasts Content Updateshttps://www.cfcasts.comJust Released LogBox 101 - 1 new videos - https://cfcasts.com/series/logbox-101 Episode 11 - Async Appender https://cfcasts.com/series/logbox-101/videos/async-appenders  2022 ForgeBox Module of the Week Series - 1 new Videohttps://cfcasts.com/series/2022-forgebox-modules-of-the-week 2022 VS Code Hint tip and Trick of the Week Series - 1 new Video https://cfcasts.com/series/2022-vs-code-hint-tip-and-trick-of-the-week  Coming Soon LogBox 101 from Eric Peterson - 3 more videos left! Koding with the Kiwi + Friends More ForgeBox and VS Code Podcast snippet videos Box-ifying a 3rd Party Library from Gavin ColdBox Elixir from Eric Conferences and TrainingRedis Hackathon on DevFrom now through August 29th, 2022, DEV has partnered up with Redis for a community hackathon that will give you the chance to build a new application using Redis or simplify a complex backend. Anyone who submits a valid project (including an official submission post, published on DEV) will be automatically entered to win a variety of fantastic prizes (including up to $2,000 USD).If you're familiar with our hackathons here on DEV, you know that the community has a lot of fun with them and gets pretty creative with what they build. Whether you've joined us in the past or not, we hope you'll throw your hat into the ring by participating in the Redis Hackathon on DEV!https://dev.to/devteam/announcing-the-redis-hackathon-on-dev-3248Into the Box - Pre ConferenceAug 29th - Sep 2nd, 20222 sessions a day, 5 days in the week - 10 sessions totalConference Website:https://intothebox.orgInto The Box 2022September 6, 7 and 8, 2022 in Houston, TexasOne day workshops before the two day conference!Sign up for the workshops before they fill up - couple are almost filledConference Website:https://intothebox.orgCF Summit - OfficialAt the Mirage in Las Vegas, NVOct 3rd & 4th - CFSummit ConferenceOct 5th - Adobe Certified Professional: Adobe ColdFusion Certification Classes & Testshttps://cfsummit.adobeevents.com/ https://www.adobe.com/products/coldfusion-family/certificate.html Registrations are now open.Ortus CF Summit Training WorkshopColdBox Zero to MegaHero : REST APIs + VueJS Mobile AppOct 5th and 6th - After CF Summit ConferenceLead by Luis Majano & Gavin PickinPrice: $799 - Early bird pricinghttps://www.eventbrite.com/e/ortus-cf-summit-training-workshop-tickets-375306340367Location: Aria - In the luxurious Executive Hospitality Suite like 2019The suite doubled it's prices but we're working hard to keep the costs to the attendees the sameInto the Box Latam 2022Dec 5th or 7thMore information is coming very soon.CFCampNo CFCAMP 2022, we're trying again for summer 2023TLDR is that it's just too hard and there's too much uncertainty right now.More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/Blogs, Tweets, and Videos of the WeekAdobe Corner8/4/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: Quick FixSometimes we all need a helping hand.Wait.Does an IDE even have a hand?Anyway, imagine if your VS Code was able to flag issues with your code, make suggestions, but then even make those suggestions come to life! The Builder extension for VS Code includes a “quick fix” capability.https://coldfusion.adobe.com/2022/08/acf-builder-extension-quick-fix/ 8/4/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: Code RefactoringWhat is “code refactoring”? Is it a cool new UK reality show where you win prizes by changing up your applications to work better? No, but if any tv producers from the UK read this and are interested, call me.https://coldfusion.adobe.com/2022/08/acf-builder-extension-code-refactoring/ 8/4/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: Code AssistOften, the main reason we use a purpose-built IDE for our development work is for getting help with things like code completion, hinting, scaffolding and other similar features. This is often a big differentiator from more simplified editors such as, for example, Notepad.https://coldfusion.adobe.com/2022/08/acf-builder-extension-code-assist/ 8/4/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: Security AnalyzerSecurity is a critical aspect of programming. The Security Analyzer is a powerful, useful tool for CFML developers to use to help prevent vulnerable code in their application. It can warn about potential threats, give you an idea on the level of the threat, and suggest potential solutions to the issues.https://coldfusion.adobe.com/2022/08/acf-builder-extension-security-analyzer/ 8/3/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: PMT Code ProfilerThe Performance Monitoring Toolkit (PMT) provides critical performance data for your running Adobe ColdFusion servers. It monitors all transactions and captures a variety of data metrics including response and run times, errors, and other data. The Builder Extension provides the ability to view data from the PMT server in a report.https://coldfusion.adobe.com/2022/08/acf-builder-extension-pmt-code-profiler/ 8/2/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: RDS IntegrationRDS has helped ColdFusion developers with their development workflows for a very long time, and ever since Adobe ColdFusion Builder version 1.0 (code named “Bolt”) CF developers have been able to interact with various aspects of their development environment using RDS. In the ACF Builder Extension, this is also the case, with powerful capabilities that become available when using & logging the extension into RDS.https://coldfusion.adobe.com/2022/08/acf-builder-extension-rds-integration/ 8/1/22 - Blog - Mark Takata - ColdFusion Portal - ACF Builder Extension: Server PanelOne of the incredible differentiating features of the Builder Extension is the ability to setup & control your servers directly from VS Code. This was a very popular feature in ColdFusion Builder (Eclipse) and provides nearly identical functionality here.https://coldfusion.adobe.com/2022/08/acf-builder-extension-server-panel/ Community Corner8/6/22 - Tweet - James Moberg - CFML Legacy ConverterAny #CFML developers working with legacy #ColdFusion code? I'm almost finished developing a CFC that will "standardize/modernize tags, functions, member functions, attributes, operators & SQL case." (I'm hoping to share sometime next week.) #NoMoreManualSearchReplacehttps://twitter.com/gamesover/status/1555990302564814850 https://twitter.com/gamesover8/5/22 - Blog - Ortus Solutions - Ortus Content Digest for week of August 5thIt's August 5th... what has Ortus been publishing this week? We have the CFML News Podcast, some CFCasts and YouTube Videos, lots of Ortus and ITB Blog Posts. We have a lot more planned for next week as well.https://www.ortussolutions.com/blog/ortus-content-digest-for-week-of-august-5th/?utm_medium=referral&utm_source=contentstudio.io 8/4/22 - Tweet - Brad Wood - Ortus Solutions - Client Cert AuthI think I've finally cracked the client cert auth in #CommandBox.  This was a huge project, but important for our government clients.  Let me know if you want to help test it. I've also refactored basic auth and laid roadwork for digest auth, SSO, and NTLM auth. #CFML #ColdFusion https://twitter.com/bdw429s/status/1555234073630674947 https://twitter.com/bdw429s 8/3/22 - Blog - Dan Card - Ortus Solutions - Integrating ColdBox with Existing Code Series Part 4: More IntegrationRecently, I did a webinar on Refactoring Legacy Code and the question came up about whether or not it was possible to use ColdBox with existing code without converting everything to a ColdBox module or making changes to the existing codebase.https://www.ortussolutions.com/blog/integrating-coldbox-with-existing-code-series-part-4-more-integration/?utm_medium=referral&utm_source=contentstudio.io 8/2/22 - Blog - Zac Spitzer - Lucee Release Roadmap, 6.0, 5.3.9 and 5.3.105.3.9 - Firstly, we have been working on the open regressions 11 with 5.3.9 and hope to release a quick RC this Friday.6.0.0-BETA - There are still a number of blockers which we still need to address, but we are getting very close.https://dev.lucee.org/t/lucee-release-roadmap-6-0-5-3-9-and-5-3-10/10810 7/30/22 - Blog - Bang Website - ColdFusion Development Alive & Well Says BANG! DevelopersAs an active ColdFusion Developer since 1998 (when it was still owned by Allaire, prior to being purchased by Macromedia and then Adobe) we laugh every time we hear "ColdFusion is Dead". We've used it non-stop for over two decades while other popular programming languages have come and gone.If you are looking for ColdFusion programmers or Web Developers fluent in Adobe ColdFusion mark-up language and the many uses of ColdFusion for software development, you are in the right place. View our Web Development page for more information about our services. For more information about the ColdFusion Web Development Platform and it's history read on.https://www.bangwebsitedesignphoenixaz.com/blog/ColdFusion-Development-Alive-Well-Says-BANG-Developers.cfm CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 116 ColdFusion positions from 62 companies across 55 locations in 5 Countries.2 new jobs listed this weekFull-Time - Web/Data Developer at Clinton, NY or Remote - United States Aug 09https://www.getcfmljobs.com/viewjob.cfm?jobid=11505 Full-Time - Application Developer IV - Temp (Coldfusion Developer) Remot.. - United States Aug 04https://www.getcfmljobs.com/jobs/index.cfm/united-states/Application-Developer-IV-Temp-Coldfusion-Developer-Remote-at-Des-Moines-IA/11504 Other Job Links Ortus Solution https://www.ortussolutions.com/about-us/careers  Tomorrow's Guides - Senior ColdFusion Developer - Remote (UK Based) https://www.tomorrows.co.uk/jobs.cfm  Hamilton https://apply.interfolio.com/110991  There is a jobs channel in the CFML slack team, and in the box team slack now too ForgeBox Module of the WeekError Filter A ColdBox Module to filter error messages to remove unwanted fields and items in the tagContext array to reduce noise and make error items more readable.Note: Based on ideas and work from John Wilson at Synaptrix! Thanks!https://www.forgebox.io/view/errorFilter VS Code Hint Tips and Tricks of the Weekgit nahCustom Git Aliasesgit config –global alias.nah=!git reset --hard && git clean -dfThis cleans whatever you have going on.`git nah`Thank you to all of our Patreon SupportersThese individuals are personally supporting our open source initiatives to ensure the great toolings like CommandBox, ForgeBox, ColdBox,  ContentBox, TestBox and all the other boxes keep getting the continuous development they need, and funds the cloud infrastructure at our community relies on like ForgeBox for our Package Management with CommandBox. You can support us on Patreon here https://www.patreon.com/ortussolutionsDon't forget, we have Annual Memberships, pay for the year and save 10% - great for businesses. Bronze Packages and up, now get a ForgeBox Pro and CFCasts subscriptions as a perk for their Patreon Subscription. All Patreon supporters have a Profile badge on the Community Website All Patreon supporters have their own Private Forum access on the Community Website All Patreon supporters have their own Private Channel access BoxTeam Slack Live Stream Access to Koding with the Kiwi + Friends https://community.ortussolutions.com/  Patreons John Wilson - Synaptrix Jordan Clark Gary Knight Mario Rodrigues Giancarlo Gomez David Belanger   Dan Card Jonathan Perret Jeffry McGee - Sunstar Media Dean Maunder Wil De Bruin Joseph Lamoree   Don Bellamy Jan Jannek   Laksma Tirtohadi   Brian Ghidinelli - Hagerty MotorsportReg Carl Von Stetten Jeremy Adams Didier Lesnicki Matthew Clemente Daniel Garcia Scott Steinbeck - Agri Tracking Systems Ben Nadel  Richard Herbet Brett DeLine Kai Koenig Charlie Arehart Jason Daiger Shawn Oden Matthew Darby Ross Phillips Edgardo Cabezas Patrick Flynn Stephany Monge  (Monghee) Kevin Wright John Whish Peter Amiri You can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors Thanks everyone!!! ★ Support this podcast on Patreon ★

We talk about beards. The gay dating kind. I swear I'm not just dating human women to hide my love for Goldeen

Mercedes is about to get herself caught up now that she's having sex for money with Coach! (6:06) DSLs rant (8:00) P-Valley has the horniest fans (11:53) Karens should work from home (18:27) The new coach looks so different (20:43) Woody is an idiot (24:25) Farrah needs to divorce Coach (26:48) Is Pico gay? (28:07) Are P-Valley writers nasty? (29:34) Uncle Clifford is on the pole now (37:15) I'm Team Patrice (37:48) Where's the other Kyle brother? Follow us on Twitter & Instagram @pvalleypodcast Our favorite episodes: https://podcasts.apple.com/us/podcast/trinity-shares-a-nasty-stripper-story/id1537454924?i=1000499160626 https://podcasts.apple.com/us/podcast/p-valley-episode-2-recap-autumn-and-andres-phone-sex/id1537454924?i=1000497169927 https://podcasts.apple.com/us/podcast/demi-talks-colorism-uncle-clifford-andre/id1537454924?i=1000501829086 --- Support this podcast: https://anchor.fm/pvalley/support

Welcome back to another episode of Elixir Wizards. Today, we chat with Digit, a talented software engineer currently based at SmartRent. He became aware of the company when he started trying to modify his smart home and realized what was behind the software. Digit works on building applications within the SmartRent suite of tools using the Nerves ecosystem. Although fairly new at SmartRent, Digit loves the powerful applications of the software they are developing. In today's show we find out more about the work Digit is currently involved with at SmartRent and what they have in store for the future. We also discuss the pros and cons of living in a smart home, the different languages that Digit uses, what makes developing a game so challenging, Using Elixir for building DSLs to generate content for Unity, what Digit's opinion is of Burrito, and much more! For all this and more, be sure to tune in today! Key Points From This Episode: Introduction to today's show and brief catch-up of what everyone has been up to. We find out what talks at the conference Digit is most looking forward to. What OTP stands for: hint, it is not ‘Open Telephony Platform.' A brief discussion about the advantages of a one-day conference. We find out who all the people are that are going to give talks at EMPEX. Digit shares what it has been like working at SmartRent. We find out how Digit landed the job at SmartRent. Breakdown of what SmartRent is in terms of the high level. We get some insider knowledge of the next-generation technology at SmartRent. Rundown of what Flutter is and the advantages of using it. Discussion about the pros and cons of living in a smart home. Find out what the best smart thermostat is, according to Digit. The different programming languages that Digit is currently working in. Digit explains the type of WebSocket support available in Flutter. Background about Digit's experience in game development. What makes finishing developing a game so difficult. The language stack used to develop games. Using Elixir for building DSLs to generate content for Unity. Digit gives listeners an overview of Burrito. The advantages of using Burrito for cross-platform with no internet connection. Examples of real-world applications using Burrito. Other applications for Elixir outside of web application development. We get some insider information about a new Elixir-based project in the works. A rundown of the security applications using Macaroons. The power that passwordless authentication has to offer. We end the show with some takeaways from Digit for listeners. Links Mentioned in Today's Episode: Digit — https://puppy.surf Digit on GitHub — https://github.com/doawoo Digit on Twitter — https://twitter.com/doawoo SmartBit — https://www.smartbitdigital.net/ SmartBit on Facebook — https://www.facebook.com/smartbitdigitalsolutions/ SmartRent — https://smartrent.com SmartLogic — https://smartlogic.io/ SmartLogic on Twitter — https://twitter.com/smartlogic_com SmartLogic on LinkedIn — https://www.linkedin.com/company/smartlogic-io/ SmartLogic on Facebook — https://www.facebook.com/smartlogic/ Sundi Myint on LinkedIn — https://www.linkedin.com/in/sundimyint/ Sundi Myint on Instagram — https://www.instagram.com/sundikhin/ Sundi Myint on Twitter — https://twitter.com/sundikhin/ Sundi Myint on YouTube — https://www.youtube.com/sundimyint/ Owen Bickford on Twitter — https://twitter.com/owenbickford/ Owen Bickford on YouTube — https://www.youtube.com/c/OwenBickford/ EMPEX — https://www.empex.co Flutter — https://flutter.dev/ Special Guest: Digit.

Typically when you mention "Ruby" and "template" in the same breath, people will think of ERB. Perhaps even Haml. But did you know that the Ruby ecosystem offers a wide variety of template engines, and quite a few are built upon pure Ruby? In this episode, I break down the main conceptual difference between "string-based templates" such as ERB and "DSLs" such as Papercraft, the various options within each category, and some of the reasons you might want to choose one approach or another depending on your use case. Enjoy!Links:Article: HTML is a Serialized Object GraphERB Erubi (ERB variant used by Rails, Bridgetown)LiquidSerbeaHamlSlimArbreMarkabyWunderbarPapercraftRuxBecome a part of the Fullstack Ruby community and learn how to put your Ruby skills to work on the backend AND the frontend. Know somebody who's a JavaScript developer but is interested in learning more about Ruby? Share the site, podcast, or newsletter with them!The Fullstack Ruby Podcast is a production of Whitefusion, a boutique web studio based in Portland, OR.Theme music courtesy of Epidemic Sound.

In this episode, Markus Völter, expert in Language Engineering, DSLs, and Model-Driven Software Development, and Václav Pech, MPS Developer Advocate at JetBrains, disclose who the Subject Matter Experts (SMEs) are and discuss whether they should participate in development with our host Paul Everitt.

Doctors Nikki Coleman, Brian J. Dixon & Jide Bamishigbin link back up on The Break Room to talk about how, from PSLs to DSLs, our words matter. How we name things shapes our understanding of ourselves and the world around us. Check out the show notes for more! Want to know more about our LinkedIn Learning courses? Check them out! https://bit.ly/3k4havy Check out full episodes of The Break Room, video included. https://bit.ly/3pFsW0e Follow The Break Room on Twitter. https://bit.ly/34R2ety

This week Wendell names his standouts in this years NRL Season, Tim Horan chats about all things Rugby Union and we solve another do or die dilemma in the DSL Judiciary.  See omnystudio.com/listener for privacy information.

We got an all-over-the-place episode of the SoBros Power Hour with Stoney, Cad, and Steven on deck for you this week, on which the gang talks about football season and fall approaching, PSLs, DSLs, Grand Old Golf, the milk crate challenge, emissions testing in Tennessee, Nashville being an "alcoholic theme park," Music City GP coming back, Mooby's, and MUCH MUCH MORE.

Which prospects should you know about? Which prospect's brother has DSLs? How quickly do we mention Kevin Knox??? Find out RIGHT NOW

About NigelNigel Kersten's day job is Field CTO at Puppet where he leads a group of engineers who work with Puppet's largest customers on cultural and organizational changes necessary for large-scale DevOps implementations - among other things. He's a co-author of the industry-leading State Of DevOps Report and likes to evenly talk about what went right with DevOps and what went wrong based on this research and his experience in the field. He's held multiple positions at Puppet across product and engineering and came to Puppet from the Google SRE organization, where he was responsible for one of the largest Puppet deployments in the world.  Nigel is passionate about behavioral economics, electronic music, synthesizers, and Test cricket. Ask him about late-stage capitalism, and shoes.Links: Puppet: https://puppet.com 2020 State of DevOps Report: https://puppet.com/resources/report/2020-state-of-devops-report/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: Your company might be stuck in the middle of a DevOps revolution without even realizing it. Lucky you! Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy in on DevOps practices? Well, download the 2021 State of DevOps report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping evolution firms stuck in the middle of their DevOps evolution. Because they fail to evolve or die like dinosaurs. The significance of organizational buy in, and oh it is significant indeed, and why team identities and interaction models matter. Not to mention weither the use of automation and the cloud translate to DevOps success. All that and more awaits you. Visit: www.puppet.com to download your copy of the report now!Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is sponsored by a long time… I wouldn't even say friends so much as antagonist slash protagonist slash symbiotic company with things I have done as I have staggered through the ecosystem. There's a lot of fingers of blame that I can point throughout the course of my career at different instances, different companies, different clients, et cetera, et cetera, that have shaped me into the monstrosity than I am today. But far and away, the company that has the most impact on the way that I speak publicly, is Puppet.Here to accept the recrimination for what I become and how it's played out is Nigel Kersten, a field CTO at Puppet—or the field CTO; I don't know how many of them they have. Nigel, welcome to the show, and how unique are you?Nigel: Thank you, Corey. Well, I—you know, reasonably unique. I think that you get used to being one of the few Australians living in Portland who's decided to move away from the sunny beaches and live in the gray wilderness of the Pacific Northwest.Corey: So, to give a little context into that ridiculous intro, I was a traveling contract trainer for the Puppet fundamentals course for an entire summer back in I want to say 2014, but don't hold me to it. And it turns out that when you're teaching a whole bunch of students who have paid in many cases, a couple thousand dollars out of pocket to learn a new software where, in some cases, they feel like it's taking their job away because they view their job, rightly or wrongly, is writing the same script again and again. And then the demo breaks and people are angry, and if you don't get a good enough rating, you're not invited to continue, and then the company you're contracting through hits you with a stick, it teaches you to improvise super quickly. So, I wasn't kidding when I said that Puppet was in many ways responsible for the way that I give talks now. So, what do you have to say for yourself?Nigel: Well, I have to say, congratulations for surviving, opinionated defensive nerds who think not only you but your entire product you're demoing could be replaced by a shell script. It's a tough crowd.Corey: It was an experience. And some of these were community-based, and some of them were internal to a specific company. And if people have heard more than one episode of this show, I'm sure they can imagine how that went. I gave a training at Comcast once and set a personal challenge for myself of how many times could I use the word ‘comcastic' in a three-day training. And I would work it in and talk about things like the schedule parameter in Puppet where it doesn't guarantee something's going to execute in a time window; it's the only time it may happen.If it doesn't fire off, and then it isn't going to happen. It's like a Comcast service appointment. And then they just all kind of stared at me for a while and, credit where due, that was the best user rating I ever got from people sitting through one of my training. So, thanks for teaching me how to improve at, basically, could have been a very expensive mistake on Puppet's part. It accidentally worked out for everyone.Nigel: Brilliant, brilliant. Yes, you would have survived teaching the spaceship operator to that sort of a crowd.Corey: Oh, I mostly avoided that thing. That was an advanced Puppet-ism, and this was Puppet fundamentals because I just need to be topically good at things, not deep-dive good at things. But let's dig into that a little bit. For those who have not had the pleasure of working with Puppet, what is it?Nigel: Sure? So, Puppet is a pretty simple DSL. You know, DSLs aren't necessarily in favor these days.Corey: Domain-specific language, for those who have not—Nigel: Yep.Corey: —caught up on that acronym. Yes.Nigel: So, a programming language designed for a specific task. And, you know, instead, we've decided that the world will rest on YAML. And we've absorbed a fair bit of YAML into our ecosystem, but there are things that I will still stand by are just better to do in a programming language. ‘if x then y,' for example, it's just easier to express when you have actual syntax around you and you're not, sort of, forcing everything to be in a data specification language. So, Puppet's pretty simple in that it's a language that lets you describe the state that infrastructure should be.And you can do this in a modular and composable way. So, I can build a little chunk of automation code; hand it to Corey; Corey can build something slightly bigger with it; hand it to someone else. And really, this sort of collaboration is one of the reasons why Puppet's, sort of, being at the center of the DevOps movement, which at its core is not really about tools. It's about reducing friction between different groups.Corey: Back when I was doing my traveling training shtick, I found that I had to figure out a way to describe what Puppet did to folks who were not deep in the space, and the analogy that I came up with that I was particularly partial to was, imagine you get a brand new laptop. Well, what do you do with it? You install your user account and go through the setup; you install the programs that you use, some which have licenses on it; you copy your data onto it; you make sure that certain programs always run on startup because that's the way that you work with these things; you install Firefox because that's the browser of choice that you go with, et cetera, et cetera. Now, imagine having to do that for, instead of one computer, a thousand of them, and instead of a laptop, they're servers. And that is directionally what Puppet does.Nigel: Absolutely. This is the one I use for my mother as well. Like, I was working around Puppet for years before—and the way I explained it was, “You know when you get a new iPad, you've got to set up your Facebook account and your email. Imagine you had ten thousand of these.” And she was like—I was like, “You know, companies like Google, company like big banks, they all have lots and lots and lots of computers.” And she was like, “They run all those things on iPads.” And I was like, “This is not really where my analogy was going.” But.Corey: Right. And increasingly, though, it seems like the world has shifted in some direction where, when you explain that to your mother and she comes back with, “Well, wouldn't they just put the application into Docker and be done with it?” Oh, dear. But that seems to be in many ways that the direction that the zeitgeist has moved in, whether or not that is the reality in many environments, where when you're just deploying containers everywhere—through the miracle of Kubernetes—if you'll pardon the dismissive scorn there, that you just package up your application, shove into a container, and then hurl it from the application team over the operations team, like a dead dog cast into your neighbor's yard for him to worry about. And then it sort of takes up the space of you don't have to manage state anymore because everything is mostly stateless in theory. How have you seen it play out in practice in the last five years?Nigel: I mean, that's a real trend. And, you know, the size of a container should be [laugh] smaller than an operating system. And the reality is, I'm a sysadmin; I love operating systems, I nerded out on operating systems. They're a necessary evil, they're terrible, terrible things: registry keys, config files, they're a pain in the neck to deal with. And if you look at, I think what a lot of operations folks missed about Docker when it started was that it didn't make their life better. It was worse.It was, like, this actual, sort of, terrible toolchain where you sort of tied together all these different things. But really importantly, what it did is it put control into the hands of the developers, and it was the developers who were trying to do stuff who were trying to shift into applications. And I think Docker was a really great technology, in the sense of, you know, developers could ship value on their own. And that was the huge, huge leveling up. It wasn't the interface, it wasn't the user experience, it wasn't all these things, it was just that the control got taken away from the IT trolls in their basement going, “No, don't touch my servers,” and instead given straight to the developers. And that's huge because it let us ship things faster. And that's ultimately the whole goal of things.Corey: The thing that really struck me the most from conducting the trainings that I did was meeting a whole bunch of people across the country, in different technological areas of specialty, in different states of their evolution as technologists, and something that struck me was just how much people wound up identifying with the technology that they worked on. When someone is the AIX admin, and the AIX machines are getting replaced with Linux boxes, there's this tendency to fight against that and rebel, rather than learning Linux. And I get it; I'm as subject to this as anyone is. And in many cases, that was the actual pushback that I saw against adopting something like Puppet. If I identify my job as being the person that runs all these carefully curated scripts that I've spent five years building, and now that all gets replaced with something that is more of a global solution to my local problem, then it feels like a thing that made me special is eroding.And we see that with the migration to cloud as well. When you're the storage admin, and it just becomes an API call to S3, that's kind of a scary thing. And when you're one of the server hugger types—and again, as guilty as anyone of this—and you start to see cloud coming in as, like, a rising tide that eats up what it was that you became known for, it's scary and it becomes a foundational shift in how you view yourself. What I really had a lot of sympathy for was the folks who've been doing this for 20 years. They were, in some cases, a few years away from retirement, and they've been doing basically the same set of tasks every year for 25 years.It's one year of experience repeated 25 times. And they don't have that much time left in their career, intentionally, so they want to retire, but they also don't really want to learn a whole bunch of new technologies just to get through those last few years. I feel for them. But at the same time—Nigel: No, me too, totally. But what are you going to do? But without sounding too dismissive there, I think it's a natural tendency for us to identify with the technology if that's what you're around all the time. You know, mechanics do this, truck drivers with brands of trucks, people, like, to build attachments to the technology they work with because we fit them into this bigger techno-social system. But I have a lot of empathy for the people in enterprise jobs who are being asked to change radically because the cycle of progress is speeding up faster and faster.And as you say, they might be a few years away from retirement. I think I used to feel more differently about this when I was really hot-headed and much more of a tech enthusiast, and that's what I identified with. In terms of, it's okay for a job to just be a job for people. It's okay for someone to be doing a job because they get good health care and good benefits and it's feeding their family. That's an important thing. You can't expect everyone to always be incredibly passionate about technology choices in the same way that I think many of us who live on Twitter and hanging out in this space are.Corey: Oh, I have no problem whatsoever with people who want to show up for 40 hours a week-ish, work on their job, and then go home and have lives and not think about computers at all. There's this dark mass of developers out there that basically never show up on Twitter, they aren't on IRC, they don't go to conferences, and that's fine. I have no problem with that, and I hope I don't come across as being overly dismissive of those folks. I honestly wish I could be content like that. I just don't hold still very well.Nigel: [laugh]. Yeah, so I think you touched on a few interesting things there. And some of those we sort of cover in the State of DevOps Report, which is coming out in the next few weeks.Corey: Indeed, and the State of DevOps Report started off at Puppet, and they've now done it for, what, 10 years?Nigel: This is the 10th year, which is completely crazy. So, I was looking at the stats as I was writing it, and it's 10 years of State of DevOps Reports; I think it's 11 years of DevOps Weekly, Gareth Rushgrove's newsletter; it's 12 or 13 years of DevOpsDays that have been going on. This is longer than I spent in primary and high school put together. It's kind of crazy that the DevOps movement is still, kind of, chugging along, even if it's not necessarily the coolest kid on the block, now that GitOps, SRE flavor of the month, various kinds of permutations of how we work with technology, have perhaps got a little bit cooler. But it's still very, very relevant to a lot of enterprises out there.Corey: Yeah. As I frequently say, legacy is a condescending engineering term for ‘it makes money,' and there's an awful lot of that out there. Forget cloud, there are still companies wrestling with do we explore this virtualization thing? And that was something I was very against back in 2006, let's be very honest. I am very bad at predicting the future of technology.And, “I can see this for small niche edge workload cases, where you have a bunch of idle servers, but for the most part, who's really going to use this in production?” Well, basically everyone because that, in turn, is what the cloud runs on. Yeah, I think we can safely say I got that one hilariously wrong. But hey, if you're aren't going to make predictions, then what's it matter?Nigel: But the industry pushes you in these directions. So, there was this massive bank in Asia who I've been working with for a long time and they were always resistant to adopting virtualization. And then it was only four or five years ago that I visited them; they're like, “Right. Okay. It's time. We're rolling out VMware.” And I was like, “So, I'm really curious. What exactly changed in the last year or two in, like, 2014, 2015 that you decided virtualization was the key?” And I'm like—Corey: Oh, there was this jackwagon who conducted this training? Yeah, no, no, sorry. I can't take credit for that one.Nigel: They couldn't order one rack unit servers with CD drives anymore because their whole process was actually provisioning with CDs before that point.Corey: Welcome to the brave new world of PXE booting, which is kind of hard, so yeah, virtualization is easier. You know, sometimes people have to be dragged into various ways of technological advancement. Which gets to the real thing I want to cover, since this is a promoted episode, where you're talking about the State of DevOps Report, I'm almost less interested in what this year's has to say specifically, than what you've seen over the last decade. What's changed? What was true 10 years ago that is very much not true now? Bonus points if you can answer that without using the word Kubernetes more than twice.Nigel: So, I think one of the big things was the—we've definitely passed peak DevOps team, if you may remember, there was a lot of arguments and there's still regular, is DevOps a job title? Is it a team title? Is it a [crosstalk 00:14:33]—Corey: Oh, I was much on the no side until I saw how much more I would get paid as a DevOps engineer instead of a systems administrator for the exact same job. So, you know, I shut up and I took the money. I figured that the semantic arguments are great, but yeah.Nigel: And that's exactly what we've written in the report. And I think it's great. The sysadmins, we were unloved. You know, we were in the basement, we weren't paid as much as programmers. The running joke used to be for developers, DevOps meant, “I don't need ops anymore.” But for ops people, it was, “I can get paid like a developer.”Corey: In many cases, “Oh, well, systems administrators don't want to learn how to code.” It's, yeah, you're remembering a relatively narrow slice of time between the modern era, where systems administrator types need to be able to write in the lingua franca of everything—which is, of course, YAML, as far as programming languages go—and before that, to be a competent systems administrator, you needed to have a functional grasp of C. And—Nigel: Yeah.Corey: —there is only a limited window in which a bunch of bash scripts and maybe a smidgen of Perl would have carried you through. But the deeper understanding is absolutely necessary, and I would argue, always has been.Nigel: And this is great because you've just linked up with one of the things we found really interesting about the report is that you know when we talk about legacy we don't actually mean the oldest shit. Because the oldest shit is the mainframes; it's a lot of bare metal applications. A lot of that in big enterprises—Corey: We're still waiting for an AWS/400 to replace some of that.Nigel: Well, it's administered by real systems engineers, you know, like, the people who wrote C, who wrote kernel extensions, who could debug things. What we actually mean by legacy is we mean late '90s to late 2000s, early 2010s. Stuff that was put together by kids who, like me, happened to get a job because you grew up with a computer, and then the dotcom explosion happened. You weren't necessarily particularly skilled, and a lot of people, they didn't go through the apprenticeships that mainframe folks and systems engineers actually went through. And everyone just held this stuff together with, you know, duct tape and dental floss. And then now we're paying the price of it all, like, way back down the track. So, the legacy is really just a certain slice of rapid growth in applications and infrastructure, that's sort of an unmanageable mess now.Corey: Oh, here in San Francisco, legacy is anything prior to last night's nightly build. It's turned into something a little ridiculous. I feel like the real power move as a developer now is to get a job, go in on day one, rebase everything in the Git repository to a single commit with a message, ‘legacy code' and then force push it to the main branch. And that's the power move, and that's how it works, and that's also the attitude we wind up encountering in a lot of places. And I don't think it serves anyone particularly well to tie themselves so tightly to that particular vision.Nigel: Yep, absolutely. This is a real problem in this space. And one of the things we found in the State of DevOps Report is that—let me back up a little and give a little bit of methodology of what we actually do. We survey people about their performance metrics, you know, like how quickly can you do deploys? What's your mean time to recovery? Those sorts of things, and what practices do you actually employ?And we essentially go through and do statistical analysis on this, and everyone tends to end up in three cohorts, they separate pretty easily, of low, medium, and high evolution. And so one of the things we found is that everyone at the low level has all sorts of problems. They have issues with what does my team do? What does the team next to me do? How do I talk to the team next to me?How do I actually share anything? How do I even know what my goals are? Like, fundamental company problems. But everyone at all levels of evolution is stuck on two big things: not being able to find enough people with the right skills for what they need, and their legacy infrastructure holding them back.Corey: The thing that I find the most compelling is the idea of not being able to find enough people with the skills that they need. And I'm going to break my own rule and mentioned Kubernetes as a prime example of this. If you are effective at managing Kubernetes in production, you will make a very comfortable living in any geographical location on the planet because it is incredibly complex. And every time we've seen this in previous trends, where you need to get more and more complexity, and more and more expertise just to run something, it looks like a sawtooth curve, where at some point that complexity, it gets abstracted away and compressed down into something that is basically a single line somewhere, or it happens below the surface level of awareness. My argument has been that Kubernetes is something no one's going to care about in roughly three years from now, not because we're not using it anymore, but because it's below the level of awareness that we have to think about, in the same way that there aren't a whole lot of people on the planet these days who have to think about the Linux virtual memory management subsystem. It's there and a few people really care about it, but for the rest of us, we don't have to think about that. That is the infrastructure underneath our infrastructure.Nigel: Absolutely. I used to make a living—and it's ridiculous looking back at this—for a year or two, doing high-performance custom compiled Apaches for people. Like, I was really really good at this.Corey: Well yeah, Apache is a great example of this, where back in the '90s, to get a web server up and running you needed to have three days to spare, an in-depth knowledge of GCC compiler flags, and hope for the best. And then RPM came out and then, okay, then YUM or other things like that—Nigel: Exactly.Corey: —on top of it. And then things like Puppet started showing up, and we saw, all right now, [unintelligible 00:20:01] installed. Great. And then we had—it took a step beyond that, and it was, “Oh, now it's just a Docker-run whatever it is,” and these days, yeah, it's a checkbox in S3.Nigel: So, let me get your Kubernetes prediction down, right. So, you're predicting Kubernetes is going to go away like Apache and highly successful things. It's not an OpenStack failure state; it's Apache invisibility state?Corey: Absolutely. My timeline is a bit questionable, let's be fair, but—it's a little on the aggressive side, but yeah, I think that Kubernetes is inherently too complex for most people to have to wind up thinking about it in that way. And we're not talking small companies; we're talking big ones where you're not in a position, if you're a giant blue-chip Fortune 50, to hire 2000 people who all know Kubernetes super well, and you shouldn't have to. There needs to be some flattening of all of that high level of complexity. Without the management tools, though, with things like Puppet and the things that came before and a bunch of different ways, we would all not be able to get anything done because we'd be too busy writing in assembly. There's always going to be those abstractions on top abstractions on top abstractions, and very few people understand how it works all the way down. But that's, in many cases, okay.Nigel: That's civilization, you know? Do you understand what happens when you plug in something to your electricity socket? I don't want to know; I just want light.Corey: And more to the point, whenever you flip the switch, you don't have that doubt in your mind that the light is going to come on. So, if it doesn't, that's notable, and your first thought is, “Oh, the light bulb is out,” not, “The utility company is down.” And we talk about the cloud being utility computing.Nigel: Has someone put a Kubernetes operator in this light switch that may break this process?Corey: Well, okay, IoT does throw a little bit of a crimp into those works. But yeah. So, let's talk more about the State of DevOps Report. What notable findings were there this year?Nigel: So, one of the big things that we've seen for the last couple of years has been that most companies are stuck in the middle of the evolutionary progress. And anyone who deals with large enterprises knows this is true. Whatever they've adopted in terms of technology, in terms of working methods, you know, agile, various different things, most companies don't tend to advance to the high levels; most places stay mired in mediocrity. So, we wanted to dive into that and try and work out why most companies actually stuck like this when they hit a certain size. And it turns out, the problems aren't technology or DevOps, they really fundamental problems like, “We don't have clear goals. I don't understand what the teams next to me do.”We did a bunch of qualitative interviews as well as the quantitative work in the survey with this report, and we talked to one group of folks at a pretty large financial services company who are like, “Our teams have all been renamed so many times, if I need to go and ask someone for something, I literally page up and down through ServiceNow, trying to find out where to put the change request.” And they're like, “How do I know where to put a network port opening request for this particular service when there are 20 different teams that might be named the right thing, and some are obsolete, and I get no feedback whether I've sent it off to the right thing or to a black hole of enterprise despair?”Corey: I really love installing, upgrading, and fixing security agents in my cloud estate! Why do I say that? Because I sell things, because I sell things for a company that deploys an agent, there's no other reason. Because let's face it. Agents can be a real headache. Well, now Orca Security gives you a single tool that detects basically every risk in your cloud environment -- and that's as easy to install and maintain as a smartphone app. It is agentless, or my intro would've gotten me into trouble here, but  it can still see deep into your AWS workloads, while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets, no DevOps headaches, and believe me you will hear from those people if you cause them headaches. and no performance hits on live environments. Connect your first cloud account in minutes and see for yourself at orca.security. Thats “Orca” as in whale, “dot” security as in that things you company claims to care about but doesn't until right after it really should have.Corey: That doesn't get better with a lot of modernization. I mean, I feel like half of my job—and I'm not exaggerating—is introducing Amazonians to one another. Corporate communication between departments and different groups is very far from a solved problem. I think the tooling can help but I've never been a big believer in solving political problems with technology. It doesn't work. People don't work that way.Nigel: Absolutely. One of my earliest times working at Puppet doing, sort of, higher-level sales and services and support, huge national telco walk in there; we've got the development team, the QA team, the infrastructure team. In the course of this conversation, one of them makes a comment about using apt-get, and the others were like, “What do you mean? We're on RHEL.” And it turned out, production was running on RHEL, the QA team running on CentOS and the developers were all building everything on Ubuntu. And because it was Java wraps, they almost didn't have to care. But write once, debug everywhere.Corey: History doesn't repeat, but it rhymes; before Docker, so much of development in startup-land was how do I make my MacBook Pro look a lot more like an EC2 Linux instance? And it turns out that there's an awful lot of work that goes into that maybe isn't the best use of people's time. And we start to see these breakthroughs and these revelations in a bunch of different ways. I have to ask. This is the tenth year that you've done the State of DevOps Report. At this point, why keep doing it? Is it inertia? Are you still discovering new insights every year on top of it? Or is it one of those things where well someone in marketing says we have to do it, so here we are?Nigel: No, actually, it's not that at all. So definitely, we're going to take stock after this year because ten years feels like a really good point to, sort of—it's a nice round number in certain kind of number system. Mainly the reason is, a lot of my job is going and helping big enterprises just get better at using technology. And it's funny how often I just get folks going, “Oh, I read this thing,” like people who aren't on the bleeding edge, constantly discussing these things on Twitter or whatever, but the State of DevOps Report makes its way to them, and they're like, “Oh, I read a thing there about how much better it is if we standardized on one operating system. And that made a really huge difference to what we were actually doing because you had all this data in there showing that that is better.”And honestly, that's the biggest reason why I ended up doing it. It's the fact that it seems to be a tool that has made its way through to very hard to penetrate enterprise folks. And they'll read it and managers will read things that are like, “If you set clear goals for your team and get them to focus on optimizing the legacy environment, you will see returns on it.” And I'm being a little bit facetious in the tone that I'm saying because a lot of this stuff does feel obvious if you're constantly swimming in this stuff day-to-day, but it's not just the practitioners who it's just a job for in a lot of big companies. It's true, a lot of the management chain as well. They're not necessarily going out and reading up on modern agile IT management practices day-to-day, for fun; they go home and do something else.Corey: One of my favorite conferences is Gene Kim's DevOps Enterprise Summit, and the specific reason behind that is, these are very large companies that go beyond companies, in some cases, to institutions, where you have the US Air Force as a presenter one year and very large banks that are 200 years old. And every other conference, it seems, more or less involves people getting on stage, deliver conference-ware and tell stories that make people at those companies feel bad about themselves. Where it's, “We're Twitter for Pets, and this is how we deploy software,” or the ever-popular, “This is how Netflix does stuff.” Yeah, Netflix has basically no budget constraints as far as hiring engineering folks go, and lest we forget, their failure mode is someone can't watch a movie right now. It's not exactly the same thing as the ATM starts spitting out the wrong balance in the streets.And I think that there's an awful lot of discussion where people look at the stories people tell on conference stages and come away feeling bad from it. Very often, I'll see someone from a notable tech companies talk about how they do things. And, “Wow, I wish my group did things like that.” And the person next to me says, “Yeah, me too.” And I check and they work at the same company.And the stories we tell are not necessarily the stories that we live. And it's very easy to come away discouraged from these things. And that goes triply so for large enterprises that are regulated, that have significant downside risk if the technology fails them. And I love watching people getting a chance to tell those stories.Nigel: Let me jump in on that really quickly because—Corey: Please, by all means.Nigel: —one is, you know, having done four years at Google, things are a shitshow internally there, too—Corey: You're talking about it like it's prison. I like it.Nigel: —you know. [laugh]. People get horrified when they turn up and they're like, “Oh, what it's not all gleaming, perfect software artifacts, delivered from the hand of Urs.” But I think what Gene has done with DevOps Enterprise Summit is fantastic in how people share more openly their failure states, but even there—and this is an interesting result we found from a few years ago, State of DevOps Report—even those executives are being more optimistic because it's so beaten into you as the senior executive; you're putting on a public face, and even when they're trying to share the warts-and-all story, they can't help but put a little bit of a positive spin on it. Because I've had exactly the same experience there where someone's up there telling a war story, and then I look, turn to the person next to me, and they work at that same 300-year-old bank, and they're like, “Actually, it's much, much worse than this, and we didn't fix it quite as well as that.” So, I think the big tech companies have terrible inside unless they're Netflix, and the big enterprises are also terrible. But they're also—Corey: No, no, I've talked to Netflix people, too. They do terrible things internally there, too. No one talks about the fact that their internal environments are always tire fires, and there are two stories: the stories we tell publicly, and the reality. And if you don't believe me on that, look at any company in the world's billing system. As much as we all talk about agile and various implementations thereof when it comes to things that charge customers money, we're all doing waterfall.Nigel: Absolutely. [laugh].Corey: Because mistakes show when you triple-charge someone's credit card for the cost of a small country's GDP. It's a problem. I want to normalize those sorts of things more. I'm looking forward to reading this year's report, just because it's interesting to see how folks who are in environments that differ from the ones that I get to see experience in this stuff and how they talk about it.Nigel: Yeah. And so one of the big results I think there for big companies that's really interesting is that one of the, sort of, anti-patterns is having lots of different types of teams. And I kind of touched on this before about having confusing team titles being a real problem. And not being able to cross organizational boundaries quickly is really, really—you know, it's a huge inhibitor and cause, source of friction. But turns out the pattern that is actually really great is one that the Team Topologies guys have discovered.If you've been following what Matthew Skelton and Manuel Pais have been doing for a while, they've basically been documenting a pattern in software organizations of a small number of team types, of a platform team, value stream teams, complicated subtest system teams, and enabling teams. And so we worked with Manuel and Matt on this year's report and asked a whole bunch of questions to try and validate the Team Topologies model, and the results came back and they were just incredibly strong. Because I think this speaks to some of the stuff you mentioned before that no one can afford to hire an army of Kubernetes developers, and whatever the hottest technology is in five years, most big companies can't hire an army of those people either. And so the way you get scale internally before those things become commoditized is you build a small team and create the situation where they can have outsized leverage inside their organization, like get rid of all the blockers to fast flow and make their focus self-service to other people. Because if you're making all of your developers learn distributed systems operations arcane knowledge, that's not a good use of their time, either.Corey: It's really not. And I think that's something that gets lost a lot is, I've never yet seen a company beyond the very early startup stage, where the AWS bill exceeded the cost of the people working on the AWS bill. Payroll is always a larger expense than infrastructure unless you're doing something incredibly strange. And, oh, I want to save some money on the cloud bill is very often offset by the sheer amount of time that you're going to have to pay people to work on that because, contrary to what we believe as engineering hobbyists, people's time is very far from free. And it's also the opportunity cost of if you're going to work on this thing instead of something else, well, is that really the best choice? It comes down to contextualizing what technology is doing as well as with what's happening over in the world of business strategy. And without having a bridge between those, it doesn't seem to work very well.Nigel: Absolutely. It's insane. It's literally insane that, as an industry, we will optimize 5%, 3% of our infrastructure bill or application workload and yet not actually reexamine business processes that are causing your people to spend 10% of their time in synchronous meetings. You can save so much more money and achieve so much more by actually optimizing for fast flow, and getting out of the way of the people who cost lots of money.Corey: So, one last topic that I want to cover before we call it an episode. You talk to an awful lot of folks, and it's easy to point at the aspirational stories of folks doing things the right way. But let's dish for a minute. What are you seeing in terms of people not using the cloud properly? I feel like you might have a story or two on that one.Nigel: I do have a few stories. So, in this year's report, one of the things we wanted to find out of, like, are people using the cloud in the way we think of cloud; you know, elastic, consumption-based, all of these sorts of things. We use the NIST metrics, which I recognize can be a little controversial, but I think you've got to start somewhere as a certain foundation. It turns out just about everyone is using the public cloud. And when I say cloud, I'm not really talking about people's internal VMware that they rebadged as cloud; I'm talking about the public cloud providers.Everyone's using it, but almost no one is taking advantage of the functionality of the cloud. They're instead treating it like an on-premise VMware installation from the mid-2000s, they're taking six weeks to provision instances, they're importing all of their existing processes, they keep these things running for a long time if they fall over, one person is tasked with, “Hey, do you know how pet number 45 is actually doing here?” They're not really treating any of these things in the way that they're actually meant to. And I think we forget about this a lot of the time when we talk about cloud because we jump straight to cloud-native, you know, the sort of bleeding edge of folks in serverless, highly orchestrated containers. I think if you look at the actual numbers, the vast majority of cloud usage, it's still things like EC2 instances on AWS. And there's a reason: because it's a familiar paradigm for people. We're definitely going to progress past there, but I think it's easy to leave the people in the middle behind when we're talking about cloud and how to improve the ecosystem that they all operate in.Corey: Part of the problem, too, is that whenever we look at how folks are misusing cloud, it's easy to lose sight of context. People don't generally wake up and decide I'm going to do a terrible job today unless they work in, you know, Facebook's ethics department or something. Instead, it's very much a people are shaped by the constraints they're laboring under from a bunch of different angles, and they're trying to do the best with what they have. Very often, the reason that a practice or a policy exists is because, once upon a time, there was a constraint that may or may not still be there, and going forward the way that they have seemed like the best option at the time. I found that the default assumption that people are generally smart and doing the right thing with the information they have carries you a lot further, in many respects than what I did is a terrible junior consultant, which is, “Oh, what moron built this?” Invariably to said moron, and then the rest of the engagement rapidly goes downhill from there. Try and assume good faith, and if you see something that makes no sense, ask, “Why is it like this?” Rather than, “Why is it like this?” Tone counts for a lot.Nigel: It's the fundamental attribution bias. It's why we think all other drivers on the road are terrible, but we actually had a good reason for swerving into that lane.Corey: “This isn't how I would have built it. So, it's awful.”Nigel: Yeah, exactly.Corey: Yeah. And in some cases, though, there are choices that are objectively bad, but I tried to understand where they came from there. Company policy, historically, around things like data centers, trying to map one-to-one to cloud often miss some nuances. But hey, there's a reason it's called the digital transformation, not a project that we did.Nigel: [laugh]. And I think you've got to always have empathy for the people on the ground. I quite often have talked to folks who've got, like, a terrible cloud architecture with the deployment and I'm like, “Well, what happened here?” And they went, “Well, we were prepared to deploy this whole thing on AWS, but then Microsoft's salespeople got to the CTO and we got told at the last minute we're redeploying everything on Azure.” And so these people were often—you know, you're given a week or two to pivot around the decision that doesn't necessarily make any sense to them.And there may have been a perfectly good reason for the CTO to do this: they got given really good kickbacks in terms of bonuses for, like, how much they were spending on the infrastructure—I mean, discounts—but people on the ground are generally doing the best with what they can do. If they end up building crap, it's because our system, society, capitalism, everything else is at fault.Corey: [laugh]. I have to say, I'm really looking forward to seeing the observations that you wound up putting into this report as soon as it drops. I'm hoping that I get a chance to speak with you again about the findings, and then I can belligerently tell you to justify yourself. Those are my favorite follow-ups.Nigel: [unintelligible 00:37:05].Corey: If people want to get a copy of the report for themselves or learn more about you, where can they find you?Nigel: Just head straight to puppet.com, and it will be on the banner on the front of the site.Corey: Excellent. And will, of course, put a link to that in the show notes, if people can't remember puppet.com. Thank you so much for taking the time to speak with me. I really appreciate it.Nigel: Awesome. No worries. It was good to catch up.Corey: Nigel Kersten, field CTO at Puppet. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice as well as an insulting comment telling me that ‘comcastic' isn't a funny word, and tell me where you work, though we already know.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

This episode, me, Dave, and Steve discuss retard strength, Muslim years, and Olmec's sexy DSLs. This episode is dedicated to John McAfee. You will be missed forever. RIP --- Support this podcast: https://anchor.fm/olde-city-matt/support

Wade Graham comes off the bench to join the DSLs team for this weeks podcast and opens up about his concussion battle and his thoughts on the new NRL rules and foul play crackdown. Wade, Gus & Jude also have a chat with Newcastle legend, Mark Hughes and Sydney FC gun, Luke Brattan. And of course, Gus's unpopular opinion of the Winter Olympics being superior to the Summer Olympics sparks up some controversy as our listeners blow up the phones to roast Gus.  See omnystudio.com/listener for privacy information.

Wade Graham comes off the bench to join the DSLs team for this weeks podcast and opens up about his concussion battle and his thoughts on the new NRL rules and foul play crackdown. Wade, Gus & Jude also have a chat with Newcastle legend, Mark Hughes and Sydney FC gun, Luke Brattan. And of course, Gus's unpopular opinion of the Winter Olympics being superior to the Summer Olympics sparks up some controversy as our listeners blow up the phones to roast Gus.  See omnystudio.com/listener for privacy information.

The DSLs speak with heavy weight champ, Justis Huni ahead of his blockbuster fight with Paul Gallen.  See omnystudio.com/listener for privacy information.

The DSLs speak with heavy weight champ, Justis Huni ahead of his blockbuster fight with Paul Gallen.  See omnystudio.com/listener for privacy information.

Episode 26: Knife crime with Alison Cope  Alison Cope is the mother of Joshua Ribera, who was murdered in 2013 when he was stabbed with a knife outside a nightclub in Birmingham. In this episode of safeguarding days, I have the privilege of speaking to Alison about Josh, his death, and her work now to help prevent youth violence by sharing her son's unique life and death story to educate young people on the realities and consequences of youth violence. – a must listen for DSLs!Alison is on Twitter @Ali_Copeor visit: www.AlisonCope.co.uk

This week Anna (https://twitter.com/AnnaRRose) and Tarun (https://twitter.com/tarunchitra) chat with Andy Chorlian (https://twitter.com/andy8052). Andy recounts the many interesting moments through his crypto journey, including being at Maker during Black Thursday, living through DeFi Summer, and then jumping into NFTs with Top Shot and PleasrDAO. Taking a break from his degen career, Andy is now developing Fractional, a protocol for fractionalizing NFTs. He explains how it works under the hood and how the concept could bridge the DeFi and NFT worlds. Here are some links for this episode: An overview of the NBA Top Shot (https://www.gamasutra.com/blogs/EthanLevy/20210412/379292/Three_Ways_the_NBA_Top_Shot_Economy_Could_Collapse.php) platform to understand what it’s about. Andy’s NBA Top Shot stats (https://livetoken.co/community-tools/account?address=9b20c779622c945b&mode=activities) page. The WSJ article (https://www.wsj.com/articles/nba-top-shot-nft-crypto-digital-collectibles-11615266042) featuring Andy’s “messy” desk. Where Media & Music Meet NFT & Blockchain, Zero Knowledge Episode 167 (https://www.zeroknowledge.fm/167) featuring Andre Anjos (RAC) and Trevor McFedries (Brud). An intro (https://medium.com/@fractional_art/what-is-fractional-dd4f86e6458a) to Fractional The Snowden NFT piece (https://foundation.app/Snowden/stay-free-edward-snowden-2021-24437) If you’re looking for a job in the world of blockchain and zero knowledge, don’t forget to check out our Jobs Board (https://www.zeroknowledge.fm/zkjobsboard)! The board is updated right after each Jobs Fair, the next one of which is today! Register here for the Jobs Fair (https://docs.google.com/forms/d/e/1FAIpQLSe_plfJLa8IKoTzSkytgQkzzF4l4N4gaySVg9EBdlarI4-sKA/viewform) and here (https://hopin.com/events/zksessions-the-zk-languages-showdown) if you want to attend the zkSessions sister event. This will be our first zk-centric zkSessions for a full dive into DSLs and libraries for programming with ZKPs. Also, make sure to subscribe to our new Substack (https://zeroknowledge.substack.com) to be updated of any future zkSessions, Jobs Fair, StudyClub or another of our many initiatives. Thanks to this week’s sponsor, O1 Labs (https://o1labs.org), the creators of Mina Protocol Mina is the world’s lightest blockchain – powered by participants. Mina is a layer-one protocol, creating a private gateway between the real world and crypto. The entire chain is around 22kb — even as it scales, thanks to zk-SNARKs. The ecosystem is growing fast and Mina's mainnet has just gone live, offering users a platform to build a private gateway between the real world and crypto, visit minaprotocol.com (https://minaprotocol.com) to find out more. If you like what we do: Follow us on Twitter - @zeroknowledgefm (https://twitter.com/zeroknowledgefm) Join us on Telegram (https://t.me/joinchat/TORo7aknkYNLHmCM) Catch us on Youtube (https://www.youtube.com/channel/UCYWsYz5cKw4wZ9Mpe4kuM_g) Read up on the r/ZKPodcast subreddit (https://www.reddit.com/r/zkpodcast) Give us feedback! -https://forms.gle/iKMSrVtcAn6BByH6A Support our Gitcoin Grant (https://gitcoin.co/grants/329/zero-knowledge-podcast-2) Support us on the ZKPatreon (https://www.patreon.com/zeroknowledge) Donate through coinbase.commerce (https://commerce.coinbase.com/checkout/f1e56274-c92b-4a99-802f-50727d651b38) Or directly here: ETH: 0xC0FFEE1B5083230a5154F55f253B6b6ae8F29B1a BTC: 1cafekGa3podM4fBxPSQc6RCEXQNTK8Zz ZEC: t1R2bujRF3Hzte9ALHpMJvY8t5kb9ut9SpQ

Darin Haener is the President and Co-Founder at Fermentable LLC. FermentAble was created by a professional brewer who experienced first hand how frustrating it is to manage a brewery’s day-to-day operations.   We explore the science of brewing, how being in the brewing industry drew Darin to solve the problem Fermentable solves, and lots of lessons and discussion on bootstrapping and building a SaaS. We also dig into why to choose Ruby on Rails or similar DSLs and a lot of fun chat on the tech behind Fermentable. Check out Fermentable at https://getfermentable.com  Connect with Darin on LinkedIn to chat more: https://www.linkedin.com/in/darinhaener/  This episode is sponsored by Veeam Software and the 4-Step Guide to Delivering Extraordinary Software Demos that Win Deals and Diabolical Coffee

Recorded July 4, 2016Running Time: 02:44:04OPENING – Booker T Theme Song “Rap Sheet”Panel QuestionsTOPIC 1: Pre-show concertDid you watch? What major announcements were made if any?TOPIC 2: General NonsenseDid you watch alone in your room clutching to your oshi pillow in anticipation of your fave getting called up? Or were you huddled around a computer screen/TV with other wota in the same room?At what point during the show did you pass out? Or did you manage to make all the way to the end without falling asleep?How beat were you the day after? Did you have to work or have other commitments that were not as enjoyable due to your obsession with seeing young girls cry about arbitrary rankings?TOPIC 3: Election ObservationsOverall presentation of show? What did you think?Was this the year of the HKT lolis and lesser SKE members?Why did NMB get no love?Were you happy that the the lower ranked speeches were kept short and to the point? Or did this just prolong the agony for the long winded senbatsu speeches.BS Sky is great, but boo to them for cutting out just before senbatsu and making us watch the shitty Fuji TV feed instead.TOPIC 4: Election RankingsUpcoming GirlsCongratulations to Allen for correctly predicting that Murashige Anna would become 2016's Ms. Irrelevant.Who was ranked too low? Who was ranked too high? (*cough*KATOMINAMI*cough*)Are you sad that Myao ended up here? Any other surprises?Miyamae Ami is center, are you happy she is ending her SKE career in this manner?Future GirlsA great injustice has been done to Kitagawa Ryoha, too low. Agree or disagree?Nishino Miki finally ranks. Did you mark out in joyful celebration or scoff at this living convulsion taking up a spot someone else should have?Tani Marika drops 32 spots. What do you believe was the cause of this? Lack of BBQ? The known fact she likes living in eternal messiness? People just fed up with her? Better members to vote for this year? Why God why?Next GirlsSutou Ririka, Tanaka Miku, Ego Yuna and Team 8's lone soldier Kuranoo Narumi are the most notable debuts in this grouping. Who amongst these girls has the brightest future?Kizaki Yuria drops 15 spots into Next Girls. Has she peaked? Is it a downhill slide into obscurity from here?UndergirlsHow about that Yabuki Nako? Or are you team Miku and are loathing this placement?The Joker (Komiyama Haruka) makes a fairly high debut. Well deserved or too high?Takayanagi Akane drops out of senbatsu into undergirls. Expected or did you have that small glimmer of hope her fans would help her keep her spot? Is this also going to lead to a downward trend for her as well?Minegishi Minami is Undergirls center. Are you content with this? You think she gonna get all these bitches all on the Rizap workout and we'll have buff Undegirls who can lift cars?SenbatsuTakahashi Juri, Okada Nana, Mukaichi Mion and Kodama Haruka bring freshness to the senbatsu. Mukaichi Mion makes a huge gain from last year's ranking (31 spots). Believe in the DSLs. Okada Nana discusses her eating disorder and her resolve to overcome. Depressing speech or inspirational? Haruppi's pain has ended. Praise Jebus she is in senbatsu. Lastly, yay for dead eye. Muto ends up not being the odd girl out and ranked up. We were wrong on that one weren't we?Speaking of being wrong, Paruru does not drop out either. But she does say she will no longer participate. Thoughts?Suda Akari's hair. Short ain't a good look for her. Agree or disagree?Matsui Jurina and Yamamoto Sayaka rank up while Kashiwagi Yuki falls to 5th. Should we consider Kashiwagi as another who will trend down? Neither Jurina or Sayanee get close to Mayuyu's number of votes. So much for someone breaking the trend of 2 people dominating the top huh?Watanabe Mayu fears that AKB is in crisis because all the old hags are leaving. Do you agree or have you moved on to the next generation of members who will carry the group forward?Sashihara Rino bests Watanabe Mayu by 67,398 votes becoming the first back to back winner and also first 3-time winner. She also breaks the 200,000 vote barrier. Do you think any member will be able to top her or is this the beginning of an Undertaker-like streak?TOPIC 5: Final thoughtsWere you satisfied with the results of this year's election? Why do you think so many people get so much butthurt when Sashihara Rino wins?What kind of song do you expect for the Sashihara led single? Will this follow the pattern of years past where they make a dance type video that staff and people all over the world copycat or has that become a little cliche?Any other random tidbits you'd like to mention before closing podcast?ENDING – AKB48 – 翼はいらない