Browsed by
Category: Problem solutions

Wisdom from Robert Martin of Clean Code

Wisdom from Robert Martin of Clean Code

Some really wise quotes:

No matter how bad your legacy code is, never EVER create a project to ‘clean up the code’. It will never get completed, you’ll inevitably have to stop, and it will end up worse than you started. This has happened every time in my experience.

The only proven way to get out of bad code requires EVERYONE on the team to get on the same page of how code is supposed to be written. Make them take the Clean Code class/read the book and then use the boyscout approach. That approach is every checkin you check in the code a little better than you found it. That’s it. In time, those little refactors move the ship in the right direction, become dominant, and then surround and destroy the bad code.

Code that has not been touched for years likely doesn’t NEED to be touched. Sure, it may be messy, but if it works, there’s no point in spending time on something you aren’t going to improve functionally.

Code reviews are largely useless. People go in, listen for 5 minutes and then at the end everyone leaves saying, “I sure hope he knew how it all worked because I toned out.”

TODO comments are fine, but should be completed before submission and never checked in. After they are checked in, they become TODON’T comments because they never get completed.

If people get into an argument about syntax/details and it lasts more than 5 minutes, then neither person has solid evidence for why it should be their way. Just flip and coin and move on.

Running Windows 1.01 and old versions of DOS

Running Windows 1.01 and old versions of DOS

I learned to program back on an old TRS-80 Model III computer as a kid. Long before Windows and even DOS, most home computers required you type in programs or load them from cassette tapes. If you were really rich, you might afford a floppy drive, but that was an expensive luxury I never had. My next computer was an IBM XT, and it ran the advanced and stalwart DOS 3.30 – which was dramatically better.

Running those old operating systems today requires you either buy one of those old systems and keep it running, or you have to emulate them. You can easily emulate DOS 3.3 and Windows 3.0 and higher on VMWare or Virtualbox, but going earlier than doesn’t seem to be supported anymore.

Enter 86Box – an emulator that lets you emulate REALLY old machines. In fact, I was able to get Dos 3.2 running Windows 1.0.

Here’s what you’ll need:

Part 1 – 86Box Setup

  1. Download 86Box and install it (source is on github).
  2. Download the latest romset and put it in the directory for 86Box called roms\
  3. Download DOS 3.2 image disks here.
  4. Download Windows 1.01 image disks here.
  5. [For later fun: download any of the other amazing images on the parent page]
  6. Start 86Box and set up 86Box by selecting Tools->Settings from the top menu, and set the system up with the following settings.

Part 2: DOS 3.2 and Windows 1.01 install

  1. Start up the 86Box.
  2. Set Media->Floppy 1 to disk01.img, then issue a ‘CTRL-ALT-DEL’ to reset it. The system should start up and boot to the dos 3.20 floppy drive
  1. Run ‘fdisk’ and it should detect your hard drive. You’ll need to create a partition to set up the hard drive.
  1. Reboot and boot from the DOS 3.20 disk again.
  2. Format the hard drive by using ‘format c: /s’
  3. Set Media->Floppy 1 to ‘DISK1-SETUP.IMG’ from the Windows 1.01 (5.25)
  4. [optional] type ‘set prompt=$p$g’ if you want to see your full path in the command prompt
  5. Run ‘setup’ from a: and follow the instructions to install Windows 1.01 on C:. Change the disks when prompted by selecting Media->Floppy 1 and setting it to each of the floppy disks for the Windows setup until it’s completed.
  6. type ‘C:’ to switch to the hard drive
  7. ‘cd \windows’
  8. ‘win’ to start windows
  9. Voila!
Dealing with Time Zones in Code

Dealing with Time Zones in Code

The real answer is to always use seconds since an epoch for logging – like the Unix epoch – with 64 bit integer representation (signed, if you want to allow stamps before the epoch). Any real-world time system has some non-linear, non-monotonic behaviour like leap hours or daylight savings.

Lenovo Yoga 730-13IKB Keyboard Replacement

Lenovo Yoga 730-13IKB Keyboard Replacement

Something I wish I knew before picking the Lenovo 730-13IKB in a super-sale open box deal. The Yoga 730-13IKB has 2 really common, and pretty unforgiveable, problems. One is display flickering issues and keyboards that have keys that are randomly flaky. I got the display fixed while it was under warranty (after trying re-seating of the display cable through the hinge and only getting a little improvement), but it went out of warranty when I started having keyboard issues. I would often have the A,S,D keys stop working, but it wasn’t always consistent and was sometimes different keys. One solution that helped was to pull the bottom off, clean the contacts, and re-seat the keyboard connection. That, however, only worked for a little while until it started again.

Time to replace the keyboard with a new one – fortunately it was only $29 in 2021. As for how to do it, It’s Binh Repaired & Reviewed gives a great disassembly demonstration. The most annoying part is the removal of the black plastic wrap over the keyboard. I actually tore the backlight layer – but since my replacement kit had a new one I just tossed the old one. Once you’ve done that, it seems to go pretty well.

Now it appears to work perfectly, hopefully it will continue to do so.

ASUS Maximus Z690 Hero failures

ASUS Maximus Z690 Hero failures

UPDATE: ASUS has issued a recall. You can check the capacitor, or check the serial and part numbers. See the bottom of this article.

I recently bought an ASUS Maximus Z690 Hero for my new i9-12900K build. In the last few weeks since release, some people are reporting their ASUS Z690 motherboards are burning up and quit working. Fortunately for me, I have been unable to find DDR5 memory, so my board is still sitting in the box – which is fortunate because it appears the board I got his this very issue.

What is the issue? Reporters say the system runs for some time, then there is often an audible pop and the system hangs. People report smelling smoke and even seeing the upper corner of the board glowing. After powering down, there is damage to the upper corner of the board by the digital readout. Powering on the board throws code 53 and never reboots.

As more reports came in, they seemed to focus on these two 4C10B MOSFET components getting fried.

Buildzoid started looking at these reports and noticed something strange. The boards that are blowing up have a capacitor that appears to be backwards. These polymer-aluminum polarized capacitors have defined positive and negative electrodes. According to the specs on these types of capacitors, if you reverse the polarity accidently (i.e. if you put them in backwards) then leakage current will increase and ‘the life span may decrease’. This would explain why they might work for a short time, but then burn out.

Here’s a picture of a burned up board with the backwards capacitor. You can see the polarity stripe on the left. All the boards that appear ok have the positive stripe on the right.

There is no official word from ASUS on this yet, but a big reddit thread has basically concluded that this is the issue and discourage anyone from using these boards immediately. If they happen to blow when you are away, the system does not always power down and could present a real fire hazard as people have reported the components becoming glowing hot by the time they can even shut the system down.

Give buildzoid’s whole video a watch:

also JayTwoCents.

12/29/2021 Update: Here’s the recall information from ASUS

We have recently received incident reports regarding the ROG Maximus Z690 Hero motherboard. In our ongoing investigation, we have preliminarily identified a potential reversed memory capacitor issue in the production process from one of the production lines that may cause debug error code 53, no post, or motherboard components damage. The issue potentially affects units manufactured in 2021 with the part number 90MB18E0-MVAAY0 and serial number starting with MA, MB, or MC.

Lenovo Yoga 730 13IKB keys not working well

Lenovo Yoga 730 13IKB keys not working well

This seems to be a common problem. On my keyboard, I’d have ASD intermittently drop out or take a couple hits to register.

I used this technique to re-seat the cable and help it lay a bit better under the battery – but I also used 99% isopropanol alcohol to clean the contacts. I actually got quite a bit of gunk off the contacts. I re-connected things but was still having trouble with f and g keys. I tried once more, and it seems to have perhaps solved it.

Time will tell, but maybe give it a try if you are having trouble.

Denuvo DRM and Intel hybrid core architectures

Denuvo DRM and Intel hybrid core architectures

12th Generation processors are built on a new hybrid core architecture of big and small cores working together. However, it turns out that some DRM software has issues with this hybrid

“Certain third-party gaming Digital Rights Management (DRM) software may incorrectly recognize 12th Generation Intel® Core™ Processors efficient-cores (E-cores) as another system. This prevents games implementing that DRM software from running successfully. Games may crash during launch or gameplay, or unexpectedly shut down.”

However, there is already a workaround for this issue with Denuvo DRM. Give it a try if you find you have one of the affected games:

  • Power-up system and enter system BIOS setup.
  • Enable switch Legacy Game Compatibility Mode to ON (one-time only) in BIOS.
  • Save BIOS setup changes and exit.
  • Boot to OS.
  • Toggle Keyboard Scroll Lock key ON.
  • Launch affected game title.
  • Toggle Keyboard Scroll Lock key OFF after ending game title.
Out of Source Builds

Out of Source Builds

Build systems are certainly not the sexy parts of software development. However, no part of the development process impacts your team so much as it’s build system. Build systems that perform poorly, regularly break, or generate inconsistent or confusing output files are one of the fastest ways to introduce bugs, slow releases, and bring a whole team to a screeching halt. That’s why automated reproducible builds are a keystone of agile development.

Out-of-source builds are one way to improve your build system. Out-of-source building is a practice that keeps the generated/compiled intermediate and binary files out of the source file directories. Traditionally, most build systems would generate object, binary, and intermediate files mixed right next to their source files. This leads to a confusing hierarchy of files that made getting a consistent picture of your build and source nearly impossible on big projects.

It turns out CMake can help you create our of source builds with just a few little tricks. Unfortunately, there were few examples and many of them were overly complex. So, to help get folks started, I wrote up a very simple sample. It’s the perfect starting point for your next project. It works with both Linux and Visual Studio builds.

https://github.com/mattfife/BasicOutOfSourceCMake

Optimal Battleship

Optimal Battleship

Nick Berry, president of DataGenetics, meticulously analyzes different strategies to play the classic board game Battleship (he also has done Chutes & LaddersCandyland and Risk)

It’s a great example of how computer scientists often work. He explores a host of techniques and analyzes the results by calculating how often you’ll get a perfect game, median number of guesses, and how bad it gets in the worst case.

He examines 4 major strategies:

  1. Pure random searching
  2. Hunt and Target – Hunt randomly until you get a hit, then proceed methodically to sink the hit ship.
  3. Hunt and Target with parity – since the minimum length of a ship is 2 units, you need only search even or odd squares
  4. Hunt and Target with parity combined with a probability density function.

His fourth approach is the most fascinating. The system calculates every possible configuration of the remaining ships, and then sums up the probability of a ship on each square. At the beginning, all the squares are basically equally probable, but as more and more guesses are made, the number of possible configurations decreases. If you continually calculate the sum of these possibilities, pick the square with the highest probability and repeat this process, you get significantly better results.

How much better? Purely random guessing gives you a median of 97 moves. Using parity with the hunt+target method averages 64 moves. But using the probability density function increases that to a staggering 42 moves on average.

Turns out, I discussed the use of this kind of probability density function by speedrunners who used the same technique to beat the splosh-kaboom minigame in the Legend of Zelda Wind Waker.