Posts

Fundamentally Wrong

Image
The Problem An article  has been shared with me by several friends and also by some critics, and some people who are both, describing how TDD is fundamentally wrong, and doing test-after-development is better. To be fair, the process described here is fundamentally wrong: The problems with step #1 would indeed lead to the wasteful problems described below it. The recommendation here would certainly be better than the process described above: TDD Is Fundamentally Wrong is Fundamentally Wrong Now, the problem with this article is more fundamental than the problem being described. TDD does not mean " Write all the tests then all the code " It has never meant that. That is not TDD. That is some other misbegotten travesty that has no name. This is the fifth or sixth time I've heard anyone describe TDD as writing all the tests first. In all cases except one, it has been described by people who self-describe as being anti-TDD, and who write articles decrying the foolishness tha...

Python Listicle!

People often ask me (directly, or just generally posting to some social site) how they can learn Python quickly.   Learning Python is one of those things where one can begin quite easily and quickly, but there is some depth to the language that one will want to understand and use once one gets past the most elementary early uses.  If you are learning from tutorials, you might want to follow along in a REPL. You can try running Python locally (see ipython and/or  bpython ), as a Jupyter notebook, or in  Repl.it  if you want to keep your local machine Python-free for the time being). You will probably want to install an IDE, though. There are many   Python IDEs and Editors  in the world, but  PyCharm is the king of them all. Nothing else even comes close. So, here are some great places to start: Learn X In Y Minutes  is great for experienced developers who are unfamiliar with the syntax and idioms of Python. It's all learn-by-example a...

Leadership.

  I have this very simple/simplistic view on leadership. People will become a follower if: a) They believe the person is competent b) They will personally benefit from that person's competence Whether it's a minister, a businessperson, a writer, a local organizer, or a criminal doesn't matter all that much. We like to impart character and integrity to our leaders, and we like to pretend that we chose them because of their superior traits, but it doesn't matter as much as we would like to pretend. If those were really the criteria, we would never fall for con men and tricksters. Remember. that people followed some pretty unsavory characters in the past and many do now. I had to chew on this for years, because people can be radical followers of some pretty awful characters. Why would they be so blind to the character of their heroes? It seems consistent now if one focuses on two factors. The perceptions don't even have to be correct. Sometimes confidence masquerades ...

Choose your Expression: Structural Matching, IF-ELSE, and Dictionaries

Image
 So, I have a command line utility that collects and presents some time-series data. What it is isn't important, but dates are involved. You can specify start dates and/or end dates with options --after and --until .  If you specify neither, you get everything. This programming idea is not so interesting on its own, and I have multiple expressions that all work just fine. It's not a programming puzzle I am here to present. Instead, I'm curious about which version speaks to you, which teaches you, which repulses you.  More than that, I'm interested in WHY.  Here is an if-the-else version: Here is a similar version using a dictionary: And one that uses structural matching: Some people will naturally prefer if/else for the simple reason of familiarity. They see a lot of if/then/else logic, and so there isn't much to learn or think about. They may call it "simpler' but it is not.  The dictionary version has more parts, but they're very simple parts, and al...

CSS Specificity Rundown

 CSS really is fun.  No, seriously. I'm not being sarcastic here.  Even though I've been in software a long, long, long time, I hadn't really studied CSS before last year (shocking, I know) and so I've been behind in my training.  I had an opportunity to dive in more, and all was going well until I started playing with media queries and ran into a specificity problem that wasn't so obvious (to me, though it may have been to you). So, to help people who are treading the same path, here are some aids on specificity: * W3 Schools has a fun "try it and learn" approach to general CSS Specificity * Saucelabs specifically breaks down specificity and media queries * Halodoc provides some best practices  to avoid troubles. * Specificity with Darth Vader and Stormtroopers and stuff at smashing magazine. These should get you past the worst of your troubles nicely. If you do get stuck, then it's always nice to experiment with a local HTML/CSS document or maybe fi...

Code Smells Listicle

 After many times looking up various resources on code smells and code smell taxonomies, I finally decided to make a listicle (list article) of these.  Enjoy: Industrial Logic's Code Smells album is carefully curated and deftly explained. A winner. Industrial Logic also has a cheat sheet for code smells (recommended) The OG Wikipedia's extensive listing A nice taxonomy at Coding Horror A nice writeup at Refactoring Guru The Samman Coaching List has nice descriptions. There is a longish list without explanations at DevIQ, as a jumping off point for many interesting web searches. Arjan Codes (a nice channel, recommended) has a video introduction to Python Code Smells. On the "positive" side of the ledger, we also have virtues: The original Code Virtues article from Pragmatic Programmers, republished at Medium. The explainer article (feel free to start here) at Industrial Logic.

What does Tim have against "private" methods?

 A big thread erupted, all full of misunderstandings and miscommunications, about the idea of "private" methods.  It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with "Absolutely Not! Never! That's wrong! Test via public interfaces." I thought a little longer, and said "I'm not sure" and then later "I'm not sure that 'private' is even needed." This is where the problems started, and maybe here I can clarify what I meant by it all.  People assume (and insist) that I could only possibly mean that they should substitute 'public' for all protected and private members, polluting the interface, and inviting the violation of a class' internal state.  That was never my intention and still isn't. Still, this is what people insist that I must have meant from the start. I suppose this is because that's what they imagined me to mean and it...