In this comprehensive series of interviews, presented in collaboration with our friends from the GitBar podcast, we delve into the fundamental concepts for devs that both senior and junior programmers should be familiar with to stay up-to-date with the current tech industry.
Top developers have shared key technologies, terms, and approaches that are shaping their respective industries today: from AI and ML to Open Source, Microservices, and Scrum methodologies. Here are their insights for the Codemotion Community to enjoy!
Table of contents
AI, Machine learning, and deep learning
By Alberto Massidda, Production Engineer @Meta
AI: It is a general concept that encompasses everything related to making a computer or software “intelligent.” AI can be based on rules (preprogrammed) or on learning (the ability to learn from data and experiences).
Machine Learning: “Letting computers learn on their own” by giving them access to a large set of data and allowing them to establish rules and patterns. The output is generated by models built through learning from training data.
Deep Learning (DL): A subfield of machine learning that mimics the operating principle of the biological brain. It relies on processing information through multiple “layers of depth.” Each layer of a neural network processes a different aspect of the data and then passes what it has learned to the next layer. The output reflects the “perspective” of all layers.
Model
Discriminative Models in AI: Learn decision boundaries from training data and use these boundaries to classify new inputs. Applicable to decision and prediction problems, such as real estate price generation, image recognition, and spam filtering.
Generative Models in AI: Estimate the distribution of training data, thus learning to generate examples belonging to various subgroups. They are used in various applications, such as image generation, speech synthesis, and automatic translation.
Learning
Supervised Learning: Algorithms learn from a set of labeled data. Each data example consists of an input and the corresponding desired output (label). The goal is to create a model that, given a new input, can predict the correct output.
Unsupervised Learning: Relies on unlabeled data and seeks to find hidden structures or patterns in the data. This can be used to group similar data (clustering), reduce data dimensionality, or discover associative rules among their features.
Semi-Supervised Learning: It falls halfway between supervised and unsupervised learning. It uses a large set of unlabeled data to induce automatic labels that will then be used to train a supervised model. Useful when data labels are expensive or difficult to obtain.
Training and Inference
Training in AI: The phase in which a model “learns” from data. The algorithm uses a training data set to adjust its internal parameters and optimize its performance.
Inference in AI: The phase in which an already trained model is used to make predictions on new unknown data. Inference is the practical application of the model.
Software Licenses
By Carlo Piana, Founder & Partner @Array Law
Software License: It is a legal statement that defines the terms and conditions for the use of software. When you purchase, download, or install software, the manufacturer or rights holder grants you a license that establishes the rights and obligations related to the use of that software, in addition to the rights and duties established by law.
Open-Source License:
Access to source code: Users can obtain, modify, and distribute the source code freely and transparently.
Freedom of use and distribution: They offer the freedom to use, copy, distribute, modify, and redistribute the software without restrictions. This feature promotes innovation and the sharing of technology.
Author attribution: They may require credit to be given to the original author of the software when the source code is used or distributed.
Copyleft license: Some licenses include copyleft clauses, such as the GPL (GNU General Public License), which mandate that derived or modified software must be distributed under the same Open Source license as the original code. This ensures that derived versions will continue to be Open Source. One of the copyleft conditions is to share the complete source code corresponding to the modified versions.
Proprietary License
Limited access to source code: Does not provide access to the software’s source code. Users receive only the final compiled product and cannot access, view, or modify the source code. It is not Open Source; it is proprietary software, even if it is free.
Paid license: Often requires payment for a license. There are different licensing models, such as single-user licenses, enterprise licenses, or time-limited licenses.
If No License is Applied:
When creating software, the law reserves all rights to the author. Therefore, if you intend to grant permission to make it Open Source, a public and express statement must be made; otherwise, all rights remain reserved. This does not mean that the software becomes public domain; in fact, the rights holder can allow free use only under certain conditions, including copyleft. These conditions must comply with the Open Source Definition to be considered “Open Source.”
Microservices
By Mattia Tommasone, Senior Developer Relations Engineer, Ads @ Google
Modularity: They are independent components that perform specific functions within an application. Each one can be developed, deployed, and scaled separately from the others.
Independence: Each microservice is autonomous and can be developed using different programming languages, technologies, and tools.
Communication via APIs: Microservices communicate with each other through well-defined APIs.
Scalability: They allow individual components of the application to scale independently based on load requirements.
Failure Isolation: Thanks to their modular nature, if one microservice fails, others can continue to function normally.
Rapid Development and Deployment: The modularity of microservices facilitates parallel development and continuous implementation. Each microservice can be developed, tested, and deployed independently, speeding up the application development process.
Ease of Replacement and Update: Due to the separation of microservices, one can be replaced with a better implementation or updated without affecting others. This simplifies the evolution and update of individual components of the application.
Horizontal Scalability: Microservices can be replicated and distributed across multiple servers to distribute load and increase application performance.
DevOps-Friendly: The architecture of microservices aligns well with the DevOps approach, as it facilitates continuous integration, continuous-release, and automation of development, testing, and deployment processes.
Division into Microservices
Coherent Functionality: Identify system functionalities that can be isolated and divided into separate microservices. Microservices should be cohesive, containing related business logic and providing a distinct functional unit.
Appropriate Granularity: Strike a balance in the size of microservices. They should be small enough to ensure modularity and independence but also large enough to independently handle a significant portion of the business logic.
Domain Boundaries: Identify domain boundaries, i.e., conceptual boundaries between different responsibilities of the application.
Communication and Interfaces: Define communication methods between microservices. Typically, RESTful APIs, asynchronous messaging, or events are used to enable interaction between different services. Clearly establish API interfaces and contracts to ensure correct and consistent communication.
Data Isolation: Consider how to manage data access by microservices. Various strategies can be adopted, such as exclusive data ownership by a microservice, data replication among services, or adopting an eventually consistent consistency model.
Transaction Management: Evaluate how to handle transactions between microservices. Distributed transactions can be complex to implement and manage. Approaches such as process compensation or the use of event sourcing and CQRS (Command Query Responsibility Segregation) can be adopted to ensure data consistency.
Monitoring and Tracing: Plan how to monitor and trace requests and responses between microservices. Having visibility into performance and interactions between services is important for diagnosing and resolving any issues.
Conway’s Law
Organizations that design systems… are constrained to produce designs that are copies of the communication structures of their organizations.
Kubernetes
By Serena Sensini, Enterprise Architect @Dedalus spa and Founder @TheRedCode
Kubernetes is an open-source system for the automation of deployment, scalability, and management of containerized applications. Its primary purpose is to provide a framework for deploying, maintaining, and scaling applications efficiently and reliably in various hosting environments.
Master Node: The main node that controls and manages the Kubernetes cluster.
Worker Node: Responsible for running containers (applications) within the Kubernetes cluster.
Kubelet: An agent that runs on each node and ensures that containers are running in a desired state.
Kube-proxy: Maintains network rules on nodes to allow management between different services.
Pod: The smallest and simplest unit in Kubernetes, representing a single process in a cluster composed of one or more containers.
Service: An abstraction that defines a logical set of pods to enable communication through networking components.
Deployment: Provides declarative updates for pods and ReplicaSets.
ReplicaSet: Ensures that a specified number of copies of a pod are running at any given time.
ConfigMap and Secret: Mechanisms for providing configuration files and/or sensitive data to pods.
Namespace: Allows logical separation and the definition of a naming convention between resources within a cluster.
Etcd: Reliably preserves the state configuration of the cluster.
Big Data
By Antonio Murgia, Data Architect @ Agile Lab
“Data has its own gravity.”
The term “big data” refers to an exceptionally large volume of data that can be analyzed to reveal patterns, trends, and associations. This concept is continuously evolving and generally pertains to data that is so vast or complex that traditional data processing methods are inadequate to handle them.
Volume: The quantity of data.
Velocity: The speed at which new data is generated and how data moves around.
Variety: Different types of structured and unstructured data.
Veracity: The correctness and reliability of the data.
Value: The ability and potential to transform data into value.
Types of Data
Structured data is organized in a predefined and easily analyzable format (e.g., relational database), while unstructured data is disorganized and does not follow a specific structure, making their processing and analysis more complex, as in the case of texts, images, or videos.
ETL and ELT
ETL (Extract, Transform, Load) processes extract data from various sources, transform it into a compatible format, and then load it into a data warehouse for analysis. ELT (Extract, Load, Transform), on the other hand, extracts data, loads it into the data warehouse first, and then transforms it within the storage itself, often providing greater efficiency for large volumes of data.
A data warehouse is a centralized system that stores structured and rarely semi-structured data, optimized for fast analysis and querying.
A data lake is a system that can store large volumes of structured and unstructured data, keeping them in their raw format until needed for use, offering greater flexibility.
Bronze, Silver, and Gold Data
The terms bronze, silver, and gold refer to data refinement stages: bronze data is raw and unprocessed, silver data is cleaned and transformed but not ready for final consumption, and gold data is refined, reliable, and ready for analysis and reporting.
Cloud
By Andrea Saltarello, CTO @Managed Designs and Founder @UGIdotNET
Public Cloud: Cloud services offered over the Internet by third-party providers, accessible to anyone wishing to subscribe or purchase them.
Private Cloud: Cloud computing infrastructure dedicated to a specific organization, offering greater control and privacy.
Hybrid Cloud: Combination of public and private clouds, allowing the exchange and sharing of data and applications between them to achieve greater flexibility and optimization of existing infrastructure.
Private Cloud vs. On-Premises: On-premises solutions are physically located and managed within the organization’s facilities, requiring dedicated hardware, software, and IT personnel for maintenance. In contrast, the private cloud offers a dedicated cloud computing environment hosted remotely, managed by the service provider but reserved exclusively for the organization, providing greater scalability and flexibility than an on-premises implementation.
Vendor Lock-in: “Vendor lock-in” in the cloud refers to a situation where an organization becomes excessively dependent on a single cloud service provider, making it difficult or costly to migrate to another provider. Before taking corrective actions, it is necessary to estimate the risk from both a probability and cost perspective if it materializes. If these factors are predominant, a strategy must be implemented to limit the impact, including the use of open standards and designing systems with portability in mind, even if it means foregoing features provided out of the box by the cloud platform and accepting the cost of developing them in-house or replacing them with additional products/services.
Cloud Governance: The set of rules, policies, and procedures that an organization implements to manage, monitor, and optimize the use of cloud resources. It includes guidelines on how cloud services are selected, implemented, and managed within the organization.
- Policies and Guidelines: Definition of clear rules and procedures for the use of cloud services.
- Security and Compliance: Ensuring that cloud services comply with legal regulations and the organization’s security requirements.
- Cost Management: Monitoring and controlling costs associated with cloud usage to avoid waste and unexpected overloads.
- Performance Optimization: Ensuring that cloud resources are used efficiently to deliver the desired performance.
- Risk Management: Assessment and mitigation of risks associated with cloud adoption, such as availability and resilience.
- Integration and Interoperability: Ensuring seamless integration of cloud services with other organization systems and technologies.
- Monitoring and Reporting: Using tools to monitor the usage, performance, and compliance of cloud services and creating regular reports for organizational leadership.
- Responsibilities and Roles: Clear definition of roles and responsibilities within the organization for the management and governance of cloud services.
User Stories and Product Ownership
By Matteo Guidotto, Senior Growth Product Manager @DaVinci Salute
Product Owner and Product Manager
The Product Owner tends to have a more tactical and team-specific focus, while the Product Manager tends to have a more strategic and market-oriented focus. However, in some organizations, roles can be merged or have significant overlap.
Listening-Driven Role
By actively listening to the business, the Product Owner can understand their needs, problems, and expectations—essential for defining and prioritizing product requirements.
Active listening is crucial for effective collaboration with the development team, understanding their challenges, concerns, and suggestions, and ensuring they are on the right track to achieve sprint goals.
By listening to other stakeholders (managers, marketing, etc.), the Product Owner can ensure that the product aligns with business goals and market strategies.
Effective listening is essential for managing and resolving conflicts that may arise among stakeholders or within the development team, facilitating mediation and finding shared solutions.
Listening builds trust between the Product Owner and stakeholders. Demonstrating empathy and consideration can contribute to creating positive and productive working relationships.
Definition of Ready (DoR):
The Definition of Ready establishes the criteria that a product backlog item must meet before it can be considered ready to be included in a sprint.
Clarity of Requirements, Agreement on Scope, Estimates (when present), and solution to all dependencies.
DoR helps prevent misunderstandings and delays in sprint work, ensuring that the team starts with clear expectations and information.
Definition of Done (DoD):
On the other hand, the Definition of Done establishes the criteria that a product backlog item must meet to be considered completed, e.g., Code Written and Tested, Code Reviewed, Complete Documentation, Satisfied Clients and End Users.
DoD ensures that each completed item meets an agreed-upon quality standard and is genuinely ready for release, if necessary.
Risks of the Definition of Ready (DoR):
An overly rigid or detailed DoR can reduce flexibility and the team’s ability to adapt to changes. It may be interpreted in a way that only the Product Owner is responsible for preparing backlog items, potentially reducing collaboration and discussion within the team on these items. It may give a false sense of security, making it believe that if all criteria are met, there will be no issues during development, which is not always true.
UI and UX Design
By Davide Di Pumpo, Design Technologist @ Amazon, and Paul Romero, UX & Service Designer and Product Manager
Design
Global Process: It is a broader process that goes beyond mere drawing. It includes planning, goal definition, problem-solving, considering user needs, and the practical implementation of a concept or product.
Goal-Oriented: It focuses on achieving specific results or fulfilling a goal. It may include strategic thinking, user research, functional optimization, and performance evaluation.
Involves Diverse Skills: Often requires a broader range of skills, including engineering, architecture, user psychology, sustainability, and much more.
The Process
Market and User Research:
- Analysis and Requirement Definition:
- Definition of use cases, creation of user personas.
Ideation and Conceptual Design:
- Brainstorming, Prototyping, Testing.
User Interface (UI) Design:
- Creating wireframes, visual design, creating interactive prototypes.
User Testing and Iteration:
- User testing, analysis of results, and iterations.
Development and Implementation:
- Collaboration with the development team, testing, and quality control.
Launch and Monitoring:
- Product launch, monitoring user experience.
Note: Depending on the project, some of these phases may be omitted.
Atomic Design
- Atoms: These are the basic elements of the user interface, such as buttons, text fields, icons, or colors. They are simple and reusable components that serve as fundamental building blocks in creating more complex elements.
- Molecules: These are groups of atoms that work together to form more advanced components. A data input module could be a molecule composed of an input field, a button, and a label.
- Organisms: Organisms are larger, self-contained components of the user interface. They represent complex sections of the interface, such as navigation bars, headers, or cards containing various molecules and atoms working together.
- Templates: Templates provide a basic structure for user interface pages. They define the general layout of organisms and molecules on a page but do not contain specific content.
- Pages: Pages represent concrete instances of complete user interfaces, where specific content is inserted. They are the final manifestation of the design and incorporate all other elements, from templates to organisms, molecules, and atoms.
Scrum
By Fabio Panzavolta, Founder @Collective Genious and Independent Scrum Master
Foundations
- Empiricism: Knowledge is derived from experience, and decisions are made based on facts. Transparency, inspection, and adaptation are the three pillars of empiricism.
- Lean Thinking: Creating value as quickly as possible and reducing waste.
Values
- Professional Scrum operates in an environment of Psychological Safety.
- Courage: Asserting one’s ideas, not hiding facts or product-related information, respecting Scrum principles and elements.
- Focus: Concentrating on doing only what is useful for creating value at the most opportune moment. Being fully present in every Scrum event.
- Openness: Embracing all ideas from anyone without judgment and resisting what one’s experience might suggest. Trying things that wouldn’t be tried otherwise.
- Respect: For all individuals as competent people and for all ideas and proposals useful for product improvement.
- Commitment: Always giving the best to achieve set goals, committing to respecting Scrum events.
Responsibilities
Product Owner: Responsible for maximizing the value of the product. Manages the Product Backlog.
Developers: Composed of professionals who actually create the product or service, they are self-organized and multidisciplinary, meaning they have all the skills necessary to complete the work, from design to development, testing, marketing, etc. They commit to delivering complete and potentially releasable product increments by the end of each Sprint.
Scrum Master: Responsible for the effectiveness of the Scrum Team through the correct understanding and use of Scrum. Facilitates the Scrum process, ensuring that the rules and practices of the framework are followed. Helps the Scrum team remove obstacles and solve problems that could hinder the achievement of Sprint goals, promotes continuous improvement, and fosters team growth and maturity.
Scrum Team: Composed of Product Owner, Developers, and Scrum Master, it is self-managed and cross-functional.
Artifacts
Product Backlog: Reflects the Product Owner’s strategy and is an emerging list of work to be done on the product. Contains the Product Goal.
Sprint Backlog: A subset of the Product Backlog representing activities and items selected by Developers for a specific Sprint. Contains the Sprint Goal.
Increment: A step forward towards achieving the Product Goal. Must meet the Definition of Done, meaning it is complete, tested, and ready for release.
Events
Sprint: The beating heart of Scrum, the event that contains all other events and provides the regular frequency of inspection and adaptation.
Sprint Planning: An event in which the Scrum Team collaborates to set the Sprint Goal, forecast the most important items from the Product Backlog, and define. Developers provide details of the work needed to complete at least the selected first items from the Product Backlog.
Daily Scrum: A daily event for Developers, allowing them to plan the next 24 hours and understand if the work done increases the chances of achieving the Sprint Goal.
Sprint Review: An informal and collaborative event during which the Scrum Team and Stakeholders inspect the increment and provide feedback useful for adapting the Product Backlog.
Sprint Retrospective: The Scrum Team reflects on the last Sprint, identifies what went well, and what can be improved, and plans corrective actions for the next Sprint.