Wrapping Up

[00:00:00]
>> You can catch me on Twitter, if you build something amazing or you get totally stuck or you need some kind of a review or whatever. I try to make myself as available as I possibly can to the community. I do like to eat, I do like to sleep and I'd like to see my family on occasion.

[00:00:21]
So, again, schedule permitting that I absolutely I love to answer questions, I love to interact. You can catch me on Twitter at simpleton as well as LinkedIn please send a connection request. And this is absolutely, I would say last year I had the opportunity to do enterprise patterns where I talked at length about the four elements of programming.

[00:00:50]
And we were able to build that out into some really cool stuff. And this is I think my second love letter to the development community and programming in general. So to that end, I think this is super powerful, I use these techniques a lot, and I feel like the joke I make is, take these ideas and go make a lot of money.

[00:01:15]
And seriously go make money with this, and when you do, let me know about it, because that to me is one of the best outcomes. Is that you've found a way to convert this into a valuable outcome and you're being compensated via monetary gains. Or you could barter for chickens or cows or whatever oftentimes I do actually barter my services but with that said, if you do something amazing, I would love to hear about it.

[00:01:46]
>> How would you create a mock API that is not hard coded, how do you sync it with real code?
>> The only thing that it's hard coded in this particular example is the interface itself. And so in that sense, you absolutely want to have a clear API contract or a data contract with whatever or whoever you're interacting with to consume.

[00:02:22]
When I think about hard coding, the only thing for me that is hard coded in the sense of canonical truth is the interface. From there, everything else should be dynamic, or should have the ability to be dynamic, but the interface itself is non negotiable. I would say as well if you're doing automated end to end testing, that you want to have the ability to mock your data out and test against mock data in cypress versus having to hit a real server every single time.

[00:03:05]
This is going to be the difference between your test running in let's say ten minutes and five hours in some cases. That you actually should have the ability to run a test against a real API but you also need to have the option to run it against a mock API that honors the contract.

[00:03:26]
So, to that end, I would say when we talk about hardcoding that the thing that you actually have to be crystal clear, it's sacrosanct, it is almost wholly, is that you have to honor the contract that needs to be written in stone. I say that a little bit facetiously but if somebody changes the contract, there's going to be a lot of problems.

[00:03:53]
But from there we're programmers and we can generate anything off of that. So hopefully I was able to answer that question is that, rarely do I hard code things if possible and sometimes I will, if it's appropriate. But more often than not, once I understand what the contract is, then I mean, I can generate a mock API.

[00:04:20]
And you'll notice here like, if I refresh this and hopefully this will work. And let's see if we can get this to go, Because this should actually think I go between 3 and 12 and so occasionally you'll see a word just as 3. The length here is actually dynamic and so it's even how many am I get, well, I don't know because it's dynamic.

[00:04:46]
And so that's where program against the interface everything else or hard code the interface or make hard assumptions about the interface. Everything else should be dynamic.
>> How easy is it to maintain these templates inside an organization, like where do you draw the line between building the components directly rather than working on the generator.

[00:05:13]
>> So the question is how easy is it to maintain the templates and kind of a tangent intent question is where do we draw the line between working on the generator and working on the templates? And so easy is absolutely relative with that said, it is a lot easier here when you have a clearly defined set of coding standards and conventions that your organization adheres to.

[00:05:52]
And if you are having trouble finding a good place to capture some kind of convention and automate around that. The question that I would ask or what I would want to discover with you is your code, written in such a way, do you have the right abstractions? Is your code fine grained enough to allow it to be automated?

[00:06:25]
Is it a candidate for that, so now to just kind of summarize this, is that when you have clear consistent guidelines that people follow, you can treat your code generators like every other piece of code in your organization. And so even in the sense of you'll notice that all my generators that they followed a specific interface.

[00:06:55]
Well now, anybody could write a generator, give it to me, and I could plug it in. And so again, this is where establishing that contract. So, for me, and hopefully you've seen how this works the wizard behind the curtain. I could write a generator from scratch, in well, at least as long as this workshop and actually much less.

[00:07:24]
And then write various templates to put into the generator and output code, that when you do it correctly, effort goes down is your skill and your perception goes up. So, I would say even on a personal level, and you could just do this it's your own desk, keep it as a magic trick if you want.

[00:07:55]
That, I'm hoping that when you look at what we've done today, you realize that what I'm proposing that some of this stuff would take 10 minutes. I mean we saw how long it took me to turn the Axions snippet of code into a reusable template. And so now when you start to factor in that, it actually is less effort to have a good set of templates in good, well architected code.

[00:08:30]
I think that the cost of investment becomes negligible. In other words, it cost very little and the upside is so high that I'm really hoping that the light bulbs went on for a few of us today. And this is something that's like, we are going to start doing this is just part of our regular development workflow.

[00:08:54]
And so, again, ECS is relative, but I believe in ECS for me my experience is that it's a lot easier to actually even individually to generate the conventional stuff. So you can focus on the stuff that's important. Any tips or techniques for dealing with non trivial data types?

[00:09:17]
One, realize that when you're dealing with a complex data model, that it's still just a data model. And more importantly is that the complexity is probably not in the data model but it's in the business rules that govern how you mutate that data model that's been my experience.

[00:09:38]
And treat that piece or any of the complexity is a candidate for isolation and optimization by removing the things that are unnecessary, consolidating the things that are duplicated, and then automating the things that are conventional. So the question is with mock data, what I recommend using tools like mock service worker or any number of the ones that exist?

[00:10:08]
I know for instance, there's one that my friend Wes Grimes wrote for nest, and it's called In-memory DB. And what it does basically is takes an interface or a model definition and it generates a bunch of mock data in memory for an SAPI. And the answer is absolutely that if there's a tool that achieves the outcome that you're looking for, leverage that to the max.

[00:10:42]
Even there's a number of things in terms of just even testing of generating mocks for test. If that enhances or accelerates your ability to build things that people love, absolutely use it. No, there was, without reservation, that's what we're here for. It's how fast and how effectively can we build relevant things.

[00:11:14]
And so obviously it wouldn't make sense to turn this into a wire cutter style dissertation, I give this one an eight out of 10 and whatever is that there's so many great tools out there. I couldn't possibly even begin to touch the tip of the iceberg. But again, use the tools that are available and leverage them.

[00:11:38]
And realize that a lot of times you get this not invented here syndrome worse like we didn't write it so we're gonna rewrite it. Even individuals there are certain people that just have an aversion to JavaScript frameworks or frameworks in general. And I would love to talk to one of these individuals, or if I ever met someone and honestly try to understand what their workflow is like.

[00:12:08]
Because I suspect that what they're doing is creating a quasi JavaScript framework every single time that they create a project. And so at least for me, because my identity is not wrapped up into like, I'm an Angular developer, or I'm a react developer. So now I'm constrained by those limiting belief is that really I think, for me is I wanna build great stuff that people love, and being very candid.

[00:12:44]
I learned that lesson the hard way when, in the first 10 years of my career when I was a flash developer. And that is how I identified my that was baked into my identity is that I am a flash flex developer. And I learned very quickly that that is a very precarious position to be in is that we are identity is not baked into tools or our framework.

[00:13:14]
Or even what we do for a living, it's amazing how when you ask somebody, so what do you do for a living? And without splitting hairs or becoming pedantic is a lot of times they'll say, I'm an Angular developer or I'm a React developer or whatever. And it's, like, that's interesting that, people that's what they say is like I am a, and then they'll insert some framework.

[00:13:45]
So a little bit, kinda a philosophical twist in there but to that end the underlying ideas that our identity is not baked in the tools that we use it's the things that we do and the tools only support that