timemachine

If you work for a company that has cybersecurity insurance, they ask, point-blank, if all employee desktops have antivirus before they quote your premium. You just have to use it. It’s not a subject for religious dogma.

This looks interesting. Is it MacOS only? And how does it behave with tools like tmux or ssh?

In the US the America On-Line (AOL) internet service provider mass mailed 3.5 floppy disks to households. This was a boon for all my classmates when I attended a vocational school that required us to submit assignments on disk.

I would remind everyone at family gatherings that I was collecting them if they didn’t need them and quickly had about 15 I could use.

Making some assumptions about what you mean by "business logic application backend." Taking it to mean the business logic layer in an application stack that sits between the presentation layer and the data access layer.

This style of application development benefits from an object-oriented language. Where an object encapsulates the domain logic of business rules. This can be accomplished in Go with structs and funcs.

Classes in Java make good domain models because of (overbearing) enforcement of file structure (object creation validation rules in the constructor, limit access to properties to getter/setter methods that can verify inputs before mutation, yadda yadda). In domain models, neatness and organization counts a lot for the long-term health of the code.

My opinion is that Go is well suited to the task of creating autonomous worker applications that enforce business logic rules for domain objects with well-defined borders. If your domain objects have overlapping concerns or you have actors/business rules that need access to more than one domain object for calculation/mutation you would be wise to think carefully about the application structure before selecting Go as your language.

GNU Debugger allows for prefixing some commands with `r` to run in reverse mode. Examples are [c]ontinue => [rc] and [s]tep => [rs].

I’m not happy that this change has happened; however, since learning about how the BOOTSEL mode works under the hood I’ve been expecting news like this from one of the big two OS vendors.

While a sleek looking use case on the surface, mounting the PI as a fake, non-standards compliant, mass storage device is just a hack.

Nice effort on an interesting topic. However, the book could use a better technical review.

For example the first recipe will not work as expected with out a multi-column unique index (specifically the MySql example).

I feel that the preexisting knowledge required for such examples does not align with the stated target audience for the book.

Memory lane. As a web dev from when this was the fad, many of these buttons are very recognizable

Can you provide a link to the source, please?

An enjoyable waste of 45 minutes. A+

I took the meaning as: Array processing can cause hidden bugs (like GOTO). The bugs are usually introduced when the size of the array changes while processing.

Also ‘find’ing and ‘filter’ing arrays is more error prone (like not properly handling a miss on a find).

I don’t completely agree with the author, but the idea that more care needs taken when dealing with arrays is worth considering.

Arrays will always have important uses. Tuples, enumerations, and the like. However, ‘n’ database records shoved into an array and then iterated over in a for-loop is a cumbersome way to structure a program.

That’s my take on it.

Thanks for sharing. Date math is my kryptonite.

This sounds so much more difficult and costly than have qualified managers.

I’ve been reading Dave Farley’s new book, “Modern Software Engineering” He has a few rants related to GitFlow vs Trunk development. Many of his points agree with OP in that merging is a big pain point in GitFlow.

I’ve both used strategies on many different projects. Regardless of the development strategy I’ve seen nasty merge parties. The way to avoid those merges is to reduce your batch size and keep your un-integrated changes to a narrow scope.

If you need to make changes out side of that scope. Stash your work; create a new branch; make the change; let your teammates know what you did; before going back to your other branch. You can then integrate that fix back to your local copy. But the important thing is that your team mates can also sync that one off change to their local copy too.

The worse thing is when two developers find the same bug and fix it simultaneously in different commits. Trunk-based and GitFlow both have this problem. Stick to the scope of work that was coordinated in your standup meeting for the day and let your coworkers know if you need to go outside of that scope. Be conscientious.

(Complete aside: Try to do trunk based development in a Perforce code base and you will learn a lot about reducing your the batch size of your commits and communicating the scope of code changes. Perforce requires you to be team oriented when developing)