Yes, you SHOULD own your data. Specifically, if you are coding something, you should own it.
And I don't mean owning in the sense of "I have the copyright" because sure, you already do. There
are thousands of lines of code I wrote in the 90s and 2000s of which there is no extant copy. NONE.
Weeks and months of code, all gone, forever.
I mean own in the sense of HAVING A COPY OF IT. You should have a copy of your code.
No, having it up in GitHub is not the same as having a copy, because you may lose the account (seen it happen)
or delete the repo (done it accidentally) or they may just delete it for whatever reason (it happens)
No, having it up in GitHub and having a git clone in your machine is not enough, because you are not going to
pull every day, and checkout every branch.
No, using GitLab instead or in addition to GitHub is not the same as owning a copy.
So, how do you own a copy?
You setup your own private GitHub-like-thingie.
My favourite one is Gitea ... it does 80% of what GitHub does, for free, from a single
self-contained binary and it runs just fine in a Raspberry Pi 3.
It has a feature to clone a GH repo. It will periodically clone all the branches, and keep them up to date. You can then continue to work as usual and it will do its thing in the background, unattended.
Or you can use it as source of truth and make GH the mirror. Your choice.
So, what's left? Making a copy of all your GH repos.
There is a somewhat arbitrary separation in tech between soft and hard skills.
Hard skills are technical skills. Knowing a programming language. Understanding a protocol. Experience with a specific piece of software. Which is all good and nice, of course. Most of us working in tech enjoy these "hard skills", or we would work on something else, right?
Soft skills is everything else. Knowing how to negotiate your sallary? Soft. Being good managing your tickets? Soft. Communication? Presentation of knowledge? Knowledge sharing? Soft, soft, soft.
Which is, of course, one of the famous two hard things in computer science1
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
This is an underrated skill. Advertisers and wizards know a good name is a big deal, and once a name is applied, getting rid of it is very difficult, so it's a good idea to try to get it right (or at least not horribly wrong) the first time.
Know your audience
You will see here rules. They are all meant to be broken on occasion. Which ones can be broken and which ones can't?
It depends.
If it's an internal tool in a company where everyone speaks english, then you don't need to spend much effort making sure it doesn't mean "testicles" in german (it's Hoden, BTW)
If it's a niche open source tool then the rule against obscure jokes doesn't really apply because there's tradition.
OTOH calling things by offensive names with intent is probably always a bad idea.
Where do you draw the line? Well, if I could give you an algorithm for that it would not be a soft skill, would it?
Rules For Names
So, what's a good name?
It's not a common word.
Make it easy to google. Please. Make it be something that's not already a much larger thing. Do not call your bigint library "Grande". Nobody will be able to ask about it without being flooded by links about tiny singers and large (not not the largest) coffees.
So, if you can't come up with a very uncommon word ... go to other languages. Go to unusual languages. That, plus context, will help.
It's not a "bad word" in another language.
Yeah, that sucks. But hey, it's also hard to figure out in advance. At least check EnglishSpanish and Cantonese ?
There is a reason why the Mitsubishi Pajero is called "Montero" in spanish-speaking countries.
It's not an obscure joke.
Python is called Python because of Monty Python. Which means the place where
you downloaded packages was called "The Cheese Shop". And the format for the
packages was called a wheel (as in "a wheel of cheese").
Obscure jokes have a tendency to encourage secondary, more obscure jokes to the point of incoherence. Try explaining "why is this called a wheel?".
Recursive acronyms count as obscure jokes. Yes.
Make it memorable and descriptive.
Not "Object Adapter Library"
Not "Language Extension Package"
Yes, those names are "descriptive" in a dry, totally uninformative way, but I am going to forget them in 30 seconds and I just made them up right now.
So, use an arbitrary, memorable name. If it works as a menmotechnic for what the thing does, better. Good examples:
SQLAlchemy: memorable. It's about SQL. It suggest complication and probably some supernatural intervention will be necessary.
Django: memorable.
Ruby on Rails: memorable. It's about Ruby. Ok, so it's not about trains, but "on rails" has metaphorical meaning.
And yes, this rule 65% of the time collides with "not an obscure joke".
Make it short
"Llanfairpwll-gwyngyllgogerychwyrndrob-wllllantysiliogogogoch Enterprise Edition" is bad.
Don't make it too short
"C" is bad (it was good in the 70s!).
Make it clear in context
Naming things is not only about naming software or things, it's also about variables, classes, and identifiers in code in general.
"i" is often bad
"strFirstName" is always bad
"data" is always really bad
"ObjectAdapterInterface" is making my eyes bleed.
A name is not a description. So, "strFirstName" is trying to describe "it's a string with the first name in it". What else is it going to be? A boolean? Do you call your pet "dogFido"?
But a name has to be a name. If you call your dog "dog", then "data" and "i" will look good to you.
And a name is not a DNA test. You don't need to describe the ancestry of things, just say what they are. A glass is not a DrinkingWaterContainer. It's a glass. 2
Name things what they are, or something that lets you identify them. I know, radical.
Conclusion
You didn't expect me to solve one of the hard problems, did you? No, I won't. These are just, like I said, rules meant to be broken.
But you need to break them consciously.
For example, I am naming a project of mine CobraPy. because it's an 80s-style retro thing, and in the 80s Karate Kid was cool, and in
Karate Kid there's Cobra Kai, and that sort of sounds like CobraPy and Py is for Python, and Cobras are also snakes.
Some improvements to the sprite engine (reusing textures and such)
Better keyboard support, or at least one that's more useful for games
Fixed a bunch of bugs
Added collision detection (did not make it to the video but it's there)
So let's go over the whole source code for that "game" and see how it works? Keep in mind that this code will look
bizarre for your standard Python programmer because it's deliberately done in a ... "basic" style? Even in a BASIC
style. Which means it aims to be more "structured programming" than what you are used to seeing.
Also, there are no guarantees that any of the APIs exposed will even exist tomorrow, since this is still in a
prototyping phase and things will change.
import time
load_sprite("player", "assets/PNG/playerShip3_orange.png")
x = 100
y = 500
step = 3
move_sprite("player", x, y)
We created the intrepid player's ship, and put it "somewhere". Sprites are identified by a name.
All sprite operations will use that name to know what sprite should be affected.
# A fleet of bad ships
fleet = [
[f"enemy-1-{x}" for x in range(7)],
[f"enemy-2-{x}" for x in range(7)],
[f"enemy-3-{x}" for x in range(7)],
[f"enemy-4-{x}" for x in range(7)],
]
for invader in fleet[0]:
load_sprite(invader, "assets/PNG/Enemies/enemyBlack1.png")
for invader in fleet[1]:
load_sprite(invader, "assets/PNG/Enemies/enemyBlue2.png")
for invader in fleet[2]:
load_sprite(invader, "assets/PNG/Enemies/enemyGreen3.png")
for invader in fleet[3]:
load_sprite(invader, "assets/PNG/Enemies/enemyRed4.png")
Again, just a few ships with different looks.
def move_fleet(x, y):
"""Move fleet so the left-top alien is in position x, y"""
for inv_y, row in enumerate(fleet):
for inv_x, invader in enumerate(row):
move_sprite(invader, x + 90 * inv_x, y + 90 * inv_y)
fleet_x = 50
fleet_y = 50
fleet_step_x = 1
fleet_step_y = 5
A function to move the fleet as a whole, and some info about it, location and speed.
load_sprite("laser", "assets/PNG/Lasers/laserBlue01.png")
load_sound("laser", "assets/Audio/laserRetro_004.ogg")
laser_last_shot = time.time()
laser_x = -100
laser_y = 0
def shoot():
global laser_x, laser_y, x, y, laser_last_shot
play_sound("laser")
laser_x = x
laser_y = y
laser_last_shot = time.time()
Same for our lonely bullet, but we have a couple of new things. With load_sound we load into the program a
sound (surprise!) and with play_sound it's played. Just like sprites, they are identified by name.
We keep track of when we shoot because this is a ship, not a machinegun, Jim!
def check_hit():
global laser_last_shot
t1 = time.time()
global laser_x
for row in fleet:
for invader in row:
if check_collision("laser", invader):
laser_x = -100
laser_last_shot = 0
Collision detection! If the bullet hits an invader ... well, we can't make it explode yet, but
we move the bullet out and allow the user to shoot again, at least.
Just load and play a nice chiptune! As usual, music is identified by a label, so
we can have more than one and play the one we want.
def gameloop():
global x, fleet_x, fleet_y, fleet_step_x, fleet_step_y, laser_y
The gameloop function is special. Whatever you put here CobraPy will try to run it 60 times a second.
No faster, maybe slower if your gameloop takes too long. So this is where you do things like update
the screen and interact with the user. You know ... a game loop.
if is_pressed(114) and x < 720: # right arrow
x += step
if is_pressed(113) and x > 0: # left arrow
x -= step
if is_pressed(38): # a
if time.time() - laser_last_shot > 1:
shoot()
User interaction! Basically is_pressed takes a key identifier (nice constants coming soonish) and tells you
if it's pressed or not. So, if right-arrow is pressed, increase x (within limits), if left-arrow is, decrease it (within limits). If "a" is
pressed and you have not shot for a second, shoot.
move_sprite("player", x, 500)
Well, that's why we increased / decreased it, right?
fleet_x += fleet_step_x
move_fleet(fleet_x, fleet_y)
if fleet_x < 50 or fleet_x > 150:
fleet_step_x = -fleet_step_x
fleet_y += fleet_step_y
The fleet moves to the right, then to the left, and at every turn, down. Does it remind you of any game you've seen?