DeeKaying @ Nettle

Inheritance vs Composition is an age old debate. The world has evolved enough that it's time to put this discussion to rest. There is no good reason to ever use inheritance in new code. Composition is functionally identical to Inheritance, produces superior outcomes, flatter class hierarchies and more flexible code than inheritance. Composition also does not violate encapsulation and avoids classes of issues produced by unexpected polymorphic dispatch to implementations. We get better class design for free as well.  In short, never use inheritance - always express the same code re-use through composition and be happy. Let's go through each of the points one by one: 1. Composition is functionally identical to inheritance. This one is easy to work with. When inheriting implementations, all subclass methods have an implicit parameter (an instance of the superclass). Composition just makes this parameter explicit as a constructor argument and takes away the superclass. Code reuse t...

I was in a funky corner of the internet, reading about reinforcement learning when I chanced upon this article that compares a number of reinforcement learning algorithms. Since we as humans are glorified neural networks amenable to reinforcement learning and companies are nothing but hierarchical relationships between humans, it was very interesting to go through that article with a business point of view. Long story short, the article figures out various conditions in which the algorithms are able to break down a task recursively, the optimality convergence conditions and the "knowledge" required of the lowest level agents to learn successfully. From my reading of the article, I'm most drawn to the "Options" style of management: work with high quality people, give them maximum freedom to act and step in only at decision points. This is the style of management that I'd grown used to at Google (and that I've seen work really well there) and is quite in ...

So you're looking to run a MySQL docker instance without any environmental dependencies? Here's how to do that: $ docker run --name mysql-test -e MYSQL_ALLOW_EMPTY_PASSWORD=true -e MYSQL_DATABASE=testingdb -e MYSQL_USER=scott -e MYSQL_PASSWORD=tiger -p 3306:3306  mysql/mysql-server:latest Documentation on the various environment variables are located here: https://hub.docker.com/_/mysql   To connect to your MySQL instance without depending on my.cnf: $ mysql --no-defaults --host 127.0.0.1 --port 3306 --user scott --password --protocol tcp testingdb That's it. You have a running instance of mysql from a docker image and you're connecting to it with a generic mysql command line client. Have fun.

Following the Unix philosophy: Do one thing, do it well and be quiet about it. In software engineering, if you're writing a system that's useful and suddenly, one day, you think it's nice to notify users via email that their useful thing is being done, you're making a mistake.  Emails from software systems should be actionable: if a system is sending an email to a user, it should be helpful, provide enough context about who it is, where it's running, who owns / runs it and what the problem is that requires human attention. Ideally, the alert email should clearly specify the next steps and the dashboards that can be used to ensure that the problem is fixed. The worst offense of the system is to send out success emails. This fails on 2 counts: 1. Success emails are not actionable - if I read a success email, I am informed and I promptly create a Gmail filter to never see another success email from the system again. The system made me do active work to ignore it. 2. Su...

If want to run your docker process with some tweaks because it's crashing in your docker container and causing the container itself to stop (without giving you a way to inspect the files on the image), here's the magic command to start it with just bash. (I found this after quite a bit of hunting on the internet, the magic flag is --entrypoint and don't forget the -s at the end) Here's a sample command: docker run -it --entrypoint /bin/bash  $IMAGE -s Sourced from: https://vsupalov.com/debug-docker-container/

Read this book by Edmond Lau:  Highly recommended. His experiences parallel my own. The book is written engagingly, quick to read and succinct in its delivery. 

I typically share the contents of this document the first time I meet someone I'm going to be working with for a long time. Style of communication: Direct and clear. I don't do well reading between the lines. If you would like me to know something, please say something. What is important to me: High quality code and a highly productive, functional team. I don't believe in posturing. I believe in commitments and delivery. Delivering more and talking less is a good way to show impact. What kind of leader I'm trying to become: One who can grow people. I'm driven by Mission, Vision, Values. What I value in an organization: Transparency, Trust and Integrity. If you have a problem, speak up. Don't ever go behind someone's back. Bring problems up together so that I can see both sides represented fairly. Be direct. What I seek in people I work with: Ability to execute and potential to grow. I will endeavor to make you a better engine...