Coding Blocks - How We Badly Built Stuff

Episode Date: March 20, 2017

This week we talk about all of the bad things we’ve done while making software. The good, the bad, … oh wait, it compiles, never mind. Want to be part of the conversation? Head over to http://www.codingblocks.net/slack to become a member of our Slack community! What are you waiting for? Join now! Oh, wait, are you […]

How many tickles does it take to make a squid laugh? Eight. Do you? I thought this was a rhetorical question. No, no, man. This is real. Oh, I didn't realize that was going to be a test this soon. Every listener is screaming 10 tickles right now.

Yes, 10 tickles. 10 tickles. Yeah, that's awesome. We tickles. That's awesome. We're the worst joke tellers. No, man, that's amazing. That's amazing. By the way, this was jokes so bad that they're good.

Debatable. Hey, easy. They'd be downer tonight. Hey, somebody chuckled out there. I promise you. All right. So here we go in five, four. You're listening to coding blocks.

Episode 57. Subscribe to us and leave us a review in iTunes, Stitcher and more using your favorite podcast app. Senior business. Oh, son. All right, Stitcher, and more using your favorite podcast app. Send your feedback. Oh, son. Go ahead, please. Visit us at CodingBlocks.net where you can find show notes, samples, discussion, and more.

Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw.

Man, you'd think we would have had this straight by episode 57. That was horrible. I can't read. All right, so we're going to get started first with our iTunes reviews. We have, okay, so I haven't seen this one, RJTman, Roadkill19, John Horovit, Kellen, Bart Bucknell, Barak73, and WraithlinSA. And over on Stitcher, we've got Schnargles, Humblecoder, Lunchbag, Charvel, Broken Java, Bairdly, and Yarbius. So thank you very much guys we really appreciate it man we got some really good ones this time too that that were some super feel good ones like you

know change lives type thing so thank you for taking the time to write those they were amazing yeah we're trying to get better all the time so it's nice to know and nice to be appreciate when you guys notice that we've done a little bit better in that vein i'll try to keep things moving along in the news section here. So as always, take out the show notes and coming back. So that's episode 57. It's super fast. All right.

So we've talked about several times on this show about SSDs and how important they are to us as developer and as people who like speed. So there were a couple of things I wanted to point out. One, all SSDs are not made the same. They're not, they're not all equal. There's a difference between, uh, even a lot of people hear them form factor like M dot two, and they're like, oh, that's the fast one. There's M dot two that uses Seda. And then there's M dot two that use PCIe connections. The PCIe are typically faster and the SATA ones are typically slower. So just be aware of that. Now also know that if you want one of these super crazy fast ones, which one do you have? You have the 950 pro or the nine? Yeah.

So outlaw has a 950 pro and that thing is insanely fast, but also know that you need systems that are going to be compatible to set that as a, as a boot disk and that kind of stuff. It's so life-changing, though. It totally is. I mean, we talk about it all the time. Really, there's no better bang for your buck, and especially nowadays with the prices being as low as they are. But that's why I wanted to bring up something. So in, in one of my news feeds the other day, I got, I got a review for what's called my digital SSD. It's a BPX SSD is their, their particular model number. And I forget what it was, bulletproof something.

At any rate, it's a 480 gig, uh, PCIe SSD that has performance on par with the Samsungs. And it's using one of the most stable and more sought after controllers, a 480 giga for about $200, 2.6 gigabit reads and 1.3 gigabit writes. And Tom's Hardware did a full on review review on this thing and apparently it even beat those numbers in their in their testing which is killer and it's got a five-year warranty on it wait what were those numbers again uh 2.6 gigabit read 1.3 right wow it's so it's right up there with the samsung at way cheaper like we're talking about 150 bucks cheaper for the same size and a five year warranty. Like it's, it's guaranteed for an insane amount of reads and writes. So, you know, check it out. We've got some links. There's a, for the most part,

it hovers around $200. There's a site called my digital discount.com that occasionally has it for about 180 and they're about to release a one terabyte version so i'm waiting for that because i think it's supposed to happen either in march or april so yeah you can get the the samsung 960 which is the uh you know the i guess maybe the popular choice yeah it's probably yeah it's the one that people know about. Yeah, so your numbers were, you said, 2.6 and 1.3 megabytes per second. Gigabyte, or gigabits per second. I'm sorry. Yep.

For read and write? Yep. Wait, yeah, 2.6 for the read, 1.3 for the write. Yeah, so to compare that then to the Samsung, there's the 960 Evo and the 960 Pro, and the Evo, which would be the lesser of the two, would be 3.2 for read and 1.9 for the write. Blazing fast. Yeah.

But for, how much is that one going for right now? Is that probably about $350 for a 500 gigger? $250. $250? Oh, that's actually come down in price that that's for the evo not for the pro not for the pro right so it's not guaranteed for as many rights basically is what it boils down to uh the yeah the pro would be like 365 for a 512 okay so yeah i mean some good things to know about again the pcie is way faster because the other ones are actually

capped by the sata um you know bus so uh just just something fun to know about and you know again to be aware that your system needs to be able to support it if you think you're gonna throw it in there as a boot disk you might need some bios updates and that so but the highest storage you said for the capacity for that was like uh80? 480 right now, and they're about to release a one terabyte version. So I'm keeping my eye on it because I'm curious. That's dirt cheap storage for that speed. Yeah, because if you want to get ludicrous, you can get the 960 in terabyte. How much are you going to pay?

700 bucks? Yeah, dude. I actually looked at the two terabyte. It's close to $1,500 for that thing. Oh, man. You weren't supposed to cheat. No, dude. I looked a at the two terabyte. It's close to $1,500 for that thing. Oh, man, you weren't supposed to cheat. No, dude, I looked a while back. It ain't cheap.

Well, that's for the Pro, though, to be fair. Yeah, so it's actually 14 now for the two terabyte version. But you could get a one terabyte Evo, not the Pro. Okay. And that's like $480. Man, it ain't cheap. So the next thing, I brought up the fact that i was going to do a hackintosh and i still plan to but the only thing that's giving me pause is we're right here at the time when apple's about to release their next round of hardware

and so the z170 or the sky lake is what is currently in max out there. And KB Lake is what's out now with the seventh generation, you know, Intel. So I'm waiting to see what happens there so that I don't buy last year stuff for the same price that I could get the newer stuff for. So I, I'm just kind of waiting for that. And wait,

so you're saying that you would actually deal with the touch bar? No, no, no, no Hackintosh. I'm going to build a hackintosh but so basically right now the ones that are kind of guaranteed to work are the ones that are on the sky lake architecture which was last year's stuff oh i follow i thought you were saying that you were like on the fence about building because you're gonna wait for apple's hardware release

because they're on the no i want i want the new chip set right i want i want the new chip set to be compatible before i go uh you know plunging in and then that's why i go ahead i always buy last year's hardware so it's funny to say here you're waiting for the new stuff like i always wait for the new stuff so i get the old stuff cheaper that's the thing though the prices on the old stuff aren't going down they're actually going up the uh the sixth generation i7 is actually more than the kb lake right now which doesn't make sense to me so yeah i find myself wanting an ipad that's been my weird one oh really like you're you're going over the hackintosh thing and i find myself wanting to get an ipad again and i'm like yeah i probably should wait i probably shouldn't there's there's hardly a better consumption device out there.

Dude, my wife's first-generation retina still works amazingly well. Like, I can still watch Pluralsight videos on it. Dude, take an Android tablet from that same time period. Right. It'll barely start up. Like, I'm serious. Like, it's ridiculous. Right.

They hold on to what they can do for a long time so and then the last bit of things that i've got here is i'm actually going to be speaking at the atlanta javascript meetup so i'm going to be giving a little talk on writing a node.js application in a serverless environment so yeah so if were in the Atlanta area and you have nothing else better to do than to listen to Alan speak on a Monday evening, feel free to join us March 27th at 7 p.m. at the Creative Circus, and we will be listening there in full attention to every word he says. I'm going to have hecklers in the audience. No heckling. I don't plan to heckle.

Okay, good. But if you did heckle, I bet someone would give you a sticker. No, I don't want to encourage anyone to heckle. So if you heckle, you're definitely not getting a sticker from me. But if you ask for a sticker politely. But I will be there with stickers in hand. So if you do join us and, you know, be sure to stop by, say hi, introduce yourself, and I'll give you a sticker even if you don't ask for one.

Totally. Awesome. All right. We ought to do an episode on serverless architectures too because I don't think we've ever really talked about it on the show. It's just a cool thing. It is, totally. Well, cool. Yeah.

Put it in Trello. So I am moving to Orlando, which is very exciting for me. Not so much for you guys, unless you live in the central Florida region. Uh, so it's exciting for me because it's, uh, kind of a city I've been living near Cocoa beach. And so it's, uh, not a lot of programmers around here. So I'm excited about being able to go to meetups and stuff more readily. So good news for me. Um, also want to mention our YouTube channel. I've got some stuff kind of planned. I've been working on, I'm not super happy with this. So I think I'm going to redo it.

But, uh, if you go there by the time this episode's out, there should be at least one more video there. Um, so yeah, go to our YouTube channel. We're doing a lot there and we're actually starting to do a little bit of aggregation too, of other programming videos that we see and like, and think are cool. So if you make videos or have some suggestions, then hit us up. That'd be awesome. Also, if you aren't familiar with 7 Day Roguelike Challenge,

then you should check it out. If you just Google 7DRL, it's a little challenge every year where people take a week and some people even take off work and stuff and they'll try to make a game. I think this year there were 100 contestants. And if you are interested in games programming or playing games, then this is kind of a cool thing to watch

because a lot of people use this, uh, this week to kind of experiment with new techniques and new mechanics and, um, just really creative games come out of this. And a lot of them go on to become bigger games on steam or whatever. So I encourage you guys to check it out. Yeah. And so with that, we're happy to announce the winner for episode 55 your copy of clean code is ronan fitzpatrick so look for that coming to you shortly congrats yes

and also uh just a reminder we mentioned in the last episode about the PostSharp giveaway. By joining the mailing list, that's where we're going to be announcing the contest details. So you have until the end of the month for that. Yep. Yep. And I just want to mention with that mailing list, too, we've actually given a lot of stuff away. And we're going to be giving away some even more stuff. We've done some JetBrains subscriptions. We've got some, um, some, a really cool book we're

excited about. It's called the imposter's handbook. We're going to be giving away some of those all in the mailing list. So, um, you should definitely join. We're giving away stuff by the truckload all the time. And actually, if you hang on till about the middle of this episode, we're going to be announcing, um, possibly our best contest yet. So we're really excited about that and we think you're going to love it. So definitely stick around to the middle of the episode and be very excited. Yeah. We don't just give back. We give back. We give all the stuff back. That's right. Awesome. So this episode, we're kind of walking away from clean code for a little while. We've gone through what more than half the book

i think at this point we definitely did a lot more chapters than i ever thought that we would if you go back and you listen to some of the like the original chapter on the clean code uh book i definitely remember commenting something about like oh we're not gonna do all of this right we're only gonna do a few chapters yeah we're gonna do two or three you know 12 later or whatever so i mean it we got a lot of great feedback on it. People love it, but we kind of want to step out and do some, you know, get back to some of our roots, I guess. I don't know. So some somewhat deep dives and some water cooler stuff.

So this episode, we want to talk about typically how we've built systems over our careers, right? Like just the stuff that we've seen out in the workforce and the ways that we've gone about doing them, because really what we want to do is want to lead up to some better patterns and better ways that you could do things. And maybe better is not the right term, but other ways to help improve your software. And it kind of, it's a good place following up from clean code. So yeah, I mean, I guess to start it off, like one of the first things is this whole idea that the database is the center of your world. And so everything you program goes around it. I mean, you know, what do you guys think? Is that pretty much what we've seen our entire career?

Well, it's kind of funny that you mentioned that because I kind of feel like if you can show me a database schema for the thing you're trying to build, then I almost don't even need to see anything else. Like a lot of times, like I kind of get like, okay, this is what I need to do. There's one to many here.

So I need to have, you know, a mechanism to create and manage those. And so you can almost build like an administration area just from a schema and like do pretty well, I think, you know, unless there's any sort of fancy rules there. So I still think that's a valid way to go. And in general,

I do like the idea about, of at least knowing what kind of persistence you're looking at, depending on the kind of app, because the more you can convert stuff to data instead of code, I think the better off you are. And what I mean by that is, um,

by having, um, you know, things be rows in a table or a flat file or a no signal database or whatever, you're, um, keeping your code doing Cody type stuff. And you're keeping things like constants and, um, things that change things that change often outside of the code, which I think is much more easy to manage. And you know, what's funny about that? I agree. Like I tend to be able to, anytime that you start a position or you start on a new application or something like there's almost always that schema that you can go look at. And so you can sort of reason about it before, even if the terminology isn't great, like even if the tables aren't named exactly where they should be, but you can look at the keys and relationships and kind of know how everything is supposed to flow

based off the schema, assuming that it's in good shape. But I half wonder if some of the importance there is the accessibility of that data is what makes it so much better, right? When it's in a database, if you want to extract that data, you just do a select, right? If you want to get that data out of an application, a lot of times it's a lot more difficult. So I think that's almost why a lot of people start there first, because eventually, don't they say basically some of a company's most important assets are the, are the information that they, that they end up storing over time, right? Like their customers or, or their accounts or anything like that. And so being able to get to that data and do reporting off of it or do analysis

on it is always important. And so that's why it seems like for so many years, that's kind of where you start is this is where we want this stuff to live. Now build things around it. Yeah. And the kind of thing I was trying to kind of get at earlier, I'm still not really expressing it very well is that when I think about doing things like kind of code first and keeping away from, from persistence, like sometimes at least for me, I'll end up doing patterns. I'm not really happy with where I start doing things like, well, if it's this class, then do this sort of thing. And what I'd rather be saying is like, if it's this type of data,

then do this thing. And so I really want to shift the focus and keep things out of code and focus more on like different types and stuff that I can specify outside of the application. So I just keep a clean line there between persistence and logic. Yeah. I don't know where you guys are coming from with this though, because like, you know, I guess maybe like your, um, you know, where your background is, you're going to have a different experience because I'm thinking like a lot of times, at least, you know, let's go way back. Right. It was like the platform, the popular platforms and the frameworks of the time, they kind of like already laid out a lot of, uh, like the database approach that you were going to take. So I'm thinking like, you know, let's go way back to the days of net commerce or web

sphere, right? Like it was already kind of a known thing. Like, okay, this is the way the, the data that's already been decided for you. You're going to use this platform, right? Yeah, I guess mine's been slightly different. Mine has always been, hey, we're building this system to do something, whether it was e-commerce or whether it was internal applications or quoting systems or whatever it was. It was always, hey, let's get around this particular centralized database and it's actually unfortunately it's almost like a block in my mind because like uh one of the guys from slack when i did that video debugging his application where he took uh

what's the game that you guys love overwatch overwatch yeah like basically building teams out like i have a hard time thinking like that. Cause I'm like, there's no persistence there, right? Like there's, there's no database. So why would you build an app? But there's lots of little things like that, like little utilities and stuff that are there. But, but I literally have come from an entire career of the database is like your gold standard, right? Like that's, that's where all the important stuff lives. And now you're going to build stuff around it to make it, make it work. Well, I kind of had this thought today that like there's, there's, you know how we talked about, uh, the different types of developers in the last episode, right? There's kind of not exactly the same thing, but kind of somewhat, it's going to

sound related is that there's three kind of classifications of developers, right? There's the developers who do services work, right? So like you go to a customer, customer wants XYZ built, and you do it, and then you move on to the next customer, rinse and repeat for however long in your career. There's the type of developer who is working on a product, you know, like your company creates one or more products and that product is installed at one or more customer locations, right? And then there's the type of developer that you work for a company who their main business app might be their.com.

And so your main focus is on just supporting that application, right? And so there's different types of flows that you're going to go, you're going to do for each of those. And so kind of where I was coming from with the mindset of the framework thing is that, you know, for as early in my career, I was in that services portion for, you know, very large company. Right. And so, you know, there were already like well-known products. It was like, I was in that services portion for a very large company, right? And so there were already well-known products. It was like, okay, this is the product we're going to be using. Customer X by Z wants a store.

This is what we've got. Here's the store app. Does that make sense? Yeah, it does. But you were still focused around it. Like WebSphere had a gazillion tables, right? And you had to be familiar with those. Oh, boy, didn't it? Right. It was, it was crazy, but, but still, it was kind of like the center of your universe, right? Like everything started there and then you

built out from it, right? Like that, that was the, in most things, it seems like that's the way it's been. Now, Joe, you worked with, um, you know, a security company, was that database centric or, or were you building tools that were more, you know, like, what did you see there? Uh, surprisingly data centric. So a lot of it was about, um, kind of maintaining the customer's info. I was mainly on the backup side. So a lot of it was just about like maintaining, um, lists of computers and access and rules and what we do with those computers and when we do it and what we do with the backups and how we restore and all that stuff and it was all built around a database very cool what so you also you worked on an

augmented reality app at one point earlier what was that was that database centric i mean because you you were doing a lot of things or was that more service like, uh, get external data related? No, that, that wasn't really, that was just more UI than anything else. Really? I mean the, the, yeah, uh, I definitely wouldn't call it date cause it was mobile. Um, so there wasn't like a whole lot of database about it at the time. Yeah. Especially right. Yeah. I mean, this was 10 10 years not 10 years ago uh like seven years ago um so but yeah i don't think it falls into the classification of the database first approach you know as you as you brought up here uh in that particular example okay so one of the things that i wanted to bring up with this is it's fairly common for all of us, though.

Like, we've all worked on things where, like, the database is kind of what you start from, right? That's you build your admin screens off of it, you build your workflows off of it, and you're persisting everything back. You know the tables. They kind of map to your classes and your application and so on, right? There's pitfalls to this. And one of the things I can think of right now is like ORMs. You know, a lot of times people will take an ORM and they'll just run a thing that'll map it against every table in their database, right? So now you have a bunch of classes that correspond

with those tables. And the beauty is now you can say, hey, I want to create a new lookup value here. Right. And you'll just have an object that create and it's there. But the problem that you get into is there's no boundaries now, right? Like everything has access to every single object in the system. And, and you literally have no clear lines of it. The easy one for me to think about is, so you have a company and let's say that it's an e-commerce thing. Cause a lot of people understand it. So you have your thing where you're buying products. That's easy to see, right? But then behind the scenes, behind the scenes, you've got a customer service department. You've got an accounting department. You've got an inventory control department. You have all these things and they've all got access to the same objects

because you've basically just created this ORM mapping and anything can do anything to all of it. And that can be problematic. Yeah, it's a nice clean layer, but it's very horizontal, right? You can't really slice that up well and say customer service can only, you know, it only makes sense for them to talk to these tables. So it's really easy to cheat and grab things from areas that you probably shouldn't be accessing directly. And messing them up too, right? Like that's the problem is when there's different business rules depending on what department

you're working in, right? Like for instance, a lot of ways that customer service apps or customer service software will try and get around a lot of the new like phishing scams and that kind of stuff, right? Like social engineering is, they might not even show you any information about a customer that's calling in. They might just be given a question and that customer has to answer it. And then they might be given another little piece of information and say, hey, could you please tell me what this is? And then they have to type it in and then they'll get a slice view of it. But if you have this ORM, that's basically bringing back an entire customer object, there's no boundaries, right? Like you can see all of it and you can potentially modify it too.

So that's one of the things that I see is sort of problematic in that approach. It just feels weird to say that a pitfall to this approach is the ORM. Am I the only one that feels like a little dirty about that being a pitfall? So I don't think it's, it's not the ORM's fault. Yeah. I understand what you're getting at. It's just the fact that it's so easy to create that layer. Right.

And once you create that layer, then everybody just starts using it. Right. It's like having that big candy dish out there. Everybody's going to have their hand in it. And you know, some people don't wash their hands and that's going to be a problem. Right. What a gross analogy.

I was thinking about, um, you've got a, an accounting app, a customer service app and say like some sort of, you know, shipping receiving app. And you know,

these are all different things. We get why the different things, but it's kind of funny to think they could all be, a customer service app, and say like some sort of, you know, shipping, receiving app. And, you know, these are all different things. We get why they're different things, but it's kind of funny to think they could all be, um, you know, accessing the same monolithic data source of the database and they've all got the same ORM. So they're all able to do it. And you can think about the kinds of problems that might happen if customer services can do things like update inventory of an item, but so can shipping, receiving, and so can accounting, you know, I think problems are going to happen when you've got three different systems modifying the same things and uh yeah it's i mean it's definitely this big core layer but i don't think it's necessarily the orm's fault as much as having a monolithic database at the center of it well that's what

i was going to suggest is that it sounds kind of like what you're saying is the problem is it's the lord of the rings problem right it's one database to rule them all. Well, is it the database of the problem or is it the fact that you've only got one ORM layer, right? Like what if you were to break that thing up and say, okay, uh, I have my, my accounting ORM or my, you know, interfaces for my accounting department. I have my interfaces for my customer service department, et cetera. Instead of having one big one that everybody could just grab from, break those up. Is this even a problem at all, though?

Is this such a bad thing? I think that's kind of what the aim of the episode is to talk about is to kind of talk about these issues, growing systems, and how we can kind of take a look at some of the ups and downs of these sort of things and figure out what to do about them. Yeah. I mean, I would say that having one major, one big blob of things that you can grab from and push to is a problem because you can't enforce any business rules, right? That's when you start getting into this world of spaghetti code, which we've all seen, right? It's like you said, typically your logic isn't based off of your class. It's based

off the type of action or behavior that's supposed to happen or data, right? So if a customer service person is touching an order, they can do something slightly different than what a customer is going to be able to do. A customer is just going to be able to put it in their cart and check out, right? If a customer service person is doing it, maybe they can go in and modify the price or give you a discount or do other things, right? So now you're going to have this control logic flow in your application that says, Hey, if this was a customer service person that's logged in, then allow them to do this. If it was a user logged in, allow them to do this. And so you start creating these complex rules in your code to

handle because all you have is this shopping cart object that everybody has access to. So now how do you enforce that stuff? So it almost sounds like you're describing like, you know, a bunch of control flow type complexity and logic, like ifs and if statements and switch statements is kind of what I'm imagining as you were saying, you know, the example that you gave a customer service versus if you were to just contain that logic inside of individual classes and let them control the behaviors that are important to them, then maybe your only, you know, decision tree is based off of some factory that's deciding which type of the object is the appropriate one to return. Right. So you, you actually abstract that away a

little bit and now you've created those boundaries that you need. And, and I'm not saying that, that, you know, you can't do this stuff. I'm just saying, this is how I've seen systems organically grow, right? Like, uh, you know, it might start off and people were writing direct SQL against the table, or if it was a MongoDB thing, then they were just writing their statements to go pull the documents out. Right. And then they look at it and they're like, oh man, I have this stuff everywhere in my app now. Right. Like it's, it's spread throughout every tier in my application is calling directly to the database to get data out. Now it's manipulating it. Oh, but now I need to share that and I can't. So then the next thing is, okay, well, maybe let's take this SQL or this, you know, whatever this, this language is out of my code and let's put it

into an ORM, right? So it's like this natural evolution that I've seen many times. And there's these pitfalls along the way, because then you get an ORM and you're like, oh man, this is beautiful. I can use objects to go get my data. And then all of a sudden that spread everywhere into your code, right? So yeah, I mean, you're not removing the problem. You're just changing how you access it. So in once in the first scenario, you were accessing it via SQL because you were manually writing the SQL. And in this next scenario, you're accessing the same data, but you're letting some other framework write the SQL for you and just returning back the objects to you. So you've improved it, right? So instead of an ad hoc SQL thing that you might have to map to an object, now at least you have a consistent thing, right?

Like you have customer dot, you know, get by ID, you know, that that customer object is always going to be that particular type. Whereas when it was a SQL statement, you might have these DTOs all over the place. So you have improved a little, but you still have this problem to where it's sort of like crawling through your application. Right? I mean, is that what we've seen? Well, you hope it's just crawling one direction too.

You know, if you've got stuff that can call other things, like if you're cheating around that ORM calling SQL directly, in addition to having that ORM, or if you've got the database, you know, maybe some jobs running or something to actually call custom code, then now you've got some cycles and things get really hairy really quick. Thoughts? Oh, sorry. I, I, you caught me cheating. I was looking ahead at something else. So, I mean, that, that's part of the problem that I've seen as they grow, right? You, you'd started out bad, then you grow to an ORM and then you get into the situation where it's like, well, man, how do I enforce these business rules? Right. And so now you have all these things that are reaching out to the ORM directly.

So now you're tightly coupled because now, so you said you have the database to rule them all, right? You have the Lord of the Rings. It's right there in the middle. And unfortunately, now you're having performance problems. Now what are you going to do, right? Because you have everything going directly to the ORM that is also then reaching out directly to the database. So you are tightly coupled all the way, basically from your UI to your service call all the way into your database, right? And so now you have another problem. You know, how do I speed this thing up? What are you

going to do? Well, if you want to add caching in the middle, now you got to create some more abstractions. You got to start breaking apart your code. And I mean, it just seems like this keeps going on and on. Right. Yeah. It almost kind of sounds like part of the problem that you're describing is not allowing access to those ORM objects period. Right. Like that should be done through, uh, you know, some repository layer maybe, and that the actual objects being returned back to you just represent the specific, you know, case that you're trying to solve. Yeah. Okay, so what if we've got our database, right?

It's at the core. We've got an ORM wrapped around that, and then we've got kind of like a business layer where we do our permission-y stuff, our, you we've got kind of like a business layer where I do our, we do our permission stuff, our, you know, just kind of logical decisions who can do what. And then we've got like a web service layer, maybe a public API layer that kind of sits on top of that and kind of controls

the ingress and egress out of those out of that business layer. And so that at the very top level, you know, your website, your clients, whatever those guys only ever see the layer beneath so that at the very top level you know your website your clients whatever those guys only ever see the layer beneath like that public api or or um it doesn't have to be public your api or your web services and so later along the lines you can split that model of database into different things or you can use cache instead of the database or whatever and it's all kind of transparent to the client. Sort of. I would add one more layer in there, though.

So you said basically you have your database, then your ORM, then your business layer, right? In between that ORM and the business layer, I think I would have the repository. So basically what he was just saying, because then at that point, your ORM is what's talking to whatever the persistence layer is behind the scenes,

whether it's a database or whatever else, right? But the repository is what's basically going to populate objects with that data. And then your business layer only cares about talking to that repository. It knows nothing about the persistence layer. So that ORM knows about the persistence layer. And if you're using something like Entity Framework, then you could be using like, what is it, linked to entities, I think is think? Well, where I was really thinking, though, is that instead of allowing Entity Framework to creep throughout your entire code base, you have this repository, some layer of abstraction above it that you go through. And then that way, depending on what the use case is, you might have multiple customer objects throughout your code base or customer classes throughout your code base,

but depending on the namespace, they could mean different things. So you gave the example of customer service and maybe in the customer service example, that customer class doesn't have all of the same data that say accounting might see, or that the order might, you know, that the order fulfillment might use or something like that. That's kind of where I was thinking of. No, I agree.

So check this out. I was just doing a little Googling. I remembered a diagram I'd seen a little while back about, I think it was windows eight, but it had some nice kind of slices. And so I was just Googling around and I found a nice diagram of the Linux architecture. And it's kind of like what we described, except that the very core is the hardware.

And this is the memory, the CPU, the hard drive, all that stuff are these big wide open pools. Well, on top of that, you've got a kernel, which is kind of like similar to our ORM layer that we're talking about. We've got a shell on top of that. And then we've got these programs that run on top of the shell. And those each can have their own dedicated memory space that they can look

and they can't reach into other people's memory spaces. And so that's the first part where these divisions start. So up until then, you've just got kind of concentric circles. And then once we get to the actual application layer, things get split up because you can run different users users can be running different applications. And that's where we've got silos, like, you know, user A can't reach into user B's process memory and pull stuff out. You know, that's a huge security problem. I guess it happens, but real hammer. But, you know, those are the kinds of things that we're trying to avoid. And it sounds like it's a direct

correlation to the kind of architectures that we're talking about. It makes sense. I mean, if anybody's had to do it right, it's basically the OS's, right? So here's my question, right? So we've already talked about, you started out as this big monolithic reach everything thing, right? You just spread your code all throughout. That gets nasty. And then you just say it was a thing thing? Did I? I might have. It's very possible. So here's my question.

If you're building an application from scratch, do you build these layers in directly, immediately, knowing that the potential problems you're going to run into? Because this is the big issue as a developer, right? We talk, and we've said it, I don't know how many times on this show, build your MVP. Your MVP might be stupid,

simple, right? Like you literally just hard code in your connection to the database and you go get data, right? Where do you, where do you draw the line of what is the right place to start? First, you spend two years writing documents and having all day long meetings, right?

You forgot about writing tickets. So many tickets. There needs to be a ticket somewhere in there. But seriously, if you were going to start something today what what would be your bare minimum layers that you would introduce it really depends on the kind of app like if i'm doing something in java like a lot of times i try to avoid having a server at all um i don't do the serverless thing because i'm not even trying to like solve so like my first thing is like how can i even get this um as somewhere that I don't even have to host it?

Like I want to be able to host this on GitHub.io. So I don't want to have any sort of backend. So it really depends on the kind of app you're trying to build. That's a good point. So he hardcodes all of his data in JavaScript arrays. That's right. And if I'm building a website, it's, you know, WordPress is taking care of that for me. Okay.

Business level application. You have data that you need to persist. You have a UI. You have a server layer. What's where do you start? Where do you end? Like today, like based off the knowledge that we've done as developers over time, like before we get into like our next topics and in some upcoming episodes

where we talk about domain driven design and onion architecture and all that, before we go there, just thinking out loud, like what, what are the layers that you would definitely want to have in place before you really got rolling? Uh, definitely. I tend to think data first still. So think uh you know if i'm gonna have a database and i'm gonna want to start doing my stuff there and putting my tables there and kind of i think it's the cheapest to move columns around at that point you know it's easy to change relationships and stuff without having to do a lot of expensive ui work and middleware stuff so um that's where i like to start and from there if i think i need an ORM, that would be second. If it's going to be something small, then I would probably just skip that.

But I think in most cases, if it was a good-sized app, I would probably want some sort of layer there that was well thought out. And then I would probably start thinking API, whether that's, I call it a business layer, or I just kind of think of it as like web services, or even if it's just a DLL, that's kind of my next go-to. And then the rest is all just dependent on the clients I want. Okay. But you might. No, I would agree with that. I mean, I was thinking of something very similar to that. I think, I think for me, I'm really close to that. The only difference for me is having that ORM with a repository on top of it before

that business layer. Yeah. See, I think that's, I feel like that's something that would be, uh, refactored in eventually. It could. The only thing that I'm always worried about with that is when you have an ORM in place and you start reaching out to that directly, that's typically a pretty tight coupling, right? Like, but again, we were talking about, you know, like this is your MVP, right? And, and so reaching talking about, you know, like this is your MVP. Right. And so reaching out to the database doesn't necessarily have to be your hand-wrote SQL. It could be you have a stored procedure, which could still be used by an ORM, by the way. So it's not necessarily that that's throwaway code that prevents you from refactoring later for later use by an ORM.

No, it's true. You're very true. Like I said, I think I would throw in the repository. I'm not saying it's necessary and it might be overkill for that. It's very possible it is, but I like that separation because then you can also test that data more easily, right? Because if you have the ORM, you can't test it because now it's an integration. It's no longer a unit test. If you put that repository in the middle, you can then mock that data. You can create an interface for a customer repository, right? You can't, you can't mock an interface for an ORM customer because it needs to connect to some sort of persistence. And so that's kind of where I'm going. Like if you have any framework

and it's, and it's for SQL server, you're tied to SQL server. You're tied to a database at that point. Yeah. You know, with the example that we were talking about, we'd skipped the ORM, right? Like,

you know, the ORM was something you might bring in later. Oh no. The repository is what you said. You would have the ORM. No, no, no.

What Joe said. And I said, I was along the same lines was that you might skip the ORM. No, no, no. What Joe said and I said, I was along the same lines, was that you might skip the ORM to begin with. And so in that case, you're not tied to, you know, you're not necessarily, your object's not necessarily tied into it. I mean, you have some part that might be doing some sort of procedure calls. But, yeah, I mean, I understand what you're saying in regards to testability though, and that would be a huge factor. But another thing that I was thinking of as you were describing that, that would be a huge part of the decision cycle is,

well, like realistically, how much time do I think I'm going to have for any refactoring, right? Like, you know, if it's, if I don't think I'm going to have a lot of time, then yeah, that's definitely going to change some of the decision-making, right? Yeah. I mean, none of it's an easy thing. Like, I mean, when you sit down and really think about it, and this is, again, you know, we've joked about it. This is why I'm horrible about doing some of this stuff on my own is because I sit down and I'm like, well, if I was going to write the perfect app, how would I do it?

And I'm never trying to write anything that I'm going to release to the world. It's more about, you know, if I do this, what problem does it solve? What problem does it introduce? Because every layer you add adds complexity and it adds a ton of boilerplate code, right? Like that's probably the thing that I dislike the most about adding these layers is it's almost always boilerplate. But we're talking about this in regards to like, you know, a brand new greenfield application. But I mean, we've talked about this in the past as it relates to adding in new features to a brownfield application where, you know, even in that scenario, I've gone with the data first approach to make sure like, okay, you know, how I want those data structures to even look like

and how I want them to be returned and what I need to have returned before I even bother to work with a middle layer API or a front end UI. Yeah, that's true. I mean, go ahead. So I will say that I do think it's pretty telling that we're programmers um that we all started with the data like i think if you talk to like any

kind of design firm out there in the world and ask them what the first thing to do they would be like wireframe wireframes and then we move to like mock-ups or something and make sure that the client's happy with it we're solving the needs that they expect and this is the product they expect to deliver so when we talk about mvp like i think that we're kind of taking for granted we're going to get the data right and then we kind of know what the front end is going to look like because you know we're going to be using angular or react or something we kind of know what grids look like you know so we're not even thinking about that that much but uh if you're really talking about designing some sort of new business system like there are a ton of companies out there that would totally start in the exact

opposite direction and work in you know what's interesting about that you remember we went to a meetup i don't remember if you were here joe at the time or not but we went to the one where they did the interview the live interview thing right we've talked about this in the past yeah so one thing that he said that he loved to do is he would ask somebody all right so where are you going to start and if they started at the database and he'd throw a wrench at him, that was going to make it hard for the UI. And if you started at the UI, then he was going to throw a wrench at them that was going to make it hard for the database thing.

And it's true. Like if you come at it from the UI approach, you can totally mess up some things that are going to be driving your back end. If you'd start at the back end, you could totally make assumptions that are going to make your UI really a pain to use. So it should be a collaborative thing.

Like you should really find out what the need is and try and start from there, right? But it's a really interesting approach on that. Another approach though that I was thinking about like that I have done too, and I'm sure like you guys tell me if you've done this too, but there have been times where like, I'll have an idea of like some screen that, you know, or something that I need to add in or create. And, uh, I'll just, you know, put dummy data in there just to, so I can even get a feel for like, what data do I need? What might I even need? Let me just create like a, uh, you know, know, a skeleton of what this thing should look like.

And then I can go back and write, you know, the data structures to match it and come back to the middle layer, you know, the server layer to return that actual data. Right. Yep. You know, one thing, I mean, we've talked about some pitfalls and some of the things that happen, you know, one of the things that I do like about the database first approach is because that

is your source, that is your key kind of where, where the life of your application lives. If you need to make changes, you typically have fairly easy access to do it, right? Like if you're adding new columns or new features or whatever, you can even migrate that data, right? Like if you're adding new columns or new features or whatever, you can even migrate that data, right? Like if you need to do things like that, it's fairly, I don't want to say easy to do, but you have a, you have a known path as opposed to, um, which we haven't talked about. We'll get into if you're doing something like the code first approach where it kind of modifies your schema for you on the fly and that kind of thing. Like usually that's a little bit hairier. Wouldn't, would you agree? Uh, yeah, I, I, I can't really speak to that approach though. Cause I've never

really gone that approach, which shame on me. Right. Like I, that approach scares me. really does like the whole idea that you change your code and all of a sudden it changes your schema like that i mean because when you say code first like you're specifically talking about a particular you know framework and tool to do that where that you know as you in your code it's going to create that versus the scenario that i described a moment ago that kind of goes in line with what Joe was describing with, you know, depending on who's, uh, who you're asking the question to, you know, if like just mocking out something and even

getting a feel for like, you know, what data you might want on the screen, that's not what you're describing when you talk about code first. Yeah. Code first is you write your classes and based off that it will create your persistence layer for you right um that's what you're doing if you're doing test driven development then i would think you'd want to be code first like all the way so you would think okay i need to add a new column to this grid let me first change my api get those tests passing, and then I take it to the UI. I mean, I don't know if we want to skip ahead to talking about that, though, because that

sounds like it would have its own pitfalls. Like, go back to that scenario that I described where you have multiple customer objects, each in its own namespace. Well, if the code is creating it and these look like different objects from a class or different classes, or let me say this again, they look like different data structures from a class perspective, then it might think, oh, I got to have different schemas with different tables to map to these things. And it might not understand that, the actually these actually map to the same record it's just business rules are preventing all of the data or you know coming back to in certain scenarios right and maybe

somebody has a better example of that like i said like i i've never bothered with that approach i haven't either because it scares me i'm aware of it like, it just seems like a bad idea. So here's another thing is what we're talking about typically ends up being a monolith, right? Like when you, when you go this route, when you start at your database, it, it kind of grows into this monolithic application, which you hear a lot of things out there about nowadays, where it's like, oh, monoliths are bad and, you know, everything should be microservices and this and this and this, right? And I'm kind of wondering what you guys think about that. Is it such a bad thing to get into that monolithic realm? I don't want to start with microservices. That seems very not agile. It's definitely

overhead. There's no doubt about it. And so that's not the direction I'm starting from, unless I know that, you know, we're going to be doing something big. And if we're doing something that big, chances are, there's already something in place that we're going to be kind of modifying and slicing off chunks of. So at that point, we can think about going the microservice route, but I definitely don't think microservices first, but I'm also old. So, you know, I agree with that, though. And you know why? There's two reasons, at least in my thinking, is one, typically when you try and start with microservices first, you don't know some of the maybe the domain isn't clear to you yet as to exactly what that microservice

needs to do. So if you start out that way, you end up just modifying the heck out of them until you get to a place where it needs to be. But the second thing for me is those things don't come for free, right? Like when you start breaking apart your architecture like that, there's a lot of things you have to make sure that thing's alive, you know, because it's separate now from your system. So if there's a failure there, you need to have checks in place to make sure that if it does fail, that you're gracefully reacting to it.

Like there's a lot of additional things that happen when you start breaking these out into separate chunks, right? Deployments get a lot tougher. Way harder. Yeah, so maybe not microservices, but definitely micro parts within the same application, right? Good abstractions. Yes. And I think that's the key, right? Is if you have good abstractions and it sets you up for being able to do things like microservices later, right?

But it's funny. I listened to a podcast and I can't, I can't remember which one it was, but one of the guys that worked on, um, what is it? Base camp, I think is what it's called. One of the biggest Ruby on rails things out there. And that dude was actually arguing for monoliths. He's like, look, look man when you break things apart you complicate things right not everybody needs to be at scale of twitter and linkedin and those guys

so if you don't need it why make everything more difficult right like we've run into the problems where you break apart you know you have nu-git packages for your application and now you're managing you know 10 different projects that all kind of have to sync up into the right place. That can be, it can be hard, right? Yeah. I want to listen to that podcast now. I've seen articles about the, and I've heard the joking, jokingly named majestic monolith, but I haven't heard anything. So if, if anyone has any recommended resources, I'd love to hear it. Man, I'll have to go back and find it.

I don't remember which podcast it was. It's been a while since I listened to it, but it was the guy who actually wrote the main app. And he said, I don't remember how many millions of users are actually in that system, but it was massive, right? And he's like, hardware is cheap, man. If you need more scale, add more servers.

How much money are you going to spend rewriting your software to be, you know, little bite-sized chunks that can be scaled out a billion times? So it was an interesting take, and it's one that I think is important that people realize is, you know, sometimes there's value in having everything in one place at a time. It doesn't mean... Go ahead.

Oh, sorry. I'm bad about this. I was just looking at an article about a majestic monolith written by the guy that you were talking about, DHH. And they've got a nice little definition here that I thought was applicable. It says, what is a majestic monolith exactly?

It's an integrated system that collapses as many unnecessary conceptual models as possible, eliminates as much needless abstraction as you can swing a hammer at. It's a big fat no to distributing your system unless it truly prevents you from doing what really needs to be done. Hmm.

That's interesting. You have a link for that? We need to drop that in the show notes. Yep, sure do. Alright, cool. Yeah. Yeah, I like that. And also, can we please stop making spas for everything?

Dude, I like spas. I like spas when we need spas but let's you know like there's nothing wrong with web pages in a lot of scenarios i kind of agree with joe on this one man all right man it's so nice back in the day people still call them pages in fact i don't miss post bags like i hated post bags i didn't i didn't like when you go to refresh a page, it's like, Hey, you're about to resubmit this form information. Are you sure you're like, dude, as soon as I, as soon as I got to the point where I could write a single page application, I was so excited. I was like, man, this is because the other thing too, is, is people are always worried about server hits, right? Like how many pages can my server do or support or sustain?

And I was like, man, if you go to a spa, it's just JSON going back and forth or just little tiny bits of data, right? Like, your web server almost just becomes a transport for data, right? It's almost your middle tier at that point. Yeah, if only we could cast redundant parts of a website and so only the parts that need to change would actually change between pages. Yeah, if only we could cast redundant parts of a website and so only the parts that need to change would actually change between pages.

Yeah, if only. No, I mean, you're totally right. There's a reason why kind of spas evolved. Sometimes I miss them. And it's kind of funny to see a lot of modern apps now kind of trying to recreate pages, which just kind of is frustrating to me because in a way they are like kind of little isolated apps

and there's benefits to that. And so I miss that sometimes. And I'm hoping they come back. I'm with you there because like, it was like each page was its own SRP, right? So, so it was really nice.

You didn't have anything to worry about. And then when we went to spas, then it's like, okay, now this one thing has to know about every page well i think i think it has gone too far with spas for sure but like for instance if if you go into google analytics you guys should do this if you go in there and you click around for some of it you'll be in the same page you'll be in the app. If you click to something that is outside of that,

it'll take you to another, it's almost like a mini spa, right? Which, which is kind of cool. So I'm curious then if we've gone too far now, at what point, where did we hit the sweet spot? And then it was like, before we realized it, you know, things went to plaid. Yeah. I don't know. Oh, I know. Oh, okay. Yeah, like jQuery 1.2.1 was the peak. Everyone was so happy with jQuery. jQuery everywhere, and it just worked great.

And then all of a sudden we started thinking, oh, no, we need some frameworks here because we don't want all these dollar signs. And that's when things started heading back down. So jQuery was like the golden age of web programming. I somewhat disrespectfully disagree. Somewhat disrespectfully disagree. Dumb manipulation should die. And that is why jQuery was never the epitome of where it should have been. Because inevitably, it was like oh if you

click this we want to add a road to this table down here and then it was like you know get element by d add a tr add some t dude no no i mean i loved it and all the little ui stuff you could do all the little uh what like the plugins or whatever. And like, that was, that was truly a good time. Like one dot two dot, whatever it was, I think it was around 2007, man.

Like we were, I was at a web, small web firm, boutiques, uh, websites, man, we were rocking and rolling,

do all sorts of crazy stuff. Just like a dollar dot something. And then we like dot something else. And all of a sudden it's just things flying around everywhere. We were, we were calling Ajax left to right. This is amazing. I actually remember the first time one of my friends was like,

hey, I'm using this thing called XHTTP request. And I was like, what is that mess? And then all of a sudden it became a big thing, right? Because you remember the old school way of doing that stuff? Iframes and posting to hidden iframes. Or just frames. Oh yeah. Frames. You could totally do it that way too. Yeah. So those are the good old times, but yeah. So at any rate, I thought it was kind of neat to walk down this path of the, the, what we've seen as we've come

along. Right. And, and kind of where you end up is, is you have this thing that works, it's kind of a pain to maintain because it, it's not been abstracted over time. And it's, you know, it's, it's just how it grows, right. It's how, it's how software organically grows. So, yeah. So with that, let me take a moment to say that if, uh, if you have already taken the time out of your busy schedule to leave us a review, know that we greatly appreciate that you did that. And if you haven't, uh, let me just take a moment to speak directly to you and beg you to head to www.codingblocks.net slash review. And you can see Alan over there begging for your review. And you can find links to Stitcher or iTunes. And if

you have some other podcast aggregator that you use that you think that we should be mentioning there that you find great reviews on, let us know that too. But we would greatly appreciate it if you would take the time to leave us a review. Hey, speaking of, somebody did bring up one. Wasn't it called Podbean? Yes. Yes, Podbean actually has one. So we found out about that recently. So, you know, there's another source. And I think they actually have reviews on there. Man, we show up twice there too. What is that about? We're that good that we're doubly awesome. We should be listened to twice.

Yeah, apparently. So yeah, at any rate, check that out. And thank you for those that do leave reviews. And so with that, we head into my favorite portion of the show. Survey says. All right. So last episode, we asked, why did you start programming? And your choices were.

Needed to fulfill a business need. Wanted to personalize my MySpace theme. Took a class in school and thought it was awesome to make games, and lastly, I like getting paid to sit. I think that answer was really for the honest people. If you're being honest with yourself and with everyone else. All right. So let's see. It's his turn. But hold on. Did anybody age us because of the MySpace thing?

I think it would have been really bad if we'd said Friendster, but okay. Geocities, baby. Not that I know. What's that? What? Don't lie I have no idea

In my youth I'm so young I have no idea what you're talking about Okay So let's go on with this Joe you're up first Alright I'm going to say 33% to make games.

To make games, 33%. Man. This one I actually have no idea on. I'm going to say I like to get paid to sit, and we're going to go with 25. 25. Yes. All right. These are Price is Right rules right rules yes i lose these a lot by a dollar so if you go over you automatically lose and i'm sorry alan oh come on. Yeah, no Joe clobbered you on this one, but what was it? So he won doubly to make games is actually the most popular answer at thirty three percent. Oh

wow. Thirty three. Really? He hit it on the head. Yeah, cheated. I'm thinking he did too. You voted right beforehand or something like, well, what's up? Well, it sounds like only three people voted. So, so, you know, what's curious about this though, is when we did the previous survey where we said, Hey, what floats your boat? Right. Right. It was almost all business.

Right. And, but yet what got people into it is they wanted to make a skin for, you know, I guess it's, I guess it's business up front, uh, games in the back. I don't know. Business development up here. Yeah. Yeah. And you need to write the next big article. It goes around Reddit and Hacker News, like the mullet programmer. Yeah. All right. So, uh, with that, let's get into the next survey for this episode, which is how fast is your personal internet connection? So your choices are DSL speeds are amazing. Oh, less than five megabits or less than or equal to 25, and then 50, 75, 100, or you're greater than 100 megabits, or it's fiber for the win at one gigabit per second.

I have a feeling I'm going to have some envy after the results. Yeah? Maybe. Maybe. Either of you already have an idea where you think? Do you want to say where you think this one might land? I think most people are going to be under 25. Oh yeah oh i don't know man if the international vote comes out yeah it's gonna be like two gigabit per second we're gonna be crying is it really that

high i don't know what country are we in i was gonna say hmm yeah no i i think most of our listeners are u.s based i i'm gonna say less than 25 i mean it depends on what cities they live in yeah i think so i think so unless unless everybody just happens to answer from san francisco and then i'm screwed so but so where are you thinking joe i'm gonna say under 75 really what about you yep uh yeah i really don't have an idea i really expect everybody to be closer to like 75 or above honestly well at least among this community like i'm going to be surprised if you're right i will actually find that to be very interesting and curious. Well, the only reason I say is outside of true metropolitan areas, like it's, it's typically way lower.

So unless we get mostly people from major like Atlanta, San Fran, you know, Dallas, Texas, that kind of thing. I think it'll be lower. I think just aggregate. I will agree with that. But again, this is what I'm saying. If the conversation speeds around for average people all over the country, then yeah, your answer may be more likely.

But I think among developers, though, it's going to be higher. I think our listeners are lonely, and that's the only reason they're listening to us. Or maybe they're going to prove me wrong wow wow major diss there I didn't mean it like that the reason why they're listening to a podcast

is to have that developer community because they're not living in one like you Joe that's what I meant jeez as you listen to the sweet soldierultry jams yes coding blocks not just kidding wow that was totally not right that came out wrong so yeah i don't know we'll see that's gonna be an interesting one

all right so you know what really stinks joe is like when you're sitting around and and something goes wrong and you spend your entire day debugging something that's not that never happened to you right oh all the time it's been way too much time trying to tack down little things that end up being five minute fixes. Right. But it took you hours to get there, right? Absolutely. And if only there was some debugging or logging or something like that, that could, you know, at least give you back some of your programming day. Oh, yeah.

It sounds like something that we might have a little bit of information on here, huh? Yeah, absolutely. You should check out our new sponsor airbreak.io, which is a full stack error monitoring tool that alerts you to errors in your software, helps you diagnose and fix them. And so that basically means no more wasted time searching log files and more time actually writing and shipping great code. Yeah. I mean, in all honesty, it really does do that, right? You can, you have plugins for super popular frameworks like WordPress. You can plug it into a homegrown application like a.net PHP. Like there's tons of different things here that they offer and they

even have their own dashboard that you can go in and look at, you know, across your different applications. Hey, what are the errors that are coming in? How frequently are they? You can even inspect them, right? Yep, you can tie them back to releases. You can get a lot of information about when they started, how frequent they've been. Just a lot of really great information.

You can even add comments. You can review them. I mean, just the sky's the limit. Yeah, it's pretty amazing stuff. So again, they're one of our new sponsors here. You should definitely go check them out at get airbrake.com slash CB for your free 30 day trial. And don't we have something really cool to announce that we started with off here at the beginning of the show? Oh, I was hoping to do the announcer voice let's do this let's do this sign up at get airbrake.com slash cb for a free 30-day trial and the chance to win a 500 amazon gift card

it's a completely free trial and you'll be shocked by how much time it saves you again that's get airbrake. slash CB. Yeah, so go ahead. What were you about to say? Yeah, it's absolutely right. And just as we kind of talked about earlier, it's really easy to hook up. The documentation is fantastic. All the actual APIs and SDKs

for various programming languages and platforms are up on GitHub. And the documentation is fantastic. You can get this set up in minutes. No joke. I got a.NET site. I you can get this set up in minutes no joke i got a dot net site i got a wordpress site hooked up in literal minutes i tied releases in and i was able to instantly start seeing the types of crashes that were bringing my sites down and uh well that's a little bit embarrassing for me you might be crashing too and not even knowing it so you

should sign up for the trial and have a chance to win that $500 Amazon gift card. Hey, can we join? Oh, wait. Sorry. Right. I don't think so. I think we might have a little problem there. Might be a little revolt.

Okay. That makes sense. Alright, so picking back up where we left off. So we talked about the ways that we've been doing things over the years. And there's a lot of knowledge and a lot of lessons learned since all this has been going down, right? Like software is becoming more and more prevalent. And so better ways to do it and ways to maintain it now are out there. And so this was kind of lead to, this whole purpose was to lead into some of the topics that are going to be coming up,

such as domain-driven design, onion architecture, microservices, and how they fit in. And we've all somewhat, like I know, Mike, you've looked at domain-driven design a little bit. Joe, did you have a chance to look at it much yet? No crazy week.

It's a pretty small topic, right? I mean, it's only like a 600 page book, right? There's it's, it's amazing when you think about how much and how long we've all been doing this stuff and how much there still is to learn and know, right? Like, is, is there another profession on the planet to where you have to, to stay up as much as this one? Medical, maybe law, law, probably. Yeah. I mean, those, those two professions, I see that you definitely have to spend a lot of time in your, you know, quote, free time staying up to date with whatever, you know, current laws are or current medical practices are and medications that are out there. But yeah, I mean, it's a constant learning thing.

Like, it's a constant learning thing. Like it's amazing. And so one of the things that we do want to talk about is domain-driven design because we're not going to go into details here, but some of the problems that we talked about with these boundaries, right? Like having an ORM that's an entire layer. That's one of the problems that things like domain-driven design solves

because you're trying to solve problems for a specific area, right? Like we talked about customer service or accounting, you know, you think about things in terms of what do these people do, you know, what types of jobs, what types of behaviors do they have? So that's really interesting. And then I think after we go through that one, we're going to talk about the onion architecture, which I think Joe, you do know a little bit about that one too, right? Yep. Yeah. I've got a lot of really cool examples. I think that's going to be really good. I think they're all going to be really good episodes, but I'm particularly excited about this one.

Yeah, The Onion Architecture. Have you looked into this one, Mike? No, I haven't gotten into that. I've been focused on just catching up on DDD. Yeah, The Onion Architecture one's going to be fun. And we want to mention these things because in case you want to get ahead of it a little bit so that when we get into these conversations you'll at least be a little bit familiar with it so you'll be able to follow along because there's going to be some deep dives in there i mean just domain driven design like you said there's a 600 page book there's hours of videos out there on plural site many websites yeah lots of reading it really made me feel dumb yeah like

there there's this uh quote in one of the videos that was like a i think a socrates quote or something like that that was something along the lines of the more you learn the more you realize how much you don't know and this definitely was absolutely in that category yeah i definitely walked away feeling just dumb yeah it's it's like drinking through a fire hose is what they say right like there's so much information and it's hard to digest all at once so yeah you're like why didn't i already know this why wasn't you like why why did i wait this till now yep so and then we're also going to i think after those we'll probably touch on microservices because we sort of touched on it here a little bit

in the fact that it's one of those buzzwords that bugs me. Really? For one reason, because everybody's like, oh, you need to be doing microservices. If you're not doing microservices, you're doing it wrong. And it's like, man, there's overhead to that kind of stuff. But I think that can be said for everything, right? Like every buzzword that's out there, people seem to overdo it.

That's true. Right? That's true. I'll give you that. Like, I mean, we've had our solid jokes too, right? You never write anything. Yeah, if you go too far, you have nothing but a solution full of interfaces. Right? I mean, you could overdo everything

yeah it is interesting i mean the the whole problem of scale i mean did anybody have this like thinking about this from when we started programming 10 15 years ago anybody ever really worry about scale like was it really a big deal back then well no because you didn't have the networks that we have today right you were the speed you had you had single you know your application sat on single instances you know yeah it just you just didn't have the same kind of concurrent users that you have today you know what is part of the problem the fact that mobile is what it is now i mean mean, think about that, right? So back in the day, you really didn't have to worry about your web server

unless you were a Microsoft or a Google or somebody like that because we have 56-BOD modems, right? 56K-BOD modems. How hard could you actually hit a server at the time? But now, go ahead. I'm sorry. No, no, you're good. You're good. No, no. Well, I was just going to say, I think it's one of those things where the tools have gotten better. And so we're doing more with it. You know, 10 years ago, um, you know, there were a lot of

eyeballs on the internet, but they were all going to a lot of like static webpages for, you know, John Deere or whatever. But now I'm sure if you go to John Deere, it's probably like a fully fledged like e-commerce site, you know, and social network. So things have gotten a lot more complicated and we were expected to do a lot more with it. And so we're having to constantly push the envelope and the growth of hardware has slowed down a lot too. So we can't just constantly, you know, we can't just count on buying a new server every two years. I remember it too being different in that from what you were describing, the problem wasn't necessarily that you were worried about bogging down the resources of the server from like a server,

uh, from like a, a CPU or memory kind of utilization point of view, it was the network utilization. So like large images, it was, you know, image compression was huge,

right? Because, because you didn't have a fast network connection, nowhere near what you had today. If you did start having, you know, a quote high number of concurrent users, it was the network congestion that was your bottleneck and your problem is what I recall. 10 base T network connection. Yeah. Yeah. I mean, it's interesting

you think about it now. I wonder if like the advent of the smartphone has really sort of pushed this thing forward faster than what anybody would have thought. Because think about it, man, your phone is constantly pinging services all day long. If you have apps installed, you're getting notifications on your phone. It's because it's hitting the server, you know, constantly trying to find out, Hey, did I get anything new? Did I get anything new? And you know, you think about the Twitters and LinkedIn's of the world. I mean, the amount of traffic these places actually have to serve and stay up, you think about the Twitters and LinkedIn's of the world. I mean, the amount of traffic these places actually have to serve and stay up, dude, I'll never forget. Like I play

fantasy football. I'll never forget a few years ago, like ESPN had done this like major rewrite and they were having like this, this launch dude, the first football Sunday, everything died. And I was like, they didn't expect this? Like, really? But, I mean, it's just kind of exacerbated because now you see that on your phone. Like, literally, you stare at the phone and you see your numbers updating every five seconds or every second. So, I don't know. It's interesting. I think a lot of the problems that we face now are just the level of accessibility, plus the network bandwidth, plus just the sheer

number of people that have access to it now. Well, I mean, definitely in the last decade, scale has become a much bigger concern because there's more devices, people have more access to it. So going to your cell phone point of view, it's not just the cell phone, it's just necessarily, it's not necessarily the device so much as it is the fact that you have this device with you that's constantly accessing. So there's more access to it from more places by more devices, more people. So definitely scale has become a larger factor. Yeah, I'm actually looking at, I'm sorry. I'm terrible tonight. Sorry, everybody. No, I was just going to say say like here's a crazy thought you

know i i just it didn't even dawn on me but when i said it but i just said the last 10 years 10 years ago was when the iphone was introduced oh 2007 that's right ouch man yeah things changed well you guys have been um talking stuff i've been designing my own tractor on johndeer.com you can actually customize i mean i was just thinking like five years ago like you would kind of hope like maybe homedepot.com has a store locator i hope so or maybe i can find a phone number to call and now like that thing better tell me the freaking aisle and the store that i'm in that i picked up from my location. But yeah, I'm seriously designing. I'm picking my chair out right now on my $48,000 tractor.

Oh, validation. Go to, go to conflicts. The UI is really smooth. I can tell they're doing some, definitely some fancy UI stuff. Like,

you know, this is crazy. Do they have pages or is it a spa? It looks like pages to me. Nope. It's wrong. It's not, it's a spa? It looks like pages to me. Nope, it's not. It's not? It's a spa. That's beautiful. I've used source in seven lines.

We're winning. Yeah, man. I'm old fashioned compared to John Deere. There's something wrong here. That's hilarious. Wait, I can't find where you can build it. That's interesting. Of course, there's a configurator.

Right. I found myself at tirerack.com putting rims on my vehicles. What would those 24s look like on that little car? Right. 24s. Yeah, there's no rubber on them there's no room for it there's no suspension on it either right so anyways yeah i mean hopefully uh go ahead i was gonna say i'm

really excited about these topics because for a long time especially with clean code we've been really focused on like the very little parts like like the tiniest bits of coding. What to name your variables, what to name your functions, how many lines should be in your functions, should you comment, should you not, should you test? And so it's kind of cool to be able to zoom back and kind of talk about higher level stuff. And I think, at least for me, I spend a lot more time struggling with these issues than I do with the smaller kind of micro stuff that we've been talking about. So it's kind of cool. That's because everybody ignores that part. Right.

Well, you get the little stuff, right? It's like Van Halen with the M&Ms, right? You get the little stuff, right? Then the big stuff is probably good too. Well, you know, one of the interesting things that you say about this, and I pointed this out, I think, in our Slack community, was it's one of the hardest things when you're trying to set up an entire application because you get tied up in so many things, right? Like

we even talked about if you're one of those people that set up, what was it? MongoDB that got hit recently where everybody had their default passwords, like the sheer amount of stuff that you have to do to even stand an application up. It can be overwhelming even for people that have done it a hundred times, right? Like there's just a lot of stuff to remember. And like some of the, and this is where I was going with it is Joe put out some videos where he shows you just doing some stuff to where, Hey, let's not worry about all the infrastructure and let's not worry about all the infrastructure and let's not worry about all the setup and the tooling and everything. Let's just go do a yeoman setup and create your app and get rolling, right? And so I highly recommend if you are getting started in things,

don't try and get tied up in the architecture too much initially because it can really bog you down. Although I'm pretty sure Joe might want to correct you on the pronunciation, if I recall. Yeah, it's yeoman. But I really do think, at least for side projects, there's a 99,000 to 1 chance that your side project is going to wither and die before it ever gets launched. And your biggest problem is going to be a lack of follow through over scalability.

Yeah, it is. But again, I too am also excited about these upcoming topics because it will bring it all together, right? Like, and it's nice to see it. It's nice to think about, Hey, how can I do this? If I have it in my mind as I'm going along, how can I do this in a way to where I don't paint myself into a corner? Right. That's, that's really what it's about is just knowing that these things exist. Yeah. And it's about having fun too on your project. So like if the scalability is what excites you, then you, that's, you know, the core experience you're really trying to build, not so much the, uh, the output. So, I mean, do, do what you feel like so going back you know circling back to the original question about where do you start that's where everyone actually

starts is what's fun for you yeah it should be where you start right right it really should be yeah which for you is going to be machine learning for joe's going to be games and for me i don't even know scaling the data scaling data that's pretty much it dude i've actually gone as far in my mind as if i built a few servers in my house that's 64 gigs of ram each and had eight threaded processors i could set up a bunch of docker containers and make it look like a web farm or some sort of server like and then i'm like wait a second alan that's really stupid there there are uh cloud services out there that i can do that a lot cheaper heard of amazon right yeah that's the problem right like you could literally do this on amazon it costs you five bucks right do it the way that i'm talking about you're gonna be

it at five grand before you even do anything right five grand maybe not with you that might buy you half a server uh actually you know what's funny is I've spent, unfortunately, many late nights searching around on Newegg. They have refurbished servers that you can buy that might be a couple years old, but you can get some decent specs for $400 or $500. I'm not going to do it. I've talked myself out of it, but I have looked. The fact that he keeps tempting himself by looking tells me that he's eventually going to pull the trigger.

He's just waiting to find the, quote, right deal. It's like shopping for a Tesla P100D. I'm not going to do it. I want it, but I'm not going to do it. Yeah, man, I have a problem. I'm a hardware junkie. I don't know why. Sometimes I just add stuff to cart.

I'm just going to put it in the cart. I'm not going stuff to cart. I'm just going to put it in the cart. I'm not going to buy it. I'm just going to put it there for maybe later. Five minutes later, like, oh, crap, I got the confirmation. I guess I accidentally bought it. I don't know. Feels like weird mountain bikes lately. Hey, wait. What about

a new 1080? You know they just dropped 100 bucks, right? No. Yeah, so the NVIDIA G 1080 Ti was just released. And so those are going to be $700 now. And then the 1080s dropped to about $500. You can actually get some for about $470 now. So, yeah. Yeah, I might have to upgrade for that price that price see there you go my video card is six

years old oh dude that's that's good return right there yeah yeah and i never buy the top of the line like it was like you know it was in the sweet price point already so well you should feel good about this because it's no longer the top of the line it's just one step below it but man that thing you can buy last year's model today that's right that's right all right well let's move on yes so uh let's say in our resources that we like oh yeah did we have one yeah um i added the lean start we kept uh talking about mvps so we brought it up several times then today so i wanted to mention the book that kind of started that and talked about really focusing on building the minimum viable product for your business.

And I was kind of thinking when we were talking about designers kind of starting with the design, I think if the author of Lean Startup was listening in, he might tell us to start with Photoshop, get a really compelling, nice looking user interface and only keep adding server functionality until people start buying it. is to start with Photoshop, get a really compelling, nice-looking user interface, and only keep adding server functionality until people start buying it. And then you know that's when you get the product.

I don't know. I just think it's kind of cool. So it's a very different way of thinking about things, and it's probably kind of healthy for us. It'd be kind of cool if there was a conference that brought devs and designers together and had assigned seating or something and made everybody and like had a signed seating or something. I'm like made everybody talk somehow.

Signed seating. Designer dev, designer dev. Yeah. I mean, you, you don't even have to assign the scene ahead of time. You could just have someone like sitting at the door and you could just tell

by the clothes they're wearing, you know, like designer dev, designer dev, designer dev, designer dev. Oh, that's hilarious.

The devs would be dressed up nice, right? That's what you said. That's what I heard. No, that would depend on whether or not they're looking for a job or not. If they're looking for a job, they're going to be clean cut, dressed nice. That's excellent. I mean, look at us. All of us.

I'm looking good. Comic book t-shirt. That's the dressy shirt. That's hilarious. I'm looking good. You have a comic book t-shirt. That's the dressy shirt. Oh, that's hilarious. All right, so now it's time for my favorite part of the episode. It's the tip of the week. Yes. All right.

All right, I'm starting this time. So last episode, we did a contest. We got a lot of really great tips mailed in, and this was kind of like the runner-up. And we got this from both Joe great tips mailed in and this was kind of like the runner-up um and we got this from uh both joe really and uh paul seal they both mentioned bootstrap studio and actually paul seal has gone on to make a video showing you exactly how to use the site and uh create a responsive website without having to do any code which is kind of weird i feel a little bit weird when i first saw it, um, because I, I didn't like tools like dreamweaver and front page and things that kind of try to, you know, whizzy way editors that

try to do too much for you. And they would try to like, so, you know, why don't you drag and drop some stuff? Don't type, we'll take care of it. And it drove me crazy. But, um, now I'm kind of coming around a little bit. And now that I'm especially trying to focus on getting things that I don't care about as much just to be done and move on. It's really refreshing to have nice tools to be able to kind of like drag some stuff around, upload some images and have a nice compelling user interface without spending a lot of time. And if this was something I was going to maintain for the next three years, then I would probably build up from hand. I'm going to use Bootstrap. But if this is like a little prototype I want to try and get out over

the course of a weekend, then you might want to consider a tool like Bootstrap. But if this is like a little prototype I want to try and get out over the course of a weekend, then you might want to consider a tool like BootstrapStudio.io or Mobarese.com for getting together sites quickly and responsive without any code. Hey, so this Bootstrap Studio, what's it written in? Because it runs

across Windows 7, Mac OS and Linux? Isn't everything HTML5 now somehow? Yeah yeah you can run it in a browser or you can download it so i'm guessing it's html5 javascript and maybe electron oh electron yeah that's probably it okay i'm guessing excellent and so mine i actually have two only because i'm borrowing one from somebody and I wanted to share this other one as well. Where in the world is Carmen San Diego? Where in the world? You're welcome.

Yes. All right. So the first one is, is one that I got from Edward Lichman, who is in our Slack channel. And we were trying to troubleshoot something that he had a problem with and basically he had this situation where he would load a web page up it would all be there and then all of a sudden it would disappear and it was like what in the world's going on here and there is a little tool in Chrome developer I never knew existed. So I'm going to open it up real quick. If you go to the network tab, is it only the, yeah, the network tab, there is a little video camera looking icon right next to the filters and right after the clear and the stop button.

And if you click that thing, it will actually take screenshots of your page as it's doing things and so you'll have this stream of screenshots that you can see and when something happens you'll actually see where it changes so that's pretty nifty if you're just wanting to see like at what point in time something happened that gives you an idea and i I mean, I've never seen it. I've been on that developer tab, I don't know how many times over the past several years. So that was a pretty cool little thing. And then the other thing that really I just wanted to point out that I think a lot of people don't even know about, if you do visual studio development like.net or anything like that visual studio or visual studio.com you can sign up and i even i have a link here and it's to the pricing page but if you got a team of five people or less it's free and with that you get

unlimited git repos you get agile tools exploratory testing release management and all kinds of other stuff um unlimited users are free access to work items one private pipeline to run builds and deploy releases from your own server and one hosted pipeline four hours a month to run builds so if you're wanting to get into something and you want to you know work on your application life cycle or something like that this is an awesome way to go about doing this and it's another place that you could put your repos so um i highly recommend checking it out it integrates perfectly with visual studio surprise surprise uh so you know that's that's my tip that i want to throw out there but it doesn't

have to be visual studio no it doesn't because and here's where like because at first the way you're kind of describing you might be thinking like oh okay well it's just another place to put my git repo i already there's already github blah blah blah but what's really separating this from the rest of the pack here is that build pipeline yes that build pipeline is huge and this is why i'm saying like it doesn doesn't have to just be related to Visual Studio. You can actually do builds for Xcode in there. If you had anything JavaScript that you wanted to do, you, the, actually the build pipeline is pretty impressive and sweet. It's really simple to create that pipeline. Literally you, you would add a build step and there's just a wealth of options there that you're going to be surprised

as to what you can do in it. Anything from something as simple as if you needed to run a command line process to compiling Xamarin projects or what have you in between,ava uh projects it's it's pretty awesome i mean that's why i wanted to say is because a lot of people don't even realize it like the first place anybody thinks about is github right i'm going to go put my code up on github so it's it's an interesting thing to know about as as an alternative option and you can access it just like you would get code right like you can you get the URL, you can clone your repos, you can do all that kind of stuff. So yeah, it's pretty cool. Yep.

So, uh, my tip of the week, I wanted to share, um, Jamie Taylor had mentioned this from our Slack channel and I had never heard of this site, but, uh, you know how we've joked about fiddle all the things, right? And how there's like a fiddle for everything, right? So some genius out there on the internet, and I mean that in the most respectful way, made regx101.com. It's basically a fiddle for your regx. It's beautiful. You can, you can put your regular expression in there. You can give it as some sample test data, and then it'll explain what the regular expression is doing,

what it matched on. This might be the greatest thing since sliced bread. If it'll load. What? Yeah, it looks like it's down right now, but I actually use this last week. I was trying to,

to write a redx for email address, which I know is totally wrong. But the explanation is really fantastic and little tips it gives you. And even the way it matches is really cool. It's just great interface. Yeah, it is a very nice tool. So, you know, definitely give that one a go. And because we've even talked about regex recently as it relates to if you were looking for a part of your application

to introduce your first unit test, then maybe that's a place to do it. So this is just another tool you can add to your toolbox of something to check the regular expression or even help you and craft it initially oh this is really cool right yep yeah when he mentioned that i was like wait what i gotta what is this oh oh my that that might be the most amazing thing that has been brought to the internet yet did it's such a great. It takes one of the least understandable things

and least usable things in the programming universe and makes it much better. And you know, the thing is, this is one of those apps that I never think about because there's no real persistence, right? Like this is one of those things that is a great utility that stands on its own. Yeah, I mean, you can actually even like,

you know, pick your flavor of regular expression. So, you know, PHP versus JavaScript versus Python versus go. Yeah. And you can save these, you could share them.

Like it's, this is awesome. I love this. This is really good. Excellent. So thanks to Jamie for sharing this in the Slack channel. And that is why our Slack is great. To learn more tips, join our Slack.

Go to www.codingblogs.net slash Slack and sign up. Come in there. There's really amazing people in there. The community is awesome because of the people. Yeah, and I think that just about wraps this up. So we hope you guys enjoyed us kind of taking a larger viewpoint and setting the stage for some new things to come and let us know what you think. Yeah. And so with that, subscribe to us on iTunes, Stitcher and more using your favorite podcast app. Be sure to leave us a review. If you haven't already,

you can find links at www.codingblocks.net slash review. Visit us at codingblocks.net where you can find all our show notes, examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel,

codingblocks.slack.com. And be sure to follow us on twitter at coding blocks or head over to coding blocks.net and find all our social links uh at the top of the page well rehearsed that's what we are i get giggle every time every time i get there like oh yeah that's a great idea yeah we've done this a hundred times now and we still mess it up somehow. It's awesome. Hey Joe, don't you hate wasting time debugging code every week when you should actually be working on new code?

Yes, I really do. Let's try it again uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh uh uh uh

uh uh uh uh uh, uh,