Programming - Tumblr Posts - Page 3
I just downloaded a program, as a git repository. It allowed you to have it work in several different ways. Which was achieved by simply using "git checkout" to check out whatever branch you want. I love it. That is so smart!
(Nearly) Never use auto in C++!!!
So I used to be amongst the people who thought "Yeah ok, auto hides the type. But if the type is not really important to understand the code, and was really long and confusing then it is worth it"
Like this: std::vector<std::pair<std::string, Employee>> MyFunction(); To turn it into: auto MyFunction();
And I was wrong. Do NOT use auto to hide that monstrosity. You FIX it. auto hides that awful thing and dumps the problem on the next poor fucker who will use it. ( People writing and using metaprogramming libraries are especially prone to doing this, since their typenames can fill entire screens ).
YOU just looked at YOUR code. Found it confusing... And decided... to HIDE it??? What it is the next person who did NOT write this code going to do when they read this going to do???
No. I beg of you. Use typedef.
You can create aliases of anything and make your code easy to read. And this only "hides" the code as much as auto and you can get the types the alias points to by musing over it. So it is auto... but way better. Because it is a UNIQUE name. Which can DESCRIBE things.
Like, with the horror in the previous example. Let us have a typedef in the .hpp file where "MyFunction" is declared. Now it reads MUCH better:
std::vector<std::pair< Employee_ID, Employee>> MyFunction();
I actually understand what the pair is now! Key value pairs! And screw it. Let us typedef the pair too now that we understand it!
std::vector<Employee_KeyValuePair> MyFunction();
And fuck it. Once more! Typedef the vector too!
Employee_Roster MyFunction();
I will bet most of you reading this only realized what the hell that moster was when you got near the end. BECAUSE THE FIRST THING IS FREAKING UNREADABLE! Fix it. Make your code readable. If you feel the urge to use an auto to hide a typename, it is time to typedef that motherfucker!
That is a very good point. I absolutely agree!
(Nearly) Never use auto in C++!!!
So I used to be amongst the people who thought "Yeah ok, auto hides the type. But if the type is not really important to understand the code, and was really long and confusing then it is worth it"
Like this: std::vector<std::pair<std::string, Employee>> MyFunction(); To turn it into: auto MyFunction();
And I was wrong. Do NOT use auto to hide that monstrosity. You FIX it. auto hides that awful thing and dumps the problem on the next poor fucker who will use it. ( People writing and using metaprogramming libraries are especially prone to doing this, since their typenames can fill entire screens ).
YOU just looked at YOUR code. Found it confusing... And decided... to HIDE it??? What it is the next person who did NOT write this code going to do when they read this going to do???
No. I beg of you. Use typedef.
You can create aliases of anything and make your code easy to read. And this only "hides" the code as much as auto and you can get the types the alias points to by musing over it. So it is auto... but way better. Because it is a UNIQUE name. Which can DESCRIBE things.
Like, with the horror in the previous example. Let us have a typedef in the .hpp file where "MyFunction" is declared. Now it reads MUCH better:
std::vector<std::pair< Employee_ID, Employee>> MyFunction();
I actually understand what the pair is now! Key value pairs! And screw it. Let us typedef the pair too now that we understand it!
std::vector<Employee_KeyValuePair> MyFunction();
And fuck it. Once more! Typedef the vector too!
Employee_Roster MyFunction();
I will bet most of you reading this only realized what the hell that moster was when you got near the end. BECAUSE THE FIRST THING IS FREAKING UNREADABLE! Fix it. Make your code readable. If you feel the urge to use an auto to hide a typename, it is time to typedef that motherfucker!
Stop teaching top down!!!
So I am trying to learn GoDot because... Well, a game engine can make games, sure... but it can also do a lot of other things when you realize it really is just a GUI renderererer (help! How do you stop spelling renderererererer???) + physics engine. Anywho, so I started following the "official tutorial" (In quotes because I am honestly not sure... It is a big open source project so it can get muddy). And... Once again I am faced with a tutorial that teaches me the larger constructions and the orgenization before telling me anything about how the smaller bits work... This is called top down teaching. And it works, WHEN (And ONLY when), the person you are teaching, are already familiar with what the smaller things can do. It can work when teaching someone who already knows object oriented programming, functional programming. They already know how functions, variables, processes and code execution works. It does NOT work when people haven't gotten the faintest idea of what these boxes and structures you are describing are. We do not teach kids algebra before they know division and multiplication. When writing tutorials like this you cannot write for everyone. You have to go with assumptions of the majority. And it is not a great idea to assume that the majority of the people who tries to learn GoDot are veterans of game development. Sure, your tutorial will be slightly better for veterans, but you have just made sure that newbies have an even harder time starting learning your engine... Whenever I start feeling like I have a solid grasp on this, I will start a tutorial on this... BOTTOM UP!
Next up! Scrum!
So... this may be a controversial post... I swear, no listen, I SWEAR that is not on purpose nor is it a goal. I hate that nonsense, but I wanted to give you a heads up. If people start talks in the replies or the reposts, be kind. Read the entire post, and their answers and consider their context before engaging in a constructive manner, or decide you have nothing to say that will improve things. And remember the hermeneutics of generosity. (Basically, assume the writer means well, and is just not good at getting their point across) https://nerdfighteria.info/v/ovrzKCQ2JTM/
I say this because entire books have been written about how to do scrum... which I personally consider somewhat insane. And it is my opinion that a lot of this is just the business management consulting scammers that again have taken perfectly good systems, concepts and words and abused them to the point of meaninglessness.
Because scrum is SIMPLE. And great BECAUSE it is simple. A bit harder than agile, but then, usually the way to the goal IS harder than defining the goal, so that checks out. So just like my post on agile, let us start with what problem is scrum trying to solve.
Basically, a company wants to be more agile. But just bursting open a door, pointing to some random developers while yelling "BE AGILE" proved a somewhat ineffective strategy (except for Steve, who immediately did a full split). To be agile you want the development team to decide how they want to do development... so what do you do when they don't know themselves? You do scrum!
Scrum (Named after the "All players grab each-others shoulders and listen to a super quick message by the coach" thing in sportsball) is a plan for how to plan development, analyze how you are doing development, and improve it. It centers around a team of developers (Usually between 4-8) and a constant time period called a sprint. This is usually 1-3 weeks. Then you do these steps: 1: Make a plan for the next sprint. Take the tasks that needs doing, break them down into clear tasks, and hand them out to people. Try to get the amount of work given to each developer as close to the amount of time they have to work on it in the sprint. Write these things down, however you want. 2: Do the sprint! Basically, do development. Each day, have a super short meeting where each developer explains what they did yesterday, and what they plan to do today. With focus on decisions they have made. Each person talks for 1-3 min. If you need to talk more, do it with the specific people you need AFTER this meeting. 3: When the sprint is over, evaluate how the sprint went. This is the most important part, and the one that should be spend the most time and effort on. Because this is the real core of SCRUM. Did everyone manage to do their tasks? Did some run out of things to do? Was certain tasks harder than expected? Why? What things we did could be improved? What things we did should be done differently, or not at all?
You write down your hypotheses, and start again at step 1 with making a plan for the next sprint, this time, with changes you want to test.
If you just realized that this is the very well known "fuck around and find out" or "The scientific method" as some nerds call it, then congratulations! You now understand Scrum at a deeper level than 90% of companies!
Now. There are 2 extra roles in the development team to make sure this method... you know, actually works 1: A scrum master. This is essentially just the poor sucker who makes sure that the team actually follows the plan, and remembers the steps that was agreed upon. They note down interesting things said during the daily meetings, the plan during the planning and the ideas and thoughts during the retrospective meeting. They are NOT a leader or manager. They do NOT dictate anything. Usually they are just a developer who have the magical skill "Being able to take notes and participate in the meeting at the same time" (I am a bit in awe of that skill).
2: A product owner. Sadly, developers have to actually make stuff, not just have fun. And the product owner is there to make sure that everything still centers around the correct goal. "To make great software for whoever wanted to software". If the team is developing software for a costumer outside the firm, then this is a representative of that firm. Ideally the specific person who ordered it. If they are making software based on orders by a manager or a marketing leader, then the product owner is that person. Only the person who wants the software knows what the software should be like. And humans are terrible at communicating so you do not want a game of telephone going on or the futile game of "Just have the costumer write down what they want the software to do, and then we make it". Because the product owner is often busy and so it is ok for them to only show up at the planning and retrospective meetings and it is ok for them to video call in, but their participation is MANDATORY. They MUST be an active part of the meetings or none of this will work.
We want the team to make changes to how they develop, and what they develop on the fly (The developers decide how, they product owners what). And if you do that without a constant line to the product owner, the project will go off the rail very quickly and fail with almost 100% certainty. It is also a great help because not only will the developers be able to get questions answered quickly, the product owner will also get a good insight into how the thing they want are actually being made and make better decisions. Wrong assumptions will be caught early, and misunderstandings minimized. Maybe a thing they want is really hard to do. If they want it enough, then maybe the hard work is worth it. Maybe not. You find out by TALKING.
That is it. That is Scrum. Now, you may already have spottet why so many people get confused on what scrum is, or how specific or expansive it is. Because what scrum is, is a super simple setup, designed to mutate, and test if those mutations are good. Meaning after a while, a team may only have the short meetings every other day. Or have tasks given to sub-teams of 2-3 developers. Or drop the daily meeting and have Sprints that last half a week. Or have moved some of their developers to teams that fits them better, and gotten developers that like the way THIS team works. Or maybe they have a extra meeting in every sprint with a select group of people outside the team that are experienced in working with what the team is currently working on. Or maybe a team does not want to do any part of basic scrum.
And none of these are right or wrong . The ONLY thing that matters is "Does it work for THIS team?".
You may think "But you just described a structure with rules that seem rather strict...". Correct! That is the STARTING point. Meaning very few teams will be running exactly like that, because most teams (hopefully) did not just recently start existing.
But sometimes you also want a reset. A team may not be working well anymore. Maybe some key team members have left the company or gotten other jobs. And it is decided that it is easier to go back to basic scrum and start inventing a new way to do things for the current team. Maybe the team think they might be a bit too used to a current way of doing things to come up with a new one. Maybe the team is dissolved, and its members put into other teams, and a new team is created in its stead to start from basic scrum with individuals from other teams that wants to try new ways of doing things. It is perfect scrum to have a team of veteran developers who have not changed how they develop things in several years because they by now know what they want.
You can easily see why this works, and why it is good. Because if a part is not efficient or the team hates it? Then get rid of it. And it is easy to see why Scrum helps a company become agile. It is a tool that facilitates the worker empowerment and grassroots decisions that agile set as a goal.
You can also see why many companies HATES this. It makes a lot of middle managers unnecessary. It empowers workers to want things, and trains them on how to get them. It stops managers from coming up with "brilliant" new ways to develop software and then force that method onto the developers. Managers who come up with ideas for products will have to explain themselves to the developers, and risk looking silly. In front of the pleb workers!!!. Dear god, costumers will get to see the greasy reality of how the software they want is made! And management have to knowledge that developers are the best at... developing.... And will have to... trust their workers...
A thing you will often hear in defense of not letting teams decide on how to develop, is that if everyone develops in different ways, then nothing will be standardized. Each team may use different tools, languages and architectures! It will be a massive mess!
Which is true... if you completely miss the point. Again, the developers should be free to choose HOW to develop. Not WHAT to develop. The product owner is the major force in deciding what features and products is developed, and standards like code format or use of profiling tools can still be required by management (Which is entirely reasonable).
But the teams get to choose HOW they develop those. A simple example, many people like placing brackets like this: void MyFunction(){ // some code }
But my team prefer doing void MyFunction() { // some code } The idea in scrum, is NOT to allow a team to go "We write however we want!". The idea is "WE decide how we get to the required form". I have worked in a team that simply had a auto-formater build into each of the team members command line tools, so when they pushed to the remote git repo, the code format followed the standard, and when THEY looked at it, it looked how the team preferred it to look. I have seen teams that wanted to work in a different language, so they used a Source-to-source compiler in much the same way.
That is scrum. It is a simple, yet powerful idea.
"I want to make games, but that requires programming skills and"
No. Just like starting to draw requires no skills, nor does making software of any kind.
Will you make great art on your first try? No. But you DID a thing.
Use the hellmachines that is machine learning for something useful. Go to chat GPT and ask it to make a simple game in html, cs and javascript.
Copy paste that into a notepad file, save it as "mygame.html" and open it with a browser. Any browser.
Bam. You have a game.
It is the equivalent of a stick figure drawing with no perspective, but it exists! Its creation is equivalent to tracing a drawing BUT IT EXISTS!
Now do it again, with less help. Figure out what different parts does by turning them on and off.
When you have questions, google them. If you have questions you do not know how to google, find communities and ask them.
You can do it! You can make things! Please make things! I want to see all the crazy stuff you will make!
“I want to write/draw/play music but I don’t know how”
Listen to me. Every creative endeavor is a leap of faith. It is flinging your soul off a ledge into fog and hoping you’ll land. There is no plan for that story you’re going to write. There are no directions for that space ship you want to draw. There is no sheet music for the song you haven’t yet written.
Making art is about accepting that you are plunging forward into the unknown, and using that to discover both yourself and your destination.
You don’t know how to write a story? Just do it! Go for it! There are no rules, friend!
You gotta make that leap.
So... I finished my first task at my new job today! First one after I finished Uni!
Which was to write the software for a sensor that is going into at least 150,000 pumps over the next year... Alone...
It is being tested by... me
And i have recieved a full 1 hour intro to all the material, including the protocols, codebase, arcitecture and the task itself...
Which is good because there is no documentation for these things ... nor is the compiler supported... and since the MCU reaches end of life in 2 years and was never popular, there is 0 examples to work with online.
I can highly recommend working for insane people, it gives you a LOT of interesting work
My boss: "So Moose, can you use the release toolchain to generate me a .hex file to run tests on?"
Moose, after several hours of trying: "No.
I mean it is theoretically possible... I JUST need to change the correct variables... but since our toolchain is an excel spreadsheet with buttons that activates visual basic macroes that calls chains of .bat scripts, which works with Rensas compilers and... Ruby... for some reason... and have 0 documentation...I have no freaking clue what anything does or where I need to change what..."
So probably this is old news for most of us on Tumblr, but binary gender is deprecated:
Fun fact, those two methods are NOT just different syntax for the same thing.
"If" Checks a condition. It compares it with something else. If you have a chain of many if/if else/if else /if else statments, the last one will only check its condition AFTER all the others have done so and failed. The if statements further down will be run with a delay compared to the ones further up. Only small, but real.
A switchcase runs every option with the same delay. No matter how many there are.
Because it uses its input, together with a constant, to get the correct memory place where the instructions are stored for the case, and jumps there.
It works by the compiler placing all the options in predictable memory so this method work.
So the swirch case does not compare its input to anything, it turns it into an address and goes there.
So the delay on every case is the same.
This can be important, if you are using the current time to measure time down to the micro or nanosecond, which is quite normal to want when you work with embedded systems :D
But rarely when working with higher level languages!
Its neat!
You know you wanna use it… So why don’t you?
When if your job is mainly about your network... then you are part of the leadership we can fire with no real longterm consequences.
Cut the fat. No firm should need "An aristocrat, because the other aristocrats will only deal with us when we hire an aristocrat to make bigger decisions"
No. Like a programmer who writes badly so no one but him can maintain it: "Fire them quickly, because every day you wait it will hurt more"
Just fucking fire the CEO, and most likely the majority of the next 2-3 levels of managment too.
Did you know people thought a country could not be run without a government? So even if the government is corrupt it is at least better to have than no government... and then Belgium just did not have one for almost two years... and they were fine.
They. were. not. Needed.
"Networking is how you get a good job" I am killing myself dawg
These are so tricksy to realise is happening.
Because I work embedded a similar problem that happens is "Your code and build tools are perfectly fine, but the hardware is unstable"
Noise on the wires, voltage changes when things unrelated to what I am doing are running.
Loads of fun things to figure out and learn that surrounds the code skill of "programming"
My program crashed for an hour or so and I tried to fix it
I finally fixed it
Twas a fucking compiler command gone bad
My code was good
FUCKKKKKKKKKKK
Got an email at work today that my workplace will now allow the use of co-pilot in development.
So I replied and asked what the firms stance is on copyright and licenses when it comes to large language models.
Because if their stance is that running code through a large language model strips copyright and licenses away then they have just given every worker permission to do that to the firms code and sell it to our competitors. Should take me a few hours to write the python file.
OR is their take that the copyright and licenses survive?
Because some of the code used to train co-pilot is under the GNU license meaning any codebase using it must be published as open source under the GNU license.
Either way, the firm is fucked.
I am looking forward to their response
Honestly... my advice when people ask how to learn git is:
1 Open a console.
2 Write "git"
3 press enter.
Now read and follow instructions.
Git is OLDSCHOOL.
Meaning it is a self documenting program
Like... I tell people that if they want the "It just works" experience, they should install Linux mint and move on with their life.
Now you no longer need to check the news if windows have snuck another thing that spies on you into your PC and you now need to manually turn it off. ( If Linux distro did that it would not have any users 12 months later... so they don't) .
There is no longer ads you risk clicking on by default embedded into your OS and programs. You cannot click on anything bad that can fuck up your machine ( User space protects ) because... it is YOUR computer. It is insane that this level of "don't have to worry. You are safe" is a feature on Linux... that should be a basic thing for every OS...
There is no obfuscation. Anything you want to see, change or control, you can. Everything is made to show you, the user, as clearly as possible what is going on. And if you don't like something, you can change it. 100% of the time. You do not have to hope that a UX designer remembered to give you settings and Daddy Microsoft allows you to do it.
When something is hard to see,understand or change in Linux, it is because it is a complex difficult thing. It is NEVER because a dude gets a salary for optimizing obfuscating how things work.
And it is not MAGIC. People who design and manage linux distroes are not a special race of humans with better ehtics and design skills than the lesser folk of windows and mac
You know what it is? Healthy competition. That thing so many people are in favor for in theory but not in practice.
It is because open source means the distros that get popular is THE ONES THAT THE USERS LIKE THE MOST.
And not just the Linux distro. Every tool. Every functionality. Every program and library. If the users want to use a competitor, they just can.
Like... my sibling in christ... stop begging Microsoft to fix visual studio so everything does not break if a file or folder have a space in it.
It have been 28 years. It is never happening.
Get ovet to Linux. Stop begging for features in Windows. In linux you DEMAND them. In linux you get them.
Because in Linux we BUILD them.
"I like windows. It just works."
No Jim.
No the fuck it doesn't.
AN ISAT REFERENCE IN MY C DEV MANUAL ?!?!?!? /j
Are y'all familiar with The Woven Book of Hours? This is a prayer book woven in silk BY LOOM in the 1880s. More specifically, the punchcard-programmed Jacquard loom, making it the first digitally produced book. It is estimated that it took 200,000-500,000 punchcards to weave it.
