December 10th, 2023
Reason 1: Mocking.
unittest.mock, Python’s mocking framework is so much more powerful than EasyMock, Mockito, or any other Java mock framework I’ve ever used. You can replace any method you like with essentially arbitrary code. No longer do you have to contort APIs with convoluted dependency injection just to mock out network connections or reproduce error conditions.
Instead you just identify a method by name and module within the scope of the test method. When that method is invoked, the actual code is replaced with the mock code. You can do this long after the class being mocked was written. Model classes do not need to participate in their own mocking. You can mock any method anywhere at any time, in your own code or in dependencies. No dependency injection required. You can even mock fields.
By contrast Java only lets you mock objects (not methods) and only when you have an available API to insert the mock in place of the real thing.
Reason 2: None
is its own type.
Read the rest of this entry »
Posted in Java, Programming | No Comments »
December 10th, 2023
Reason 1: Strong, static, compile time typing
I used to take Pythonistas at their word that they didn’t actually need strong, static compile time type checking. That was before I spent over a year writing Python more or less full time.
I am constantly blocked by not understanding which variables have which types. I am frequently spelunking through many levels of code and popping open the debugger to find out what type a variable actually has when. Not having explicit, enforced types makes code far harder to understand and edit.
Corollary: var
is very bad idea for Java and should not be used.
This is well known in the Python community today. PEP 484 is basically an admission that inline typing is a necessity for robust code, and Guido has admitted as much. It’s why large Python shops like Meta and Google have invested in tools like Pyre and Pytype to add strong typing to the language. These tools help, but they’re not as good as Java’s strong, reliable, static type declarations and type checking.
Reason 2: Checked exceptions
Read the rest of this entry »
Posted in Programming | No Comments »
April 16th, 2023
How many times have you seen someone use a hammer to pound screws because they are a hammer expert, they are comfortable with hammers, they don’t know how to use a screwdriver, and they don’t want to take a week to learn how to use a screwdriver? Maybe not so much if you’re a carpenter, but if you’re a software developer it happens all the time.
I’ve noticed a common anti-pattern of defining declarative DSLs in Turing complete languages — specifically Python — to avoid the overhead of learning new syntax and tools, XML or JSON. Instead programmers define the DSL as a Python library and reuse the Python compiler with predictable results. Blaze/Bazel, Airflow, dataswarm, and many other projects have gone down this road. Gradle made the same mistake, only with Ruby instead of Python.
This is massive tech debt that causes massive problems (security, indeterminancy, irreproducibility) and has heavy cost. Never do this. It always leads to a huge expensive effort to redefine the language as its own thing (not Python) that still looks like Python, and the team ends up writing a complete parser in addition to everything else. XML is not that hard. Nut up and learn it.
Do not write declarative configs in a Turing complete language.
Do not invent Python subsets for config files. <cough>Starlark</cough>
Posted in Programming | No Comments »
December 14th, 2020
Here’s another example of confirmations that shouldn’t happen:

Read the rest of this entry »
Posted in User Interface | Comments Off on Pointless Confirmation
November 3rd, 2019
There are so many privacy-enhancing extensions out there, it’s hard to keep track of which do what and where they overlap in functionality. Since an excess of extensions and plugins slows down your browser, I’ve decided to keep an updated list of what I recommend and use as well as the defaults that need to be changed. The following recommendations are as of October, 2019. I’m focusing on a relatively straightforward experience that doesn’t interfere with day-to-day surfing, break a lot of websites, or require extreme technical knowledge. (That is, no NoScript or GreaseMonkey.)
This article is primarily focused on desktop browsers. I might have more to say about mobile platforms in a future post.
tldr; Use Firefox 70 or later with these three extensions:
Read the rest of this entry »
Posted in Privacy | 1 Comment »