Hey! This is the Daily Overpass! My name is Eric and I make apps!
Now today, I want to talk about how I completely messed up my source code but,
I use source code control to recover.
Alright, so, I have completely messed up the code on one of my apps. Everything
was working fine, it's out on the market, it's making money - not a lot of money - was
making a little bit, and everything's working, no bugs and I had
an idea. So, I had this great idea. I don't even remember what the idea was, but I
went through and I started tinkering with things. See, the thing is, as a
software developer I like to tinker. Nothing is ever good enough. Everything
could be a little bit better whether it's adding a new little
animation to a logo or something like that. Or adding a new ad network or
putting some new analytics in or just changing - or just changing the structure
or anything. This is the thing, a lot of times that we developers, we like to
change things and it's imperceptible to the user. It's just like the code is not
structured in the right way. You know, to be really cool is if we take this module
and make it smaller, more efficient. So, we have like it -
it's just easier to replicate all those kinds of stuff. This is the kind of stuff I do.
However, unlike in the old days, when I just did software development, I use a
block out. I'm gonna block out the next four hours. I'm gonna block out the next two
days and I'm just gonna do this. When I start tinkering with things now,
the phone will ring, something will happen, I gotta go,
there'll be some problem. Maybe something at home, maybe I gotta go do
something, and then or more likely than not, another shiny thing pops up, like
I'll have an idea for an app. And those aren't changing it and I'll think, "Oh, you
know what, I should have done on the other app. And then I'll switch over to the
other one and then I'll come back to the original code. A few months later and
it's in the state of, you know, there's bugs in it, there's things that I've done
but never completed. It's like if you're - if you're cleaning
your garage, you pull everything out and you know, you
put everything away, and then you can't finish it .So you just shove everything
back in and then this looks worse than it did when you started. That's kind of
what it's like. Now, fortunately I use source code control. So, I've used
source code control for years and I won't code without it. It's one of the
things I do and I talked to - when we get clients, when we get to people with
existing code, they come in, they say, "You know, can you have a look at my apps?"
"Yeah, just send me the subversion or git or whatever it is you're
using, I'll download it." And they don't. They just zip it up and send it to me.
Because they're not using any source code control and I think that is crazy.
And just personally, one of the things I really struggle with when I hire people,
bring people on, is getting them to use source code control. Even if I could get
them to download from our git repository, a lot of times, they'll zip
stuff back and send it to me. Or... And this drives me crazy.
They'll rename the folder and then submit it again as a subfolder in the
same git repository. So we have all this duplication all over the place.
Okay, so today, what I wanted to do is talk about - to talk about what I do when I
mess up the code, things like this, and how it really saves me now.
In the past I've used visual sourcesafe for .net, actually like vb6
I think, and then team foundation server for .net projects. And then I moved
over to sub-version. I'm a big - I was a big fan of sub-version. Then we moved on
to GIT and everybody uses GIT. The big advantage of git, and again there's so
many nuances to this, there's people who are far more into getting a source code
control than I am, but I can talk about it for days and days. And I probably just
use a subset of it. But for me, the big difference in git and sub-version is that,
I guess, I could commit my changes locally and not have to push them to the
cloud for everybody to see, or for all the team to see, but I prefer to do that.
Anyway, so most of the time, when I do a commit, I do a push as well. So, let me
have a look at my screen over here. So here's the - here's the app. Now, this is
actually Lua. I'm using - this is Lua on JetBrains webstorm. So, I use WebStorm
IDEs a lot. I use a WebStorm, I use
IntelliJ, although IntelliJ is pretty much the same as Android studio. It just -
you know, I paid for it, so I might as well use it.
Or PhpStorm, if I ever have to work on PHP (puking sound), and then there's one of the
nice things about the JetBrains tools is that their - they have consistent
interfaces across all of them so I like to use it. So like - so whatever it is.
Oh! I made a mistake - I made a change here at some point in the past and I need to check it now.
Every time I make a change or I'm about to make a change, or even if I can't
remember the change I made before, I will go
and I'll do git status and basically, what that will do is they'll check
against the local git repository to see if I've made any changes to any of the
codr locally that hasn't been committed. And if I see there's anything,
I'll just git add dot, just add everything in. You can do it one file at
a time, but I'm very simple and I always just to wanted to - I just do everything
and do the whole folder. Even using git ignore. You could use a file called
git ignore if you want to exclude all the libraries and everything like that.
Mmm, I try to do that, but sometimes I'll just - I'll just commit everything, I don't
really care. I'll let the developer who takes it over to handle that
so they can delete all that stuff. So you know, git add, git commiand then
test commit. So, test commit again because this is the second time being
through this video because I forgot to record the screen. You can test commit
again. It can't do anything and then I'll go get push and get push. So, if
I just think git commit that's fine. Everything stored locally and I can go
back to that version of code if I need to. So, if I pull everything out of the
garage and I decide, man, I just wish I hadn't even started this, then I could go
back to that. But I'm not gonna do that, get pushed at the moment, although I
tried to do it as often as possible. Because there are two types of people
who backup files and code, there are those who have had a hard drive failure
in the past and those who haven't. And unfortunately, I've had several hard
drive failures in the past and you know, I don't trust one single hard drive, I
usually have multiple backups all over the place. So, that's it. Most the time,
that's the flow. It's git check, git commit - commit, whatever. If I
go to JetStorms, I mean everything you can do from the command line like that.
There's lots of tools out there. There's one called one called source branch,
or branch tree or something like that on the Mac, when there's all kinds of
different git, you know, gits and sub-version clients, we've torn SVN a
lot in the past, but in jets - in JetBrains tools, you pretty much go into
any code window. Let's say this home.LUA, I can go in here and say going to git
and I can say, show me the history. So, here at the bottom, I can see and the
history of every time I've changed this file in the past. So, even though I've
committed everything each time, it'll say when this particular
file has passed. I can also log into bitbucket which is where I push it and
then view the changes there too, but and the file if I want to go through here
and say, so what I could do here is just say, screw this, I just want to
roll back to the last version which is one thing I do. Another thing I
could do is just show history, so actually compare with and let's say, I
want to compare it with the one from last July here and I could go here
and see all the changes that have been made left and right. Comparing the code
and what I've done over time. And if I wanted to specifically go back
through and check something. And this is - this is really helpful if you release
something and you're sure that it worked before and you didn't, you can take it
and check that code out, put it in a different location, run it everything
like that. But mostly, for my own benefit. The reason I use the source code control
is that I can roll back in. I could - it makes - it's like a safety net. If I
want to make a change, Now, and the nice thing about doing the - doing the git dip
or you know, checking the differences between files over time and you can do
this to the command line too, but they got like plus, plus, minus, minus, stuff like
that and I think it looks like vomit, so I never use that. The nice thing
about this is that if I'm several versions in, so let's say with Ear Agent,
I've had this kind of issue before where I've added a new ad network. I had it in
there for six months, I had several changes and modifications and bug fixes
in between there, but and then I'll go through and I want to remove that ad
network. This has actually happened where I've gone through and I just
did it from memory. I remembered it was check, move it from there, move from there
and I think it was either the manifest or the on/pause function where I forgot
to remove something. And it was crashing on certain devices. I did the
limited rollout and it was crashing on a few devices. It wasn't clashing on mine,
it wasn't crashing on all of them, but a few of them were crashing because I'd
left that little bit of code in there. And what I should have done was gone
back to that commit and git and say, okay so which files were changed and go and
deep each one, then I could manually go through and remove them without rolling
back and losing all the changes instant. So, anyway, my point today, put to end off
this week, is that if you're not using source code control, you really should.
And junior developers especially, who don't see the use of it. I hope this is a
bit more clear. It's not so much for your boss. It's for you, so you can go through
and make changes and be very daring with your code, and not have to worry about
the fact that like, if you just want to completely restructure everything, not
have to worry about the fact that, oh if I completely mess everything up then
then I'm screwed. Or, you know, it's all or nothing. I have to move and do this
and then go back into the last version or whatever. Another thing you could do
is branching. So, if I have two bits of code, one experimental, one live, and I
want to update the live as it goes to the experimental one, I want to continue,
I can have two branches of code that keep going forward and merge them
through the source code control. So anyway, I hope that's been helpful. Let
me know how you, guys, are using it and if you're not using it. And that's it for
today. Hey, that's it for this week! I'll talk to you, guys, on Monday!