Serialization is the process of converting a data structure into a format that it can be safely stored or transmitted and the recreated from the stored or transmitted format. It's usually used to refer to applying this process to complex data structures like trees, objects, or graphs, as they don't inherently lend themselves to being transmitted as a simple string of binary data. Converting an in-memory object to JSON or XML is an example of serialization.

Parsing, on the other hand, takes a stream of (structured) data and then does something based on the contents of that stream, usually either creating an in-memory structure based on it, or executing a sequence of operations based on it. Deserialization (the reverse process of serialization) is a particular type of parsing, it takes serialized data and recreates the original data structure from it. However, you can do many other types of parsing. Compiling source code is also a type of parsing (together with then serializing the result of the parsing as machine code or assembly), as is linting or formatting code, doing static analysis of it, and many other things you would do to it using tools. So is decompressing a compressed file or listing the contents of an archive.

Note that both terms are very generic. Parsing routines and data serialization routines tend to be rather specific to the exact purpose they were designed for.

I've now had five (!!!) Pull Requests merged into open source projects! This closes one of my biggest programming bucket list items 😃 And I'm still making more, so its only going to go up from here.

It's a waste of time to learn vim.

here's my reasoning.

Yes it's a bit annoying if you have to edit something on the fly on a server without a GUI - but fumbling around in vim for this small amount of time is still quicker than learning all the keybindings. and why are you vimming around on the server anyway? isn't that a red flag in the first place?

I have probs spent well less than 1 day in total working in vim, in my dev career.

whereas I spend 8 hours a day in an IDE which catches 80% of my mistakes for me and offers all sorts of other features to boot.

My thought is Royfeld. It’s one word and the .com is available (obviously the most important reason to choose a name).

My tips:

• Consistent formatting.
  • Helps in scanning files if everything is "as it should be", exact styles aren't as significant as some make them out to be, but consistency is.
• Naming things well.
  • Some developers have trouble with this, but I like to think of it in a simplistic way. If someone came to you and asked "what does this do?", rephrase the response into a name. If every variable is a basic noun, things can get muddled and there is extra overhead to understand the code when repeat names that are basic continue to show up. Being slightly more descriptive makes a huge difference.
• Comments that are complete sentences (subject/predicate) that do not only restate the code.
  • I don't say that to test English, but I have seen a lot of comments that are very vague or cryptic. They might be a sentence fragment or phrased as a question without a question mark, so it can be confusing as to what the meaning is.
• Avoiding brevity and making code for humans to read.
  • Abbreviations and acronyms might make sense when writing it, but it might not mean anything to others or yourself in the future.