Full-range monitor speakers

Klipsch RP-160M monitor speakers with Scandinavian-produced stands 👍 (NorStone).

I have never experienced monitors that kick you in the nuts with the woofers, but these definitely do! Both on hard drop-kicks and low frequency emissions (LFO).

Not to mention the middle-notes, which sound fantastic on these speakers. Having Klipsch' patented LTS (Low Travel Suspension) horns also helps to better define high-notes.

Although they are only 100W / 8Ω, they pack some seriously loud volumes, even without distortion!

Thumbs up! 👍👍👍

Panorama(-ish) picture of my rig(s):

Happy 27th! :D

Linux celebrates another birthday today—27 years!

https://opensource.com/article/18/8/happy-birthday-linux

https://www.omgubuntu.co.uk/2018/08/happy-birthday-linux-27

Ubiquiti UniFi

Recently acquired a Ubiquiti UniFi AP-AC-PRO (1750 Mbps) wireless access-point, by recommendation from a professional friend. Telling me these things have ALL the pro-features of the more expensive APs around. And I have to admit, they... just work 👌 and very, very good I might add.

Even Linus Torvalds (yes, THAT Torvalds) uses these, because they are incredibly configurable for both simple and (very) advanced setups, and rock-solid in operation.

PoE+ (48V/24W) required though, as the USB-interface is misleading, it does not power the unit at all. Ubiquiti does not include a PoE+-injector with their APs, and does not specify this on the packaging either. But that was the only annoyance about them.

For the unit-price, you get a lot of features and functions compared to other "prosumer" choices.

And best of all: it runs Linux. Yes, this prosumer wifi-ap runs open-source software.

P.S. - 17th of August:

Acquired another AP for better coverage, as there are some rooms in the basement with sound isolation in the roofs. The signals got better, and reached through the intended rooms.

Also enabled mesh-networking (even though it was a beta-feature), and it got even better!

Ubiquiti FTW!

ZipStick®

1987 ZipStick® joystick. This yellow buttoned joystick uses micro-switches and has a triple fire action, and is THE best joystick I have ever used / abused. It can withstand practically ANYTHING!

Got hold of a near-mint copy (a few scratches on the housing and dirt beneath the screws), which tested OK and working on an Amiga A600 + Amiga A1200. SCORE!

Amiga-gaming will be a pleasure with this accessory! ;) :D

Switch

I was reading this article a couple of weeks ago, and sure was tempted in getting one...

Yes, I am a weak individual to g33k-marketing, I know this... 😅

So... I ended up shelling out the wet stinky, and it is on its way in the post 😋

Ubuntu on Nintendo Switch

Yes. Indeed. It will be used to do what its supposed main function is... But, I will also tinker and experiment with this gadget to my hearts content 😅 😎



Update Monday, May 28th:

Oh HELLZ YEAH!

Nintendo Switch Red/Blue JoyCons

Nintendo Switch + 8Bitdo NES30 Pro Bluetooth gamepad

Continuous Integration and Deployment

Continuous Integration is the practice of constantly merging development work with a Master/Trunk/Mainline branch so that you can test changes and test that those changes work with other changes. The idea here is to test your code as often as possible so you can catch issues early on. In the continuous integration process, most of the work is done by an automated tests technique which requires a unit test framework. It is best practice to have a build server designed specifically for performing these tests so your development team can continue merging requests even while tests are being performed...

Yes, automation here is key.

...Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship - this could be UAT (User Acceptance Testing), staging or production. The idea behind continuous delivery is that you’re constantly delivering code to a user base, whether it be QA or directly to customers for continual review and inspection. Although similar to continuous integration, continuous delivery differs because it can feed business logic tests where unit tests are unable to catch all business logic, particularly design issues.

...Continuous Deployment is the deployment or release of code to production as soon as it’s ready. There is no large batching in staging nor a long UAT (User Acceptance Testing) process before production. Any testing is done prior to merging to the Mainline branch and is performed on production-like environments. The production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button).

And after all that, log-auditing after deployment; checking key metrics if they are influenced negatively or positively by change(s).

In the ideal workflow, the entire process could be automated from start to finish:

• Step 1: Developer checks in code to development branch.
  
• Step 2: Continuous integration server picks up the change, merges it with Master/Trunk/Mainline, performs unit tests and votes on the merge to staging environment based on test results.
  
• Step 3. If Step 2 is successful, developer deploys it to the staging environment and QA tests the environment.
  
• Step 4. If Step 3 passed, you vote to move to production and the continuous integration server picks this up again and determines if it’s ok to merge into production.
  
• Step 5. If Step 4 is successful, it will deploy to production environment. 

This process varies slightly based on needs, requirements and approaches.