What Are Strings???

What are strings???

So, on the codeblr discord there was a question which is hard to answer unless you already fully understand what a string is... So, what is a string?

And this is a great question! Because to answer it we will learn a hell of a lot!

To answer this, one needs to know what an array really is. This is important in any language you write in. But in most languages it only becomes important to know when you get to optimizing code.

So for most, it is fine to think of arrays simply as collections. But in C, you need to know what they truly are to work with them (Which is why newbies are often taught C to learn these things)

I will use drawings and links to godbolt code examples I made, to help you understand things.

To explain what strings and arrays are, I will use a trick that you may also want to copy if you have a hard time learning concept in programming or electronics.

Try to to "re-invent" it. By going step by step into the things that required it to be invented, and how it was done.

So arrays. They are a way of storing many variables in one place, and work on them very very efficiently.

We start with having variables. Each variable have an address where they are in memory, and a value at that address.

An address is just a number. Nothing more. But to make it clear when we are talking about them, traditionally you write it in HEX. These numbers are marked with "0x", as in, to write "6" in Hex, we write "0x6"

Now, on each address you can store 8 bit. To store values that are larger, we use more than one memory address.

Ok, with all info, let us draw the example we will use, and write the code:

We will have 3 numbers. Each takes 16 bits:

https://gcc.godbolt.org/z/cse64Kd6x

(Notice that the adresses counts DOWN. This is for stack and heap reasons we will not explain here. But just know that we count DOWN, not up when it comes to adresses on the stack, which is all we will work with here.)

If we know the type of a variable, we also know how much space it takes.

So to really know a variable, we need to know its type, and its memory address.

Now, if we create these variables one after the other they will be placed right next to each other in memory.

Then we can create a pointer! A pointer have a type they point to, so it knows how much space the variables takes, and a memory address. We will create it pointing at the first variable!

Let us draw it on the example:

https://gcc.godbolt.org/z/9abqMjrs3

And now, if we want to work on all of our values, we simply do whatever we want, and then subtract 2 from the pointer to get to the next value, and then work on that one, and so on.

If we want to add 1 to every value, we could do this:

Step 1, add 1

Step 2: Move pointer

Step 3: Add 1

And so on and on! :D

https://gcc.godbolt.org/z/7KGadT868

This is how arrays works. But instead of us having to remember to count DOWN, and what size variables are we have gotten all this build into the language. It also GARANTEES that the variables are placed next to each-other in memory (This is not actually guaranteed when you use single variables like we have in the examples... NAUGTY US!)

So this code does exactly the same as we just did. And as you can see it is MUCH easier:

https://gcc.godbolt.org/z/KWxc939v4

So as you can see, a array is... more or less a pointer that you cannot change (because it always point at the first element), also known as a const pointer. And instead of moving the pointer, we use the index... which is just "The adress of the first variable, and then move it down as many times as the variables size times the variable number we want"

And a string... is a specific kind of array we often need, because we often need strings of characters. A string is a array containing elements that are characters.

If you are using ASCII, that is 8 bit signed values

If you are using UTF-16 then it is 16 bit signed values

See? It is super easy to explain what strings are!

... IF you know what arrays are... and why we use them....

Ha Ha!

I did it! I got up at 3 AM to start working before going into work at 8 and I managed to do good during the code review!

I managed to teach the apprentice a good chunk of stuff embedded and C++. ( Static_cast, Steongly types enums, rule of 0/5, system clock running backwards and a bit more ) AND I managed to know a few things that my supervisor had not run into before! ( One of which was Godbolt existing... which confuses me, but oh well ).

I also picked up a bunch of good stuff (For example, I realized I was still thinking in terms of microcontrollers and so had not thought about how the fact that main() takes arguments influences the code architecture)

Now my brain is mush but I do not care! It went well! I can do this!

AHHHH!

Have to do a code review of a codebase I have had access to for 2 days... by copy... As in, I do not yet have access to the reposetory, as so cannot build the project... And so none of my tools work on it... Because massive anxiety an autism, and my supervisor asked if it was ok to have it today (Friday), rather than on Monday and so my mouth just said the words it figured the other person in the conversation wanted to hear... I do not have access to the internal communication tools either so... juuuust have to do it..... AHHHHHHHHH! I swear... I am so happy I went on tumblr, because I am just using the "Do it alone, do it scared" as a freaking mantra at this point...

(Also, sorry for not answering people or being super active... I am just focusing as much as I can on this internship)

I am always baffled how many companies does dark agile. The agile manifesto is online, and freely accessable. And it is 9 lines of text. And this is apparently too hard and complex for something like 80% of firms to get their head around. I hope they never try to do anything complex or hard.

That is great! Being able to state positive things about yourself is a really great skill! Honestly, it is good for your mental health and outlook!

Study affirmations

🏹 Studying is very easy for me.

🏹 People are always in awe of how easily I'm able to understand and retain information and get good marks.

🏹 I'm the smart friend in the friend group.

🏹 I study multiple courses at a time and yet score perfectly.

🏹 I'm a genius.

🏹 I'm a prodigy even though i didn't realise it until recently.

🏹 I thought I was an average student but i didn't realise how easy it is for me to study and get great marks.

🏹 Everyone idolizes me when it comes to being an idol student.

🏹 People are in awe of my knowledge.

🏹 I study when I'm tired because it helps me relax.

🏹 I do not waste my time.

🏹 I sometimes even hyperfocus on my course because it's so damn interesting!

🏹 I'm the Queen/King who always fascinates people with my presence.

Love you. ❤️

Designing systems with bad Implicit requirements. (Or "How to hire people")

So I have now been searching for a job for half a year. And my conclusions are: 1: Firms have no idea what they are doing. Everyone seems to make decisions based on "What does everyone else seem to be doing" and "How do we usually do it" 2: Your ability to do the job you are applying for have just about 0% relevance in your ability to GET the job you are applying for. I am a system designer. And when I get exposed to the same system many times, I start analysing it... it is basically habit at this point. And so, I analyse the hiring system. And so far, in all the interviews I have been to I have been asked 0 technical questions about the position I was interviewing for. 0! And the little feedback from my many many rejections, was that I am not experienced enough. That is weird. Because they are making a judgement on how skilled I am... while not at all asking about or testing my skills. And yesterday I finished my internship (Which is a polite way of saying "Whored myself out for 0 pay in desperation"), and I was in a room with 6 other developers, who was all programming in C++ And I now know that I was the best person at C++ in that room. Better at designing with C++, building architecture with it, knowing the intricacies of the language, and knowing tiny weird little details of the language. (Most of the others had different things they were better at. More experience working with the specific hardware and codebase at the job, better at 3D simulations and so on) So I know for a fact I am skilled. But the system that is build with these interviews mean that skills do not count. Someone with terrible skills who had done bad work at their student job for a year or two, is considered better than someone with great skills who have focused on their studies and not yet worked. Or said in another way. There is an implicit specification in the system design that "Being good at the job, does not matter" So since that is frustrating as hell, and I need to interact with it to stop my brain exploding, lets design a better system. First of all, the OBVIOUS (That... I have seen exactly 1 firm do):

Blind recruitment.

The system will have to have humans make the judgement of who to call into interviews, and who to hire. And humans are stupid little monkeys with brains with software that is just layers covering for the flaws of other layers. Yes, that also means you. And yes, that also means me. We are biased. You can try to constantly evaluate yourself, be aware of your biases and minimize them, but they cannot be removed. Science ( as in, the entire field , have tried for several hundred years and is only "meh" at it So how do we deal with that? We remove the info that is not needed, and can ONLY lead to bias. A person making a judgement if a candidate should be called in for a interview should not know the candidates gender, name, age, skin color, religion or any other information we can remove that have no value when it comes to figuring out if that person will be good at their job. You may think "Hey wait a minute. Age DOES have an influence!" but it really does not. EXPERIENCE does, and SKILL does, and PERSONALITY does. And yes, age can corelates with that. But that is it... it MAY corelate with it. We want to value 2 people with the same skills, and the same experience in the relevant fields equally, if they are 25 or 40.

Throw the letter of motivation in the trash where it belongs

Does the job you want someone to do involve writing 1 page marketing nonsense, that follows standards that is never specified? No? Then stop making people write those to get the job. Letters of motivation should only be required for jobs where the skills you showcase by WRITING such a letter is relevant.

Throw the CV in the trash where it belongs

There is NO agreement on what a CV should contain. You can find people claiming that THEY know, and that you should ignore the thousands of others who say the exact same thing but disagree on what it should contain. You may be able to boil it down to "relevant skills" and "relevant experiences"... but now you are having the person who have no information about the job or the inner workings of the firm guess what skills and experiences are considered "relevant". So unless the job you want them to do involves blind guesswork, don't do that. Simply have a website that asks the candidates the relevant questions. Write down the very specific skills you want (Embedded C++, Javascript in React, Kotlin for Android etc) and ask the candidate if they have those. Simple yes/no questions. And for each of them, have a more general question (Low level programming, front end web development, Android development). Now, ask the candidate the general question, and if they say yes, ask them the specific questions that relates to that. Do the same for experience. A specific question could be "Do you have 1 year or more experience working with relational databases via C# ?" and a more general question could be "Do you have more than 1 year or more experience working with C#" or "Do you 1 year or more experience working with relational databases?". And yes, you can also have them write a paragraph about their extra experiences: "What hobby or work in other industries have you done that have help you develop as a worker?" "For how long did you do that?" This is essentially the specific bits you are interested in from the CV. And basically, anyone in the codeblr community could make this website in a few days, AND have it output files that is nicely formatted. Give them a few more days, and they will have a website for setting up the interview question website so it can be done quickly and efficiently.

You CANNOT know if a person will work well in the firm, or in the team

What to ask at interviews have been studied a lot. And we have data to at least make SOME statements. One of which is that it is IMPOSSIBLE to determine if a person will work well together with a team based on interviews. People simply do not act in a way at interviews where you can judge it. No amount of personality tests that con artists have sold your firm will help, and no, people cannot figure it out just by talking to someone (People however THINK they can. Which is worse that simply not being able to). The only way to find out is to hire people. We can do a middle ground technique and hire people for a trial Period. Which is NOT a guarantee that they will KEEP working well with the team... but it is MUCH better at predicting it than people who think they are somehow better at psychology than the entire scientific field of psychology. And yes, this costs money. But it costs LESS money than the alternative.

Either know what you want from a interview, and be able to test it, OR, throw the interview in the trash where it belongs

Interviews are THE most expensive part of hiring someone. And I have yet to be at a interview where ANYONE asked themselves "Why are we doing this?". I would say, in 8/10 cases, they are wasted. If you need someone to do design, architecture or development or other work where thinking in creative but structured ways are required, then you can gain some value. Either ask questions that 100% of candidates should be able to answer, and then dig into the "why" of their answer. For example, ask a software developer to name a software pattern they are relatively familiar with. Then ask them what that pattern does, and when it should be used. And when it should NOT be used. You can also give people homework to do before the interview. Again for programming, FizzBuzz is a great choice. Why? Because it is a solved problem, that is solved in a unsatisfying way. The problem is basically: "Make a program that takes a number to count up to as a input. If the number is divisible by 3, have the program output "Fizz", if it is divisible by 5, yell "Buzz". If it is both, yell "FizzBuzz"". Basically, you will quickly find the optimization that you never check for "FizzBuzz!". You just check for the two other things and output the relevant word. If both are true, then FizzBuzz will appear. So you make your 3 checks into 2 checks.... and then you are stuck. There IS no way to optimize further. Ask the candidate what extra information they would want to solve this test better. You can ask this at a interview or again, via a website that also gives the candidate the problem. Because fun fact, if you know if the program should be optimized for Speed (IE CPU efficiency) or how much space the program takes, or both, then you can actually make the program a LOT better. And knowing to ask the right questions when you are given requirement to your program IS a very great skill to check if the candidate have. You can also check the code. Was it easy to read? Is it easy to modify? Did they do anything cleaver like use linear programming to make it run faster? Did they do clever optimization tricks? (If they did that is good... but it DOES also mean they might pre-maturely optimize, which is a deadly deadly sin in software development.) I went through that in detail, because it showcases HOW to approach designing questions and tests for a candidate for a specific job.

And if you think it is too much work, or if you cannot come up with relevant questions and tests... THEN DO NOT DO INTERVIEWS. If hiring someone without an interview feels like a blind shot. You are correct. But it is LESS of a blind shot than hiring a candidate based on random and irrelevant skills. And it is a shit-ton cheaper.

A beginners guide to GIT: Part 4 - How to use GIT as 1 person

Table of content: Part 1: What is GIT? Why should I care?

Part 2: Definitions of terms and concepts

Tumblr

A beginners guide to GIT: Part 2 - Concepts and terms

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. <-------- You are here Part 3: How to

Part 3: How to learn GIT after (or instead of ) this guide.

Part 4: How to use GIT as 1 person

Tumblr

A beginners guide to GIT: Part 4 - How to use GIT as 1 person

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to learn GIT after (or in

Part 5: How to use GIT as a group.

Tumblr

A beginners guide to GIT: Part 5 - How to use GIT as a group.

Table of content: Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to lea

When it comes to not getting in each other's way, working alone is the simplest (It has a lot of other drawbacks). This is the simplest way to use GIT. You can do it with an external repository as a backup or just locally on your computer. It depends on how important your project is. If your laptop crashes tomorrow, which projects would you have a really hard time losing? Better to have an external backup for that. Github is often used for this (Maybe less now that Github makes machine learning AI’s, and so ARE stealing your code to train their AI on.) but you can also use Bitbucket (Which... may also steal your code...) and there are many many others out there. GIT is often used in certain patterns, called “workflows”. These have you working in more or less rigid ways to make it simple to work together. But since you are working alone, you do not risk others changing your code while you are working, so you can do it the simplest way :D

I will be doing a step by step guide that you can follow along. I will be doing it on a completely empty project and making a tiiiiiny program in C. This is because it is super simple. You do NOT have to know C to follow. You can also follow the steps with your own already existing project.

I PROMISE you, GIT cannot hurt you. Worst case scenario is that you fiddle around and break the repository part. (Meaning the files in the .git folder). But your files will always be safe.

(If you do not have git installed, check out part 3 for that)

First, I make a folder, navigate my shell into it, and call git init:

By the way, you can get used to GIT messages like this that tell you all your options, and explain what GIT has done for you. GIT is very good about giving you as much help and info as possible,

Now I will teach you the most important command in GIT.

It is more important than any other. Ready?

git status

This makes GIT tell you what git thinks is happening right now. What issues there are and what files are tracked, untracked or have been changed. Use this command often, especially while you are new to GIT, run it after every other command. It is how you learn what GIT is doing and thinking :3

Since our repo is empty it tells you what branch you are on (master. The only branch we will need since we are working alone)

and that you have not made any commits.

It also tells you the commands git think you will want to use on files. Since our repository is empty, it tells us to create some files, and then how to add them :3 So let's do that:

I have added my tiny program, as you can see:

Now let us see what GIT thinks we did:

Now, since there have been changes, git shows us them.

Files can be untracked tracked and not changed (In which case, git status does not show them) tracked and changed.

Right now, main.c is untracket. Which basically means GIT have no idea about this file, other than it is in the folder.

Ok, let us commit(save) the file. GIT tells us this is done with git add <File> . So we will write git add main.c

Then we use git status again to see what happened git status

And yeah, our file is now ready to be committed. So lets do it! git commit -m “My first commit!”

The “-m” option is to write the git update explanation directly in the console instead of using an external program to do it. Done You have now committed your code! It is now saved!

git status shows that everything in the working tree is as it was last time we committed (Duh. We JUST committed)

I will now make some changes to the main file:

Git status shows us main.c was changed...but what if we wanted to know what was changed in more detail? How will we get status to do that for us? Let us find out! git help status

git then shows the help page for status And there we can see this part:

So if we write status with 2 -v arguments, we get all the details. Let us try:

And look! It shows us EXACTLY what lines were changed! I stage the changes and commit:

And you have now learning enough about GIT to use it.. You now have all your work saved, in different commits. If you ever want to know all the commits you have made, write git log:

And if you want to know what a specific commit did, you copy the name of the commit, and write git show:

Now, everytime you want to save your work, you

1: Write/change the files you want

2: Add the files you want as part of this commit

3: make the commit These three steps are your workflow.

If you have a remote repository, then you add them steps

4: push to remote repository

To do this step, you can actually just write

git push

If you have set up a remote repository, then it just works. If you have not, then git will tell you what to do Whichever remote repository you use will tell you if you need to do other steps, like setting up passwords or ssh keys. They will also tell you how to set up the remote repository (That is not a GIT thing, that is a bitbucket or a github thing, so refer to whichever of those sites you want to use) And that is all! Every time you commit, your project is saved (it is smart to commit often, but usually only commit when your project can be compiled.) And whether you use a remote repository or not, you now have a fully valid GIT repository, and all the git tricks can be used on your project!