2026-07-24

2026-07-24 Friday - Book Review: Software Security for Developers

Last Updated (see Addendums): 2026-08-07 Fri

[My LinkedIn companion post]

[image source: Amazon]



Book: Software Security for Developers: With Examples in Java and Spring

Publisher: Manning 

Publication Date: June 9, 2026

Authors: 

Adib Saikali
Distinguished Software Engineer @ Tanzu
Toronto, Ontario, Canada
https://www.linkedin.com/in/adibsaikali/

Laurentiu Spilca 
Principal Development Consultant, Endava
Bucharest, Romania
https://www.linkedin.com/in/laurspilca/?locale=en 

 

Review Rating:  4-Stars

Review Title: A good book for an introduction to Software Security - for both Developers and Managers 

[Link to my Amazon Review]

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

I enjoyed reading this book. It is well-written, and provides a broad survey of important software security concepts and techniques – with easy to understand illustrations, descriptions, and code examples. 

The companion GitHub repository provides 27 subfolders with Java & Spring examples.


Chapters 2-17 include a number of exercises (182), and at the end of the chapter there is a consistent approach in providing Exercise answers – as well as a Summary. The summary bullets are meaningful, and well written. 

If the reader leverages the contents of each chapter, including the exercises, and the code examples – then this book will provide the diligent reader with a very HANDS-ON learning experience.


Some minor nits:

The naming convention of the folders in the companion GitHub repository for the book would have been better named using a consistent 2-character identifier for the chapter, and a 2-character identifier for the exercise - so that a natural sort order would be enforced.

"Single-sign on" is improperly written, it should be "Single sign-on"
page-v
page-211 
page-335


While the writing is crisp & concise, and the coverage of the subject matter is *mostly* sufficient for a book of this length – there are three notable deficiencies:

1. The book suffers from a paucity of coverage for the very important topic of Post Quantum Cryptography (PQC).

Although the book was published in June 2026, there are only two pages (53, 75) that vaguely refer to NIST cryptographic algorithms standards – and neither of those mention the NIST work on Post Quantum Cryptography (PQC). Nor are there any "additional reading" suggestions. 

Further, on Page-94, this statement is made:
"Cryptographers are building encryption algorithms that can resist quantum computers, but none has been standardized so far."
- This is incorrect. 


On August 13, 2024, NIST released final versions of the first three Post Quantum Crypto Standards: FIPS 203, FIPS 204, and FIPS 205. [see NIST press release]

✅ Federal Information Processing Standard (FIPS) 203, intended as the primary standard for general encryption. Among its advantages are comparatively small encryption keys that two parties can exchange easily, as well as its speed of operation. The standard is based on the CRYSTALS-Kyber algorithm, which has been renamed ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism. 

✅ FIPS 204, intended as the primary standard for protecting digital signatures. The standard uses the CRYSTALS-Dilithium algorithm, which has been renamed ML-DSA, short for Module-Lattice-Based Digital Signature Algorithm. 

✅ FIPS 205, also designed for digital signatures. The standard employs the SPHINCS+ algorithm, which has been renamed SLH-DSA, short for Stateless Hash-Based Digital Signature Algorithm. The standard is based on a different math approach than ML-DSA, and it is intended as a backup method in case ML-DSA proves vulnerable. 

On March 11, 2025 NIST released Hamming Quasi-Cyclic (HQC) as the fifth algorithm for post-quantum asymmetric encryption as used for key encapsulation / exchange.The new algorithm is as a backup for ML-KEM, the main algorithm for general encryption.

Additionally, there are international alternatives to the NIST standard, that could have been briefly cited, and links provided. For example, see this Akamai article, 'A Guide to International Post-Quantum Cryptography Standards', published on Oct 08, 2025.


2. The book suffers from an absence of "further reading" suggestions for the important topic of Zero Trust. 


3. The book does not mention Homomorphic Encryption. 
 

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Addendums: 

Note: 2026-07-26 Sunday: I will probably add another 10-20, or 30 links here, before I am finished. 

These are just some of the suggested additional reading resources such a book could have included:
(illustrative, not exhaustive)

Status: Work-In-Progress 

Suggested sites for further reading:  

 
Java Security: 
 
Spring Security:  

 

 Interesting Security-related web sites: 

 

 

 


Interesting Security-related GitHub Resources:  

 

Homomorphic Encryption (HE) / Fully Homomorphic Encryption (FHE): 
  • Suggested Background Reading: 
    • https://en.wikipedia.org/wiki/Homomorphic_encryption 
      • "Homomorphic encryption is a form of encryption that allows computations to be performed on encrypted data without first having to decrypt it. The resulting computations are left in an encrypted form which, when decrypted, result in an output that is identical to that of the operations performed on the unencrypted data. Homomorphic encryption can be used for privacy-preserving outsourced storage and computation. This allows data to be encrypted and outsourced to commercial cloud environments for processing, all while encrypted."
      • Note table: "Implementations" 
    • https://en.wikipedia.org/wiki/Paillier_cryptosystem 
      • "The Paillier cryptosystem, invented by and named after Pascal Paillier in 1999, is a probabilistic asymmetric algorithm for public key cryptography. The problem of computing n-th residue classes is believed to be computationally difficult. The decisional composite residuosity assumption is the intractability hypothesis upon which this cryptosystem is based."

 

 

 

  • Papers:
    • OpenFHE: Open-Source Fully Homomorphic Encryption Library
      • https://eprint.iacr.org/2022/915 
        • "Fully Homomorphic Encryption (FHE) is a powerful cryptographic primitive that enables performing computations over encrypted data without having access to the secret key. We introduce OpenFHE, a new open-source FHE software library that incorporates selected design ideas from prior FHE projects, such as PALISADE, HElib, and HEAAN, and includes several new design concepts and ideas. The main new design features can be summarized as follows: (1) we assume from the very beginning that all implemented FHE schemes will support bootstrapping and scheme switching; (2) OpenFHE supports multiple hardware acceleration backends using a standard Hardware Abstraction Layer (HAL); (3) OpenFHE includes both user-friendly modes, where all maintenance operations, such as modulus switching, key switching, and bootstrapping, are automatically invoked by the library, and compiler-friendly modes, where an external compiler makes these decisions. This paper focuses on high-level description of OpenFHE design, and the reader is pointed to external OpenFHE references for a more detailed/technical description of the software library."
      • [Also see 'openfhe-development' GitHub Repo citation below, under 'GitHub Resources']

 

 

    • SoK: New Insights into Fully Homomorphic Encryption Libraries
      via Standardized Benchmarks (2022)
      • https://eprint.iacr.org/2022/425.pdf 
      • "Fully homomorphic encryption (FHE) enables arbitrary computation on encrypted data, allowing users to upload ciphertexts to cloud servers for computation while mitigating privacy risks. Many cryptographic schemes fall under the umbrella of FHE, and each scheme has several open-source implementations with its own strengths and weaknesses. Nevertheless, developers have no straightforward way to choose which FHE scheme and implementation is best suited for their application needs, especially considering that each scheme offers different security, performance, and usability guarantees. To allow programmers to effectively utilize the power of FHE, we employ a series of benchmarks called the Terminator 2 Benchmark Suite and present new insights gained from running these algorithms with a variety of FHE back-ends. Contrary to generic benchmarks that do not take into consideration the inherent challenges of encrypted computation, our methodology is tailored to the secure computational primitives of each target FHE implementation. To ensure fair comparisons, we developed a versatile compiler (called T2 ) that converts arbitrary benchmarks written in a domain-specific language into
        identical encrypted programs running on different popular FHE libraries as a backend. Our analysis exposes for the first time the advantages and disadvantages of each FHE library as well as the types of applications most suited for each computational domain (i.e., binary, integer, and floating-point).        "
      • "This work was partially supported by the University of Delaware Research Foundation Grant 21A01012 and
        the Electrical and Computer Engineering department at the University of Delaware.        "

 

 

  • GitHub Resources:
    • GitHub Repo: Awesome - A curated list of amazing Homomorphic Encryption libraries, software and resources

 

    • GitHub Repo: mpc4j
      • https://github.com/alibaba-edu/mpc4j 
      • "Multi-Party Computation for Java (mpc4j) is an efficient and easy-to-use Secure Multi-Party Computation (MPC), Homomorphic Encryption (HE), and Differential Privacy (DP) library mainly written in Java."
      • Language: Java
      • License: Apache 2.0
      • Status: Appears to be active (recent updates in 2026) 

 

 

    • GitHub Repo: Ciphercraft
      • https://github.com/ADWISE-VCU/Ciphercraft 
      • "Contains Packages for ElGamal, Paillier, Goldweiser-Micali and DGK Homomorphic Encryption System. Also implements secure multiplication, division and comparison." 
      • Language: Java 
      • License: MIT 
      • Status: (last updated ~2025) 

 

    • GitHub Repo: fhe-core
      • https://github.com/kryptnostic/fhe-core 
      • Language: Java, Wolfram Language 
      • License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International Public 
      • Status: DEPRECATED (see krypto)

 

 

  • Spring Security support for Homomorphic Encryption (HE): 

 

 Suggested links for relevant IETF RFCs:

 

 

 

 

 

 

 

 

Suggested software development (security-related) books for further reading:   

(Note: I will be citing books published by Manning, O'Reilly, and Packt - as well as some others)

 

 

 Post-Quantum Cryptography (PQC) links for further reading: 

  

  • Regulatory Forces:

 

  
  • Spring Security support for Post Quantum Cryptography (PQC):  
  • Enhancement: NimbusJwtEncoder does not support Edwards Curve signature (EdDSA) family algorithms. #17098


National Institute of Standards and Technology (NIST) Cryptographic links for further reading:  

  • Use of Cryptographic Modules by Federal Agencies and Departments
    • https://csrc.nist.gov/projects/cryptographic-module-validation-program
      • "FIPS 140-2 and FIPS 140-3 requirements are applicable to all U.S. Federal agencies. Agencies must use cryptographic-based security systems to provide adequate information security for all operations and assets as defined in 15 U.S.C. § 278g-3."
      • "Non-validated cryptography is viewed as providing no protection to the information or data—in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated. Should the cryptographic module be revoked, use of that module is no longer permitted."

 

Posted by No comments:
Labels: , , ,

2026-07-13

2026-07-13 Monday - On The Importance of a Backlog of Ideas

[image credit: izhar-ahamed on pixabay dot com]


Allen Hollub's LinkedIn post:

"""
...
Frankly, I'd dump the backlog entirely. It is not helping you. Instead, do the most valuable, smallest thing. Get feedback. Decide what to do next based on that feedback. ...
...
""" 
My commentary:
  1. Doing the "smallest thing" – may not necessarily be the smartest thing. 
  2. To eliminate unknowns, risks – or to determine whether something will meet a particular Non-Functional Requirement (NFR) – the smallest thing may not be the correct choice. 
    • This is especially true when a critical cusp is reached. 
    • "He grokked that this was one of the critical cusps in the growth of a being wherein contemplation must bring forth right action in order to permit further growth." [source]
    • Often, when establishing an architecture runway, experiments are required – especially with new technologies. 
    • See "Knowledge Acquisition" (re: "... you gather information to accomplish future tasks. When you identify a feature that needs further research, you create a knowledge-acquisition task, such as a prototype, experiment, or proof-of-concept, to gather the information you need.")
  


Michael Switzer's LinnkedIn comment:

"""
Backlogs are a waste … so are most roadmaps

Are you working on the most important thing? That’s the only thing that matters … ideas are cheap, it’s easy to find things to work on .. stop creating noise with backlogs and roadmaps

If it’s actually important it will come back up…
""" 
 
 
 
My LinkedIn comment:
"""
Consider, as a counterargument...

As a writer, I know that good ideas can be fleeting – and are precious – and must be captured.

Many well-known successful writers have mentioned that it is critical to capture those flashes of inspiration of an idea - and why many keep a notepad by their bedside, and carry one with them, everywhere they go.

Thus they recognize the importance of having a backlog of writing ideas.

I keep a separate professional journal for every client engagement - and also have a small spiral-bound notebook that I carry with me everywhere, and keep by my bedside. 
""" 
[image source: Staples.com, Staples Record Book, 300 pages]

 
Great writers understand that inspiration is fleeting and that the mind is a terrible filing cabinet. 
 
The consensus among authors is clear: if you do not write down an idea the moment it strikes, it is gone forever.
 
Some Attributed Habits and Quotes from Writers
 
"Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen." 
— John Steinbeck

 

"Always carry a notebook. And I mean always. The short-term memory only retains information for three minutes; unless it is written down, you have lost it forever." 
— Will Self

 

"...combining new ideas with your previous ones will produce something completely different." 
— Steven Johnson


"Guillermo del Toro is famous for compiling books full of notes and drawings about his ideas before turning them into films, something he regards as essential to the process. ..."
– Trivia for “El Laberinto del Fauno” (2006) on imdb.com

 

“Sometimes I have a good idea, something I wish I could remember, and instead of writing it down, commit it to my memory only to disappear when I needed it. Write your ideas as they come, if you wait it will be too long and you may not recover it. It may get destroyed as it is to seed to and fro in the ever rushing river of our thoughts”
― Bangambiki Habyarimana, Pearls Of Eternity 

 

“Write down the thoughts of the moment. Those that come unsought for are commonly the most valuable.” 
– Francis Bacon 

 

“Keep a notebook. Travel with it, eat with it, sleep with it. Slap into it every stray thought that flutters up into your brain. Cheap paper is less perishable than gray matter, and lead pencil markings endure longer than memory.”  
– Jack London

 

“Well you know, for my experience, your head's for having ideas, not for holding them.”
– David Allen


“Get your ideas on paper and study them. Do not let them go to waste!”
– Les Brown

 

“Remember, my friend, that knowledge is stronger than memory, and we should not trust the weaker.”
– Bram Stoker

 “I take notes like some people take drugs. There is an eight-foot stretch of shelves in my house containing nothing but full notebooks. Some would call this hypergraphia (Dostoevsky was a member of this club), but I trust the weakest pen more than the strongest memory, and note taking is—in my experience—one of the most important skills for converting excessive information into precise action and follow-up.” 
– Tim Ferris

 

More quotes:

 

Considering some variations in Product Backlog Definitions:  

André Bernardo offered this definition of a Product Backlog: 

"A product backlog is a problem space for solving user friction, bugs, and technical tasks" 

 

However, many organizations use very different definitions of a Product Backlog [wikipedia.org]: 

  • "... is a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome." [source]

  

  • "... contains a prioritized list of work items, including user stories, features, bug fixes, technical tasks, and research activities needed to improve the product." [source] 

 

  • "...  is a comprehensive, evolving list of all desired work on the product, while the sprint backlog is a subset of items selected for completion during a specific sprint." [source]

 

  • "... represents the long-term, prioritized list of desired work, including features, enhancements, bugs, and technical debt." [source]

 

  • "... is an emergent, ordered list of what is needed to improve the product." [source] 

 

  • "...  a prioritized features list, containing short descriptions of all functionality desired in the product." [source]

 

  • "... Option Pool: Lean" [source]
    • "... work with stakeholders to select the highest value work when they have the capacity to perform the corresponding work. In effect prioritization is done on a just in time (JIT) with the team’s stakeholders." 


Although there may be strongly held opinions about different definitions, adopted by different people, I think we likely agree on some very common ground, more than they may think ("focus on the next most valuable thing" ) - which does not conflict with allowing the Product Backlog to include possible future ideas for improvement, or future features - which may fall out over time, if they are not prioritized for inclusion in future sprints.  

There is nothing inherently static about a Product Backlog, based on any of these definitions. It is important that it be maintained on a continuous basis. If someone projects an idea onto the concept of a Product Backlog as a static list - that is an aberration, and likely a projection of a very skewed understanding of how it has historically been defined.   

 

 

Posted by No comments:
Labels: , , , , , , , ,

2026-06-09

2026-06-09 Tuesday - Some Considerations When Evaluating The Benefits/Risks of Establishing a New Client Relationship

 Years in Professional Services Consulting: 30+

Geographic Scope: Global

[image source: geralt on pixabay dot com]
 

Some Considerations When Evaluating Potential New Client Relationships: 

This post summarizes some thoughts I wanted to share, in response to this LinkedIn post (asking for input), by Jurgen Appelo


When I evaluate the benefits/risks of establishing a new client relationship, here are just some of the factors I consider:

⏹️ Duration of the specific engagement's SOW under discussion.

⏹️ Potential duration of the longer-term relationship, and follow-on SOWs.

⏹️ Fee size, payment structure, and invoicing/payment terms.

⏹️ Financial viability of the client, and risks of their default.

⏹️ Any external information / evidence of toxicity levels within their culture.

⏹️ Degree of bureaucracy burdens (e.g., their strategic sourcing / vendor management processes, contract negotiations, reporting, billing, legal, compliance, security, insurance, etc.).

⏹️ Long-term value of the client relationship [2], itself.

⏹️ Long-term value of the relationships [2] established, during the engagement.

⏹️ Potential future value of client recommendations, and potential business referrals.

⏹️ Reputation of the client, and any risks associated therein.

⏹️ Client's adherence to ethical business practices, or lack thereof.

⏹️ Client's legal exposure risks (previous history, current, pending).

⏹️ Client's regulatory compliance risks (previous history, current, pending).

⏹️ Potential blast-radius if things go sideways (re: events outside of my control).

⏹️ Contractual terms that impose egregious burdens, and that may potentially exceed the total value of the engagement compensation.

⏹️ Intangible value components (e.g., potential for learning & personal growth: acquisition of new skills, working with new technologies, new concepts, best practices, new/increased industry domain knowledge, etc.).

⏹️ Potential for negotiating retention of some/all of the intellectual property I will create during the engagement.

⏹️ Contractual clauses that make broad claims on intellectual property I possessed before the engagement, or created outside of the scope of contract - during the engagement, or created after the engagement ends). 

⏹️ Travel requirements (difficulty, frequency, costs, and reimbursement considerations).

⏹️ Personal safety considerations (physical location of their offices; risks of pandemic outbreaks; high crime rates in the area; travel to areas that are high risks, active war zones, or high potential for terrorist attacks; degree of difficulty to effect escape/evasion if there is a risk of a coup d'état, major social unrest disruptions, or regime collapse). [1] 👈

⏹️ The "Fun Quotient" of working with the team within the organization. 

⏹️ {Novelty | Difficulty | Challenge} factor (harder problems = higher score = more attractive)

⏹️ Bragging Rights - for a successful completion of the engagement.

 

Reflections After 30+ Years in Professional Services Consulting: 

(these are drawn from over the decades of my career, in different roles, in different organizations, and  performed within the scope of my own consulting practices) 

Largest Successful Proposal Pitched: $80M+ (for a global satellite communications company in London) 

Shortest successful (one & done) "Close The Deal" client meeting: 7 minutes (last question: "When can you start?")

 
Typical Outcomes for my client engagements: Increased revenue, efficiency, profitability, innovation, competitive advantage; new products & services; accelerated delivery of new business capabilities; elevated capabilities of staff; improved processes; reduced technical debt. Usually, I am engaged with $10B-$20B+ ARR companies, but I have also been engaged with $2B+, $50B+, $100B+, and $250B+ companies.

Worst Consequence for a client that ignored my warnings: 75% of Market Cap (~$900M) vaporized. 

 

Longest (and Most Distant) International Assignment Location: Sydney, Australia (~1 year; 3 weeks on site, 1 week home; repeat)

Shortest (and Most Distant) International Assignment Location: Hong Kong (2 weeks)

 

Shortest contract document:  1-page. (great client)

Longest contract negotiation: multiple months (absolute worst client, ever)

 

Best contract outcome:  One meeting (1-hour); Immediate "GO" decision; Initial 3-month SOW, extended (continuously), over 4 years. 

 

Favorite International Assignment: Sydney Australia 

Most Unexpected Delight: Istanbul, Turkey

 

Worst Food Poisoning Experience: Istanbul, Turkey (during a cholera outbreak) 

Best Meal, In All My Travels: A small Italian restaurant, in a narrow alley, London

 

Most Unusual Assignment Location:  A Wall Street firm; Manhattan, NY (living in the Marriott World Trade Center, part of the former World Trade Center (WTC) complex; dinners at the Windows on the World restaurant, North Tower). Watching Maria Bartiromo eat her lunch in the square. The juxtaposition of extravagant wealth, surrounded by the absolute poverty of the many homeless.

Most Life-Threatening Client Risk Encountered: Being electrocuted by ungrounded wiring in their offices (Istanbul, Turkey)

 

Closest brush with being shot by the police: Foolishly scrambling to find my bus ticket, when a swarm of special police (in an Eastern European country) suddenly boarded with automatic rifles  (they were looking for someone). The terrified look of the other passengers, all looking at me, told me just how close I came to being worm food.

 

Most Memorable Flight Experience: Because I flew coach often (monthly) on a particularly distant international assignment, one of the local friends I had made in the city where I was working (that also happened to work for the airline I flew on), on my last return trip, unbeknownst to me, made special arrangements to have  wine and dinner from First Class delivered to my coach seat. The look on the faces of the people seated near me were clearly amazed, and one asked: "WHO ARE YOU!?"

 

Most Memorable Act of Kindness: On the Saturday that I was to depart Istanbul, still suffering from a severe case of food poisoning – I arrived at the airport only to discover that the queue extended outside of the terminal, and far down a hill. I felt doomed. I desperately wanted/needed to get inside to the executive lounge restrooms (and the excessive heat/humidity was not helping my situation). A small child, from out of nowhere, approached me. He did not speak any English (and the situation exceeded my limited Turkish vocabulary), but motioned for me to follow him. He led me to a side door, where a security guard stood. I do not know what was said, but it was the magic incantation that was needed (most urgently, in that moment): I was allowed to enter. I suspect he was an angel (but, he might have been a kind Djinn).

 

Cities with the Warmest Social Reception:  1. Sydney, Australia; 2. Istanbul, Turkey; 3. Washington D.C.

Cities with the Coldest Social Reception: 1. Moscow, Russia; 2. Cleveland, Ohio; 3. Seattle

 

Most Unusual Layover Experience:  Singapore, SilverKris Lounge (ask me about that sometime, over a drink)

Worst Luggage Disaster: Tahiti, my luggage was left on the tarmac - took a week to catch-up with me in Sydney. Each day I was told "it will be here tomorrow"; so I kept washing my clothes each night, in the sink, for a week.

 

Favorite mode of travel: Trains

Favorite train memory: A winter overnight trip, in a sleeper car, viewing the distant moonlit snow covered Carpathian mountains, on my way to Prague.

 

Favorite International Airports:  1. DFW; 2. Singapore; 3 Frankfurt 

Worst Airports: Newark (for on-time departures); Moscow (for safety); Bali (rats) 
(also see [3])

Best Business Class Airline Experiences: 1. Singapore Air; 2. Qantas; 3. British Air

Best International Expat Community Experience: Happy Hour in the bar of the Sheraton Grand Warsaw, Poland 

Best use of my Frequent Flyer Miles:  Flying my not-yet girlfriend to the island of Saint Lucia (in the Caribbean, ~2,480 miles from Little Rock, Arkansas) just for dinner (1993, for our 2nd date). 

 

[1] While some reading this may dismiss this entry (👆) and its importance – Let me assure you that it is based on personal lessons-learned, while usually operating solo in high risks areas, that included: 

  • because the threat of an Al-Qaeda attack was deemed very high (upon our arrival in-country), an armed private security detail was tasked to deliver a colleague and me from the airport – to our hotel; 
  • a private briefing, at a U.S. Consulate, on the almost certain risks of being tracked/targeted by Al-Qaeda – while in-country, and the operational security steps to mitigate the risks; 
  • not long after the private briefing, a terrorist car bombing attack occurred at that same U.S. Consulate. 
  • the threat of car bombs was so high at my hotel, that all cars were inspected; 
  • while seeking intelligence on possible local threats, I was advised by a police precinct office in the Middle East city (where I was working) of nearby terrorist cell activity – and to avoid certain  neighborhoods; 
  • a cholera outbreak in the Middle East city (where I was working); 
  • civil unrest; 
  • violent anti-government protests; 
  • acts of violent government oppression; 
  • acts of state-sponsored terrorism; 
  • organized crime activities; 
  • assassinations of police and government officials; 
  • being targeted and tracked by a pair of muggers in a city in Europe; 
  • an attempted carjacking, while driving through a very bad part of a city; 
  • being cornered by a belligerent threat on a city bus; 
  • a sudden surprise attack launched at a bus stop; 
  • an assassin's bullet that barely missed my temple; 
  • and a terrorist car bombing attack narrowly avoided (my hotel was severely damaged).
  • I have refused three assignments in the past that exceeded my risk tolerance levels: 
    1. In an active war zone (primarily due to the inability to legally obtain body armor and weapons, in-country); 
    2. In a Post-Soviet state, with a very dangerous Russian Mafia (Bratva) controlling the city where the work would be performed.; 
    3. Because their office was in the MOST DANGEROUS area of a major city in South Africa, and they also refused to provide security, a Per Diem (for meals and incidentals), housing, and transportation. 

 

[2] In this context, the value of a relationship is bi-directional, and multi-dimensional. For example:

  • Will they demonstrate a willingness to help others, and/or make mutual introductions – in our respective professional networks?
  • Will they demonstrate a willingness  (and an activity level) in sharing interesting news, experiences, lessons-learned. 
  • Are they curious?
  • Do they demonstrate a habit of continuous learning? 

 

[3] 2026-09-22 DailyMail.com

  
Posted by No comments:

2026-05-17

2026-05-17 Sunday - What You Need To Hear - Not What You Want To Hear

 A needful message:

I know you didn't hear the answer you wanted, or expected.

You wanted to hear the gold-plated answer for strategic initiatives.  

But, I have analyzed your company and operations - and what you sorely need is attention to the basics; to execution; to customer service; to quality; to efficiency; to reducing bloated costs. 

Based on my decades of field observations, what most companies call "strategic initiatives" are abject miserable failures - either never launching, never achieving an ROI, terminated with extreme prejudice, or eventually crashing & burning. Few survive longer than 2-3 years. Time after time, expenditures of time and money that would have been better spent honing the fundamentals.  

I will tell you what you need to hear.


(This painting, for me, is a metaphor. For life is a voyage...and there will always be ships that are in distress. Ships that are approaching danger, some that are just escaping. Some that steer well clear of danger, and others that rush upon reefs with wild abandon - heedless of the warnings of others. Some ships will crash upon the rocks - and others may yet avoid such disaster. Keen eyes are needed to read the charts, to scan the horizon, to read the currents, to know the shifting patterns of wind.)

 

[A 1667 painting by the Dutch artist, Ludolf Backhuysen, 
"Ships in Distress off a Rocky Coast", 
National Gallery of Art, Washington, D.C.]


 

 

Also see my LinkedIn companion post. 

Posted by No comments:
Labels:

2026-04-28

2026-04-28 Tuesday - Thoughts on Date Handling

 

[image credit: Orca on pixabay dot com]

(this post was prompted by a question posted on LinkedIn by Robin Moffat  

A placeholder for organizing my thoughts on date handling...

Benefits of Using Native Date Types:

  • Data Integrity: Native types like DATE, DATETIME, or TIMESTAMP enforce correct formatting and valid dates (e.g., preventing a date like February 30th).
  • Performance: Native date types are typically stored as compact numeric values. This makes sorting and indexing significantly faster compared to string comparisons.
  • Date Arithmetic: Using native types may allows you to easily perform operations like adding days, finding the difference between two moments, or extracting components (year, month, day) without complex string parsing.
  • Standardization: Most relational databases and programming languages provide robust libraries for handling native dates, ensuring consistent behavior across different systems.

 

Best Practices: 

  • Always use UTC: Store all timestamps in Coordinated Universal Time (UTC) to avoid complexities with time zones and daylight saving changes.
  • Convert at the Edge: Only convert dates to strings (formatted for a specific locale) when they need to be displayed to a human in the presentation tier.

 

When Storing/Transmitting Dates as Strings May Be Necessary:  

  • External API Constraints: When an external service only accepts or provides data in a specific string format (e.g., JSON which lacks a native date type).
  • Historical Edge Cases: Some database DATE types do not support dates in the distant past. For example: 
    • SQL Server's DATETIME limit of 1753-01-01
    • MySQL TIMESTAMP restrictions starting at 1970
    • Lack of BCE (Before Common Era) support

 

Standard-based Date Format:

 

Native Date Storage Considerations:  

  • C#
    • ... TO-DO, add entries
  • C/C++ 
    • ... TO-DO, add entries 
  • Java
    • ... TO-DO, add entries 
  • Python  
    • ... TO-DO, add entries 
  • Rust 
    • ... TO-DO, add entries 

 

Other misc. articles/posts that may be of possible interest: 

 


Posted by No comments:
Labels: , , , , ,

WordCount

Copyright

© 2001-2026 International Technology Ventures, Inc., All Rights Reserved.