Going To Make A "Getting Started With GIT" Post

Going to make a "Getting started with GIT" Post

(This is my getting the "why are you making that post" out of the way, so that the posts with the actual information does not get polluted by it. And also polling people on what they find confusing about GIT so I can target that a bit better) So I re-blogged a post with a really nice GIT diagram, showing what commands sends what where. And I noticed 3 things in the replies and reblog. 1: A lot of people seem to be intimidated by the perceived complexity of GIT. That is fair. But I promise, while HOW it works is complicated, using it is not. 2: Many have it on a TODO list for after they learn to code. Which is... backwards. It would be like waiting with learning how to use a keyboard until after you have become a good writer. Trust me, learning GIT as one of the first things will make it EASIER to learn to code. 3: Several people suggested that GIT is overcomplicated. That is... simply not true. It is one of the old school pieces of software (Meaning it does 1 thing, is open-source, free and is impossible to monetize). It does something very very complicated in the simplest way possible. I think people simply do not understand how complicated the problem GIT solves is. I am not saying "People are dumb" (I think... anyone thinking that is fundamentally missing something in how the world works.), I am saying "People seem to be either misinformed or not informed". And that I can help with!

I WILL make a "Getting started with GIT" Post, but if people want an easy explanation for something more, then I will also make posts for those later... Or maybe they fit in as part of a getting started post. We shall see

Vocalization of your thoughts can help you solve problems. In the same way that writing them up or making a diagram of the problem can help you fix it. Try tricks people recomend, and if they work for you. Great! Use them! Here is my duck by the way :3

He is so sassy!

Source For more posts like this, CLICK HERE to follow Ultrafacts

Yeeep. Also, Assembly languages is different for every CPU family (And sometimes generations within those) because the assembly instructions (Which is... ALL the keywords in any assembly language) maps 1:1 to "what the CPU can do". So if you know a bit of assembly, suddenly, you have the ability to easily look up "What can this family of CPU's do?".

Reason to learn assembly #1

You will be able to better understand the program output of your compiler (specially if using C, C++ or Rust). Because in the end people using those languages want all the tasty performance their code can achieve, knowing assembly can be pretty useful for evaluating the scope of some optimizations. "Do I really need to do this optmization or does the compiler know it already?", "Does the compiler know how to inline this lambda?", "Is the compiler smart enough to get rid of this loop for me when I enable this thing?" and so on

Not only that, but you will be able to have some intuition when comparing the performance of similar code by its assembly code.

A really cool tool abot the subject is called Compiler Explorer and it basically lets you easily analyse the output of your code online

godbolt.org

Compiler Explorer

Compiler Explorer is an interactive online compiler which shows the assembly output of compiled C++, Rust, Go (and many more) code.

That is GREAT!

As much as I love developing new things there is something uniquely satisfying about refactoring code or hardware setups.

I tend to make diagrams of the codes architecture after it works, to figure out how to make it work in a maintainable way. It feels like a lovely brainteaser

refactoring

I lied when I said I was going to work next on loading a 3-D model. Sorry, old habit! Actually, I went straight into refactoring. Let me explain...

The English Wikipedia defines refactoring as "the process of restructuring existing computer code . . . without changing its external behavior", which is fairly accurate, though lacking in motivation.

My back-of-mind definition would be "changes to code whose primary purpose is not to add features or solve issues, but to make the codebase easier to maintain".

Back when I worked for corporations, I got in the habit of never mentioning refactoring around anyone who wasn't a software developer. If my boss (or my boss's boss) knew I was making changes (and spending work hours) on something other than approved features or known issues, awkward questions would arise. (Like, do we have a billing code for that?)

Anyone who's worked intimately with a large software project knows that if changes are made only for features and issues, the project will accumulate "technical debt" that makes it difficult to maintain: hard to explain/learn/understand/remember how it works and hard to make changes without introducing bugs.

Both of today's refactorings focussed on the BaseApplication class, which became unwieldy weeks ago. Last night the source file for the class reached 1901 lines of Java code (not counting blanks, comments, and javadoc). I don't place a hard limit on lines of code in a class, but a file containing 1901 LoCs positively screams technical debt. It's especially painful these days, since I'm working on a laptop with a tiny screen and using a track pad instead of a mouse. (I spend lots of time scrolling back and forth, hunting for the lines I need to change.) Cramming as much as possible into a single file makes some sense for a tutorial, but I see the V-Sport project as something I'll be maintaining for many years.

First I split off all the code that deals with physical devices and put that in a new PhysicalDevice class. The change greatly clarified which properties of the physical device matter and how that information is accessed.

Then I split off all the code that deals with texture data into a new Texture class. The new class bundles up 3 related Vulkan resources and provides a clear lifecycle of create/use/destroy. I expect it to minimize duplication of code when the project transitions (sometime in the near future) from a single texture to multiple textures.

I'm subjectively pleased with how smoothly today's refactoring went. One measure of its success is that BaseApplication shrank from 1901 to 1650 lines of code. Still plenty of room for improvement, though!

A girl who I took her degree at the same time as me, had taken a bachelor in english before becoming an engineer.

And everyone around her was ASTONISHED that a engineer would be able to write dokumentation that are readable to HUMANS. She have NEVER been unemployed. She was hired FAST.

It is HARD to learn skills that are 100% useless to whatever you end up doing. Do things you like. Study whatever you like. Have whatever hobbies. If they make you a better you, that will make you better at WHATEVER job you will end up doing.

And people WILL hire you for more. Because you WANTING to learn these skills, will naturally do with passion and enthusiasm. And want to do it a lot.

That is what people usually call "Talent".

You have it too! You ARE talented. And I beg of you, allow yourself to delve deep into these passions so you can become the best you, you can be.

The world have need of good people doing their best. Let us make sure we cultivate many such people.

Cannot code when anxious

Cannot think logical when anxious. Code requires thinking logically So Cannot code when anxious. BUT Brain cannot multi-task some disorders So Cannot be anxious if I focus on massive sensory overload. So Moose is blasting the same song on max volume into his skull via headset so progress can be made Stupid DIY brain I got handed out by mother nature