9 changed files with 117 additions and 6 deletions
@ -0,0 +1,33 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - One Version To Add, One Version To Remove" |
||||
date = 2019-07-30 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "versions", "upgrades"] |
||||
+++ |
||||
|
||||
A lot of things change during development. One day you need a field, another |
||||
day that field may be completely different. For those cases, use one version |
||||
to add the new field and another to remove. |
||||
|
||||
<!-- more --> |
||||
|
||||
You have a database with a lot of customers and their ID is numerical. But for |
||||
some reason, they now need to be strings. Instead of changing the field type |
||||
and doing a whole migration, make a deploy with a new field, in which you'll |
||||
keep the old _and_ the new format going on and, in the next release, remove |
||||
the old field. No downtime. You can even run the migration while the system is |
||||
up, since the new field won't be used. |
||||
|
||||
(I'm simplifying the problem a lot here, 'cause the customer would have |
||||
references all around your system, but you get the point, right?) |
||||
|
||||
I had a problem in which we store the link for an object directly in the |
||||
backend (we shouldn't, that's a frontend problem, but that's a discussion for |
||||
another time); our interface is changing and so should the link. If we did a |
||||
change in the link directly, that would mean the backend would have to be |
||||
deployed _at the same time_ as the new interface; by adding the new link |
||||
format in another field, we can deploy the backend easily without breaking the |
||||
current system. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/log-events", prev_chapter_title="Logs Are For Events, Not User Interface", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title="Learn To Monitor") }} |
||||
@ -0,0 +1,29 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Git-Flow Is The Way To Go" |
||||
date = 2019-07-30 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "git", "git flow", "source control"] |
||||
+++ |
||||
|
||||
If [Gerrit is such a mistake](/books/thing-i-learnt/gerrit), what can you use |
||||
instead? Git Flow! |
||||
|
||||
<!-- more --> |
||||
|
||||
Git Flow is a plugin for Git for managing branches. It is based on the concept |
||||
of "feature branches", in which each branch is a feature or bug you're working |
||||
on. Once you finish it, it will just close the branch. |
||||
|
||||
Although there is a lot to be said about Git and how you should use it, the |
||||
fact is that Git Flow manages a lot of complexity of having a stable branch, |
||||
an "unstable"/testing branch and all features around those. |
||||
|
||||
Not only that, but with the current source control sites like Github and |
||||
GitLab, the flow is quite similar -- although working with branches is changed |
||||
with forks. |
||||
|
||||
You can even install Git Flow and use it on your personal project -- which is |
||||
something I do with this blog/book! |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/gerrit", prev_chapter_title="Gerrit Is A Mistake", next_chapter_link="/books/things-i-learnt/project-organization", next_chapter_title="Organize Your Code by Data/Type, Not Functionality") }} |
||||
@ -0,0 +1,46 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Own Your Shit" |
||||
date = 2019-07-30 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "personal", "own your shit"] |
||||
+++ |
||||
|
||||
When I said "Scala is garbage" or "Gerrit is a mistake", it wasn't "l33th4x0r" |
||||
who said that; it was Julio Biason. 'Cause I do believe that putting your face |
||||
to be slapped is the way we grow. |
||||
|
||||
<!-- more --> |
||||
|
||||
I do understand -- and you must have realized reading some of the previous |
||||
points when I talk about it -- that privacy is important. For some people, |
||||
hiding their real name is important for lots of reasons. |
||||
|
||||
But I also personally believe that using some weird name and some face that |
||||
isn't yours on your avatar may give you a false sense of "that person is the |
||||
guilty one, not me" when it comes to criticism. |
||||
|
||||
I mean, yes, I hate Scala with a passion. I do understand _why_ the language |
||||
developers decided to come with some options about it, and I still think those |
||||
decisions were stupid and you should never sacrifice readability for |
||||
ease-to-use. |
||||
|
||||
But it wasn't some random person using a weird name full of numbers and an |
||||
avatar of some anime saying Scala is garbage. My name is even in this blog |
||||
name, in the URL and in every social network I use there is a picture of me. |
||||
|
||||
So yeah, Julio said Scala is garbage. |
||||
|
||||
There is another thing about using your real name and real face: I'm not just |
||||
saying "Scala is garbage", I have to back that up with some facts -- or, in |
||||
this case, personal opinions -- about it. It's not simply an attack to Scala, |
||||
is a somewhat thought out attack on Scala. |
||||
|
||||
And, on top of that, someone will one day come to me and say "Yeah Julio, that |
||||
thing you said about Scala: It is that way because of this, this and this". |
||||
And I'll probably have to say "You know, you're right: I was wrong." Because I |
||||
can't simply move my mistake to some other personality; who was wrong was |
||||
_me_. And unless I own my shit up, I'd never get the understanding I'd need to |
||||
see my mistake about Scala in the first place. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/time", prev_chapter_title="You Always Have The Time") }} |
||||
Loading…
Reference in new issue