Wolters Kluwer

Wasted a few days chasing ghosts During my development workflow, I spend time running our server process after making code changes. Often, a problem will happen with some JavaScript caching or umask-induced permissions problem . The result is that you're making code changes and not seeing any change. But caching and permissions problems are not the only way this can happen. It can also happen by having to restart the server process when the control script does not properly handle things, resulting in multiple server processes. Then the code you just wrote does not appear to work because you are not talking to the server process you think you're talking to. This can happen because: Multiple server processes can share the same port Handling of starting, stopping, and cleaning up is not done correctly Process is more complex due to the insistance of using "shared user  accounts" Two separate things were happening. First, multiple processes per “one server” is expected he...

Umasking Security Theater Wasted several hours debugging a questionable environment setting TL;DR I recently spent several hours debugging an issue that was ultimately caused by an unnecessarily restrictive system umask setting. The current umask of 0027 causes newly created or rewritten files to lose world-read permissions, which can result in difficult-to-diagnose failures such as JavaScript files returning HTTP 403 errors. In a development environment, the operational overhead and lost productivity caused by this setting appear to outweigh its benefits. I recommend changing the default umask from 0027 to 0022 . Details While investigating intermittent JavaScript loading failures, I discovered that some files were being created with the following permissions: $ ll /path/to/file.js -rw-r----- 1 user group 960591 Apr 10 18:42 /path/to/file.js Because the file lacks the o+r permission, the web server is unable to read it, resulting in a 403 Forbidden response when the browser attemp...

  The 10-Hour Display Nightmare: How Corporate VPNs and Software Locks Can Ruin a Local Workspace As a professional engineer, you expect to have control over your environment. You expect that when you plug in a high-resolution display, you can use those pixels to write code. But when you mix corporate IT lockdown policies, aggressive VPN client routing, and the user-hostile design of modern remote desktop tools, you get a perfect storm of technical absurdity. Here is the anatomy of a maddening, multi-day battle just to control a screen resolution. The Objective: A Usable 4K Canvas The goal was simple: connect from a local Linux workstation ("Earth") to a corporate Windows laptop using a remote desktop client, and scale the display environment to a comfortable, readable 4K resolution. Instead, the system hard-capped the resolution at 1920x1080 , cramming a modern development environment into a tiny, unreadable box. The Enemy: The Headless Display Driver and the Closed Lid The ...