Today we talk with Dejan Miličić, a consultant with more than 20 years of experience as a professional software developer with RavenDB. His areas of expertise are designing, writing, and maintaining applications, with a focus on software architecture and backend development.

Dejan discusses the challenges and benefits of NoSQL databases, and what he has learned along the way to simplify and reduce the time required to make changes. We also talk about ways to approach different types of NoSQL databases, and how they should be used.
On YouTube
NoSQL and RavenDB - JSJ 530

Sponsors

Links

Picks

Special Guest: Dejan Milicic.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: Howdy, howdy from gray Portland. I've got a host here that says AJ isn't here. Yeah. He's just unmuted and then remuted. So he must not be here. I'm Charles Max Wood from Top End Devs. And this week we're talking to Dejan. Uh, do you want to introduce yourself? Just let people know who you are and why you're famous. 

DEJAN_MILICIC: Yeah. Thank you. I'm not famous. I'm trying not to be I'm a developer. I'm now in the third decade of my professional experience. And at the moment for past eight or nine months, I'm working as a developer advocate for RavenDB. 

CHARLES MAX_WOOD: Oh, cool. 

 

Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv top end devs, but what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with devchat.tv and I renamed it to top end devs because I want to give you the rAJajesources that are gonna help you to build the career that you want. Right? So whether you wanna be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I wanna give you the resources We're going to have career and leadership resources in there, and we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

CHARLES MAX_WOOD: So yeah, that, that explains, uh, you wanting to come on and talk about NoSQL databases and stuff like that. Do you want to just explain what RavenDB is and then we can kind of backfill into NoSQL and what it is and why people care and all that good stuff? 

DEJAN_MILICIC: Sure. RavenDB is NoSQL database. So in general terms, NoSQL is not negation. It's short for not only SQL. And this category of the database is emerging in 90s where companies like Google Yahoo started solving really hard problems. So they had to develop new ways to handle large data. And RavenDB emerged around 2009. We can talk a bit later on how it was born from frustration. So 13 years later, second-generation multi-model NoSQL database. 

CHARLES MAX_WOOD: Gotcha. Yeah. It's interesting, right? Because I remember that it kind of hit its heyday for a while. People were using like MongoDB and CouchDB were kind of the ones that I kept hearing about. And then you've got Cassandra and Voldemort and a bunch of other ones, right, that all do different things and they seem to be kind of optimized for specific problems. And then, I don't know, SQL kind of got its Renaissance, right? Where people realized, you know, most of the stuff I was trying to do with Mongo, I can do with SQL, but there still seem to be quite a few people out there who are looking at some of these no SQL options and having it add up to something that makes sense for them for whatever reason to use a NoSQL option. So I'm curious as we kind of dive in, yeah, what kinds of problems, if I'm facing this, that, or the other, am I gonna be looking at something like a RavenDB or a MongoDB or one of these other options out there and going, you know, I'm gonna use this instead of my typical SQL database to solve my problem and...What is it about those that makes them a good fit for those problems? 

DEJAN_MILICIC: So I can approach this from my personal side. I was a developer using SQL Server and MySQL for a long period of time. And eventually I ended up as a C Sharp developer using Entity Framework. So Entity Framework is ORM. And I noticed following pattern on every single project I was doing. I complete it and it turns out 80% of the code is working fine. And the like remaining 20% is, is making problems for me. And my first instinct of course is I'm not doing something right. So I'm not expert in this. I need to learn more. I need to, to, to, to go on and talk to people who are really experts. And then I started meeting other people, other developers who had the same problems. So usually as C-sharp developer, which I am, you end up going taking those 20% of your code, introducing something like Dapper, writing SQL queries and commands by hand and replacing that. And this works, but it actually brings whole house down because you don't have this nice modeling automatic generation of SQL anymore. Migrations are hard. It's a little problem. And I also noticed time I'm reaching for the red is more and more by default. So I'm starting new project. And I'm immediately thinking, will this be slow? Will I need Redis? Let me put Redis right away. And it's, it's a bit like, maybe it's too harsh to say you get a bit insecure about yourself as a developer, but I was feeling a bit like that. So, uh, I was feeling you, you need to be really, really devoted to the database to, to be able to produce really high quality solutions. 

CHARLES MAX_WOOD: Right. I've kind of heard the argument from some people that if you run into speed issues with the SQL database, like PostgreSQL. A lot of times you're just, you haven't set up your indexes right, things like that. So how do you know if it's that kind of a performance tuning that I can just do on a SQL database versus, hey, you know, I really ought to just have a look at one of these other systems that seem to solve this problem. 

DEJAN_MILICIC: So the thing is you want to have something that's called bit of success. And the bit of success is like a setup of technologies you're using, which are guiding you. Tour success. It is true that you can go and introduce indexes and fine-tune and observe and you spend lots of time on it So part of the story behind Raven DB is precisely that guy who Created Raven DB or an E. Most people know him by his blogging name. Ayende He was developing and hibernate. He was participating as a developer on an open source and hybrid project. After that, he started working as a consultant for companies using relational databases. And after a certain period of time, he figured out that developers and companies are repeating same mistakes over and over again. So his first instinct was okay, as I'm usually joking to be a good developer, you need to be a bit lazy. So what you try to do, you try to optimize. So first instinct was to create the application or let's say profiler, which would be detecting these anti-patterns that developers are creating, like select them plus one or queries without index, things like that. And then he got like really frustrated about the state of the things. And he was inspired by the Couchbase and he started thinking what could be ideal database or what could be a database that is preventing all these problems. So instead of solving problems this way or the other, let's try to produce system which is preventing you from creating problems. So I can give you one example, a conscious design decision with RavenDB was to disallow to make it impossible to run query against raw data. So all your queries are always going through indexes. So what happens if you don't create index? Well, RavenDB steps in and create one for you. 

CHARLES MAX_WOOD: Okay.

STEVE_EDWARDS: So is that a permanent index or one just sort of a transient index that's there for the duration of the query? I mean, if I query against something, a table that doesn't have an index, and you said Raven creates one for you, does that store that permanently in the database? And so it's there the next time? Or is that just sort of a transient index for the life of that query? 

DEJAN_MILICIC: So general strategies to produce grownup database, as we like to say. So database without the need for a nanny. So we...think we like to think there is no such position as a full-time DB administrator for RavenDB. So speaking about the automatic indexes, whole story is that RavenDB again tries to optimize things. So you have some settings which you can change, but with default settings, automatic index, if not used for some time will become idle. And after period of idleness, it will be completely wiped out. So if you don't, if you don't, so your query will trigger index creation. If your application continues to use it, it will be active and catching up new documents, things like that. But if this was one time only for like some ad hoc data investigation, after some time it will become idle and after some time in idle state, it will be removed. 

STEVE_EDWARDS: So is that a setting then where you can set your time parameters, you know, keep this for a day or a week? 

DEJAN_MILICIC: I think it's 72 hours is default. So if you run it after 72 hours, if there's no queries again, which are using this index, it will be completely wiped out. 

CHARLES MAX_WOOD: So my weekly report then would reconstruct the index every time I run it. Specifically, yeah, hold on to this longer. 

STEVE_EDWARDS: So then how does that work? If you let's say it's a crazy on the fly and you decide, okay, I want to keep it. And I assume you can go in and save that index to become permanent. Or maybe just stretch out the time, the default time value. 

DEJAN_MILICIC: You would change the full time. You cannot. So you have two classes. One are automatic indexes. They are managed by the database. And then we have so-called static ones, which you program in programming language of your choice, let's say in C sharp or Java, you inherit Epser class. You program it. And this is static index, which is not touched by the, by the data. So it won't be deleted, it won't be idled. You took control over index. But if you don't take control over index, if you let database create it, then database will match. 

STEVE_EDWARDS: So if it's in the code, so if it's in the code, then does that mean that, let's say it's in your code and you don't use that query for a while because for whatever reason, that particular procedure isn't used in your application very often. So then the code is gonna generate that index for you in Raven, that's what you mean by it's controlled by the code? 

DEJAN_MILICIC: Yes. So you code it as a class, you deploy it, and there it is. It's completely managed by you. So it's your choice if you're going to delete it or keep it or expand it with additional fields, things like that. 

STEVE_EDWARDS: So I'm gonna guess that the Raven must be somewhat efficient in terms of building the indices if you're building them on the fly and deleting them on the fly like that. 

DEJAN_MILICIC: It's quite capable. What I like especially when you download it, if you want to install it on your machine, it's like, 82 megabytes archive, which you unzip. And this database, which is zipped into 82 megabytes can run a database which is like 15 terabytes in size. You can run huge clusters, things like it's, you could say it's really scalable. So you, this is something you can use for your, your own hobby project, or you can set up cluster consisting of like 30,000 nodes communicating together. 

CHARLES MAX_WOOD: Interesting that kind of opens up the scaling argument, you know, as far as like, I've seen all kinds of different schemes for scaling, you know, different kinds of databases. Some of the databases have, I guess, better mechanisms built in for this than others, but yeah, that's interesting for sure. One thing that I'm kind of curious about though, is that you kind of mentioned that this database is sort of a self-optimizing database, right? So it watches what queries you're making and then it'll create the indices and things like that, like we're talking about. What other optimizations does it make? Like if I'm making other queries into the database beyond indexing, are there other things that it does for me automatically? 

DEJAN_MILICIC: Yes, so I already mentioned automatic indexes. As you're running your queries, some of these indexes will be merged together. Then if database detects that indexes are overlapping, some of them which are obsolete will be automatically removed and your queries will still be served. And then there's lots of like internal reconfiguration happening as you use. So for example, if you're running RebinDB on a machine where memory is larger than the dataset, it will, it will bring up whole dataset into the memory and it will serve your queries from the memory completely. It will be still possessing your, your rights to the disk but the reads will be served directly from the map. And this is happening automatically without a need to touch anything. Then it's also about observing which queries are more frequent and allocating more CPU and more memory to these frequently repeating queries. Then it's also about the cluster. So if you have cluster of, let's say three nodes, you have option to say, I would like to work with the fastest node. So once per minute, RavenDB client as a part of your application will measure latency and it will pick up the fastest node to work with. If this node goes off, you will have hot failover to next node in predefined scene. So lots of things are happening behind the scene based on the actions that you undertake towards your database. 

CHARLES MAX_WOOD: That makes sense. 

STEVE_EDWARDS: Hey, Chuck, can we step back a minute? I wanna do some clarification. It seems like...In our initial introduction, I know at least in my brain, I've always sort of grouped NoSQL databases as the same thing. You know, Mongo's with Raven. I was talking with AJ ahead of time and he was saying that Mongo is not, Mongo is not a document database the way Raven is in terms of how it deals with caching. Is that true or false? How would you, would you differentiate between Raven and Mongo in terms of their structure and how they work? 

DEJAN_MILICIC: Probably the biggest difference is inside of the Raven DB, you have actually two databases. One is KeyValue Store, so you read and write, and the other one is Lucene.net. So all these indexes are built inside of Lucene and served from Lucene, which means that out of the box you are getting full-text search, spatial indexing, suggestions, highlights, everything that Lucene offers. 

STEVE_EDWARDS: Yeah, okay. So that's now that's cool. That's interesting. I say that as someone who spent many years working with Apache Solar. which is based on Lucene. And currently with the stack at my current day job, we use Elasticsearch with MongoDB, which is built, and Elastic is also built on top of Lucene. So yeah, Lucene is definitely the way to go from a search standpoint in terms of giving you key value storage, speed and indexing and that kind of stuff. 

CHARLES MAX_WOOD: Yeah, it's interesting too, because when I think of document database, I'm thinking more along the lines of MongoDB, right? Where you have like a...pseudo structure, I guess, right? Where you, it's schema list, but you know, you have the, the keys for each value or column, I guess, for lack of a better way of putting it. They don't really do columns in the same way SQL databases do, but right, but for each value on your object. And what you're saying is, is that you, you just stick it in a key value store and then you build search indexes off of it with Lucene, which would make it super fast.

DEJAN_MILICIC: And you store it inside of internal storage engine, which is like optimized. So for example, there's internal format, which is called political where you can access properties of your document in non-streaming manner. So you can just pinpoint and so indexing process can pinpoint and take just specific value and index it. 

CHARLES MAX_WOOD: Right. 

DEJAN_MILICIC: So if you're fetching by the key, you get whole JSON from the key value store, which is super fast. If you're querying, then your queries are always going through indexes. And this is fast again, because you are picking up from the disk engine, will pick up pre-computed results. So what is interesting that you want to, again, to be resilient against large data volumes. So let's imagine you have e-commerce store and you are calculating some aggregates for the daily sales or the monthly sales, something like that. So aggregation will be done once. Results will be stored on the disk. And it then it doesn't matter if you have 100 shoes sold or 100 million shoes sold, because aggregates will be computed once stored in the disk, and then queries are just filtering pre-computed results. 

STEVE_EDWARDS: So does Raven do the aggregation by default somehow, or I would assume you would have to tell it how to aggregate it because you're going to want it in a certain way, right? That's one of the benefits of Elastic is I know that we use this. It handles aggregation, something we use quite extensively.

DEJAN_MILICIC:Yeah, for simpler aggregations and simpler operations, you can run queries and automatic index will be produced. But if you want to take more control or to use advanced aggregations, then you write map reduce index on your own map phase, which is producing indexing entries and then reduction phase, which is like performed recursively in several steps. So originally MapReduce was developed by Google and run 95, I think. And it was developed as a technique to take petabyte scale of data and run it across data farm in parallel. So it's like massively parallelization of data processing. And same technique is applied here on only on the microscale. So you're doing this parallelization on the CPU threads. 

CHARLES MAX_WOOD: So kind of talking through how this all works, I guess the question comes back to When am I going to want to pick something like this over, you know, just stuffing my data up into a PostgreSQL or something like that? 

DEJAN_MILICIC: Well, I would now jump to one of my favorite topics, which is domain driven design. I think this is great technique. So, uh, if you're going, for example, with domain driven design, or if you're really trying to model your business domain or whatever domain may be in, in a good way, then with document database in general. So whatever document database you pick, you can develop your business domain model, store it directly into the database, which is important because you eliminate ORM. You eliminate this translation between object graph in the memory and the tables in the database. You're not translating back and forth anymore. You don't have this impedance mismatch anymore and hold persistence layer is gone. So less programming. You just work with one set of data structure and you just throw them at the database and database knows how to store collections without you going and splitting it artificially into like tables because a relational database cannot hold a collections. So I think this is the biggest, biggest advantage. So when you're speaking about NoSQL databases, it's not about the speed or indexing, it's also about developer experience. And if you think about it, you develop project for a year. And then for 10 or 15 years, you exploit. So if you think on the grand scale, like developing phase is like 10% and the maintenance and the life cycle is like 90% of the time. So if you make a change, changing things easy, you will, you won't hesitate to modify your code, data model, et cetera. Which means that this agility, holy grail, everyone is pursuing is actually about the, how easy it is to make change. In my career, I had cases when customers come to me and ask something very simple, and I go mad because I know it will take me three days. And then I start thinking, is it normal for like two sentences requirement change to result in three days of work? It's not. This is an indication that I was doing something in a suboptimal way. So when I switched to NoSQL databases, I noticed things like these are gone. Of course, I'm not saying that you cannot do wild things in NoSQL databases. There's a nice story about an early customer of RavenDB who took the notion of document databases quite literally. And he was complaining about performance. When support looked into the case, it was actually that the whole database was a single document. Oh. So it was like document databases literally. Those were the early days of document databases. So you're not...you're not prevented from making problems or challenges, as people would say, as people would put it, but you are somewhat more directed towards elegant, simple solutions. Because if you think about it, or if you start reading literature, you run into the notions of essential complexity and accidental. Essential complexity is the complexity of the domain itself, and accidental complexity is what all this mess that we developers introduce around the actual domain that we are in. So if you have many moving pieces, if you put Revit in front, you need to know when to invalidate it. If you use several layers of abstraction, you need to update them all. You need to do a translation between boundaries of the subdomains, things like that. If you switch to microservices, right away you introduce huge amounts of accidental complexity, you need to change the way you are testing things. Otherwise, you end up with distributed monolith, which is even worse than monolithic monolith. So you need to cover the cases where if one component of the system or one microservice of the system fails, not to have cascading failures. And also, when you look at it again, you have polyglot programming movement in the 90s. And on the wings of that, we ended up with projects where you have microservices which are implemented in different languages. Because if you're doing like machine learning, it's highly probable that you will go with Python and you can mix various languages in one project with microservices. And microservices are actually maybe even more about team organization than actual technical choices. And then based on that, you should also go and pick up the best persistence mechanism for each of these microservices. So if you have a need for full-text search, you should go and pick up the right tool for that. And there's nothing wrong with going with multiple strategies for data persistence. 

CHARLES MAX_WOOD: I don't know. I mean, everybody talks about microservices like they are the absolute bomb. They'll solve all your problems. And I think in some cases, especially you're talking about domain-driven design and-and the way that some of this stuff comes together. I can kind of see my way around to having a few services, again, depending on how the domain actually appears, right? How things interact across the knowledge domain, as opposed to splitting it up, you know, like you said, you know, according to the organization that is building it. But yeah, you add a whole bunch of complexity because you have that communication medium in the middle of it. that you have to figure out and you have to make sure that everybody knows how to talk to everything else. Whereas typically if you're within the same framework or program, then the system kind of handles a lot of that for you. And I'm not saying that one is necessarily a poor choice, but it needs to be a deliberate choice based on the actual interactions that occur within your application and how you want that to work. But yeah, then you can start making choices. But I've also seen apps where they, you know, they have like a they use both Mongo and Redis and PostgreSQL and something else, right? And they just have the different drivers in there and then their different systems. You know, it's like this piece talks to the Redis database and this piece talks to the, you know, the, the Mongo database and that, but they have distinct reasons why they've picked those. And so I think that's kind of what you're talking about. It's just knowing, Hey, look, you know, this, this data, this behavior is best suited to the structure. 

DEJAN_MILICIC: I usually go with the rule of thumb that I need to be able to explain to myself if I'm using certain approach or certain piece of technology, which problem it is solving. And I'm calling this driving on autopilot. I don't want to be driving on autopilot. I don't want to have cookie cutter and produce every project in the same manner. So if I cannot defend this decision in front of myself, then I'm thinking, okay, I'm not going to use. And this comes to the databases as well, if I'm not able to provide clear explanation. So When I was leading teams, it was never, okay, I'm the boss and I'm tech lead. You need to accept my decision. If I'm not able to defend or explain my decision so that everyone agrees or like confirm that I'm thinking right way, then we're not going to use that. 

CHARLES MAX_WOOD: Yeah. I'm kind of in the same boat where typically I'm picking like a PostgreSQL backend database and I kind of have a set of defaults that I'm using. And then, yeah, if I deviate from that, it's because I can actually justify it with a real reason to do so. Otherwise, yeah, it seems a lot simpler just to kind of keep everything in the same place. 

DEJAN_MILICIC: And it's also like sociological aspect to it. If you have a team and the team members are proficient in post-grade, that's probably what you're going to go with. 

CHARLES MAX_WOOD: Yep. 

DEJAN_MILICIC: So it's, technical decisions are not, are not just technical decisions. They are like multifaceted decisions and you have to live with consequences. And I know...couple of developers who are praising microservices only for me to find that they went through like three companies in five years. They were developed, so they developed microservices project and when once it's launched, they moved to another company and they don't have to live with consequences of their choices. 

CHARLES MAX_WOOD: Right. 

DEJAN_MILICIC: To AM calls and things like that. 

AJ_ONEAL: Can y'all hear me now? 

CHARLES MAX_WOOD: Yes. 

DEJAN_MILICIC: Yep. 

AJ_ONEAL: Okay. tried to butt in a few times now. Anyway, on the subject of microservices, I would like to point our listeners to Ethan Garofalo, who gives, I think, really good explanations about how to architect. Because, like was said earlier, if you just have a distributed monolith, then you're worse off than having a monolith. And a monolith is not necessarily bad, and microservices are certainly not necessarily good. When it gets to the point where A single developer can't run the system on their machine or on a VPS because there's dozens and dozens of keys and services. At that point, you better be pretty big enterprise because if your startup needs 12 different services in order for your social media app to work, then you're really over engineering it but not actually over engineering it because it's not engineered well. 

CHARLES MAX_WOOD: Yep. So I did want to kind of switch gears here a little bit or maybe go multimodal on this podcast episode. There's a pun, but you mentioned that, uh, that Raven is multi multimodal. 

STEVE_EDWARDS: Sorry. It's a little late on that. 

CHARLES MAX_WOOD: It wasn't really late than ever. Right. Um, and, and I've seen this right where, yeah, people reach for the key value store database for certain things. And then they reach for the document database for certain things, or they reach for I've heard Cassandra explained in  a couple of different ways, none of which really had any meaningful application for me. But yeah, how do you approach the different types of NoSQL databases? How do you feel like each of those should be used if I'm starting to make these deliberate choices? Hey, I'm using the default whatever I normally use and it's just not doing what I need it to. Yeah, how do I go about looking at some of these other options to say, maybe this is going to set me up for success?

DEJAN_MILICIC: So I think, again, every decision should be completely conscious and you should think, okay, what problem I do have here and what's most appropriate solution. When I say most appropriate, not necessarily the best because you should also look at the price and the learning time and the maturity of the technology. But with multimodal databases, they are sometimes called second generation NoSQL databases because they started with the single. So you have four major categories of NoSQL data. Key value stores, document databases, graph ones, and the Y column store. So the Cassandra is, for example, Y column store. And most of them started from one category and then they started expanding to other ones. So for example, all of them are essentially the key value store, because that's most basic functionality. But if you just need key value store, probably Redis is solution for you. You're probably building some kind of caching mechanism or coordination between a web farm machine, things like that. Now RavenDB over years, and this is something I like. New things were not invented by the iVertar architect. They were precise requests by people who were using, who were running into problems. And then answers to that were introduction of, for example, ability to store time series data, ability to store binary data as attachments, so Raven you're not mixing JSON documents and zip files or photos. You have concept of attachments. So you in the same manner as you would do with the email, you attach binary files with JSON documents. And these binary files will be isolated from JSON documents, but related. In other words, if you upload 15 gigabytes of video files, this will not choke your access to the JSON doc. So again, it comes to the choice of most appropriate tools. So if you have seven or eight ways to model things, then you have better opportunity to choose the right solution to your problems. So if you have Internet of Things project, if you need to accept and store and later on analyze trends for hundreds of thousands values per day or per minute, you can store that into a relational database, but the better solution is to find So again, yes, you can do, you can use assembly and write web website, e-commerce website. There's no technical obstacles, but what you need is to actually have life where you will devote yourself to actually building application, not wrestling with the technology. So if you need to store a stream of devices sending GPS coordinates, if you're building like a shipping company tracking of the trucks, you can...You can use relational database, but you can use also MongoDB in document mode, but it's way better to use most appropriate tool for that, which would be time series supported database. And then it's also the case of if you, for example, using CQRS as approach, you want to separate models for writing data and reading. So when you're storing, you're storing documents from your domain model. When you're reading, you essentially need some kind of equivalent of view models. So you want to combine data from different selections or tables into, into one single view model. And then if your database can support that, it will like, will be more pleasant for you. So instead of joining eight or nine tables, you go and use like, for example, RavenDB has projections where you can use JavaScript on the server side to create projection to execute code and you get your view model directly from the database. You just need to throw it to the view and render it. 

CHARLES MAX_WOOD: Gotcha. 

STEVE_EDWARDS: So I got a question in terms of clients. So looking at the Raven documentation, the different client libraries that are API's that are C or C sharp, Java, Python and Node.js. There's also Go and PHP under development. That's where I was going. As someone who works with Laravel quite a bit, I was going to ask you about PHP options as well. 

DEJAN_MILICIC: PHP is coming, but the interesting detail here is, again, design decision, conscious one, was to reuse existing technologies and protocols whenever possible. So, communication protocol for RavenDB is HTTP. There's no proprietary protocol. We are leveraging HTTP. And then, as a result of that, sometimes RavenDB server will...respond to your queries with 304 not modified. I hope it's 304. I'm keeping mixing 302 and 304. Well, so database will respond 304 not modified empty payload on the body. You're already holding the latest results and go ahead and use it because RavenDB is leveraging eTac. So every result that So client, RavenDB client will send query again and e-tag basically saying to the server, here is my query and here is e-tag which is marking results that which I'm already holding. And then if there were no changes in the meantime, if response is the same, server will just respond not modified. Go ahead and use what you already. And these are small details, but they are like free lunch coming from the decision to use HTTP as a product or very important thing. If you look at the data breaches lately, they're not hacking anymore. It's walking through the open door because you have Elastics earch, for example, set up and it's unprotected. These data breaches are walking through the open doors. Again, the reasoning was like this. We are using HTTP as a protocol and we will protect it for sure always, so we are going to use HTTPs. And then since we are using X. Five or nine to protect our HTTP traffic, let's use this same certificate as authentication means. So there is no credentials. Instead, you are using X five or nine certificate to identify yourself. That way you're eliminating credentials completely. You're eliminating like default credentials, which needs to be changed. Whoever installed any relation database remembers you have a light administrator account and you need to either set or change password after installation is done. So what happens if you forget to do it? If you have with SQL Server, if you have SA or something like that, SA empty or SA password. You see security. 

AJ_ONEAL: So for the web developers in the room, SA is the Windows version of root. 

STEVE_EDWARDS: System admin, right? 

DEJAN_MILICIC: And also when you think about it, The security is more or less done thing. We know what works. When you log into your e-banking, it's completely protected. Everything is functioning nice. So then when you look at the design of system that would be secure, it's about decisions what to use. So if you need to spend two hours securing your cluster after you installed it, if you need to read 40 pages of the manual, or if you need to bring over experts on security to protect your cluster, you have non-technical weak points. So precisely for that reason, the conscious security design decision was made to make everything secure by default. So by default, all requests not coming over HTTPS are rejected. All requests without certificate are rejected. There's no default ports which are open. You would have to close. So this is also part of overall security and you're

 

So folks, I'm here with JD from Riga. JD, you guys get like a billion errors a month. What are some of the more interesting errors that you've seen over the years? Oh, that's a good question. We certainly deal with a lot of errors. A couple of things come to mind. When we very first launched and we kind of expected, you know, we'd see some people sign up and try it, we actually got one of the top 10 Facebook games. Remember when they were huge? Yeah. And so they, one of the top 10 Facebook games, and it was between us, one of the most buggy bits of software I've ever seen. And so it managed to completely blow us off the internet and like our first week of launching. So we, we sold that. That's why I couldn't win at poker. Those farm bill animals. Yeah. And there was another, another one always sticks in my mind because obviously we, we track JavaScript and just like with mobile era. crash reporting, you can't access the end user's browser console to see errors. So you really want to track that and report it. And I remember this one customer, and they had this really fancy animation on the cursor on their website. And unfortunately, their JavaScript to do that, they deployed a bug with it, which meant that on every single mouse move event of every single customer they had, would send an error report to Raygun. So, you know, working at Raygun is like dealing with a constant distributed denial of service attack and doing it with style. So, if you want to know what kinds of interesting things are going on that you're not seeing in your app, you have to check out Raygun. They're doing a free trial right now. You can get it at raygun.com. 

 

AJ_ONEAL: I actually want to go back a little bit if it's an all right time to jump. I have, I like what you're saying about Raven in terms of automatically creating indexes and...automatically doing this, that, and the other. And I did miss a really important part where you were talking about some specific differences between Raven and Mongo and potentially something else. You started to say that and I had an internet problem. So I missed some of that context. But what I have wanted has been essentially what I see as the problem with GraphQL is that what we needed is somebody to standardize how to do nested queries with REST and how to give a good standard with REST for this is how to get basically your initial object and this is how to cherry pick keys. We just need a syntax for that. We didn't need an entirely new technology. We just needed somebody to kind of provide, okay, use dots, use square brackets, that kind of thing. We didn't need a whole new complex server. And with Postgres, It seems that, yeah, and I think in some cases, these tools do exist. They're just not very popular, but I really don't want a new database. I just want something on top of Postgres. That's a little client layer that when I, like you said, I make a select on something that was an index that it just does a quick alter table and puts that index in there and, and I want the ergonomics of Postgres to be better. But I don't really, I have a hard time believing that there's some sort of, you know, technology that over the past 30 years of databases that we somehow discovered that's new, it just seems to be ergonomics. So with Raven, why not just provide ergonomics over an existing database? Why create a whole new database system? What, what, what's the pull on that? Or is it just that it's too hard to market that ergonomics layer? 

CHARLES MAX_WOOD: Hey AJ, I think you should call it post post-CrescueL.

AJ_ONEAL: All right, Steve, where's your where's your 

CHARLES MAX_WOOD: no, it's all good. 

AJ_ONEAL: Go ahead lunch. Sorry. 

STEVE_EDWARDS: Sorry 

DEJAN_MILICIC: So what you just stated actually happened 

STEVE; there we go better late than never sorry, Dan 

DEJAN_MILICIC: So what you just stated actually happened if you if you're aware of the Martin Martin is layer on top post-gred and actually Author of the Martin was using Raven DB and then decided to go and build same economics layer on top of post-grade. There are a couple of things that I think are important. 

CHARLES MAX_WOOD: How do you spell that? 

DEJAN_MILICIC: M-A-R-T-E-N. So this would be like document-like, document database-like layer on top of post-grade. So storing JSON within the post-grade and providing various capabilities on top of it. 

CHARLES MAX_WOOD: Okay. 

AJ_ONEAL: So also you're using document database in a different way than I'm familiar with it. Because I'm thinking of document database like CouchDB, as in literally it's documents and you're building out your caching layer, you're doing your queries ahead of time and you're providing documents. Whereas you're using document database just to mean something that's optimized for JSON, I think. 

DEJAN_MILICIC: Not necessarily for JSON, but it's more like you start modeling in Java or C Sharp or Python your domain model. You do that in the best tradition of domain driven design being completely persistent, unaware or not putting DB at the center of your process, of your modeling process. This is what I'm seeing across companies. We start new project, we draw on a whiteboard, they draw boxes and I'm living in a dream that they are doing modeling. And then when I see FK, I know we're doing. FK is a foreign key, they were modeling database all the time. So first important thing here is that you are detaching yourself mentally from the data. Leave it for after. There won't be problems. You will be able to store it efficiently, query it efficiently. Just free yourself up, go and model your domain. 

AJ_ONEAL: Well, you still have to do migrations. You still have to pull every row out of the database and put every row back in. So yeah, you can improve the ergonomics around that. But it's not just, oh, don't worry about the database, go build your data because no matter...You know, you're going to handle the complexity here, you're going to handle it there, but a human is going to handle that complexity. 

DEJAN_MILICIC: I agree, but what matters is the moment where you pay your attention to the data. So whole process, in my opinion, should start with modeling abstract domain. After your modeling is done, now you start thinking about how to persist that, and then you decide, okay, am I going to store it as it is? Am I going to remodel it a bit? How many subdomains are touching my object? If too many of them are touching, maybe this is a sign that I should isolate into subdomains, which may or may not later become microservices or some logically detached things. But as I said, reversing things. So instead of first thinking about the database and persistence, because you are bearing the scars of many projects where you suffered, you free up yourself, you go and model it, then you see if you need to, if you can store it as it is if you need to model it a bit, if you need to reshape it a bit to accommodate persistence storage of your choice, or you need to develop a completely separate persistence layer for sorting. 

AJ_ONEAL: I think I agree with that. And I think that there's some project Amy was talking about once that I think has become fairly popular. It's some sort of pure JSON database, not meant at all for production, but just meant for getting a prototype out where everything stored as JSON files. JSON REST, I think it might have been called, something like that. Do you like that kind of idea of a project? 

DEJAN_MILICIC: So here you should look at the JSON as a choice of the format in the function of serializing things over the wire. So you build... 

AJ_ONEAL: What other format could you possibly use? 

DEJAN_MILICIC: Well, you could use whatever you want. Like MongoDB, Invented, Vson. 

AJ_ONEAL: Oh, but that's just JSON. I mean, that's not different from this. 

DEJAN_MILICIC: Yes, but the story is following. Uh, Jason is a proper format, which is also widely used. And it's used internally. And we are, uh, RavenDB is also transferring that to binary format. Uh, at the very end, but in some way, uh, when you work with the database, it should be kind of black box. So you throw your object graph at it. Database is able to store it and later on efficiently deliver either these same objects to you or create projection, which is combining properties from different objects. So if you have, I don't know, typical boring business case of purchase order, you need to display company name, company address, product names. And this this is combined from three, four or five collections or tables. 

AJ_ONEAL: Yeah. But I mean, Raven can't make that choice of how to decompose it, though, right? I mean, I guess you could do something to automatically say, oh, this looks like this. These things are this looks like an enumerated set. So maybe I can decompose it, but how would it decompose that? 

DEJAN_MILICIC: So it's more in the lines of CQRS, where you store your objects as they are. They are stored as complete JSON documents. So when doing modeling, your first choice would be, of course, to present paper physical documents as classes, and then these classes are becoming JSON. So you end up with the JSON representation of the physical objects and concepts from the real world. And then on the read side, you are writing projections in JavaScript or C sharp, which, and this code lives within the database. So you could speak of store procedures in 21st century, which are not stored procedures anymore. These are pieces of either JavaScript or C sharp, which are executed on the server side, which is producing projections. So you say to RavenDB, give me purchase order, and you're not getting this purchase order you store. You've got dereference purchase order view model, which is composed from three or four, five collections. So what you get back from the database is actually read model, which is completely different from write model. If you see this, 

AJ_ONEAL: this is starting to sound more like CouchDB to me, where you're, you're writing the JavaScript, essentially the filter function or the map filter function as data is going in so that it's prepared for when the data goes out. 

DEJAN_MILICIC: I maybe mentioned it in the beginning that Couchbase was inspiration for this data. Oren. 

AJ_ONEAL: Yeah, and I was having a little bit of internet trouble, so I may have missed that. 

DEJAN_MILICIC: Yeah, so Oren actually used Couchbase as an inspiration and started thinking how this could be improved to produce something even better. So you may see some decision traces sourcing from the Couchbase. 

AJ_ONEAL: Yeah, but the...One of the problems you're solving, which Couchbase does not attempt to solve, is queries. Because Couchbase, or as I knew it, CouchDB, I guess it's changed names a couple of times, but is that you put your data in, you define your reports, essentially, you define your queries, and then the data gets pre-sorted into the query. So everything is cached as literal could be saved to disk documents. Whereas you are saying, okay, well, you can make a query arbitrarily, we can put an index on that. And then...that you so you can make arbitrary queries with RavenDB. Whereas with Couch, you can't really make an arbitrary query. You can make a report and then have the report run, or I call it report with the map filter function and have it run. But you can't really do a one-off query. 

DEJAN_MILICIC: Exactly. And not only that. So if you imagine if you have a purchase order with order lines and you don't have a total value as a part of your model, you then go and create projection which is using JavaScript to calculate the total from the order lines. And then you have JavaScript or C sharp performing this, this section. And not only that indexes as of two years ago can be expanded with a C sharp or JavaScript code. And I was playing around with the following thing. I went to Kaggle. I downloaded a huge collection of tweets about airline companies. I trained. 

AJ_ONEAL: What, what did you go to? 

DEJAN_MILICIC: Kaggle.

CHARLES MAX_WOOD: It's a place where you share machine learning and other tools. Big data sets. Data sets, yeah. 

DEJAN_MILICIC: So what I did, I trained machine learning model that is recognizing toxic text, profanities and other things. And then I wrote code, which is grading, scoring arbitrary text towards, against the system. And I plugged in that into RavenDB. So RavenDB was in real time using indexing to score incoming tweets, which I'm saying to the database. So again, I have stored procedures in 20th century's where I can expand functionality of the database with my custom code, or for example, I can, if I'm using attachments, I can create document management system easily where I'm using indexing and I'm streaming content of the attachments and using And these attached files can even be, for example, zip archive, which I will unzip on the fly. Database will pick up the stream, content from stream and produce index. So idea here is to make life easier, to make things work out of the box whenever possible. Or, for example, if I'm building microservices, you would have to provide message queue with inbox pattern implemented and outbox pattern. Some of the companies using RavenDB are using RavenDB ETL, where two Raven databases can communicate with each other, taking document, JSON documents, morphing them, and pushing or loading into second database. So in some cases, instead of microservices communicating with messages with each other, you simply write a small piece of JavaScript, which is transforming, pushing to another data. So you eliminated a need for queue. Outbox, inbox, retrying communication if it fails, etc. 

CHARLES MAX_WOOD: Interesting. I kind of wanted to ask about things as far as data science and data systems, machine learning goes. How much data can Raven handle? It seems like a lot of these, like you said, you set up a cluster of however many machines and you can more or less scale it as big as you want. Where do you start losing efficiency? Is it when you...you know, spend more than one machine because there's always latency over the internet or the network, right? So yeah, what does that look like as far as like scaling and then processing, you know, where I can either do some of my algorithms, sometimes within a database and sometimes the algorithms have to be run through like a Python with PyTorch or something like that. 

DEJAN_MILICIC: So coming back to the question about the difference with MongoDB. So for example, MongoDB has a dedicated primary node, which is accepting writes. Okay. Again, this time decision with RavenDB was to provide multi master setup where you have, for example, cluster of three equal nodes with three exact copies of your database on each one of these nodes. So let's imagine you have cluster of nine nodes. You can sustain the loss of eight of them. And the remaining one will be serving your application. 

CHARLES MAX_WOOD: How do you manage consistency across the nodes? 

DEJAN_MILICIC: You can run local transactions and then gossip protocol is used to distribute that. You can run cluster wide. 

AJ_ONEAL: The gossip protocol? 

DEJAN_MILICIC: Yes. So there are two layers of topology. When you look at the machines, a rough distributed consensus algorithm is used for the machines. So you have to, you need to have majority of the nodes up and running to to have clustered in technical terms. So to build a quorum or majority, you need to have majority of the notes, obviously. So you need to have, for example, in cluster of three nodes, you would need to have two nodes available to perform cluster operation, like creation of a new database. However, once you create your database, you descend to second layer of topology, which is database group topology. And on that level, Gossip Protocol is used to disseminate data from one node to the rest of the nodes in the cluster. Now, what you can do, you can create local transactions where you store to just one node and this node disseminates to the rest of the nodes, or you can go with cluster one transaction where your transaction will be over when majority or all of them accept your changes. Or you can go middle ground saying, okay, I'm writing to single node and I'm waiting for the guaranteed number of replication. This is in the midway between local transactions and the full cluster transactions. So it's more like you having a choice as a developer to determine which business case should be handled by which technical features. So if you're selling tickets for the Super Bowl, you want to have cluster wide transactions because you have consensus and you won't be able to run into the case of selling same seat to two or three people. Yeah, they would like that. Yeah. But if you have something simpler, then you can say, okay, I'm going to write to a single node and wait for guaranteed replication to at least one more note. Or you will say, okay, I'm writing to this node and that's it. 

CHARLES MAX_WOOD: Gotcha. 

DEJAN_MILICIC: Maybe I did. Maybe I went too far on tangent. Maybe I did not answer your question. 

CHARLES MAX_WOOD: No, I don't think so. I think you're good. One other question that I have though is, so if I'm running, if I have all the data on one node, then. What's the limit on the size of my database? 

DEJAN_MILICIC: Yes, this is something I did not answer at the moment. That's around 15 terabytes, but sharding the last big feature, which is missing is under development. So in something like month or two, we will have first version supporting sharding. 

CHARLES MAX_WOOD: And then, and then the sky's the limit because I can run this across however many nodes. 

DEJAN_MILICIC: Yeah. But I think most. When I speak to people, they ask me about the sharding almost as if they have like checklists checking. 

CHARLES MAX_WOOD: That's true. I've never run a 15 terabyte node or 15 terabyte database. 

STEVE_EDWARDS: And that was something I was going to mention earlier, Chuck, when you're talking about the weekly report. It wouldn't matter if the indexes die after three days if you're running a weekly report because you're only running it once a week. 

CHARLES MAX_WOOD: Yeah. 

STEVE_EDWARDS: A lot of these scenarios that we, you know, just like you're saying here. People have these check boxes in their head, but they don't, they don't actually think, do I need the checkbox? Checkbox important for me is just, Oh, this is what was on the whiteboard when I was in college and this is what my uni professor said. Therefore, 

CHARLES MAX_WOOD: right. I don't need the index to necessarily build the report. I just, it's built when it's built, but my users will drift away and not buy my product or not use my system. If it's too slow, that's where I actually care about speed. So yeah, pointed point.

DEJAN_MILICIC: I remember on a couple of occasions, companies where you have BI departments running reports and killing database CPU peaks. And then you say, okay, you will do your reports on Monday morning up until 10 a.m. That's it. You need to finish. And then you start the free replica just for the BI department to run their. 

CHARLES MAX_WOOD: Yeah, that's what we always did on the once it became too intensive is yeah, we just spin up a read replica and say,go nuts, right? Because you can pick the read replica and nobody else will feel it. 

DEJAN_MILICIC: But you see, over time you start to build these fears. Either you like it or not, you start fearing, okay, what will happen with my project when someone runs reports? And you want, at least I want to avoid that. 

CHARLES MAX_WOOD: Yeah, makes sense. All right, we're kind of getting toward the end of our time. Is there anything else that people need to know about NoSQL databases or RavenDB before we do picks? 

DEJAN_MILICIC: I noticed people still...are although NoSQL is almost 20 years old as movement, I would call it the movement, I'm noticing people are still like driving the note pilot and selecting relation databases, which is not wrong choice. It's just that this choice should be conscious and informed and based on concrete project and concrete means. 

CHARLES MAX_WOOD: Right. 

DEJAN_MILICIC: It's also okay to use text files if it's one of project. 

AJ_ONEAL: So the biggest problem with SQL is that it's not standardized. Because for a standard query language, there's no standard. There's all these little tiny gotchas of, oh, well, in MS SQL, you escape with a bracket. But in Postgres, identifiers are single quotes, but values are double quotes. But in MySQL, it can be backticks for identifiers and for values sometimes. And SQLite tries to...play the middle ground, I think it leans more towards the Postgres way of things, but it's just more lenient in general. But then, if you go to the NoSQL arena, well, then it's even worse. Because now, everything is bespoke. And rather than being able to build things in just the query language, for example, for the stored procedure, or the view, or however you want to use the right terminology to capture the essence of what you were talking about as a projection earlier. Now it's, okay, well, if we commit to this platform, we have to also commit to the programming language, which I mean, really isn't that hard of a thing to commit to because you're going to anyway, but you're tying more things in together with NoSQL and there's not even an attempt of a standard. There's not a dictionary of, hey, here's what projection means, right? Projection is a bespoke term for RavenDB what Couch calls its kind of projection, which might be a little bit derogatory towards RavenDB because it sounds like a RavenDB projection is a bit more than what the CouchDB, what I would call report is. I don't remember what the name is for their map filter function, you know, and so on and so forth. So it's easier that you talked earlier about the cognitive load, and this is one of the reasons why I'm suggesting something like Martin is. It's easier for people to gravitate towards something that at least has some semblance of both stability and similarity, as opposed to this wild west of, well, everything's different and it changes all the time. 

DEJAN_MILICIC: Standard Zoom matter. I completely agree. And probably that's major factor in the success of Postgres. Yeah.

CHARLES MAX_WOOD: Yeah. 

AJ_ONEAL: Postgres and Postgres has a lot, a lot of really good tooling built around it in every language. Now, granted. It's not the same tooling in every language, but you can find great Postgres tools for Rust and great Postgres tools for Go and decent Postgres tools for Node and so on and so forth. I imagine for C Sharp, like you mentioned. So I think that that's part of the draw. And that's kind of why I said, I'd really love to see something like Raven, but built on top of Postgres. So I have that sense of security. And also like we saw with RethinkDB, RethinkDB was something where they had a lot of cool concepts. They had a lot of ideas that really started to make sense. In the second iteration of the product, because the first iteration was all about optimizing rotational storage, and I don't think anybody even heard about them yet. Then they got investment, they started to get big, and then they were all about kind of being in the Mongo space, maybe kind of in this Raven space. You know, so there was a venture-backed company, they were big, they were pumping things out, and then all of a sudden they disappeared overnight. And that's another concern for someone that's starting, whether it's a new project or it's transitioning an old project, how do you get, not just with NoSQL in general, which I think is well categorized as having been a fad, obviously it's still around, but you know, in terms of just new things every week and and Mongo kind of stuck around, Redis, I don't know that it really fits with NewSQL, it's just a caching layer or a key value store, which you know, we've had those for decades upon decades upon decades, that's why other databases have been built on traditionally has been binary key value stores. But so with all of this negativity, what is something that you feel that Raven brings to the table to assuage some of those fears of, hey, Raven's kind of going to be stable and Raven's going to be around for me to continue to use? 

DEJAN_MILICIC: So I completely agree with you. And this is probably the biggest challenge and probably one of the hardest market times. Because you are producing something that's used as a part of infrastructure and changing databases is painful. You don't want to do it. Or if you're going to do it, you want to do it once every 20 years. What I see is that developers love RavenDB. And in most of the organizations, I was facing following scenarios. Developers go home, work in the evening on the hobby project using RavenDB. They go back to the work saying, I would like to, I tried this database on my hobby project. It seems to be working nice. I did some load testing. It's also nice. I would like to use it for our next project. And then manager says, okay, I never heard about this database goes Googles around the bit says, okay, this is the same thing as, as CosmosDB. And the CosmosDB is a big name. Why shouldn't we be going with CosmosDB? devil lies in the details. It's when you start developing, when you start living with your choices, it's about what matters. So I think as a general rule of thumb, managers should have more confidence in their teams, in their developers, whatever their choice of technology might be. 

AJ_ONEAL: So also, I mean, I need to boost something on the, 

CHARLES MAX_WOOD: I need to push this to pick soon. So fast. 

AJ_ONEAL: Okay. Well, on the practical side of things, it seems that you have a good business model. And that is one reason that I would believe that you would stick around as you seem to be charging reasonable prices for your, your, your basic tier is about a thousand dollars per year per CPU core. You've got a community tier that's free. And that gives me some degree of confidence. If I'm paying a thousand dollars for something, I have some degree of confidence. 

DEJAN_MILICIC: It's also open source. It's completely, it's interesting business case, completely open, open, open source, HPPL three license. So you can go and work it if you want. And I think community by now is large enough. So even in the case of like a rock from the sky, I think headquarters and all developers are gone. I think community is at this point, large and strong enough that they will continue to push. I'm strong believer in strong proponent of open source. I think it's great as a concept. And when you see that someone built a company around it, over something that's completely free. That's amazing. 

AJ_ONEAL: So when you say the AFGPL though, doesn't that mean that any service that I connect over HTTP is infected with that license as well? 

DEJAN_MILICIC: If it's not part of the application, it's not. I would have to go into strict details to see what is, but if it's not embedded as a part of the application, I think it can be used. But there's also what's interesting, there's community license which is suitable for commercial usage and lots of startups are using it. And at some point they reach out to you, okay, I've been using this for three years now. We are profitable. We want to contribute back. So those are interesting stories. 

CHARLES MAX_WOOD: All right. I'm going to push this to PIX. We should do another episode on licensing because I find that fascinating. I'll find a signature need to talk to you, but let's go to PIX. 

 

Hi, this is Charles Maxwood from Top End Devs. And lately I've been coaching some people on starting some podcasts. And in some cases, just taking their career to the next level, you know, whether you're beginner going to intermediate and immediate going to advanced, whether you're trying to get noticed in the community or go freelance. I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching. 

 

CHARLES MAX_WOOD: Steve, do you wanna take us to what you consider the high point, as you always say, of our episode? 

STEVE_EDWARDS: Yes, but I will get there very briefly, but I actually did have a legit pick. My pics are always legit, but a different one. I came across this page on Twitter today, and it's really cool. It's low Earth orbit visualization map, and it shows all the different low Earth orbit satellites that are floating around in the ether above us, and gives you ways that you can see when they might be traveling over your particular geographic location, and gives you the ability to see them. Looks like a pretty cool little thing. I've done that before with the International Space Station where you figure out when it's coming over and then you go outside and you can see it go overhead. So it's platform.leolabs.space slash visualization. So we'll put that in the notes. And then it's also worth mentioning, I guess one of my picks is Utah. Last week, my daughter and I spent the week driving around doing a big loop through Utah and a bunch of national parks. I got to see like arches and canyon lands in Eastern Utah, went down to Lake Powell and then did Bryce Canyon. Gorgeous, I love that Canyonlands type. Oh, Monument Valley too, right on the border. I love Monument Valley. It's, you know, it was used as a John Ford movie director used it for a lot of his Westerns and you see it. You just see pictures all over the place. And there's actually a scene from Forrest Gump when he's out running around where they take a picture on Highway 163 going through Monument Valley. And if you look on Google Maps, it says, highway used in Forrest Gump movies. So got some really awesome pictures. Funny story, I also got to meet AJ and his lovely wife, Agnes in the Prova area and we went out to dinner one night. Funniest thing, and developers will understand this, we're sitting there talking, Agnes looks at me and goes, so Steve, how many computers displays do you have? And I guessed right away that AJ had a whole bunch and she didn't understand them. I said, well, I actually have five. She's like, oh no, she was hoping that I wouldn't agree with AJ, I've got my three big monitors and two laptops and all this. It was really funny. My daughter just loved daddy, his daughter, she was real cutie. But then all that getting on to the high point, the jokes. So I had them all brought up and then I lost them. Oh yeah, so usually I tell audio jokes, but I actually have a bunch of jokes that are in sign language, but I can guarantee that nobody's ever heard them. Right? So what is the difference between a camera and a foot? And I found this because I was taking a lot of pictures last week. A camera has photos and a foot has five toes. And then finally, this was sort of a leftover from St. Patrick's Day, which was a couple weeks ago before I left on vacation. Why are leprechauns so hard to get along with? Because they're so short tempered. Thank you. That is my picks for the week. 

CHARLES MAX_WOOD: All right, AJ save us. 

AJ_ONEAL: Well, first of all, I couldn't I was muted, but I didn't get that last one. Can you can you help me a little bit? 

STEVE_EDWARDS: What about the leprechaun? 

AJ_ONEAL: Yeah, 

STEVE_EDWARDS: because they're short tempered. No leprechauns are short people. Sorry. You know, it's like, where do you find a leprechaun baseball team in the Little League? 

AJ_ONEAL: Sorry. I'm not. 

CHARLES MAX_WOOD: Save us! 

AJ_ONEAL: Okay. All right. Wow. You hurt my ears there a little bit, Chuck. So I'm going to pick one, Ethan Garofalo. He's got a few talks on microservices that I have in a playlist. I should go and search out what his latest ones are, because the latest one I have is from 2019. And he's probably done more since then. But I like to keep up to date on his playlist site. There's talks, I guess. They're good talks. Anyway, so Ethan Garofalo, he's literally written the book on microservices. We had him on the show once. You should probably I should probably pick whatever show that was. But I don't know what it was. And then also, there's this YouTube channel that's makes fun of developers and, but it has one pretty much, it's all but a documentary and it's called Microservices. And I swear I've been in the room, I've seen that happen. It's hilarious, but it's somewhat explaining on the whiteboard why we can't get the user's birthday into their profile information. And it's- 

STEVE_EDWARDS: You're gonna like this. 

AJ_ONEAL: Yeah. And then he actually has somewhat of a followup called I delivered value but at what cost. It's not as funny, but it's when they finally are implementing the dates into a megastar. Yes. That wasn't a joke. That was just me laughing, thinking about it. Anyway, 

STEVE_EDWARDS: they were all laughing with you. 

CHARLES MAX_WOOD: Not at you. 

AJ_ONEAL: Oh, okay. Good. And then the last thing that I had to pick, I had something else to pick. What was it? Oh, the Brandon Sanderson. Yeah. I was going to pick Brandon Sanderson as, as they refer to him, quote, in the world of the, the fantasy fandom, our Lord and savior, Brando Sando. See, he is the best fantasy author of all time. He finished The Wheel of Time. He created The Atlantris and The Mistborn series and now his magnum opus is The Way of Kings slash Stormlight Archives. And he, during the pandemic, was really down and wasn't able to go to any conferences. And so then, boop, out of nowhere, he announces that he actually wrote four whole books over the last two years. In addition to the books...that he was contracted to write. And so over the next two years, we're gonna get another six books from him. And he made a Kickstarter where you can get kind of the, I guess, I don't know if it's a special edition of these books, but they're in, I think most of them are in the Cosmere. I think three of the four are in the Cosmere. I don't remember what he said exactly. And then there's gonna be swag boxes and all this stuff. And so you can get the audio books for as well. Sorry, actually. I'm mentioning this too late because by the time this goes out, it'll be over. But anyway, I mean, check it out. Maybe there will still be one of those Indiegogo things where you can sign up after the fact and, and still get it. But my wife and I got the audio books and, and, uh, maybe some of the other extras as well. 

CHARLES MAX_WOOD: Yeah. I wants it. Yeah. Sorry. Did I cut you off? 

AJ_ONEAL: Nope. That's it. That's all I got. Just Dan Boyd out. 

CHARLES MAX_WOOD: I'm going to throw out some pics. Then the first pick I have is board game. It's called Scythe on board game geek. It has a weight of 3.43. So it's on the heavier end of games, but it's a fun one. It's a resource, collect and manage build game. So it's kind of in the vein of Settlers of Catan, sort of kind of for lack of a better way to put it. But it's fun. You get to fight other armies as well, but the combat's not really the point of the thing. So anyway really enjoy that game. We have one of the expansions too and I'm trying to remember which one it is but I'll have to pick it at a different time. Another pick I have, so I am finalizing things for the summits this year. It looks like the JavaScript one will probably be in July. I'm reaching out to a few folks like Brendan Eich, you know, some of the more popular guests that we've had I guess, to see if they want to come on and speak. So keep an eye out for that. Got DHH coming for Rails in August probably do Angular React, View, etc. during the fall and winter. So anyway, so if you're interested in any of those topics and showing up for some online conferences, definitely do that now. I'm doing it a little different than I have in the past, because I know some people have come to the conferences that I've done in the past. I'm actually going to... I'm trying to make it as easy for attendees to interact as possible. So we'll have a Slack room like I've always done. It'll actually be the chat in the software I'm using, but then...We're going to have tables for people just to sit and video chat with each other, which is all built in you'll be able to go talk to the vendors and I'm working on doing giveaways as part of the deal and seeing if I get the sponsors to give away Stuff that we can give away online, right? You don't have to be present to win sort of thing I don't have to figure out a ship you a thing. But the other thing is is that All the attendees will get an NFT for the conference. And I'm working on getting NFTs for just other, kind of like badges almost, that you can earn as part of the conference, right? So if you talk to a certain number of people or visit a certain number of sponsors or visit specific sponsors or things like that, you'll get entered into their drawings and you'll get their NFTs. So anyway, it'll be super fun. I'm looking at doing themed days. And so, you know, we might do a day to day and have like a Postgres expert and a Raven expert you know, whoever show up. So anyway, 

STEVE_EDWARDS: this is where I want that movie quote from treasureless, your marriage here, a moderate about I just, we don't need those thinking badges, 

CHARLES MAX_WOOD: right? 

STEVE_EDWARDS: I think I'm gonna have to upload that as a sound effect. 

CHARLES MAX_WOOD: You might have to, but anyway, uh, you can find all the details at JS remote comp.com. You can find the details on all the conferences at top end devs.com slash conferences. And I think that pretty well wraps that up. The only other pick I have is so I was at Nashville this last weekend. It's funny because Steve comes here, so I left town. But some of my, I wasn't trying to be funny, anyway. One of my friends got me turned on to Yellowstone, the TV series, and it's really, really good. So I'm gonna pick Yellowstone. 

STEVE_EDWARDS: Have you started to watch any of the prequel that just came out that's got Sam, I forget. 

CHARLES MAX_WOOD: I want to, I haven't yet. I was kind of. 

STEVE_EDWARDS: 1876?

CHARLES MAX_WOOD: I think it's 1883. 

STEVE_EDWARDS: 1883, right. 

CHARLES MAX_WOOD: But yeah, I haven't picked it up. I've heard from a lot of people that they like it better than Yellowstone. So, anyway, apparently they're looking at making another one, which is like 1923 or 1933. I don't know. Anyway, so yeah, apparently 1883 is just a one season. It's a one-off series. But anyway, and this is all hearsay. I don't know any of this. So, it's what they were telling me. Anyway, but yeah, I'm going to pick Yellowstone. I'll probably come back around and pick 1883 if it's as good as Yellowstone is. But yeah, anyway, that's my pick. Dayan, what are your picks? 

DEJAN_MILICIC: Okay. I'm rather boring, so in my free time, what I do, I'm coding. So this week I'm playing around with the programming language called Idris. And what's so spectacular in my humble opinion about it. It's, uh, it is so strongly typed that compiler is not a device for catching your errors anymore, but compiler can use type declarations that you prepare and generate part of the code for you. So you have this interactive mode where you say, okay, this is a signature of the method and this is functional programming language, and it will generate a good part of the code for you. And then you can even go and write formal proofs for your code. And I don't know if you're aware, but for example, when you use Firefox, TLS implementation in the Firefox was generated this way. They took programming language called F star. They wrote formally proven implementation of the TLS and then they generated C code that was compiled and built into the Firefox. And the best part is during the implementation, while following TLS protocol, they managed to find a couple of the errors in the protocol itself, in the specification of the protocol. So I think formally proven pieces of software are future to come. So usually they say it takes around 20 years for innovations to land in the industry. So I'm playing hopefully at the moment with something that will arrive around 2050 2050 into our lives, making us all safer and happier. 

CHARLES MAX_WOOD: Awesome. Now, one thing I forgot to ask earlier, if people want to find you online or connect with you in some way, where do they go?

DEJAN_MILICIC: I'm trying to use Twitter in a very nice way by sharing the links so they can find me on Twitter. So that's my favorite social network. 

CHARLES MAX_WOOD: Awesome. All right. We'll go ahead and wrap it up here. Thank you for coming. This was awesome. And until next time, folks, Max out. 

STEVE_EDWARDS: Adios! 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.