androidfred

Avoid optional, nullable attributes with this one simple trick

(Clickbait title, comment if it worked below :P)

TLDR, summary

Optional, nullable attributes needlessly introduce state to your objects and needlessly makes your code more bug-prone and more complex. By default, optional, nullable attributes can and should be avoided. A very simple and idiomatic way to avoid them is to just take them out.

Longer version

How many times have you come across classes like this

NOTE: Overuse of String and Int for everything is a problem all of its own, primitive obsession, but that's a different topic altogether - the topic of this post is strictly about what attributes classes are composed of, not necessarily their types

androidfred

Stop using noargsconstructors and setters (and builders)

TLDR summary

Noargsconstructors and setters are outdated, 90's style old school Java. They needlessly allow entire categories of defects that are easily avoided by using only allargsconstructors and no setters. Please stop writing code like that.

Longer version

How many times have you come across (or written) code like this

public class User {

androidfred

Use semantic indenting

TLDR - Summary

Semantic indenting can greatly increase readability and maintainability of code. It can even increase the quality of code! (eg by making excessive dependencies more obvious etc)

Longer version

How many times have you come across code indented like this (ignore the code, it's just gibberish, focus on the indenting itself)

    @Autowired
    public FooService(FirstDependency first, SecondDependency second, ThirdDependency third,

androidfred

This "progressively more detail" image loading algorithm can help you do and learn anything

Summary, TLDR

When doing or learning pretty much anything, the strategy where you tackle the whole thing all at once, but starting with a rough outline and then incrementally revisiting everything to go into increasingly more detail, is often more effective than doing things perfectly little by little and missing the big picture. (pun intended)

Longer version

Back in the days of dial up internet, which was very limited in speed and capacity compared to modern internet connections, images on a web page could take very long to load. There were different strategies for dealing with that problem, and if you look hard enough (pun intended again), they can reveal some things about how to do and learn stuff.

androidfred

Package by feature - not by layer

TLDR, summary

Traditionally, most Java apps are organized by layer, which needlessly encourages large, unwieldy "God classes" and spaghetti dependencies, where every class and package depends on every other across the system.

Instead, consider packaging by feature.

Longer version

Package by layer and what it leads to

How many times have you come across classes like this

androidfred

You don't need to learn to code, and neither do your kids

I'm a Software Developer, but I don't see why everyone should have to, or feel like they have to, learn to code.

In general, kids and adults alike, but especially kids, should spend more time being active, around others (within reason, these are extraordinary times), and outside - not in front of computer screens.

Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in baking, medicine, law, a trade or literally anything else.

That's not a value judgement, or a judgement of people's intelligence (or lack thereof - unlike a lot of techies, I don't believe we're smarter than everyone else), or a belief that you can't acquire or develop skills - it's just common sense.

androidfred

Test your tests

Summary: test interfaces, not implementations

Tests that pass when something is actually broken, and fail when things actually do work, are worse than useless- they are positively harmful.

The requirement

Let's say we've been tasked with returning 400 when GET /users/<userId> is called with a negative userId.

The test

The requirement can be turned into a test that hits the endpoint with a negative userId and checks that a 400 is returned:

androidfred

Basic resistance training program

WORKOUT A

Optimally, the order of the exercises shouldn't change, but if equipment is taken or whatever, changing the order is ok.

Squatting movement

2-3 sets of 5-15 reps each

eg https://exrx.net/WeightExercises/GluteusMaximus/BBFullSquat

doesn't have to be barbell squat - can be leg press, squat machine, single leg step ups on a bench you can do in the park, whatever, as long as it's a squatting/leg pressing movement

androidfred

Database pointers

I used to think creating and managing a db and a schema for a given service was easy, and that I knew all about how to do it... but I was wrong! There are actually quite a few things that need to be kept in mind in order to avoid easily preventable issues when working with databases and how they interact with your code and tests - this post will cover a bunch. Parts of it is pretty technology specific (eg AWS RDS and MySQL specific), but much of it is universally applicable for all db technologies so well worth reading even if you use something else.

I hope you will find it helpful - and that you will comment and point out any errors or things you think are missing that are worth mentioning!

Creating and managing databases

At Expedia, AWS RDS is commonly used. One of the main points of AWS RDS is to make creating and managing databases easy, but there are actually still a surprising amount of complexity and potential pitfalls that should be kept in mind when using RDS, much of which i

androidfred

How to run long running scripts, jobs

Running long running script jobs is tricky because:

• running them from your local machine, interruptions will result from loss of internet or VPN connectivity, or from your local machine going to sleep, running out of power etc etc
• running them from jumpboxes 1) interruptions will result from the session timeout 2) even if you send the script job to run in background, interruptions will still result from jumpbox churn (jumpbox machines are often churned all the time for security reasons) 3) jumpbox urls are often just load balancers, there's no guarantee that, even after sending a script job to run in background on a jumpbox, and you later ssh to jumpbox again, you will end up on the same machine (so you'll never be able to find, let alone terminate the process if there's a problem etc)
• in general, long running script jobs require using commands we don't use all that often (like nohup), making sure we keep track of and are able to kill the process if required, m