I have to say that one of the great pleasures I have is getting to meetups and talking to other technical folks in person. I do love talking shop and being able to chat with other developers face to face with no particular agenda is really nice.

Welcome to the four new subscribers that have joined us since our September newsletter! I hope you find this newsletter worthwhile reading and, again, to everyone—I would love your feedback!

Other than that I hope this newsletter finds you well. We’ve got a few articles which I hope you’ll find interesting and useful and another puzzle to give your grey matter a bit of a workout!

If this newsletter has been forwarded to you and you like what you see and you’d like to see more please subscribe at https://impractical-engineer.beehiiv.com/subscribe. It’s free and it’s very simple to unsubscribe should you decide it’s not for you. And if you subscribe please drop me a note. I always love to talk to other software developers!

Reviews Dept.

Puzzle Dept.

Consider that if I have two dots on a page I may draw a line to connect them. Like this:

Further consider that if I have three dots on a page, I may have one line, two lines or three lines like this:

What is the minimum number of dots which I need if I wish to draw four lines?

Special shoutout to my brilliant pal Hillel Wayne who, as far as I know, was the first person to solve the puzzle (at least he’s the first one who sent me the correct solution).

The answer is zero. At no point in the puzzle did I say “the lines must pass through dots”. I said “may draw” and “may have”. Hence there’s nothing preventing anyone from simply drawing four lines on the page with no dots whatever. I don’t know if there’s a name for this sort of puzzle but I know I have seen its type before. The implied constraint makes the problem seem trickier than it really is.

It happened a while ago that a census taker was proceeding along a street gathering census information. He finished with number 19 and moved on to the next highest address number on the same side of the street. A lady responded to his knock.

“Good afternoon Ma’am. I’m gathering information for the census. Can you please tell me the occupations of yourself and your spouse?"

She responded: “He is a postman. I am a professor of mathematics.”

“Oh, I have some background in math!” said the census taker. “Do you have children?”

“Yes we do!”

“How many?”

“If you factor our house number, the larger factor is the number of males in our home and the smaller factor is the number of females (including me) in our home!”

“Excellent! Thank you so much for your time ma’am!” He jotted down both the number of males and females in the math professor’s home and, whistling a happy tune, he continued on to the next house.

How many daughters do the professor and her husband have?

One of the most important but seemingly least understood concepts for software engineers is the idea of “state.” Like monads it seems to be one of those concepts that’s actually pretty simple but not well understood. I’m going to see if I can help the readers of this newsletter to understand the idea of state better.

According to Merriam-Webster, state is a noun meaning: “a mode or condition of being”. That word—mode—should set off some alarm bells for people who’ve used modal applications. A modal application (just to ensure we’re all speaking the same language) is an application where actions will be enabled or disabled depending on prior actions. Probably the most famous modal app is the vi editor. In the vi editor one can be in the editing mode—where what you type goes into the editor buffer or one can be in the command mode—what you type is interpreted as a command. The problem is that it’s very easy to get into one mode or the other and not realize it. You can be in a productive flow, typing away at some brilliant algorithm, accidentally hit the key that transitions from edit to command mode, and suddenly you’re getting all sorts of strange behavior. If you’ve never heard it, one of the tastier bon mots I’ve seen is that people trying to figure out how to exit vi accidentally create some terrific passwords.

Mode and state are practically synonymous in this context. State is the set of all variables at a given point in time in an application that either allows for some action to occur or prevents some action from occurring. To, I hope, make the idea of state clearer, let’s consider an example. We’re writing a banking app and one thing we need to support is transactions. One behavior we need is that if there’s a pending transaction we prevent new transactions from being created. Hence if we’re in a “pending transaction” state the “create new transaction” action is not allowed to occur. We would need some way of keeping a flag in memory or some other sort of mechanism to indicate that a transaction is pending. Also a pending transaction state may allow us to either commit the transaction or roll it back. But if we’re not in a pending transaction state then neither committing nor rolling back actions are allowed.

One interesting thing to note; the original implementation of the World Wide Web was “stateless.” That is, you’d send a request to a website and it would return a page to you and no state was created at all. The website had absolutely no way to tell if you’d requested a page 1 time or 1000 times. Adding state to the web required some rather interesting engineering. Initially the state was added on the back end via databases and other mechanisms. CGI (Common Gateway Interface) was one of these backend mechanisms—CGI gave the web page a means to communicate to a database.

Later state was added on the browser side with cookies. You’ll note that both of these mechanisms (databases and/or cookies) are non-volatile. That is they maintain state across the machine being disconnected and reconnected to a website.

Another term that often arises in computer science is a finite state machine. A finite state machine is a model of a process as a set of states which the process can go through. I cannot treat finite state machines with any depth so I’ll end the discussion here.

Want to know more about the idea of state? Drop me a note and let me know!

Humor (We Hope) Dept.

Most of us scoff at the idea that the position of the constellations in the sky on the day we were born determines anything about us. And justifiably so—can you imagine 1/12^th of the population all having the same things happen to them every day? This seems the sort of thing that the more credulous members of our population fall for (and I sure won’t fall for it anymore, I’ll tell you!). That said, we needed something to poke fun at this month and so we proudly(?) present:

Halloween Dept.

Halloween’s not till the end of the month but we felt compelled to supply some scary stuff to keep you up at night till then. Here’s some things that keep us up at night:

Feedback Dept.

If you’d care to share:

or anything else, please contact me, Onorio Catenacci, editor of the Impractical Engineer at my email.

If this newsletter has been forwarded to you and you like what you see and you’d like to see more please subscribe at https://impractical-engineer.beehiiv.com/subscribe. It’s free and it’s very simple to unsubscribe should you decide it’s not for you.

And if you’re a subscriber and you’d like to do a small favor for the editor, please share this with your developer friends!