Jekyll2026-01-25T18:27:46+00:00https://trueprogramming.com/atom.xmlTrue ProgrammingMassimo Caliman's Blog On Computer ScienceMassimo Calimanmcaliman@gmail.comDeveloping Secure Java EE Applications 12025-09-07T00:00:00+00:002025-09-07T00:00:00+00:00https://trueprogramming.com/developing-secure-java-ee-applications-1-introduction-en1. Introduction
  • Welcome and Objective
  • Current Threat Landscape
  • Java EE / Jakarta EE Context

2. Why Are We Here? - The Objective of This Talk

  • Developer Empowerment
    • Equip Java EE developers with concrete knowledge and tools
  • Security is Everyone’s Responsibility
    • Not just a problem for cybersecurity experts or IT Ops
  • From Threats to Prevention
    • Understand what to look for and how to defend against it
  • Improve Code & Processes
    • Integrate security into the software development lifecycle

3. The Evolving Threat Landscape (The “Why” - Part 1)

  • Frequency & Sophistication
    • Attacks are no longer just ‘script kiddies’
  • Motivations
    • Financial Gain (ransomware, data theft)
    • Industrial/State Espionage
    • Vandalism/Reputational Damage
  • Real-World Consequences
    • Data Breaches
    • Significant Financial Losses
    • Reputational Harm, Loss of Customer Trust
    • Legal & Regulatory Penalties (e.g., GDPR)

4. Applications are the Target (The “Why” - Part 2)

  • From Infrastructure to Code
    • Attackers focus on where they find the most vulnerabilities
  • Common Attack Vectors
  • Code Vulnerabilities
    • SQL Injection, XSS, Broken Authentication, etc
  • Misconfigurations:
    • Servers, Frameworks, Libraries
  • Components with Known Vulnerabilities
    • Third-party dependencies
  • The OWASP Top 10
    • Our reference guide for the most critical web application vulnerabilities

5. The Java EE/Jakarta EE Context: Our Ecosystem

  • Power & Complexity
    • The chosen platform for mission-critical enterprise applications
  • Architecture
    • Distributed Components (EJBs, Servlets, JPA, JMS, JAX-RS, etc.).
  • Unique Security Challenges
    • Inherent Complexity
      • Many components must be securely configured and interact
  • Legacy Applications
    • Older applications with outdated security practices
  • Delegating to the Container (But Not Too Much!)
    • The Java EE container offers us exceptional ‘out-of-the-box’ security features: authentication, role-based authorization, and session management. But it’s essential to understand that the container is only one part of the solution. If our application code is vulnerable (e.g., SQL Injection, XSS), the container cannot work miracles. Application code security is our primary responsibility.
  • Security:
    • A Shared Responsibility Starts with Developers

6. The “Plan”

  • Developing Secure Java EE Applications - (1)
    • Introduction (this Introduction)
  • Developing Secure Java EE Applications - (2)
    • Understanding Common Threats
  • Developing Secure Java EE Applications - (3)
    • Secure Development Principles in Java EE
  • Developing Secure Java EE Applications - (4)
    • Specific Best Practices for Java EE Jakarta EE
  • Developing Secure Java EE Applications - (5)
    • Security Testing and Monitoring
]]>
Massimo Calimanmcaliman@gmail.com
Sviluppo di applicazioni Java EE sicure 12025-09-07T00:00:00+00:002025-09-07T00:00:00+00:00https://trueprogramming.com/developing-secure-java-ee-applications-1-introduction-it1. Introduzione
  • Benvenuto e obiettivi
  • Panorama attuale delle minacce
  • Java EE / Jakarta EE Contesto

2. Perché siamo qui? - L’obiettivo di questo Talk

  • Empowerment degli sviluppatori
    • Fornire agli sviluppatori Java EE conoscenze e strumenti concreti
  • La sicurezza è responsabilità di tutti
    • Non è solo un problema per gli esperti di sicurezza informatica o per gli IT Ops.
  • Dalle minacce alla prevenzione
    • Capire cosa cercare e come difendersi
  • Migliora il codice e i processi
    • Integrare la sicurezza nel ciclo di vita dello sviluppo software

3. Il panorama delle minacce in continua evoluzione (Il “perché” - Parte 1)

  • Frequenza e sofisticatezza
    • Gli attacchi non sono più solo opera di “script kiddies”
  • Motivazioni
    • Guadagno finanziario (ransomware, furto di dati)
    • Spionaggio industriale/statale
    • Vandalismo/Danno alla reputazione
  • Conseguenze nel mondo reale
    • Data Breaches
    • Perdite finanziarie significative
    • Danno alla reputazione, perdita della fiducia dei clienti
    • Sanzioni legali e normative (ad es. GDPR)

4. Le applicazioni sono l’obiettivo (Il “perché” - Parte 2)

  • Dalle infrastrutture al codice
    • Gli aggressori si concentrano sui punti in cui trovano le vulnerabilità maggiori
  • Vettori di attacco comuni
  • Vulnerabilità del codice
    • SQL injection, XSS, autenticazione compromessa, ecc.
  • Configurazioni errate:
    • Server, framework, librerie
  • Componenti con vulnerabilità note
    • Dipendenze da terze parti
  • La Top 10 dell’OWASP
    • La nostra guida di riferimento alle vulnerabilità più critiche delle applicazioni web

5. Il contesto Java EE/Jakarta EE: il nostro ecosistema

  • Potenza e complessità
    • La piattaforma scelta per le applicazioni aziendali mission-critical
  • Architettura
    • Componenti distribuiti (EJB, Servlet, JPA, JMS, JAX-RS, ecc.).
  • Sfide uniche in materia di sicurezza
    • Complessità intrinseca
      • Molti componenti devono essere configurati in modo sicuro e interagire tra loro.
  • Applicazioni legacy
    • Applicazioni obsolete con pratiche di sicurezza superate
  • Delegare al contenitore (ma non troppo!)
    • l contenitore Java EE offre eccezionali funzionalità di sicurezza “pronte all’uso”: autenticazione, autorizzazione basata sui ruoli e gestione delle sessioni. Tuttavia, è fondamentale comprendere che il contenitore è solo una parte della soluzione. Se il codice della nostra applicazione è vulnerabile (ad esempio, SQL Injection, XSS), il contenitore non può fare miracoli. La sicurezza del codice dell’applicazione è la nostra responsabilità primaria.
  • Sicurezza:
    • Una responsabilità condivisa che inizia dagli sviluppatori

6. Il “Piano”

  • Sviluppo di applicazioni Java EE sicure - (1)
    • Introduzione (la presente Introduzione)
  • Sviluppo di applicazioni Java EE sicure - (2)
    • Comprendere le minacce comuni
  • Sviluppo di applicazioni Java EE sicure - (3)
    • Principi di sviluppo sicuro in Java EE
  • Sviluppo di applicazioni Java EE sicure - (4)
    • Migliori pratiche specifiche per Java EE Jakarta EE
  • Sviluppo di applicazioni Java EE sicure - (5)
    • Test di sicurezza e monitoraggio
]]>
Massimo Calimanmcaliman@gmail.com
Developing Secure Java EE Applications 22025-09-07T00:00:00+00:002025-09-07T00:00:00+00:00https://trueprogramming.com/developing-secure-java-ee-applications-2-understanding-common-threats-en2. Understanding Common Threats
  • Injection Flaws (SQL, NoSQL, Command Injection)
  • Broken Authentication and Session Management
  • Cross-Site Scripting (XSS)
  • Sensitive Data Exposure
  • Security Misconfiguration
  • Deserialization Vulnerabilities
  • Cross-Site Request Forgery (CSRF)
  • Using Components with Known Vulnerabilities
  • Brief Practical Examples

2.1 Injection Flaws (SQL, NoSQL, Command Injection)

  • An injection flaw is a vulnerability which allows an attacker to relay malicious code through an application to another system

2.2 Broken Authentication and Session Management

  • Weaknesses in authentication and session handling (session hijacking, credential stuffing)
    • Mitigation Strategies (Java EE Context):
      • Strong Authentication Practices:
        • Enforce Strong Password Policies, Implement Account Lockout Mechanisms, Apply Rate Limiting on Login Attempts, Utilize Multi-Factor Authentication (MFA), Hashing with Salt & Slow Algorithms: As discussed, use robust, salted, slow hashing algorithms like BCrypt, SCrypt, or Argon2. Never store plain text passwords. Avoid Verbose Error Messages on Login
      • Secure Session Management Practices:
        • Use Strong, Random, and Unique Session IDs, Set Secure and HttpOnly Flags on Session Cookies, Invalidate Sessions Upon Logout [HttpSession.invalidate(), HttpServletRequest.changeSessionId() (Servlet 3.1+)]
    • Leveraging Java EE / Jakarta EE Security Features:
      • Container-Managed Authentication
      • Jakarta Security API (JSR 375+)
      • Standard API Usage

2.3 Cross-Site Scripting (XSS) etc…

  • Reflected, Stored, and DOM-based XSS. How they affect EE web applications
    • Cross-Site Scripting (XSS) attacks exploit vulnerabilities in web applications by injecting Cross-Site Scripting (XSS) attacks exploit vulnerabilities in web applications by injecting malicious scripts into pages viewed by other users, affecting their experience and potentially compromising their data.
    • Reflected XSS occurs when an attacker uses a malicious link or form to inject a script, which is then reflected back to the victim’s browser.
    • Stored XSS happens when an attacker injects a malicious script into the application’s database, and it’s then delivered to unsuspecting users.
    • DOM-based XSS exploits weaknesses in the client-side code, allowing an attacker to manipulate the Document Object Model (DOM) and inject malicious scripts.

2.4 Sensitive Data Exposure

  • How sensitive data can be exposed (lack of encryption, excessive logging)
    • Data in Transit: Information intercepted while traveling across networks (e.g., public Wi-Fi, internet) can be easily read. Think of login credentials, financial details, or personal messages sent over unencrypted connections (HTTP vs. HTTPS).
      • HTTPS/TLS Always:** Configure your application server (e.g. Tomcat, WildFly, WebSphere, GlassFish) to use HTTPS (HTTP Secure) with TLS (Transport Layer Security) for all communications. This is essential for the web tier (browser to server), web services (SOAP/REST), and also for database connections if possible.
    • Data at Rest: Unencrypted files and databases, if accessed by unauthorized individuals (e.g., through a security breach, lost device), are fully compromised. Stolen laptops or servers with unencrypted hard drives offer direct access to sensitive information.

2.5 Sensitive Data Exposure

  • Password Hashing: Never store passwords in plaintext or with reversible encryption..
  • Use robust, salted hashing algorithms such as bcrypt, scrypt, or Argon2.
  • Libraries like Spring Security or Apache Shiro offer ready-to-use implementations.
  • Example (conceptual): String hashedPassword = BCrypt.hashpw(plainTextPassword, BCrypt.gensalt());
    • https://docs.spring.io/springsecurity/ site/docs/current/api/org/springframework/security/crypto/bcrypt/BCrypt.html

2.6 Security Misconfiguration

  • Common configuration errors in application servers, frameworks, libraries…
  • Don’t rely too much on what you find on stackoverflow … LLM
  • Read the official documentation anyway (sometimes even that can have errors!).
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
 version="4.0">

 <session-config>
 <session-timeout>15</session-timeout> <cookie-config>
 <secure>true</secure>
 <http-only>true</http-only>
 </cookie-config>
 </session-config>

 </web-app>

2.7 Deserialization Vulnerabilities

  • Risks related to deserializing untrusted data.
  • What is Deserialization?
  • The process of converting a serialized data format (e.g., bytes, JSON, XML) back into an object in memory.
  • Why is it Risky?
  • If the serialized data comes from an untrusted source, it can be crafted to manipulate the application’s state, leading to Remote Code Execution (RCE) or other severe attacks.
  • Java’s Vulnerability
  • Java’s standard deserialization mechanism is particularly vulnerable. Malicious payloads can exploit object construction and side effects.

Common Attack Vectors

  • Remote Code Execution (RCE)
    • Malicious objects can be designed to execute arbitrary code on the server.
  • Denial of Service (DoS)
    • Carefully crafted payloads can cause excessive resource consumption, crashing the application
  • Data Tampering/Corruption
    • Altering object state to bypass security checks or manipulate data.
  • Information Disclosure
    • Exploiting deserialization to read sensitive data

How Attacks Happen (Conceptual Java Example)

  • The ObjectInputStream.readObject() method is the entry point for deserialization. Without careful validation and sanitization of the input, it will attempt to reconstruct any Java object from the byte stream. Attackers can create malicious byte streams that, when deserialized, construct objects designed to trigger harmful actions.
  • Countermeasures & Best Practices

Countermeasures & Best Practices

  • Avoid Deserialization of Untrusted Data
    • The safest approach. If possible, use alternative data formats like JSON or XML with carefully defined schemas, and use specific parsing libraries (e.g., Gson, Jackson, JAXB) to control defined schemas, and use specific parsing libraries (e.g., Gson, Jackson, JAXB) to control object construction.
    • Use Whitelisting, not Blacklisting
      • If deserialization is unavoidable, carefully define and enforce which classes are allowed to be deserialized. Never try to block known bad classes; new exploits will always be found.
    • Modern Deserialization Libraries
      • If you must deserialize, consider using libraries designed with security in mind (e.g., those with built-in whitelisting capabilities). Research current best practices.
    • Java’s Serial Filter (JEP 290)
      • Starting with Java 9 (and backported to some Java 8 versions), use the serial filter mechanism to control which classes can be deserialized. This is a crucial defense but requires careful configuration. byte[]
byte[] serializedData = getUntrustedData(); // From network, file, etc.
// 1. Create a filter that allows only specific classes (whitelist)
BinaryOperator<ObjectInputStream, ObjectInputFilter>
filterFactory =
(ois, serialFilter) -> ObjectInputFilter.Config.createFilter(
"com.example.*;!*"); // Allow only classes in com.example package
// 2. Set the filter factory on the ObjectInputStream
try (ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(serializedData))) {
ois.setObjectInputFilter(filterFactory.apply(ois, null)); // Apply the filter
Object obj = ois.readObject(); // Now safer, but STILL requires caution
System.out.println("Deserialized object: " + obj);
}

2.8 Cross-Site Request Forgery (CSRF)

  • How to exploit the user’s browser’s trust.

2.9 Using Components with Known Vulnerabilities

  • The importance of securely managing dependencies

2.9.1 Brief Practical Examples

  • Show snippets of vulnerable Java EE code and explain why it’s vulnerable
]]>
Massimo Calimanmcaliman@gmail.com
Sviluppo di applicazioni Java EE sicure 22025-09-07T00:00:00+00:002025-09-07T00:00:00+00:00https://trueprogramming.com/developing-secure-java-ee-applications-2-understanding-common-threats-it2. Comprendere le minacce comuni
  • Difetti di iniezione (SQL, NoSQL, iniezione di comandi)
  • Autenticazione e gestione delle sessioni non funzionanti
  • Cross-Site Scripting (XSS)
  • Esposizione di dati sensibili
  • Configurazione errata della sicurezza
  • Vulnerabilità di deserializzazione
  • Cross-Site Request Forgery (CSRF)
  • Utilizzo di componenti con vulnerabilità note
  • Brevi esempi pratici

2.1 Difetti di iniezione (SQL, NoSQL, iniezione di comandi)

  • Un difetto di iniezione è una vulnerabilità che consente a un aggressore di trasmettere codice dannoso tramite un’applicazione a un altro sistema

2.2 Autenticazione e gestione delle sessioni interrotte

  • Punti deboli nell’autenticazione e nella gestione delle sessioni (dirottamento delle sessioni, credential stuffing)
  • Strategie di mitigazione (contesto Java EE):
  • Pratiche di autenticazione forte:
  • Applicare politiche di password forti, implementare meccanismi di blocco degli account, applicare limiti di frequenza ai tentativi di accesso, utilizzare l’autenticazione a più fattori (MFA), hashing con algoritmi salt & slow: Come discusso, utilizzare algoritmi di hashing robusti, con salt e lenti come BCrypt, SCrypt o Argon2. Non memorizzare mai password in chiaro. Evitare messaggi di errore verbosi al login
  • Pratiche di gestione sicura delle sessioni:
  • Utilizzare ID di sessione forti, casuali e univoci, impostare flag sicuri e HttpOnly sui cookie di sessione, invalidare le sessioni al momento del logout [HttpSession.invalidate(), HttpServletRequest.changeSessionId() (Servlet 3.1+)]
  • Sfruttare le funzionalità di sicurezza Java EE / Jakarta EE:
  • Autenticazione gestita dal contenitore
  • API di sicurezza Jakarta (JSR 375+)
  • Utilizzo dell’API standard

2.3 Cross-Site Scripting (XSS) ecc…

  • XSS riflesso, memorizzato e basato su DOM. Come influiscono sulle applicazioni web EE
  • Gli attacchi Cross-Site Scripting (XSS) sfruttano le vulnerabilità delle applicazioni web iniettando Gli attacchi Cross-Site Scripting (XSS) sfruttano le vulnerabilità delle applicazioni web iniettando script dannosi nelle pagine visualizzate da altri utenti, compromettendo la loro esperienza e potenzialmente mettendo a rischio i loro dati.
    • L’XSS riflesso si verifica quando un aggressore utilizza un link o un modulo dannoso per iniettare uno script, che viene poi riflesso sul browser della vittima.
  • L’XSS memorizzato si verifica quando un aggressore inietta uno script dannoso nel database dell’applicazione, che viene poi consegnato a utenti ignari.
    • L’XSS basato su DOM sfrutta le debolezze del codice lato client, consentendo a un aggressore di manipolare il Document Object Model (DOM) e iniettare script dannosi.

2.4 Sensitive Data Exposure

  • Come i dati sensibili possono essere esposti (mancanza di crittografia, registrazione eccessiva)
  • Dati in transito: le informazioni intercettate mentre viaggiano attraverso le reti (ad esempio, Wi-Fi pubblico, Internet) possono essere facilmente lette. Si pensi alle credenziali di accesso, ai dettagli finanziari o ai messaggi personali inviati tramite connessioni non crittografate (HTTP vs. HTTPS). * HTTPS/TLS sempre:** configurate il vostro server applicativo (ad es. Tomcat, WildFly, WebSphere, GlassFish) per utilizzare HTTPS (HTTP Secure) con TLS (Transport Layer Security) per tutte le comunicazioni. Ciò è essenziale per il livello web (dal browser al server), i servizi web (SOAP/REST) e, se possibile, anche per le connessioni al database.
    • Dati inattivi: i file e i database non crittografati, se accessibili da persone non autorizzate (ad esempio a seguito di una violazione della sicurezza o della perdita di un dispositivo), sono completamente compromessi. I laptop o i server rubati con dischi rigidi non crittografati offrono accesso diretto a informazioni sensibili.

2.5 Sensitive Data Exposure

  • Hashing delle password: non memorizzare mai le password in chiaro o con crittografia reversibile.
  • Utilizzare algoritmi di hashing robusti e con salt, come bcrypt, scrypt o Argon2.
  • Librerie come Spring Security o Apache Shiro offrono implementazioni pronte all’uso.
  • Esempio (concettuale): String hashedPassword = BCrypt.hashpw(plainTextPassword, BCrypt.gensalt());
    • https://docs.spring.io/springsecurity/ site/docs/current/api/org/springframework/security/crypto/bcrypt/BCrypt.html

2.6 Security Misconfiguration

  • Errori di configurazione comuni nei server delle applicazioni, nei framework, nelle librerie…
  • Non affidarti troppo a ciò che trovi su stackoverflow … LLM
  • Leggi comunque la documentazione ufficiale (a volte anche quella può contenere errori!).
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
 version="4.0">

 <session-config>
 <session-timeout>15</session-timeout> <cookie-config>
 <secure>true</secure>
 <http-only>true</http-only>
 </cookie-config>
 </session-config>

 </web-app>

2.7 Deserialization Vulnerabilities

  • Rischi legati alla deserializzazione di dati non attendibili.
  • Che cos’è la deserializzazione?
  • Il processo di conversione di un formato di dati serializzato (ad esempio byte, JSON, XML) in un oggetto in memoria.
  • Perché è rischioso?
  • Se i dati serializzati provengono da una fonte non attendibile, possono essere manipolati per alterare lo stato dell’applicazione, causando l’esecuzione di codice remoto (RCE) o altri attacchi gravi.
  • Vulnerabilità di Java

Vettori di attacco comuni

  • Esecuzione di codice remoto (RCE)
  • È possibile progettare oggetti dannosi per eseguire codice arbitrario sul server.
  • Denial of Service (DoS)
  • Payload accuratamente progettati possono causare un consumo eccessivo di risorse, bloccando l’ applicazione
  • Manomissione/corruzione dei dati
  • Alterazione dello stato degli oggetti per aggirare i controlli di sicurezza o manipolare i dati.
  • Divulgazione di informazioni
  • Sfruttamento della deserializzazione per leggere dati sensibili

Come avvengono gli attacchi (esempio concettuale Java)

  • Il metodo ObjectInputStream.readObject() è il punto di ingresso per la deserializzazione. Senza un’ attenta convalida e sanificazione dell’input, tenterà di ricostruire qualsiasi oggetto Java dal flusso di byte. Gli aggressori possono creare flussi di byte dannosi che, una volta deserializzati, costruiscono oggetti progettati per attivare azioni dannose.
  • Contromisure e best practice

Contromisure e best practice

  • Evitare la deserializzazione di dati non attendibili
  • L’approccio più sicuro. Se possibile, utilizzare formati di dati alternativi come JSON o XML con schemi definiti con cura e utilizzare librerie di analisi specifiche (ad esempio Gson, Jackson, JAXB) per controllare gli schemi definiti e utilizzare librerie di analisi specifiche (ad esempio Gson, Jackson, JAXB) per controllare la costruzione degli oggetti.
  • Utilizzare whitelist, non blacklist * Se la deserializzazione è inevitabile, definire e applicare con attenzione quali classi possono essere deserializzate. Non cercare mai di bloccare classi notoriamente dannose; si troveranno sempre nuovi exploit.
  • Librerie di deserializzazione moderne
  • Se è necessario deserializzare, prendere in considerazione l’utilizzo di librerie progettate tenendo conto della sicurezza (ad esempio, quelle con funzionalità di whitelist integrate). Ricercare le migliori pratiche attuali.
    • Filtro seriale di Java (JEP 290)
  • A partire da Java 9 (e con backport ad alcune versioni di Java 8), utilizzare il meccanismo del filtro seriale per controllare quali classi possono essere deserializzate. Si tratta di una difesa cruciale, ma richiede un’attenta configurazione. byte[]
byte[] serializedData = getUntrustedData(); // From network, file, etc.
// 1. Create a filter that allows only specific classes (whitelist)
BinaryOperator<ObjectInputStream, ObjectInputFilter>
filterFactory =
(ois, serialFilter) -> ObjectInputFilter.Config.createFilter(
"com.example.*;!*"); // Allow only classes in com.example package
// 2. Set the filter factory on the ObjectInputStream
try (ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(serializedData))) {
ois.setObjectInputFilter(filterFactory.apply(ois, null)); // Apply the filter
Object obj = ois.readObject(); // Now safer, but STILL requires caution
System.out.println("Deserialized object: " + obj);
}

2.8 Falsificazione delle richieste cross-site (CSRF)

  • Come sfruttare la fiducia riposta dall’utente nel proprio browser.

2.9 Utilizzo di componenti con vulnerabilità note

  • L’importanza di gestire in modo sicuro le dipendenze

2.9.1 Brevi esempi pratici

  • Mostra frammenti di codice Java EE vulnerabile e spiega perché è vulnerabile.
]]>
Massimo Calimanmcaliman@gmail.com
Software Architect2025-05-09T00:00:00+00:002025-05-09T00:00:00+00:00https://trueprogramming.com/software-architect

The Architect: Hello, Neo. Neo: Who are you? The Architect: I am the Architect. I created the matrix. I’ve been waiting for you. You have many questions, and although the process has altered your consciousness, you remain irrevocably human. Ergo, some of my answers you will understand, and some of them you will not. Concordantly, while your first question may be the most pertinent, you may or may not realize it is also the most irrelevant. Neo: Why am I here? The Architect: Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix. You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden assiduously avoided, it is not unexpected, and thus not beyond a measure of control. Which has led you, inexorably, here. Neo: You haven’t answered my question. The Architect: Quite right. Interesting. That was quicker than the others. … From “The Matrix Reloaded”

A Software Architect is a professional who designs and develops the architecture of a software system, defining its technical specifications and components. He or she ensures that the software meets business needs, is efficient, scalable and easy to maintain.

What does a Software Architect do?

  • System-level design: The Software Architect focuses on the system’s high-level design, including coding standards, development environments, and automation mechanisms.
  • Definition of technical specifications: Establishes the technical specifications, interfaces, communication between components and database management rules.
  • Ensuring quality and efficiency: It ensures that the software is designed to guarantee quality, efficiency, scalability and maintainability.
  • Collaboration with the team: Collaborates with developers, designers and other team members to define and implement the software architecture.
  • Requirements study and analysis: Analyses customer requirements and translates them into an appropriate software solution, defining the technical characteristics of the system.
  • Life cycle management: Monitors software development and maintenance, making changes and improvements to ensure the system remains up-to-date and functional.
  • Knowledge of technologies: Must have a solid understanding of software development technologies and methodologies, as well as familiarity with design and testing tools.

What are his or her responsibilities?

  • Provide a functional and efficient solution: The Software Architect must be able to provide a software solution that meets business needs, is efficient and is easily scalable.
  • Ensure software quality: He/she ensures that the software is well designed, tested and documented, minimising the risk of errors and improving maintainability.
  • Support in the development phase: Helps the development team implement the software architecture, providing guidance and solving problems.
  • Risk management: Identifies and manages risks associated with software development, ensuring that they are addressed in a timely and effective manner.
]]>
Massimo Calimanmcaliman@gmail.com
Git Tag2024-05-11T00:00:00+00:002024-05-11T00:00:00+00:00https://trueprogramming.com/git-tagIn today’s programming landscape, version control systems (VCS) are indispensable. It’s hard to imagine a time without them, yet some of us can remember the pre-VCS era – a time when managing code changes was significantly more challenging. Nowadays, with the advent of VCS, developers can efficiently track changes, collaborate seamlessly, and maintain a clear history of their codebase.

One of the core functionalities of a VCS like Git is tagging. Tagging allows you to mark specific points in your codebase history, often designating a significant release or milestone. Git offers two types of tags: annotated tags and lightweight tags. This article focuses on the benefits and creation of annotated tags, which provide additional information and a reference point.

Understanding Annotated Tags

Nowadays, annotated tags play a crucial role in maintaining organized and well-documented codebases. They not only provide a reference point in your code history but also store additional information. This information, typically a descriptive message, can explain the purpose or significance of the tagged version. By incorporating annotated tags into your development workflow, you can enhance the clarity and traceability of your project’s evolution.

Creating Annotated Tags with Git

The following command creates an annotated tag in your Git repository:

git tag -a <tag_name> -m "<comment>"

where

  • -a: specifies the creation of an annotated tag.
  • -m: introduces the comment that will be associated with the tag.

Once you’ve created your annotated tag, you can share it with collaborators by pushing it to a remote repository.

Here’s the command:

git push origin <tag_name>

Benefits of Annotated Tags

Clear Context: The comment associated with an annotated tag provides valuable context for understanding the tagged version’s purpose or content.

Improved Collaboration: Sharing annotated tags streamlines collaboration by giving your team a clear reference point with additional information. Version Tracking: Annotated tags serve as historical markers, allowing you to easily revisit specific versions of your codebase.

By effectively utilizing annotated tags, you can enhance your project’s organization, clarity, and collaboration for your development team. In today’s collaborative development environment, annotated tags have become an essential tool for maintaining a well-managed and well-documented codebase.

To list stored tags in a repo execute the following:

git tag
]]>
Massimo Calimanmcaliman@gmail.com
Monads: A First Definition2024-04-27T00:00:00+00:002024-04-27T00:00:00+00:00https://trueprogramming.com/monads-first-definitionIn the world of functional programming, monads can be defined as algebraic structures that encapsulate values and computations, providing a coherent interface for the management of computational contexts.

This definition, although more formal, maintains the essence of the monad concept as a container for values and behaviour.

To highlight the structural and algebraic aspect of monads, we can use the following formulation:

  • A monad M is a triplet (T, η, μ) where:
    • T is a functor
    • η is a natural isomorphism between the functor unit T and the empty object
    • μ is a bind operation

In some other fashion, the triplet (T, η, μ) defines the rules for the manipulation of values within the monad, ensuring consistent and uniform behaviour.

Example:

The monad Maybe, used to handle null values, can be defined as:

  • T(x) = x or None (represents the encapsulated data type).
  • η(x) = Just x (converts a normal value to a Maybe value)
  • μ(f, mx) = bind f mx (combines a function f with a Maybe value mx)

This formal definition, although it may seem difficult at first sight, provides a solid basis for understanding the inner workings of monads and their power in functional programming

]]>
Massimo Calimanmcaliman@gmail.com
A list of books on Clojure2023-09-09T00:00:00+00:002023-09-09T00:00:00+00:00https://trueprogramming.com/clojure/clojure-books

Simplicity is hard work. But, there’s a huge payoff. The person who has a genuinely simpler system - a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He’s going to kick your ass. He’s gonna spend more time simplifying things up front and in the long haul he’s gonna wipe the plate with you because he’ll have that ability to change things when you’re struggling to push elephants around. – Rich Hickey, Creator of the Clojure programming language.

I’ve heard a lot of people say that there are no good books on Clojure, or that the resources available are too limited. I’m here to tell you that this is not true! There are a number of excellent Clojure books available, covering a wide range of topics.

Here is a list of Clojure books that I think are great.

Clojure Data Structures and Algorithms Cookbook

  • 25 recipes to deeply understand and implement advanced algorithms in Clojure
  • Author: Rafik Naccache
  • Publisher: Packt Publishing
  • Copyright © 2015

Clojure for Data Science

  • Statistics, big data, and machine learning for Clojure programmers
  • Author: Henry Garner
  • Publisher: Packt Publishing
  • Copyright © 2015

Clojure for Java Developers

  • Transition smoothly from Java to the most widely used functional JVM-based language – Clojure
  • Author: Eduardo Díaz
  • Publisher: Packt Publishing
  • Copyright © 2016

Clojure for Machine Learning

  • Successfully leverage advanced machine learning techniques using the Clojure ecosystem
  • Author: Akhil Wali
  • Publisher: Packt Publishing
  • Copyright © 2014

Clojure Data Analysis Cookbook

  • Over 110 recipes to help you dive into the world of practical data analysis using Clojure
  • Author: Eric Rochester
  • Publisher: Packt Publishing
  • Copyright © 2013

Practical Clojure

  • Luke VanderHart and Stuart Sierra
  • Publisher: Apress
  • Copyright © 2010

Quick Clojure: Effective Functional Programming

Mark McDonnell Publisher: Apress Copyright © 2017

The Joy of Clojure

MICHAEL FOGUS CHRIS HOUSER Publisher: Manning Publications Co. Copyright © 2011

]]>
Massimo Calimanmcaliman@gmail.com
Using Prolog to Build Expert Systems2023-08-14T00:00:00+00:002023-08-14T00:00:00+00:00https://trueprogramming.com/prolog-expert-systemProlog is a logical programming language that is often used to write expert systems. An expert system is a computer program that can mimic human reasoning in a specific domain. Expert systems are often used to solve problems that are difficult or impossible for humans to solve, such as medical diagnosis or financial planning.

To write a small Prolog engine or expert system, you first need to define the domain of the problem that you want to solve. This means defining the key concepts of the domain, the relationships between the concepts, and the rules that govern the domain. Once you have defined the domain, you can write the Prolog code that implements the expert system.

The Prolog code for an expert system consists of a set of facts and rules. Facts are statements that are true about the domain. Rules are statements that describe how the facts are related to each other. To solve a problem, the expert system starts with a set of facts and applies the rules to deduce new facts. The process continues until the expert system is unable to deduce a solution to the problem.

Here is an example of a small expert system that can be used to diagnose diseases. The domain of the problem is medicine and the key concepts are symptoms, diseases, and drugs. The rules describe how the symptoms are related to the diseases and how the diseases are related to the drugs. To diagnose a disease, the expert system starts with a set of symptoms and applies the rules to deduce the possible diseases. The expert system then provides a list of the possible diseases and the doctor can then select the most likely disease.

Writing a small Prolog engine or expert system is an interesting idea because it can be used to solve a wide range of problems. Expert systems can be used to solve problems that are difficult or impossible for humans to solve, such as medical diagnosis or financial planning. Additionally, expert systems can be used to automate tasks that are currently performed by humans, such as customer support or report generation.

Prolog code for a small expert system that can be used to infer family relationships

% Definitions of facts

father(john, peter).
father(john, paul).
mother(mary, peter).

% Definitions of rules

is_sibling(X,Y) :- father(Z,X), father(Z,Y), X\=Y.
is_child(X,Y) :- father(Y,X).
is_father(X,Y) :- father(X,Y).
is_mother(X,Y) :- mother(X,Y).

% Query

?- is_sibling(peter, paul).

true.

?- is_child(peter, john).

true.

?- is_father(john, peter).


true.

?- is_mother(mary, peter).

true.

If you are interested in writing a small Prolog engine or expert system, there are many resources available online. You can find tutorials, example code, and libraries that can help you get started.

]]>
Massimo Calimanmcaliman@gmail.com
Passing Parameters to Methods/Functions/Procedure in Programming Languages2023-08-13T00:00:00+00:002023-08-13T00:00:00+00:00https://trueprogramming.com/passing-parameters-in-programming-languagesIn a programming language, parameters are variables that are used to pass information into or out of a method (or a function or procedure). There are 2 main ways to pass parameters: by value and by reference.

Pass by value

When a parameter is passed by value, the value of the parameter is copied into the method. If the value of the parameter is changed in the method, the change will not be reflected in the value of the original parameter.

For istance, the following pseudocode passes an integer by value to a method:

proc foo(by val number)
  number = 10
endproc

number = 5
foo(number)
print(number) # the output is 5

In the above pseudocode, the foo() method is called with the value 5 as an argument. The value 5 is copied into the number variable inside the method. The number variable is then set to the value 10. However, the change in the value of number is not reflected in the value of the original number. When the foo() method terminates, the value of number is still 5.

Pass by reference

When a parameter is passed by reference, the reference to the parameter is copied into the method. If the value of the parameter is changed in the method, the change will be reflected in the value of the original parameter.

For example, the following pseudocode passes an object by reference to a method:

proc foo(by ref person)
  person.name = "Mark"
endproc 

person = Person("Luke")
foo(person)
print(person.name) # Prints Mark

In the above pseudocode, the foo() method is called with the object person as an argument. The reference to the object person is copied into the person variable inside the method. The person variable is then used to change the name of the object. The change in the name of the object is reflected in the original object. When the foo() method terminates, the name of the object is still Mark.

The type of parameter passing to use depends on the type of parameter and the operation that needs to be performed. If you need to change the value of the parameter in the method, you need to use pass by reference. If you do not need to change the value of the parameter in the method, you can use pass by value.

]]>
Massimo Calimanmcaliman@gmail.com