Kartones Blog

I had read that LinkedIn Learning was an acquisition and rebranding of the famous Lynda.com platform, but hadn't given it a try (nor have I taken any Lynda course in the past). But yesterday I saw that I had "free access" to some courses, and one of them looked interesting. Being an opportunity to a) see how the learning platform works and b) actually learn or at least refresh some Java concepts, I gave it a go.

On with the small review:

Java Memory Management It's a 3h course, roughly half of it code examples and exercise walkthroughs. We'll learn how Java keeps variables in memory, from basic stack-heap concepts to the final keyword or String specifics, basic JVM optimizations we can apply and, most important, an introduction to finding and debugging memory leaks and memory usage potential problems. I liked the introduction to a few tools, attaching to running applications and checking how memory grows (or keeps steady on well behaving programs) but also how to grab and afterwards load heap dumps.

Explanations are clear, diagrams simple and abundant, code examples to the point and easy to follow, and in general my only complaint is that the course is old, as mentions Java 8 being "recently released", which in 2021 is not the case anymore 🤓 Still, worth watching.

Notes

• primitives and object references go to the stack, objects to the heap
• one stack per thread
• one heap per application (shared between stack)
• object references are passed by value when passing objects as method parameters
• final does not apply const correctness
• Easy to have escaping references, so return immutable objects (e.g. unmodifiableMap or ImmutableMap) and build readonly versions of objects
• JVMs optimize and create objects in the stack if detects they are local scoped only
• Java does string interning, that's why it's important to use .equals() instead of == when comparing them
• PermGen heap existed until JDK7, Since JDK8 is MetaSpace
• Java VisualVM tool and the Visual GC plugin for memory analysis
• Memory Analyzer (MAT) (from eclipse.org) tool for heap dumps

2021-01-24

Review

Title: Rocket Jump: Quake and the Golden Age of First-Person Shooters

Author(s): David L. Craddock

I read Masters of Doom in 2010 but the book was written in 2004. Still, it stopped its tale after the first Quake, and we could say that it is a mostly positive story. Rocket Jump spends a brief time talking about Wolfenstein 3D, more about Doom I and II, but the majority of time goes from 1995 onwards, through the Quake series but also including Doom 3 and mentioning most modern entries (like Rage, Doom 2016 and Quake 4), up until 2018. As such, it is a great complement to get a broader picture of id Software, and of course their games and the id Tech engine evolution.

Some of the content is narrated, but mostly consists of interviews, with author notes and remarks where deemed fit. While the chapters are in chronological order, during the interviews content goes back and forth a lot, so for example we'll learn a dozen times how hyped id were about the NiN band, or we'll read a triple interview about (theoretically) one topic switching interviewee each sentence, even if they are not talking about that topic, making it weird to read, at least to me. But despite the occasional offtopic drifts all of the interviews add value.

At first I thought I was going to read mostly generic and high-level technical details of the Quake games, but I'm happy to inform that some interviews go into specifics and narrow but great detail. Quake not only brought one of the first true 3D engines, but also spawned a new era of modding, so we learn about QuakeC, mapping, the creation of quake movies (so called machinima, using the game engine), and a few highlights of memorable and amazing mods, like Quake Rally, CTF, Team Fortress and the first Quake bots.

The second half of the book (approximately) contains interviews with people from closely related companies to either Quake or in general First Person Shooters: 3D Realms, Valve (the folks behind Team Fortress mods and games), Rare (because of Goldeneye), LucasArts (creators of Dark Forces), a member of Nine-Inch Nails band (Quake's soundtrack and many effects were done by them)...

I used to think about id Software as a hard working but cool videogame studio. After reading the book, I am still glad they made the games the built, even if they have been repeating the same genre for more than 25 years, but I now know that the company culture degraded while building Quake, and never recovered, slowly getting worse and worse until almost nobody from the original team remains anymore. The book summarizes at the end: "Id Software has rocket-jumped time and again over more than 20 years. [...]. Every single time, they paid a price.". A fitting sentence for a company where backstabbings and unexpected employee firings were way too common.

A great reading, especially if you lived through that era of the FPS shooters and adventures.

2021-01-10

Review

Title: 97 Things Every Programmer Should Know

Author(s): Kevlin Henney & others

As you might guess, this book contains 97 tips and advices for programmers (nowadays "developers"). Each tip is 1.5 to 2 pages long, and the topics are very varied: From design patterns and good coding practices to testing, refactoring, debugging, Continuous Integration, compilation/build & deployment... but also other areas like estimations or collaboration (code reviews, pair programming, etcetera).

It's from 2010 so starting to feel outdated at some places, but in general the advices are still relevant as of today (mostly why I kept reading it until the end).

Can be read quickly, and doesn't contains much code. Also, with brief texts comes brief descriptions, so if something interests you, probably you will have to dig deeper on your own.

Not bad, not a revelation, still a good reminder of (mostly) good practices.

Notes

Miscellaneous, unsorted notes (far from all of the book contents, though)

• leveraging technical debt
• Referential Transparency
• Understand your users (false consensus effect)
• Many incremental changes instead of a huge one
• Check and add tests
• New tech is not enough on itself to justify a refactor
• Sharing code (components, libraries) creates dependencies, take that into account
• Boy Scout Rule (leave the code better than you found it)
• Concentrate on building business-domain code as much as possible (today evolved to "build vs buy")
• Simplicity wins
• Explicit domain concepts
• Good encapsulation. It's all about narrow interfaces
• Code layout: easy to scan, standardized, expressive, compact
• Do code reviews
• Reason about: Preconditions and postconditions for functions, invariant for loops, immutable objects whenever relevant
• Nested sections -> Nested functions
• Short, single task focused functions, with few parameters
• Code comments: only relevant ones. "Comments as code": Either they add value (complement code) or are waste to remove/rewrite
• APIs:
  • Difficult to get right the first time, more difficult to change later
  • Good abstraction
  • Symmetry and consistency
  • Expressive
  • Convenient for the caller
  • Write unit tests for code that uses the API -> surfaces hurdles
• Don't ignore/silence errors, fix them
• Learn a language, but also understand its culture
• Interfaces exist for the convenience of their users, not their implementers
• Domain-specific types over primitive types (e.g. VelocityInKnots)
• Prevent errors by helping/aiding the user. Massage input, offer hints, cues, defaults...
• Write code as if you had to support it for the rest of your life
• Write tests for the people trying to understand your code

2021-01-05

Review

Title: The New Corporation

Author(s): Joel Bakan

When I watched The Corporation it blew up my mind, mostly because I vaguely knew what a corporation was (I thought it was "just a big company"). I totally recommend the documentary, and I won't be going into details of what corporations are. Just watch it.

What this new book (and related documentary that I have not seen) does is building upon the first one, looking back to what has happened in the last 15 years since the original publication. It explains how corporations have changed, not on their underlying pillar (seeking profit), but in the public message and image they showcase, now being in theory agents of change. We learn how they are "doing well by doing good", making money by being good actors, not being good actors because its the right thing to do. Get explanations of their "social and environmental values", given that many times their solutions are not even solving the problem or solving a problem they themselves caused before. And of course, avoiding as much as possible the most equitable solution: paying taxes.

Other big topic covered is how they are slowly taking control of public services through privatization, proclaiming that governments are no longer needed, instead "good corporations" being the solution. Also enumerates quite a few scandals and notable accidents from big corporations.

I don't want this to be a big review, so a more detailed, almost chapter by chapter summary and quite a few "evil corporation examples" can be read at CounterPunch.

The book tries to not be all grim and pessimistic, the last chapter being focused on sources of change for good and ways to "fight back" privatization and abuse of power. Although feels small compared with the remainder offering such a negative view of the world, but at least is something.

It's an interesting book and an easy read. You might not agree on everything it says, and I also think that a few specific topics take too long (too many examples given), but still good overall and recommended.

2020-12-27

Review

Title: The Tech Resume Inside Out

Author(s): Gergely Orosz

I've read quite a few articles on how to improve your resume/CV, but half of the times you don't know if the person giving the advice really knows about it, and the other half the advices are generic, not only for technical resumes. I heard about this book listening to a podcast and thought would be handy for my wife, but I've actually fully read it and applied quite a few of the suggestions it provides.

It's around 200 pages and includes a few handy templates if you don't want to start from scratch. I liked that it contains both advices from the author and from other hiring managers, recruiters and staff-level people, all of them from the tech industry. It also clearly states that a technical resume (at least one oriented either for a developer or for an engineering manager) has certain differences from a generic one, providing many examples and very specific points to modify or even remove.

The book also touches more sensitive areas, like potential biases, career switches, or coming back from long breaks, and being recent even covers COVID-19 specifics. It doesn't shies away from pointing out wrong software, services and myths about resume screening, a sincerity that I don't see often. Similarly, most of the "before and after" examples are very direct with the flaws (and why they are such), and you will probably feel identified with some of them (at least was my case).

I think the book is quite useful as there is not much literature specifically for software development and similar tech positions, plus the templates are a welcome extra. What I did was read it while applying some of the ideas and changes on my on CV, but can also just be fully read once and then do a second sweep directly focusing on what you felt would be improvements.

2020-12-13