Here’s how it works:

1. Virtualization: Docker virtualizes the operating system of the computer where it’s installed. Imagine it as a lightweight, portable container that holds everything your application needs to run.
2. Containers: These containers package up your application along with all its dependencies (like libraries, configurations, and other software components). Each container is isolated from the others, ensuring that different applications can coexist without conflicts.
   • Usually those containers also run the smallest possible version of the software, you can theoretically install an operating system like Ubuntu 20 with all its bells and whistles in a container, but what is typically done by professionals is that they build a stripped down version of the operating system that can do one job only.¹
3. Benefits:
   • Consistency: Docker ensures that your application runs consistently across different environments (development, testing, production).
   • Efficiency: It optimizes resource usage by sharing the host OS kernel across containers.
   • Portability: You can move containers between different systems without worrying about compatibility issues.
   • Scalability: Easily scale your application by creating more containers.
4. Use Cases:
   • Development: Developers use Docker to create consistent development environments.
   • Deployment: Docker simplifies deploying applications to servers, cloud platforms, or even edge devices.
     • When time comes to deploy my app to production, I don’t need to set up separate servers and what not. I just save my containers into image files then just go to Amazon and deploy with docker to the server instances I choose. I don’t care what operating system Amazon is running on those servers, because docker will build me containers that are identical to those I saved on my own computer and run them.¹
   • Microservices: It’s ideal for building and managing microservices architectures.

In summary, Docker makes application deployment and management easier by encapsulating everything needed for an app to run within a container. It’s like a magic box that holds your app and its dependencies, making it portable and efficient!

For me… I’m considering user Docker in conjunction with Playwright to setup automated testing. Then I can deploy the parts into Azure or whatever makes sense for the client.

References:

1. Reddit Article from SnitchesStitcher ︎
2. FreeCodeCample article – Docker Simplified ︎

2) Hold the two buttons (front and back) and plug it in.

3) Wait about 7-10 seconds, and the front ring will start rapidly flashing.

4) Let go and VOILA!

Simple process… worked very quickly and now I can properly mute and unmute my Yeti.

With all of the hoops I seem to need to jump through to do the things I want to do with this data, I may qualify for Cirque du Soleil.

Between us, I think we tend to get all the best oddities down pat.

I’ve been using WinMerge for more years than I can count.

You can setup WinMerge as the Diff tool really easily in Sourcetree. Just pick it in the settings. :)

But, if you want to use WinMerge as your Merge tool, you need to set Custom settings.

External Diff Tool: WinMerge
Diff Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe
Arguments: \”$LOCAL\” \”$REMOTE\”

Merge Tool: Custom
Merge Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe
Arguments: -wl -wm -dl PreviousVersion -dm Base -dr Local $LOCAL $BASE $REMOTE -o $MERGED

Thursdays are good gambling days.  Kenny Rogers used to sing his song on Thursdays whenever he could.

Grrr.  Works in Dev, not in Prod.

My ability to unknowingly transition something back and forth between functional and not functional is mind-boggling.

I come from a background of using source code control and versioning. I originally started with Visual SourceSafe long ago. I’ve since used other tools, but predominantly using the “library method” and Microsoft tools (Team Foundation Server or TFS).

My current role… has me using git (well, bitbucket to be specific). My last role had me using that as well… but they had a different workflow then I do now.

So, I’m trying to wrap my head around the new terminology.

I’m going to document some of the “new terms” and map them to what I understand them to mean. I’ll include some links to where I did some of my research to come up with this “map”.

• Remote – The source code living out on the server.
• Local – your copy of the source code on your local working space.
• Fetch – Get the latest version of the code from the remote.
• Checkout – Make the branch the “Active” one. This means all future commits happen to this branch.
  • If you have the project open in Visual Studio when you checkout a branch, VS will usually prompt you to reload the project.

I’ll post/update more as I find new stuff.

So, we scheduled a day to go. And drove and drove.

Now, my wife was the one who wanted to go. I went along because… she’s my wife, and she asked me to go. I figured I’d just wander around the store, nod my head if asked if I liked something… and maybe hit the LEGO store on the way home. :)

Instead, I had a fun time. The store we visited has multiple levels. One floor is the “show room” and the other is the actual “shopping area”.

While shopping, my wife grabbed a shopping cart (or shopping buggy or trolley – depends on where you are from).

She commented “these drive weird” and then promptly said “here, you push the cart” and resume shopping.

I quickly realised something. The IKEA shopping carts have castors on all four wheels. Most buggies are castors in the front, and fixed wheels in the back.

While this initially was a bit weird to push, I quickly realised how versatile this is. You can push the cart from the side, the front, the back, at an angle, strafing… doesn’t matter.

As you can see here… I had a bit of fun. You can push the cart forward, do a 360 spin… and still keep walking in a straight line!

What really struck me as interesting… is these wheels. They are a bit odd shaped. And had these funny things on the sides of them. At first, I assumed the wheel shape was something to do with how smooth it rode (and it probably does). But I later found out what I believe is the why.

See, as you leave IKEA, you are on the 2nd floor. So you need to go down a level to get to the parking garage. You could take the elevator (and you have to if you have one of the big flat-carts used for furniture). But for shopping carts, they have a type of escalator, or moving ramp.

And those skinny disc wheels? They fit right down into the grooves on the ramp… and the funny things on the side of the wheels? They keep your cart wheels from sinking too far down. But, it causes the cart to be 100% trapped on the moving ramp. You can’t push it… so it’s a super-safe way to move your cart down a level… and then the escalator reaches the end, the cart moves up back onto the floor, and you continue on your way.

So… big Kudo’s to IKEA for some really cool “UI” for their shopping carts.

Here is a short video on the “strafing IKEA carts” I found on YouTube.

Oh, and yes I did get to go to the LEGO store. :)