- Find handy dandy note taking software, drawing software, and system design/modeling software
- Start off by piggy backing off established extendable software
- Modify read mes/configs/presets
- Look at small already made extensions/plugins/addons and modify them a. if you are stuck look at extensions/addons from similar software in the same language or different applications, and read documentation and use tests
- Then move on to make your own extensions/plugins/addons
- Then work on other small libraries
- Then work on other editing other established softwares And refactoring them
- Then when you feel comfortable enough you can make your own software
- Learn the standards of the language
- Read docs
- Read code outloud like english sentences
- Look up stuff you dont understand
- Read the tests
- Read comments
- Look at similar projects
- Use tools to help you such as ides, debuggers, and ai
- Ask for help from contributors, forums, and issues
-
identify the problem - thinks of in terms of what is repetitive, what changes frequerently, and dependencies:
a. type of problem: its a counting, minimum/maximum, or a greedy problem
b. the cases: base, edge, corner, and boundary
c. variables: input, output, mutable, static, and global
d. bottlenecks: searching/accessing, ordering/sorting, and reading/writing,
f. patterns: Data collections, data encoding, and dataflow,
-
Research and decide on focus areas - think in terms of modularity, use case, and distributive scaling strategies
-
Write good pseudo code - to make it easier to name stuff later down the line
-
Write good tests - to allow for debugging, minimize bugs, and the problem actually being solved
-
Implement the code - solve the simplest problems, dont be afraid to use an extra dependency or two as you can inline them later
-
Document, organize, and refactor your code
The most straightforward theory is preferable to all others of several sufficient possible explanations for the same state of facts. In other words: The simplest explanation is always the most probable.
The simplest explanation for the best approach to testing is that we work with the information we can get.
Efficiency depends not only on the quality of information we find but on the usage of that information.
information we collect has a certain level of quality, but not all information is helpful. More than that, some information can confuse and disorient us completely. To learn to discern such information, we need a repertoire which we collect by practicing. Therefore, it is essential to understand the context of the topic we are researching.
90 percent of people are significantly more successful in achieving their dreams by setting challenging and specific goals.
Once we know the goal (The Goal) to which we are attracted (Willingness), we can use various principles, such as the Pareto Principle or Occam's Razor, to develop our talents (Talent) and skills and make our decisions (Decision Making) to pass the obstacles that fall across our path by asking the right questions (Questioning).
No matter what goal we have in mind, we must decide on it.
Because the decision of what goal we want to achieve influences how we learn, a task or goal helps us influence how we think.
How to reach the goal? If we think about it few successful people are able to say that they knew exactly what path that would lead them to their goal beforehand. What they do know for certain, is the goal that they had set for themselves.
A problem is an emotional state. Without emotions, it is just a situation.
The only thing we have to do is to add the word "yet."
I cannot do this '**yet**.'
I do not understand this '**yet**.'
This is not for me '**yet**.'
Progress is noticeable when the question that tortured us has lost its meaning.
However, first of all, we have to fail. It is an unavoidable and essential part of learning. This is one of the parts of the learning process which make us successful. Experience is built on failures. It explains that we know how to handle differently. Sometimes adverse, situations where something does not work as expected.
Solving a problem can require creativity
it is necessary to put our brain into a different "mode," forcing our brain to function differently. A specific category of activity that forces our brain to behave differently is called creativity.
The reason is that we force the brain to invent something new. At the same time, we cannot focus on the mindset while developing something new as this requires completely different thought processes than dealing with a task.
we use the information we already have. The art of thinking, called "Outside the box," is an essential part of the "hacker mindset",
Thinking outside the box means seeing things outside of the limitations placed on us
once you solve a problem, it is important to:
- think about how many different ways are there to solve it
- think about why you didn't solve the problem in a different way.
- think about the reasons for choosing the method that you chose
it is crucial to train the eye to notice even the most minor details. All our knowledge and experiences are based on associations that connect us with different perceptions, such as colors, smells, etc. These will be recalled later either actively or passively.
The primary and most difficult objective we must overcome is the combination of our knowledge, adaptation, and new information.
We have to understand how things work, how they are structured, and how to use them. All of the technical information we need to be successful in this field is already out there.
Purpose of documentation is to present the information we have obtained in a comprehensible and easy way to reproduce a specific activity.
Therefore the essential characteristics of documentation are:
1. Overview
2. Structure
3. Clarity
information we collect has a certain level of quality, but not all information is helpful. More than that, some information can confuse and disorient us completely.
When writing docs:
- position yourself as a reader
- Avoid repetition and ambiguity.
- Make documentation as easy to read as possible.
It often is not easy to find the information we need. First, we have to find out what kind of information we need.
* What do we already know?
* What do we not know yet?
When reading new information, an individual process is started, there is an initial reaction to an external information's influence, and then we imagine/interpret and process/link to our own existing knowledge.
We learn what we need, how to use it, and how to work with it. We will see what kind of things can happen, collect our first practical experience, and improve our existing skills
Moreover, the we can now learn all of the theoretical aspects more in-depth through practice and repetition.
To be good at something means we know what we are doing. If we know what we are doing, that means that we are experienced with this topic. Experience means we have a vast repertoire in this field. Repertoire comes from associations and practical experience. When we say practical experience, we want to know how much we have to practice to become competent at a specific task.
A right question is a precise question that allows us to establish the relationships between the components, to understand them, and to take us one step further to the required answer.
Relational Oriented Questioning Model represents five components:
Your Position - This describes the position we are in and our view. The Object - The object is the core element of the question. The main component of our sentence takes the meaning out of the question. Known - This information is known to us. Unknown -This information is not known to us. Other Position(s) - This component describes the position of other persons.
We can assign two states, rough or precise, to a question:
* A rough question would be: "How can I hack X?"
* A precise question would be: "How can I use the server's SMB service to identify its existing user accounts?"
- Connection - How is X connected to Y?
- Affection - How does Y influence the state of component X?
An inexperienced woodcutter takes 30 minutes to sharpen his axe and 3 hours to cut down the tree.
The experienced one will sharpen the axe for 3 hours and cut down the tree within 30 minutes.
Therefore, it is essential to understand the context of the topic we are researching and it is essential to pay attention to details that appear unimportant at first glance
What happens when we get stuck? There are many ways that we become "stuck". It could be that we focused too much and lost the context of the task at hand, or we are tired and did not take enough breaks.
We know that one person cannot know everything. In this case, we have to learn how to find, choose, learn, and adapt the information we need.
To filter such information, we need a repertoire which we collect by practicing.
Focusing is the purposeful and deliberate alignment to a specific goal.
If we know our goal, it is easier to align our focus accordingly.
Attention is influenced by your interests, needs, personal attitudes, beliefs, orientations, goals, and experiences.
When we leave the so-called comfort zone, we enter a situation or field where we have little or no experience. This kind of uncertainty lowers our ability to think and has a powerful impact on our thought processes, which, in turn, slows us down.
- small children do not exhibit such uncertainty
- They love to try out something new all the time and are not afraid or uncertain of making mistakes.
Mistakes are an essential part of the learning process, and we should always keep it in mind.
Those who chose to leave the comfort zone would reach their destination faster than they thought they would. They would never have sprinted at such speed before in their lives.
Now we should understand the progression between decisions to step out of our comfort zone or stay in it. We will often get into situations where we do not know what to do. These will come again and again. However, we will always learn something new, and it will become more comfortable each time.
Document and write version of all tools being used in your project with their versions and operation system env Keep track of reference env
Make sure you can build the entire project with just one command at all times so u can reduce change of mistakes
While you're writing down style, you might also want to think about documenting how you do other things in your project consistently:
- What do your commit messages look like?
- What do your issues/tasks look like?
- How are files and folders named? These are things that are harder to automate, but worth writing down! Again, consistency is the most important policy, so decide something for now, and write it down! Any time you have a "should we do X or Y" discussion, WRITE IT DOWN and never have it again.
- Continuous Reviews
If you do reviews during a Pull or Merge Request on GitHub/GitLab, these are a good example! By focusing primarily on the changes, you get a better chance to see "micro" level changes. Did someone change what a function does? Did someone add a bunch of new code? Does what they changed make sense?
These reviews are great for giving directed feedback (could this be done more simply? Is this adequately tested?), and for checking hard-to-see in the "large scale" bugs, like off-by-one errors, or forgetting to validate some input or check whether a pointer is null (in C/C++).
- Inspection Reviews
You want to have someone "drive" and explain each part of the code, and allow the team to ask "why" questions, as well as considering "does this make sense?"
Think about how the different parts of your system interact with each other, either through message passing, function calls, shared memory, semaphores/mutexes, or any other way. Is the system matching the original design? Or is it growing in an odd organic way?
For both kinds of review, there is one important concept to keep in mind: Respect.
You should also automate any steps of the review you possibly can.
- Code formatting? Automate it.
- Code LINTing (we'll talk about that later)? Automate it.
- Do the tests pass? Automate it. Review time is EXPENSIVE, use it on the important stuff that you can't automate.
Really at the end of the day, the usefulness of reviews boil down to a one thing: It's good to have different perspectives of the code that you write. You get one for each of:
- You write it
- You test it
- You explain it to someone else
- Someone else gives their perspective
Also, take note of the kinds of questions that were valuable in a review. Eventually, it will make sense to collect these into a review checklist you can use to help jog your memory and ask good questions. Do all pointers get checked for NULL? Is input always validated? This checklist is also a great training tool
Eyeball debugging: But in summary, it's helpful to think about the tools you have for observing at hand already, and to think about your expectations for how your system works vs. how it is actually behaving.
Print debugging: this works best using the scientific method:
- Guess at what your system is doing
- Add print statements
- Run, and analyze the results
- Repeat until everything is clear
Second: Debuggers like GDB typically require "stopping the world" to step through code at "human speed". This means that a lot of odd things can happen:
- Interrupts may not fire as normal
- You might miss messages or events
- Hardware can "time out"
In terms of mediating the cost of print debugging, there are a couple "power user" techniques that are great to add to your toolbox. At least for Cortex-M devices, these include:
- Semihosting
- ITM/SWO
- RTT
- Memoized logging
- Deferred Formatting Semihosting is a technique of "logging over the debugger", instead of over a serial port.
From a plus side: It's very easy to implement, and if you have a JTAG/SWD debugger, you don't need a separate serial port! All these messages just go through the debugger.
- https://github.com/sindresorhus/awesome
- https://github.com/jaywcjlove/awesome-mac
- https://github.com/Awesome-Windows/Awesome
- https://alternativeto.net/
- https://www.libhunt.com/
- https://git.herrbischoff.com/awesome-macos-command-line/about/
- https://git.herrbischoff.com/awesome-command-line-apps/about/
- https://github.com/karan/Projects-Solutions
- https://github.com/GorvGoyl/Clone-Wars
- https://book.hacktricks.xyz/
- https://ctf101.org/
- https://www.hacker101.com/
- https://anonymousplanet.org/
- https://www.privacytools.io/
- https://blackarch.org/
- https://atlasos.net/
- https://haveibeenpwned.com/
- https://www.techempower.com/benchmarks/
- https://os.phil-opp.com/
- https://missing.csail.mit.edu/
- https://www.lurklurk.org/effective-rust/
- https://craftinginterpreters.com/
- https://learnxinyminutes.com/
- https://regexone.com/
- https://www.interviewbit.com/
- https://www.tutorialspoint.com/
- https://www.w3schools.com/
- https://www.bigocheatsheet.com/
- https://programming-idioms.org/cheatsheet/Rust/Python
- https://rosettacode.org/wiki/Rosetta_Code
- https://hyperpolyglot.org/
- https://www.breakdown-notes.com/make/load/rust_cs_canvas
- https://google.github.io/styleguide/
- https://refactoring.guru/
- https://phuoc.ng/
- https://quickref.me/
- https://webhint.io
- https://cheats.rs/
- https://www.arewewebyet.org/
- https://devdocs.io/
- https://devhints.io/
- https://www.30secondsofcode.org/
- https://cpppatterns.com/
- https://hackingcpp.com/cpp/cheat_sheets.html
- https://www.sonarsource.com
- https://bytebytego.com/
- https://osintframework.com/
- https://metager.org/
- https://www.phind.com/
- https://you.com/
- https://searchcode.com/
- https://sourcegraph.com/search
- https://www.kaggle.com/
- https://cheatography.com/
- https://www.exploit-db.com/
- https://roadmap.sh/
- https://andreasbm.github.io/web-skills/
- https://www.sijinjoseph.com/programmer-competency-matrix/
- https://godbolt.org/
- https://dogbolt.org/
- https://crackstation.net/
- https://2captcha.com/
- https://codebeautify.org/
- https://regex-generator.olafneumann.org/
- https://codepen.io/sdras/pen/rpwjzw
- https://www.fakenamegenerator.com/
- https://beej.us/guide/bgnet/
- https://cses.fi/book/book.pdf
- https://gamehacking.academy/
- https://pages.cs.wisc.edu/~remzi/OSTEP/
- https://algs4.cs.princeton.edu/home/
- https://carlcheo.com/compsci
- https://visualgo.net/en
- https://tourofrust.com/index.html
- https://thimbleby.gitlab.io/algorithm-wiki-site/
- https://www.youtube.com/watch?v=txr7iB4NFEE&
- https://www.youtube.com/watch?v=erEgovG9WBs
- https://www.youtube.com/watch?v=a2EkORFcSZo
- https://www.videocopilot.net/tutorials/
- https://texturelabs.org/
- https://greyscalegorilla.com/
- https://diffusionbee.com/
- https://chat.freedomgpt.com/
- https://www.speedtyper.dev/
- https://scratch.mit.edu/
- https://www.codingame.com/start/
- https://apps.apple.com/us/app/swift-playgrounds/id908519492
- https://www.exercism.org/
- https://www.codewars.com/
- https://www.openvim.com/
- https://cmdchallenge.com/
- https://www.linuxfromscratch.org/
- https://wokwi.com/
- https://crackmes.one/
- https://honzaap.github.io/Systemizer/create
- https://racknerd.com/