Warning: This post is only for developers who are having issues when coding against file descriptors in the form of C-style file handles or sockets on MacOS. For everyone else, this does not apply. Running out of Resources Right now I am developing an application that uses sockets (underneath a stack of other software) for inter-process communication. The problem is that after a few debug runs or crashes (I did say developing), the application will not start again from resource starvation.
Only a few times in a lifetime does an opportunity come along that could change everything. It comes in the form of a challenge that will stretch you and push you to your limits, even though its in a domain you know everything about (or believe you do). It comes as a disruptive force to a stable market. Its both risky and yet eminently doable. And there is tangible demand for this change, a change the incumbents resist (and have good reason to).
Recently, GitHub updated actions from Node 12 to Node 16 (See GitHub Actions: All Actions will begin running on Node16 instead of Node12). As a result, Hugo deploys will fail. All I saw was that I committed the updated site, and the deploy did not happen.
To make it work again, you need to update your
gh-pages.yml in the hidden
.github/workflows folder to reflect the new Ubuntu and
This is my fourth CPU Architecture transition in the Apple ecosystem, from the Motorolas on the II’s and LC, through the PowerPCs in the Titanium Powerbook, Intels on the Aluminum MacBooks to the ARM M1 today.
This transition has been the smoothest by far, so much so, it’s not worth posting about. But that would overlook the incredible amount of work performed by untold thousands of people in building and testing their software to ensure this invisible transition happened.
And it would overlook the significant changes in hardware too, not just the CPU architecture, but also the move to new GPUs, screens, security chips, ports and keyboard.
I have been writing software professionally for 32 years. I must have written several millions of lines of production code in that time.
But I do not own the rights to any of the work product I have made. It all belongs to someone else. That is the way.
The question is how can one go about making great software product, still earn a satisfactory living, and yet retain the rights on that work product and create a revenue steam off it?
Today, I turn 55. I now have over 32 years of work experience. These numbers got me thinking about what I wish I had known when I started my professional careers.
We’ve all heard this before. Maybe it’s time to act on it.
“Go to where the puck is going, not where it has been”. - Walter Gretzky (Wayne Gretzky’s father) Should we be building new product on existing, proven software stacks, or taking the challenge to start using the newer tools? In this post, I take a high-level look at the technology landscape for commercial software development to aid in a thought exercise on how I would want to create new software products.
Discoverability is the user’s ability to find key information, features, services and capabilities in a software application. It enables users to locate, see, learn and understand what capabilities the software provides. If users cannot discover a capability, how will they know it exists in the application in the first place? Designers and developers need to keep this in mind when architecting and structuring applications. They need to not only focus on what is being provided, and how users can use it, but also on how users can find it.
I plan to write more about being a coding CTO, but in the mean time, to set my credentials, I posted an article on Noverse describing, at a high level, what software and systems I have built for Asset Managers. Take a look at What Did I Create as an Asset Manager CTO.
The vast majority of non-code writing performed by software engineers is short form standard format, defined here as:
- Short Form: A small amount of headings and text up to 1000 words
- Standard Format: The same standard structure or pattern of document repeated over and over again
Yet even though its short form and standard format, it takes too much time and effort to produce these, so we developers conveniently “forget” to create these valuable documents (or mess up structure of them).
I have found my way to optimize the creation of these so I can spin them up quickly, deliver the information needed correctly, send them out and get back to coding.