Detailed Notes
In a digital landscape brimming with innovation, the allure of diverse technologies often leads to unintended consequences. In our latest podcast episode, hosts Rob Broadhead and Michael Meloche delve deep into the tangled web of technology sprawl. From personal coding repositories to organizational software ecosystems, they illuminate the challenges and opportunities inherent in managing a multitude of solutions. Join us as we unravel the complexities of technology sprawl and explore practical strategies for streamlining solutions and skillsets.
Understanding the Impact of Technology Sprawl
Rob and Michael highlight the ramifications of unchecked technology sprawl, drawing parallels between personal coding repositories and organizational software ecosystems. They emphasize how disparate solutions can lead to convoluted systems, inefficiencies, and maintenance headaches.
The Pitfalls of Unchecked Diversification
The hosts illustrate the pitfalls of unchecked diversification, using examples of developers and organizations succumbing to the allure of novelty without considering long-term implications. They discuss scenarios where developers veer off course, introducing new technologies that exacerbate complexity rather than solving problems efficiently.
The Dangers of Siloed Expertise
Both hosts caution against siloed expertise, particularly in the realm of quality assurance (QA). You do not want a disparate testing framework to hinder collaboration and scalability. In addition, they stress the importance of cohesive strategies and standardized approaches to mitigate risks associated with fragmented skill sets.
Navigating Technology Sprawl: Strategies for Simplification
Offering pragmatic solutions, the hosts advocate for proactive measures to streamline technology sprawl. They propose a strategic approach to consolidating diverse technologies, emphasizing the importance of aligning with organizational standards and fostering adaptability among team members.
Balancing Innovation with Stability
Rob and Michael underscore the delicate balance between innovation and stability, urging developers and organizations to prioritize cohesion over novelty. They advocate for thoughtful decision-making and adherence to established standards to ensure long-term viability and mitigate the risks of excessive diversification.
Charting a Course for Sustainable Growth
In closing, the hosts encourage listeners to assess their technological landscapes critically and embark on a journey toward simplification and standardization. They emphasize the value of collaboration, adaptability, and strategic decision-making in navigating the complexities of technology sprawl.
Feedback and questions are welcome at [email protected], and listeners are invited to connect with Develpreneur on YouTube for more insights and discussions. By focusing on mastering data integration, developers can unlock new possibilities and streamline their workflows.
Additional Resources * Software Development Challenges and How To Navigate Them - https://develpreneur.com/software-development-challenges-and-how-to-navigate-them/ * Leverage Your Unique Skills – Interview With Tyler Foley - https://develpreneur.com/leverage-your-unique-skills-interview-with-tyler-foley/ * Run Towards Success Not Away From Challenges - https://develpreneur.com/run-towards-success-not-away-from-challenges/ * Learning From Challenges – A Season With a Positive Focus - https://develpreneur.com/learning-from-challenges-a-season-with-a-positive-focus/
Transcript Text
[Music] and there we go so that was a good like well that's that's again that's a couple of those that we could go every the more we think about it more like we could go eight different ways easily on that a couple of times over so I think we may come back to that glad you kept pinging me back because I took your initial question a totally different direction and I'm glad you pulled me back on that because you're right there's so many Pathways there's so many branches we could go with this and ultimately at least with this one the big thing is understand what your organization needs or what they want what their standards are and really follow that path with what you bring to the table now if you have something great bleeding edge Cutting Edge in a company say like a Fortune 500 that might not go over well but if you're bringing it to a hackathon yes bring the latest technology bring something new try something that's what hackathons are for not trying to do it in a full implementation on a brand new or on an existing application within an organization unless that's the only organization I mean I've been to a couple of those where if you got like you said startups and that sometimes that's the thing to do is they say hey this is what we're we have no Legacy we have nothing and then it's like that's the perfect time to do something brand new or I've got a customer that they had some level of sprawl it was it's it is in an MVC sort of a it's in a you know an interior architecture it sense that they have like a they have a UI they have an API they have a database they've got a mobile they've got these different silos but then looking at it I was like you know but I can combine like the web and the API real easy and then I can share code and then I have less I have to test because I don't have to you know even if it's the exact same code we'll say in quotes that we copy and paste from a web you know from our web page that's in whatever language to an API built in the same language so let like say we've got for some reason we've got JSP front end and we've got a Java backend API we could copy and paste that code but then we still need to test it in both of those environments if we actually have one solution that we're hitting so we know we're hitting the exact same code this actually goes into like microservices and stuff like that a little bit I guess you could do those things or lambdas and such but that's again it goes to the idea let's have less points of failure and so that means there's less to task that means you you can actually beat on stuff faster you can verify yes it's good or hit hit its bugs a lot quicker because it's also going to be hit more often so that was sort of where I was thinking on that one and it was just because that was near and dear to my heart the only issue with that is if you don't have established testing in place doing something like that can be total chaos because you pull code from here try to work over here well it's not working well why is it not working because you don't have the test or you don't have those requirements Define so re touching and rewriting that code can become complex and very expensive to go from A to B without that testing so and that's sort of where I'm at is it's because they don't have they weren't consistent in how those two things worked and that's that's I think we've talked about that where like I've got one I had one case where I had three different I had essentially the same function written three different times in this different code because some people hadn't been pay paying attention what they were doing so they kept solving the same problem and finally had to just like take one is basically like I'm going to take this one everybody else is going to call that one and then we're going to fix everything so that it works that yeah it was a pain in the butt it that's one of those even if we have the test we are still going to break it in those other places because they have a different they're thinking a little differently about what they're sending in and what they're expecting back and that's actually what I've been tracking through with a lot of this is I was like oh cool I can do all of this and API it's awesome and kick the data out and then I realized that the way they way they expect that to be packaged back to them varies a little bit it's like some it's in a a response with a status sometimes the response has the status just the whole thing is just munged together and so it's one of those it's like you know it's all Json so it's easy enough for it's like oh okay here's what it is and I just got to go grab that node but if it's expecting a node that's not there then it blows up so that's sort of the good the bad is I can run through it and if it blows up then I can go track down and go oh something in here is expecting you know a different name or a different value or a slightly different format what are you testing with me right now I'm not doing like I'm not running like an automated test I'm actually going through and just throw two things out at you to hopefully at some point you can get to this rest assured um I forgot the other one but rest assur definitely oh and assert J um apply those to rest assur is the API open API framework for testing uh and if you're testing with any integration points you can use uh test containers and mock server to mock the endpoints if you need any integration testing but definitely do rest assured testing and assert J and if it fails it'll tell if you're using assert J if it fails and it's a specific Json value that's missing it will tell you hey we're expecting this but we got this so a certain J gives you a very clean uh error message as far as uh data comparison versus uh unit testing well but I can't use the that's the thing is this is this is after the fact so it's like I'm sitting on a so it's an Android application that has been built out that is trying to talk to an API that I'm now I'm basically going back and re I'm moving it to a whole new AP AP and so it's trying to figure out how to it's really it's it is it's an integration issue at this point because it's basically the API has been updated and has some stuff that's a little bit different and a little bit uh there have been some changes in the back end that have to flow all the way to the front end so now the front end has to change um so I have to look at how did it used to how is it that it used to look at the API to re because I'm also trying to like minimize code changes on that front end and so it's like in some cases where it would be if I was doing it from scratch then or if I want to just rewrite that function or that method I'd say you know what I'm going to go do it and here's where I'm going to grab the Val but since I'm trying to not touch the data I'm actually using the mobile app as I'm just walking through and using it and I've just got I'm like in you know debug or Hell or Heaven depending on what you look at and I just am like going through and stepping through stpp and going okay yes it's making this call yes it's doing this it's do and just literally combing through the code to figure out where is it doing stuff that's consistent Within itself and where is it doing stuff differently and where it is trying to figure out why they're doing it and if it is adjust accordingly and if not say okay let's just you know go back and standardize that to how the works and so it's been a it's just one of those it's like you it's it's walking into again it's an existing system that's been around for years and works sort of but they've got a lot of things that were not AR so it's rearching it almost from scratch and actually it was the guy that's the customer was like it may easier to build this from scratch and some of the pieces I have so it was like it was PHP front end PHP API and I looked at all of that stuff and I was like I'm gonna do it all on python I'm gonna do it I'm G like I'm gonna get out of all of that kind of stuff and it's basically because it was built on a couple of Frameworks that were just gotten a little bit out of control it was a little bit they did they they didn't understand I think what they were doing so they were relying too much on the framework I said you know what I'm just going to do it this way because I would rather do it than back and then figure out all that PHP and I'm going to rewrite it anyways because he said we've got tons of bugs but they don't have like they don't really keep track of them they just no stuff breaks they don't you know they so it's like okay let's just do something that we know what there let's you know we know how it works as opposed to trying to learn somebody else's thousands and thousands of lines of code and it's I expected is there a way you could essentially stand up a mock server for like hard-coded endpoints basically just feedback basically if you make a call return this uh and then change that endpoint that that data to what you would what the change would be and then see what the front end does with it that's sort of what I'm doing but I don't need a mock server because I've got data and everything else set up so what I do is I have the I'll hit I'll hit it with the the call and look at what it's bringing back which would be basically what I would do otherwise it would just be a mock and actually I guess I've got I've got access to their prior one so what I do is I'll look at it I'll say okay this isn't working so I'll go hit the old one and say well what were they getting and then I can go look at the current one and say okay well what are we sending and go oh you know we renamed a f a variable or we've moved the structure around and then and then it's you know it's changing it out so I've actually got the this one of those a nice thing in a sense is that I have those which you would normally need to mock something for I don't need to because I've already got I've got a fully populated database and and examples to use so I can use a my mock is actually existing stuff that's been stood up so it's now it's down to really it's like it's almost in you know testing mode of it like oh this failed a test all right now I've got to go fix the code so it's not it's like stuff that I can already quickly hit the te I can find out that it fails quickly and then it's like okay let's figure out how we fix it do we want to make it work all like the new stuff does or is there something that we missed with the old stuff because again that's also it's not it is documented but it's not there's a lot of do documentation but there's also a lot of details that have sort of been just missed that have been overlooked so it's just all in all it's a really fun project it's one of those it's like are you running P test to go with it so that before you deploy your code you run and if your pie test pass you uh your deployment goes out or if it fails it stops the deployment no not right now I haven't I've thought about going back and throw and throw and I think I'm going to wait because the the API is itself a little bit in flux and it's well it's say it's the pieces that are there are are solid but it's still growing a little bit and just because of the time frames because this is one of those they would love to have at like last month I'm I'm doing the the obligatory I'm punting on documentation like they want pipelines they want cicd they want all this stuff and I was like that's great but there's only so much we can do in the amount of time so we're basically going to build this out and then I'm going to back fill it and say okay now go back and like build out all of those so we'll have you know a real nice you know from Soup To Nuts testing documentation and all that and it is nice I mean it's like a lot of the pieces I'm using are so that it's building documentation it's sort of like the API has got its own front end and and documentation side things like that but it's just uh yeah it's one of those it's it's do as I say don't do as I do because that's exactly what we're running into but it's also it's a time thing it's just like they can't what they would like to have and what would be the right the in quotes right way to do it they can't afford it right now it's like we go to like we've got to move too fast so we can't go back and retrofit those tests and that documentation instead we're going to have to just sort of like put to-dos all over the place generate a lot of technical debt and then come back after the fact and I've already told him I was like look if we can get to like a an Alpha Beta release where it's like okay now we can get in front of people and so their users can start testing it it's stable enough that they can start beating on it then they can do that and while we're going through that test debug cycle then can start generating out some unit tests and some of that kind of pieces so that it's it's you know we can stabilize it essentially are you using Postman at all oh yeah I use it fairly regularly I think actually now I haven't had to as much because I've got I'm always watching what the the mobile app is hitting but I I use Postman a ton for for all of those piece anything API related I'm all about Postman so see if there's an equivalent to rest assured for python I think there is uh for future because I know you do a lot of PHP in Python but the I've noticed there's a lot of equivalence if you're a very proficient uh Postman User it's very easy to go from that to writing uh rest assured type scripts because the uh the layout is very similar it's like if you were to export uh Postman it would almost look identical just writing it in whatever language you're writing it in and that's what it's got they've got one that's um basically they've got like a it's because it jeno can do websites but it also has a rest framework which is what i' I've rolled it back into as I started looking I was like shoot I can it's going to be a lot easier for me to just reduce effort and roll all this in so that there's one server can serve the web and the the API and if we want to spin it up in two places so be it and they also have a test client that there's a Django test client that built specifically for that as well um so I may use that or I may use like I've used flask and some other things through testing in the past that makes it pretty easy to just crank out unit tests for particularly for API so we'll sort of see as I get further into it which is the easier way to go and it may be something I signed one of the other guys to I may dep on what we've got I'll be like hey here's a handful of tests start knocking them out last time I tried that it sucked they it was not a very good one I ended up coming back like I'd say okay here's like 15 tests I'm expecting you to write they could write three of them because they could only write like the Happy path case for the for each thing and like no it's like it's not that hard it's like here's your parameters here's the some some general processes like what if it doesn't exist what if it's out of bounds like all of those kinds of thing what if the server's dead you know those things it's like these are what you can do to build out your test and it was just really tough to get that going but I may swing back around to it because guys you know learn more along the way now I run into that every day even with senior guys yeah they see a lot of those as well you're testing the framework we don't need to test the framework I'm like but wait this is input if the input changes you should be testing user input and it's a constant argument yeah yeah I've have run into it I run I have that argue with myself sometimes it's like I really need to test this like ah and it's like usually it's like because the customer will find out when there's a bug and then I they'll let me know but then it's like no I need to do I I just I ran out with the customer the day is that I would like realize that we had moved really fast on a couple things so we had a I I built something out selenium that just like runs through the whole site and just test all this stuff out and we made a bunch of changes and I hadn't gone back and updated it so I had one that kicked out and it was like like right away you can find it as a user and if I had updated stuff I would have found right away with that I was like and so I told the C like I'm sorry my bad I'm going to go back and update those tests and get that stuff I'm going to go back and update our test Suite because we just we got out of sink and then you know your tests are useless at that point so all right well I am going to go be useless and I'm going to go shop at Aldi apparently and go get some groceries and stuff so um we'll wrap this one up and I guess we'll do it again same time next week basically unless we find a better time to do it uh are you done did you say the uh the uh co-starters is done are yeah we're done we can go back to our normal time oh okay well cool so yeah we'll have to we maybe catch up and do a little uh debrief on that I'll be interested to hear how you what you got out of it and all that kind of good stuff may even do that may do that as an episode next week I think that'd be sort of cool to just be like hey went through this thing this is what I learned and what we we got out of it because that's that's honestly what I've been working with with the uh the lead generation guys I've had I I've actually I just told him today I was like I'm going to pause because I haven't gotten haven't gotten any sales out of it I've gotten some leads but I haven't gotten sales out of it and I was like you know there's nothing I can do it's like if I'm not getting sales out of it it's not worth spending the money but a lot of it has been conversations I've had with him and it's like well here's some things you can do and here's some templates and here's you know some things to try to build a better offer and I think those things are great for us to cover in you know future podcast episodes in particular it's like what what are some lessons learned that we've learned and are still learning in some cases about how to how to brand and and how to focus so yeah is the big thing was I got Envision QA up.com it's now live um and you saw the free stuff I kind of wish I taken screenshots of that before uploading it but um that was the biggest thing because that almost organically everything on my site came from uh what they pushed us to for pitch not and that's the thing is I think that's what you once you have it you can repurpose it that's where you can go back and you can like put it on your website and you can put it into flyers and you can put it out on all of the job sites and and into your emails and all that kind of stuff and that's that's what I've been trying to get to is it's you know I just I have not spent enough Business Development time lately and I got to get back to that so I can I can Circle back and refine some of those messages and and get those updated across the board so all right I'll let you get to it and have a good weekend and we'll talk to you next time around all right take care everyone have a great day good one he bye [Music]
Transcript Segments
[Music]
and there we go so that was a good like
well that's that's again that's a couple
of those that we could go every the more
we think about it more like we could go
eight different ways easily on that a
couple of times over so I think we may
come back to that glad you kept pinging
me back because I took your initial
question a totally different direction
and I'm glad you pulled me back on that
because you're right there's so many
Pathways there's so many branches we
could go with this and ultimately at
least with this one the big thing is
understand what your organization needs
or what they want what their standards
are and really follow that path with
what you bring to the table now if you
have something great bleeding edge
Cutting Edge in a company say like a
Fortune 500 that might not go over well
but if you're bringing it to a hackathon
yes bring the latest technology bring
something new try something that's what
hackathons are for not trying to do it
in a full implementation on a brand new
or on an existing application within an
organization unless that's the only
organization I mean I've been to a
couple of those where if you got like
you said startups and that sometimes
that's the thing to do is they say hey
this is what we're we have no Legacy we
have nothing and then it's like that's
the perfect time to do something brand
new or I've got a customer that they had
some level of sprawl it was it's it is
in an MVC sort of a it's in a you know
an interior architecture it sense that
they have like a they have a UI they
have an API they have a database they've
got a mobile they've got these different
silos but then looking at it I was like
you know but I can combine like the web
and the API real easy and then I can
share code and then I have less I have
to test because I don't have to you know
even if it's the exact same code we'll
say in quotes that we copy and paste
from a web you know from our web page
that's in whatever language to an API
built in the same language so let like
say we've got for some reason we've got
JSP front end and we've got a Java
backend API we could copy and paste that
code but then we still need to test it
in both of those environments if we
actually have one solution that we're
hitting so we know we're hitting the
exact same code this actually goes into
like microservices and stuff like that a
little bit I guess you could do those
things or lambdas and such but that's
again it goes to the idea let's have
less points of failure and so that means
there's less to task that means you you
can actually beat on stuff faster you
can verify yes it's good or hit hit its
bugs a lot quicker because it's also
going to be hit more often so that was
sort of where I was thinking on that one
and it was just because that was near
and dear to my heart the only issue with
that is if you don't have established
testing in place doing something like
that can be total chaos because you pull
code from here try to work over here
well it's not working well why is it not
working because you don't have the test
or you don't have those requirements
Define so re touching and rewriting that
code can become complex
and very expensive to go from A to B
without that testing so and that's sort
of where I'm at is it's because they
don't have they weren't consistent in
how those two things worked and that's
that's I think we've talked about that
where like I've got one I had one case
where I had three different I had
essentially the same function written
three different times in this different
code because some people hadn't been pay
paying attention what they were doing so
they kept solving the same problem and
finally had to just like take one is
basically like I'm going to take this
one everybody else is going to call that
one and then we're going to fix
everything so that it works that yeah it
was a pain in the butt it that's one of
those even if we have the test we are
still going to break it in those other
places because they have a different
they're thinking a little differently
about what they're sending in and what
they're expecting back and that's
actually what I've been tracking through
with a lot of this is I was like oh cool
I can do all of this and API it's
awesome and kick the data out and then I
realized that the way
they way they expect that to be packaged
back to them varies a little bit it's
like some it's in a a response with a
status sometimes the response has the
status just the whole thing is just
munged together and so it's one of those
it's like you know it's all Json so it's
easy enough for it's like oh okay here's
what it is and I just got to go grab
that node but if it's expecting a node
that's not there then it blows up so
that's sort of the good the bad is I can
run through it and if it blows up then I
can go track down and go oh something in
here is expecting you know a different
name or a different value or a slightly
different format what are you testing
with me right now I'm not doing like I'm
not running like an automated test I'm
actually going through and just throw
two things out at you to hopefully at
some point you can get to this rest
assured
um I forgot the other one but rest assur
definitely oh and assert J um apply
those
to rest assur is the API open API
framework for testing uh and if you're
testing with any integration points you
can use uh test containers and mock
server to mock the endpoints if you need
any integration testing but definitely
do rest assured testing and assert J and
if it fails it'll tell if you're using
assert J if it fails and it's a specific
Json value that's missing it will tell
you hey we're expecting this but we got
this so a certain J gives you a very
clean uh error message as far as uh data
comparison versus uh unit testing well
but I can't use the that's the thing is
this is this is after the fact so it's
like I'm sitting on a so it's an Android
application that has been built out that
is trying to talk to an API that I'm now
I'm basically going back and re I'm
moving it to a whole new AP AP and so
it's trying to figure out how to it's
really it's it is it's an integration
issue at this point because it's
basically the API has been updated and
has some stuff that's a little bit
different and a little bit uh there have
been some changes in the back end that
have to flow all the way to the front
end so now the front end has to change
um so I have to look at how did it used
to how is it that it used to look at the
API to re because I'm also trying to
like minimize code changes on that front
end and so it's like in some cases where
it would be if I was doing it from
scratch then or if I want to just
rewrite that function or that method I'd
say you know what I'm going to go do it
and here's where I'm going to grab the
Val but since I'm trying to not touch
the data I'm actually using the mobile
app as I'm just walking through and
using it and I've just got I'm like in
you know debug or Hell or Heaven
depending on what you look at and I just
am like going through and stepping
through stpp and going okay yes it's
making this call yes it's doing this
it's do and just literally combing
through the code to figure out where is
it doing stuff that's consistent Within
itself and where is it doing stuff
differently and where it is trying to
figure out why they're doing it and if
it is adjust accordingly and if not say
okay let's just you know go back and
standardize that to how the works and so
it's been a it's just one of those it's
like you it's it's walking into again
it's an existing system that's been
around for years and works sort of but
they've got a lot of things that were
not AR so it's rearching it almost from
scratch and actually it was the guy
that's the customer was like it may
easier to build this from scratch and
some of the pieces I have so it was like
it was PHP front end PHP
API and I looked at all of that stuff
and I was like I'm gonna do it all on
python I'm gonna do it I'm G like I'm
gonna get out of all of that kind of
stuff and it's basically because it was
built on a couple of Frameworks that
were just gotten a little bit out of
control it was a little bit they did
they they didn't understand I think what
they were doing so they were relying too
much on the framework I said you know
what I'm just going to do it this way
because I would rather do it than back
and then figure out all that PHP and I'm
going to rewrite it anyways because he
said we've got tons of bugs but they
don't have like they don't really keep
track of them they just no stuff breaks
they don't you know they so it's like
okay let's just do something that we
know what there let's you know we know
how it works as opposed to trying to
learn somebody else's thousands and
thousands of lines of code and it's I
expected is there a way you could
essentially stand up a mock server for
like hard-coded endpoints basically just
feedback basically if you make a call
return this uh and then change that
endpoint that that data to what you
would what the change would be and then
see what the front end does with it
that's sort of what I'm doing but I
don't need a mock server because I've
got data and everything else set up so
what I do is I have the I'll hit I'll
hit it with the the call and look at
what it's bringing back which would be
basically what I would do otherwise it
would just be a mock and actually I
guess I've got I've got access to their
prior one so what I do is I'll look at
it I'll say okay this isn't working so
I'll go hit the old one and say well
what were they getting and then I can go
look at the current one and say okay
well what are we sending and go oh you
know we renamed a f a variable or we've
moved the structure around and then and
then it's you know it's changing it out
so I've actually got the this one of
those a nice thing in a sense is that I
have those which you would normally need
to mock something for I don't need to
because I've already got I've got a
fully populated database and and
examples to use so I can use a my mock
is actually existing stuff that's been
stood up so it's now it's down to really
it's like it's almost in you know
testing mode of it like oh this failed a
test all right now I've got to go fix
the code so it's not it's like stuff
that I can already quickly hit the te I
can find out that it fails quickly and
then it's like okay let's figure out how
we fix it do we want to make it work all
like the new stuff does or is there
something that we missed with the old
stuff because again that's also it's not
it is documented but it's not there's a
lot of do documentation but there's also
a lot of details that have sort of been
just missed that have been overlooked so
it's just all in all it's a really fun
project it's one of those it's like are
you running P test to go with it so that
before you deploy your code you run and
if your pie test pass you uh your
deployment goes out or if it fails it
stops the deployment no not right now I
haven't I've thought about going back
and throw and throw and I think I'm
going to wait because the the
API is itself a little bit in flux and
it's well it's say it's the pieces that
are there are are solid but it's still
growing a little bit and just because of
the time frames because this is one of
those they would love to have at like
last month I'm I'm doing the the
obligatory I'm punting on documentation
like they want pipelines they want cicd
they want all this stuff and I was like
that's great but there's only so much we
can do in the amount of time so we're
basically going to build this out and
then I'm going to back fill it and say
okay now go back and like build out all
of those so we'll have you know a real
nice you know from Soup To Nuts testing
documentation and all that and it is
nice I mean it's like a lot of the
pieces I'm using are so that it's
building documentation it's sort of like
the API has got its own front end and
and documentation side things like that
but it's just uh yeah it's one of those
it's it's do as I say don't do as I do
because that's exactly what we're
running into but it's also it's a time
thing it's just like they can't what
they would like to have and what would
be the right the in quotes right way to
do it they can't afford it right now
it's like we go to like we've got to
move too fast so we can't go back and
retrofit those tests and that
documentation instead we're going to
have to just sort of like put to-dos all
over the place generate a lot of
technical debt and then come back after
the fact and I've already told him I was
like look if we can get to like a an
Alpha Beta release where it's like okay
now we can get in front of people and so
their users can start testing it it's
stable enough that they can start
beating on it then they can do that and
while we're going through that test
debug cycle then can start generating
out some unit tests and some of that
kind of pieces so that it's it's you
know we can stabilize it essentially are
you using Postman at all oh yeah I use
it fairly regularly I think actually now
I haven't had to as much because I've
got I'm always watching what the the
mobile app is hitting but I I use
Postman a ton for for all of those piece
anything API related I'm all about
Postman so see if there's an equivalent
to rest assured for python I think there
is uh for future because I know you do a
lot of PHP in Python but the I've
noticed there's a lot of equivalence if
you're a very proficient uh Postman User
it's very easy to go from that to
writing uh rest assured type scripts
because the uh the layout is very
similar it's like if you were to export
uh Postman it would almost look
identical just writing it in whatever
language you're writing it in and that's
what it's got they've got one that's um
basically they've got like a it's
because it jeno can do websites but it
also has a rest framework which is what
i' I've rolled it back into as I started
looking I was like shoot I can it's
going to be a lot easier for me to
just reduce effort and roll all this in
so that there's one server can serve the
web and the the API and if we want to
spin it up in two places so be it and
they also have a test client that
there's a Django test client that built
specifically for that as well um so I
may use that or I may use like I've used
flask and some other things through
testing in the past that makes it pretty
easy to just crank out unit tests for
particularly for API so we'll sort of
see as I get further into it which is
the easier way to go and it may be
something I signed one of the other guys
to I may dep on what we've got I'll be
like hey here's a handful of tests start
knocking them out last time I tried that
it sucked they it was not a very good
one I ended up coming back like I'd say
okay here's like 15 tests I'm expecting
you to write they could write three of
them because they could only write like
the Happy path case for the for each
thing and like no it's like it's not
that hard it's like here's your
parameters here's the some some general
processes like what if it doesn't exist
what if it's out of bounds like all of
those kinds of thing what if the
server's dead you know those things it's
like these are what you can do to build
out your test and it was just really
tough to get that going but I may swing
back around to it because guys you know
learn more along the way now I run into
that every day even with senior guys
yeah they see a lot of those as well
you're testing the framework we don't
need to test the framework I'm like but
wait this is input if the input changes
you should be testing user input and
it's a constant argument yeah yeah I've
have run into it I run I have that argue
with myself sometimes it's like I really
need to test this like ah and it's like
usually it's like because the customer
will find out when there's a bug and
then I they'll let me know but then it's
like no I need to do I I just I ran out
with the customer the day is that I
would like realize that we had moved
really fast on a couple things so we had
a I I built something out selenium that
just like runs through the whole site
and just test all this stuff out and we
made a bunch of changes and I hadn't
gone back and updated it so I had one
that kicked out and it was like like
right away you can find it as a user and
if I had updated stuff I would have
found right away with that I was like
and so I told the C like I'm sorry my
bad I'm going to go back and update
those tests and get that stuff I'm going
to go back and update our test Suite
because we just we got out of sink and
then you know your tests are useless at
that point
so all right well I am going to go be
useless and I'm going to go shop at Aldi
apparently and go get some groceries and
stuff
so um we'll wrap this one up and I guess
we'll do it again same time next week
basically unless we find a better time
to do it uh are you done did you say the
uh the uh co-starters is done are yeah
we're done we can go back to our normal
time oh okay well cool so yeah we'll
have to we maybe catch up and do a
little uh debrief on that I'll be
interested to hear how you what you got
out of it and all that kind of good
stuff may even do that may do that as an
episode next week I think that'd be sort
of cool to just be like hey went through
this thing this is what I learned and
what we we got out of it because that's
that's honestly what I've been working
with with the uh the lead generation
guys I've had I I've actually I just
told him today I was like I'm going to
pause because I haven't gotten haven't
gotten any sales out of it I've gotten
some leads but I haven't gotten sales
out of it and I was like you know
there's nothing I can do it's like if
I'm not getting sales out of it it's not
worth spending the money but a lot of it
has been conversations I've had with him
and it's like well here's some things
you can do and here's some templates and
here's you know some things to try to
build a better offer and I think those
things are great for us to cover in you
know future podcast episodes in
particular it's like what what are some
lessons learned that we've learned and
are still learning in some cases about
how to how to brand and and how to focus
so yeah is the big thing was I got
Envision QA up.com it's now live um and
you saw the free stuff I kind of wish I
taken screenshots of that before
uploading it but um that was the biggest
thing because that almost organically
everything on my site came from uh what
they pushed us to for pitch
not and that's the thing is I think
that's what you once you have it you can
repurpose it that's where you can go
back and you can like put it on your
website and you can put it into flyers
and you can put it out on all of the job
sites and and into your emails and all
that kind of stuff and that's that's
what I've been trying to get to is it's
you know I just I have not spent enough
Business Development time lately and I
got to get back to that so I can I can
Circle back and refine some of those
messages and and get those updated
across the board so all right I'll let
you get to it and have a good weekend
and we'll talk to you next time around
all right take care everyone have a
great day good one he bye
[Music]