2026-07-31

2026-07-31 Friday - Book Review : Deep Learning with R, Third Edition

 

[image source: Amazon.com]

Deep Learning with R, Third Edition
From first principles to generative AI

Published by: Manning

Authors:

✅ François Chollet

o   https://www.manning.com/authors/francois-chollet

o   https://www.linkedin.com/in/fchollet/ 

o   Founder of Keras

§  https://keras.io/

o   Co-Founder Ndea

§  https://ndea.com/

o   Co-Founder ARC Prize

§  https://arcprize.org/

o   https://intro.co/francoischollet

o   https://fchollet.com/

✅ Tomasz Kalinowski

o   https://www.manning.com/authors/tomasz-kalinowski

o   https://www.linkedin.com/in/t-kalinowski/ 

o    Engineering Manager, Posit (formerly RStudio) 

o   https://opensource.posit.co/people/tomasz-kalinowski/

o   https://posit.co/

o   https://github.com/t-kalinowski

o   https://bsky.app/profile/t-kalinowski.bsky.social

 Companion GitHub Repository: 

Publication Date: June 2, 2026

Pages: 648

My Review Rating:  5-Stars  

Also see my review on Amazon

My companion post on LinkedIn 

Review Title: A Master Class - A Deep Treatment of Deep Learning with R

My immediate first impression of this book:

👉 In one word: Excellence;

👉 In three words: Attention to Detail.

I will admit upfront that I am a longtime fan of François Chollet’s writing, and his creation of Keras (from Chapter 7, Section 7.1, “The design of the Keras API is guided by the principle of progressive disclosure of complexity: make it easy to get started, yet make it possible to handle high-complexity use cases while requiring only incremental learning at each step. Simple use cases should be easy and approachable, and arbitrarily advanced workflows should be possible.”).

I consistently find great value in the books he has written.

This book is no “flash in the pan” – with 20 chapters, and over 600 pages of content.

This is a book that will extend your knowledge and help deepen your understanding.

Beginning with ‘Chapter 2, The mathematical building blocks of neural networks’, the authors set out to give you a foundation of understanding. This type of foundational prep is missing in many books. Without understanding the fundamental concepts and principles, the reader may be able to do the mechanics of coding something – but will usually fall short in understanding and be unaware/unable to apply the appropriate concepts, where/when needed.

This is not a book that you should read quickly, nor is it a book you should assume to read only once.

To get the optimum benefit of this book, you must put in the work. Revisiting chapters, like an old friend.

You should approach reading this book, like you would if you wanted to build muscles in your mind. There will be effort required to build the skills that will develop intuition – and that’s what will likely differentiate the diligent reader who selects this book, from the dilettante that merely touches it with the fingertips.

The rewards will be many.

This book strikes an excellent balance between the narrative of teaching, and the steady pacing of hands-on coding examples (which are invariably well explained).

A key distinction that elevates this book above many others: It teaches the Why, not just What.

Also, I suspect that readers will be pleased with the quality of the illustrations, particularly those that immediately help illustrate possibly unfamiliar concepts.

In some Japanese arts, there is the concept of a shokunin. While it might be simplistically translated as “craftsman”, or “artisan” – the meaning is much deeper: It represents a profound lifelong vocational philosophy – a relentless, meditative drive to continuously refine their work. As researchers, writers, and teachers – the authors are just such master shokunin.

 

A minor update that will be required for the next edition of this book:

re: See page-15 ("AI is making major strides toward helping accelerate science. The AlphaFold model from DeepMind is helping biologists predict protein structures with unprecedented accuracy.")

2026-07-28:  Google DeepMind dismantles Nobel-winning AlphaFold team in strategy shift (Yahoo Finance > Financial Times)


Additional Reading Suggestions:

  1. R in Action, Third Edition: Data analysis and graphics with R and Tidyverse (2022)

 

Posted by No comments:
Labels: , , ,

2026-07-24

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

[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. 
 

====================================================================== 

 

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

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: , , , , , , , ,
Subscribe to: Posts (Atom)

WordCount

Copyright

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