Posts in the “programming” category

I saw this definition of type safety yesterday in a book named Programming TypeScript and I thought it was very simple and good:

Type Safety: Using types to prevent programs from doing invalid things.

Kent Beck has a good article on Medium titled, Programmer Test Principles.

I had never heard of the term “Yoda Conditions” until now, but I have seen them in some Java code where programmers put the constant first in an effort to avoid null pointer exceptions.

(image adapted from codinghorror.com)

Famed programmer Joe Armstrong passed away this weekend. He created the Erlang programming language, based on the actor model, and without using Google, I’m pretty darned sure that Erlang had an impact on Akka, the very cool actor library for Scala. Here’s an article Mr. Armstrong wrote some years ago, titled, Why OO Sucks (OO as in OOP).

“Write shy code — modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations.”

~ Dave Thomas

I saw this “SQL joins as Venn diagrams” image on this Twitter page. To give attribution to the original author, it appears to have been created by C.L. Moffatt and documented in this Visual Representation of SQL Joins article. However, this article makes the case that Venn diagrams are not an accurate description of SQL joins.

“The sooner you start to code, the longer the program will take.”

~ Roy Carlson (which I saw in this tweet)

In general, I’m a fan of that quote, meaning that the harder the problem is, the more I like to find a whiteboard or some index cards to work through the problem that way before I start coding.

“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”

~ Neal Ford (as seen on this tweet)

This Wikipedia page on continuous integration is actually a good resource for computer programming best practices.

twobithistory.org has a nice story about Lisp titled, How Lisp became God’s own programming language. That page links to Paul Graham’s old Beating the averages post where he shares this Eric Raymond quote: “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.”

A friend of mine is an honest reviewer of apps. When I asked her to use the AAA iOS app while we were driving back from Florida, she said, “OMG, please don’t make me use that piece of crap again.”

From this AirBnB article about using React Native: “JavaScript is an untyped language. The lack of type safety was both difficult to scale and became a point of contention for mobile engineers used to typed languages who may have otherwise been interested in learning React Native ... A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.”

The 90/90 Rule: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”

~ Tom Cargill

Here’s An Illustrated Proof of the CAP Theorem, if you’re into things like consistency, availability, partition tolerance, and distributed systems.

Based on his current work in developing Rust, Aaron Turon has a couple of good blog posts on developing/leading open source projects titled, listening and trust, part1, and listening and trust, part 2.

I just came across a couple more null values out in the wild, this time on the espn.com website.

A video I want to watch: Why writing correct software is hard, and why math (alone) won’t help us.

I can never find a list of states for an HTML select/option list (aka, combobox, drop-down list) when I need one, so I’m putting two versions here. The first select/option list shows a list of states, but only shows the abbreviations of the states:

For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:

1. Passes the tests
2. Reveals intention (should be easy to understand)
3. No duplication (DRY)
4. Fewest elements (remove anything that doesn’t serve the three previous rules)

There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so ‘passes the tests’ takes priority over ‘reveals intention.’”

For more information on Kent Beck’s Four Rules of Software Design, see that link, or this link to the original rules on c2.com.

I haven’t worked with JavaScript much in the last few years, and I just learned about this cool console.table output-logging technique, which I just saw on this website, which has several other good JavaScript debugging techniques.