For doing it in C, by far the most useful thing you could do is implement your own generic hash table. Having a good hash table handy makes things a lot easier. Though since you're a beginner you might want to find a good library for it at first. Writing a hash table is great C exercise though, so I definitely recommend doing it at some point.
I don't necessarily want to share my github as it contains my real name, but I'd be willing to send you a tarball of my 2020 code tomorrow if you send an email to mtlmtlmtlmtl at pm.me
I've just now started on day 1 for this year, so no code there yet worth showing off.
I think I understand how to build a hash table except for one thing: which hash function should you use? Is there a simple one that’s good enough for most things? How do you pick one?
You would write your hash table constructor to accept a hash function as a function pointer then pass in the appropriate hash function for whatever the key type is.
You can use the same hash function for any arbitrary struct as long as there's no pointers in it. If there are pointers, you'd have to implement one combining the hashes of all the members through something like xor. I used fnv1a_64 for my hash function in AOC 2020 which is a pretty good general choice for strings and other contiguous objects and is just 10 lines of code. Pseudocode on Wikipedia or I'm sure you can find C code on Stackoverflow. Hope that helps :)
if your hash table is a really good modern open addressed hash table, something like Google's Swiss Tables, you need a really good hash because you will be badly penalised otherwise, these modern structures demand a hash with proper behaviour for even halfway reasonable performance.
If it's just a My First Hash table with closed addressing, buckets etc. you needn't care too much. If you're hashing integers, just use the integer itself, that's a terrible "hash" but with this like 1980s data structure it's good enough.
Fujitsu TX100 s3, TX120 s3, Dell ML110, HP microserver series are little towers, quietish (you can change out the fans to make them practically silent).
I'm disappointed that the three photos in the Gallery with the laptop in use aren't actually showing what the screen would look like IRL; they've been cleverly doctored by overlaying screenshots on top of the display.
I found out about this book through the EmbeddedFM podcast [1]. Their latest episode is an interview with the authors of the book. Highly recommend the episode, and the podcast in general for folks that are into electronics.
What kind of company were you working for? I've lived and worked in Melbourne my whole life and complacency is not a cultural attitude of the location, but of specific companies.
Agreed - I work in Australia and I've worked with a lot of complacent people but a lot of very good people too. I thought the complacent people was just Sturgeon's Law applied to people who work in technology.
