Learn about TinyML.

The post What Is TinyML? first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll talk about TinyML. We’ll show how it works and present its advantages, challenges, and future.

TinyML enables the deployment of machine learning (ML) and deep learning (DL) models on small, low-power devices such as sensors and microcontrollers. This is important because it allows for developing intelligent edge devices that can process data locally without a connection to the cloud or a powerful server:

In the TinyML approach, all the steps described in the traditional approach are done on the device. This can result in faster response times, reduced latency, and improved privacy and security:

In addition, TinyML enables the development of new applications and use cases that were previously impossible due to the limitations of traditional ML approaches. For example, TinyML can be used for predictive maintenance in industrial settings, real-time health monitoring, and intelligent agriculture.

**TinyML uses specialized algorithms and techniques designed to run efficiently on small, low-power devices.** These algorithms are often based on simplified versions of traditional ML models, such as neural networks or decision trees, that can be optimized for the limited processing power and memory of microcontrollers and sensors.

Creating a TinyML model is similar to fitting a traditional ML model. First, we collect data from sensors or other sources and process them using specialized software tools. Then, we use the data to train our model.

Finally, we deploy our model on the target device, where it can analyze data in real time and make predictions (decisions) that the device is programmed to react to:

This enables various applications, from detecting manufacturing equipment anomalies to monitoring medical patients’ vital signs.

There are many techniques for preparing a tinyML model. We’ll cover two.

For example, to create a TinyML version of a neural network, we can train it on available data as in the traditional approach. Then, **we can reduce its size by rounding its parameters to the nearest 8-bit integers.** This technique is called post-training integer quantization.

**The pruning technique identifies and removes the connections and neurons with little impact on the output. **During the model training, if a particular weight gets close to zero, we remove it from the model without significantly affecting accuracy. Additionally, if a neuron consistently outputs values close to zero, we remove it from the model. As a result, we reduce the size and complexity of neural networks**.**

**TinyML can operate on small microcontrollers, enabling edge computing and reducing the need for cloud connectivity. **

If a low-power device can’t provide enough processing power or memory, then connecting to a cloud with a model is necessary.

TinyML enables low-power and energy-efficient data processing, which reduces devices’ power consumption.

We design TinyML algorithms to be lightweight and efficient, **requiring less computing power and consuming less energy.**

Instead of transmitting sensitive data to the cloud, which exposes devices to possible cyber risks like hacking and privacy violations, TinyML empowers edge devices to conduct real-time analysis and decision-making.

So, if devices are secure enough, the risk of network-based attacks is reduced.

One of the biggest challenges in TinyML is the limited memory and processing power of tiny devices. This makes it difficult to implement complex machine-learning algorithms and models.

As a result, **developers must optimize their models and algorithms to fit these devices’ constraints, which can be a significant challenge**.

This requires developers to find ways to reduce the size and complexity of their models without sacrificing performance or accuracy.

Techniques such as pruning and quantization can be used to achieve this goal. However, these methods require careful consideration and experimentation to find the best approach for a given application.

TinyML can also face security risks. Indeed, **if the devices are not adequately secured, keeping the ML models on devices can increase the risk of security breaches.** For example, if a device was stolen or lost, a hacker could access and use the ML model for malicious purposes.

Moreover, hackers could exploit software vulnerabilities to gain access to the ML model if we don’t update the device regularly with security patches.

Hardware improvements, such as developing low-power and high-performance microcontrollers, have enabled more complex models to run on tiny devices.

TinyML has a broad range of applications:

**Healthcare monitoring and diagnosing systems:**We use TinyML in medical devices to diagnose diseases, monitor patient health, and provide personalized treatment recommendations.**Self-driving cars:**In autonomous vehicles, we use TynyML to improve perception and decision-making capabilities.**Drone vision:**Today, TinyML models can be trained to detect objects such as animals, people, vehicles, or obstacles in drone footage, enabling efficient and safer navigation.**Edge computing**: TinyML brings machine-learning capabilities to edge devices such as cameras, smartphones, and drones, enabling real-time decision-making without relying on cloud services.

Here is the summary table of advantages and disadvantages of TinyML:

In this article, we talked about TinyML. Overall, TinyML allows for deploying machine learning models on small and resource-constrained devices, enabling real-time decision-making and reduced latency.

However, these devices’ limited processing power and memory can lead to decreased model accuracy.

Learn why and how Requirement Traceability Matrices (RTMs) are the cornerstone of successful software projects.

The post What Are Requirements Traceability Matrixes? first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll learn how Requirement Traceability Matrices (RTMs) serve as vital tools in software development.

Understanding their structure and application empowers teams to seamlessly track, verify, and manage requirements throughout the project lifecycle, ensuring a streamlined and successful development process.

**Requirements Traceability is paramount in ensuring that every facet of a software project aligns with the stakeholders’ vision.** RTMs serve as a bridge between project managers, developers, and testers, ensuring an unambiguous understanding of each requirement. By establishing a direct link between requirements and corresponding test cases or source code, RTMs help maintain consistency and prevent scope creep.

In large-scale projects, numerous requirements may be interdependent. RTMs provide a bird’s eye view, allowing developers to gauge the impact of a particular requirement on the entire project. This ensures that all components function cohesively. It also aids in identifying potential conflicts or redundancies, streamlining the development process.

RTMs establish a well-defined boundary for the project scope. Any deviations from the initially outlined requirements are flagged, allowing stakeholders to make informed decisions regarding changes.

This prevents the project from expanding beyond its original intent, maintaining focus on the core objectives. It also aids in resource allocation, ensuring that efforts are directed towards meeting the defined requirements.

Effective communication is the bedrock of any successful project. RTMs serve as a common language, facilitating clear and concise exchanges between stakeholders, developers, and testers. This eliminates misunderstandings and aligns everyone toward a shared goal. Additionally, it provides a historical record of discussions and decisions, aiding in resolving disputes or clarifying requirements in the future.

RTMs play a pivotal role in the validation and verification process. By cross-referencing requirements with corresponding test cases, teams can ensure comprehensive coverage. This not only validates that each requirement is met but also verifies that no extraneous functionalities are introduced.

As projects evolve, changes are inevitable. **RTMs enable efficient impact analysis, allowing teams to assess the repercussions of proposed alterations.** This informs decision-making, ensuring that modifications are aligned with project objectives and do not inadvertently introduce risks or conflicts.

In regulated industries, compliance with specific standards and guidelines is non-negotiable. RTMs provide a structured approach to documenting and demonstrating compliance. This is invaluable during audits or when seeking certification, instilling confidence in stakeholders and regulatory bodies.

Identifying and mitigating risks is a crucial aspect of project management. RTMs serve as a proactive tool in risk assessment. By understanding the dependencies and relationships between requirements, teams can anticipate potential challenges and devise contingency plans.

Within this section, we unveil a simple user story tailored for a software project. This narrative provides a glimpse into the essential requirements that will shape the project. As the development unfolds, we employ the Requirements Traceability Matrix (RTM) to meticulously monitor the project’s advancement, ensuring every requirement is meticulously addressed.

The system administrator wants to ensure that user authentication is robust and secure, allowing access only to authorized personnel, in order to safeguard sensitive data and maintain the integrity of his systems. The system should be able to generate status reports and should work across multiple platforms.

This user story encapsulates the need for a comprehensive authentication system. The Requirements Traceability Matrix (RTM) provided serves as a solution to ensure that each aspect of this user story is addressed, tracked, and tested effectively throughout the development process.

Following a thorough analysis of the user story and extensive interviews with all stakeholders, the system architect compiles a comprehensive list of project requirements. Additionally, the architect stratifies these requirements according to their significance. The following table comprises all identified requirements:

The table below provides a list of test cases (TC-001 to TC-005) along with their corresponding requirements trace and descriptions of what they are testing:

Below is an example of a simplified Requirements Traceability Matrix (RTM) based on the requirements and tests outlined above:

The table above represents a simplified Requirements Traceability Matrix (RTM) used in software development projects. Each row corresponds to a specific requirement, identified by a unique Req ID. The “Description” column provides a brief description of the requirement, while “Source” indicates where the requirement originated, whether from a user story or stakeholder interview.

The “Priority” column denotes the relative importance of each requirement, categorized as High, Medium, or Low. The “Status” column tracks the current progress of the requirement, indicating whether it’s In Progress, Pending, or Completed. Finally, the “Test Case” column establishes a link between each requirement and the associated test case(s) for comprehensive testing.

This table serves as a practical tool for project teams to ensure that all requirements are adequately addressed and tested throughout the development process.

Please note that this is a simplified example.** In a real-world scenario, the RTM would likely contain a more extensive list of requirements, along with additional details for each component.** Additionally, the RTM would evolve over the course of the project as requirements change and progress.

An RTM is an intricate framework comprising several essential elements. These components work in tandem to create a comprehensive and reliable traceability matrix.

Each requirement is assigned a distinct identifier. This ensures that no two requirements are confused, facilitating precise tracking. These identifiers are typically alphanumeric codes that provide a quick reference for stakeholders to locate and cross-reference specific requirements.

Detailed descriptions of each requirement provide a comprehensive understanding for all stakeholders, including developers, testers, and project managers. These descriptions go beyond a simple statement and may include additional context, constraints, acceptance criteria, and any other relevant information that aids in the complete comprehension of the requirement.

This component specifies where the requirement originated. It could be a user story, a stakeholder interview, or any other source that provides context. Understanding the source of a requirement helps in validating its authenticity and relevance. It also assists in future discussions or clarifications regarding the requirement’s intent.

While not always included, assigning priority and severity levels to requirements can be immensely beneficial. Priority indicates the relative importance of a requirement, guiding the development and testing teams in their focus. Severity, on the other hand, highlights the potential impact of a requirement not being met, aiding in risk assessment and mitigation.

Tracking the status of each requirement is crucial. This component indicates whether a requirement is pending, in development, under testing, or implemented. It provides a real-time snapshot of the progress of each requirement, allowing stakeholders to assess the project’s overall advancement and potential areas of concern.

**Perhaps the most critical component, traceability links establish connections between requirements, test cases, and source code.** This ensures that each requirement is rigorously tested and adequately implemented. It creates a clear lineage from the initial requirement through its various stages of development, testing, and deployment. This not only verifies that the requirement has been met but also aids in impact analysis when changes or updates are introduced.

Building a robust Requirements Traceability Matrix (RTM) is a cornerstone of successful project management. It involves a meticulous process, starting with the foundation of well-defined requirements.

In crafting requirements, each one should possess a distinct identifier. This ensures that no requirement is duplicated or misinterpreted, providing a clear roadmap for tracking and verification. **We call this maintaining uniqueness and identifiability of requirements.**

Another important aspect is ambiguity elimination. Impeccable requirements leave no room for interpretation. This aspect delves into techniques for writing unambiguous statements, thereby eliminating potential misunderstandings.

Requirements must be quantifiable and verifiable. **We must ensure that each requirement can be objectively measured and tested.**

A well-structured document forms the basis of an efficient RTM. This goes into the importance of maintaining a clear, organized, and standardized documentation format.

Document versions should be tracked meticulously to prevent confusion and ensure that all stakeholders are aligned with the most recent requirements. This requires guidance on implementing effective version control practices.

**As requirements evolve, it’s crucial to manage changes effectively.** This part explores strategies for tracking alterations, maintaining a comprehensive change log, and communicating updates to all relevant parties.

Specialized RTM software can significantly streamline the creation and management process. **Many RTM tools offer integration with other project management and development platforms.** Merely having access to RTM tools isn’t enough; ensuring that team members are proficient in their use is equally important.

Agile methodologies emphasize adaptability and responsiveness. This section illuminates how RTMs seamlessly integrate into Agile workflows.

Requirements in any project are subject to change. **RTMs excel at dynamically tracking these alterations, providing a real-time view of evolving project needs.** This ensures that every iteration aligns seamlessly with the project’s overarching goals, fostering adaptability and responsiveness.

When requirements shift, it’s imperative to understand how these changes ripple through the project. RTMs maintain clear traceability of changes, allowing stakeholders to grasp the impact and make informed decisions.

In agile development, resources are precious, and their allocation demands precision. **RTMs play a pivotal role in prioritizing requirements for each sprint.** By doing so, development efforts are concentrated on high-priority features, ensuring that the team maximizes productivity.

A well-prioritized sprint plan, derived from the RTM, ensures that development efforts are consistently aligned with the project’s broader objectives. An effectively managed RTM facilitates seamless coordination between development activities and overarching project goals.

In this article, we learned how Requirement Traceability Matrices (RTMs) are the cornerstone of successful software projects. From ensuring clear communication to preventing scope creep, RTMs offer invaluable insights. Their adaptability in Agile environments further solidifies their significance, making them a vital tool for modern project management.

The post What Are Requirements Traceability Matrixes? first appeared on Baeldung on Computer Science. ]]>Explore a quadratic algorithm for approximating the chromatic number of a graph.

The post Vertex Coloring in Graphs first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll explore vertex coloring in graphs.

A graph is a collection of nodes (vertices) and edges such that every edge joins two vertices from . For example:

We look at the problem of coloring all nodes of a loopless graph with unique colors. To clarify, a loopless graph is one in which no node has an edge connecting it to itself.

**Vertex (or node) coloring of means finding an assignment that colors each vertex so that no two neighboring vertices have the same color**. For instance:

Formally, a proper vertex coloring of is a mapping , where are colors, such that no two adjacent vertices have the same color:

If there’s a proper coloring of a graph with colors, we say that is -colorable.

We define the chromatic number of (denoted by ) as the minimum number of colors required to vertex color . In other words,** it’s the smallest such that is -colorable**.

First, for a graph where , it holds that . Second, for a complete graph , since each vertex is connected to the remaining vertices. On similar lines, where is a null graph.

Moving on, if is a sub-graph of , then . This is intuitive since would need no more colors than because has no more nodes than .

Determining the chromatic number for a generic graph is an NP-complete problem.

These problems are of great interest to computer scientists because they arise in many practical applications, but no algorithm with the worst-case polynomial complexity is known to solve them.

The nodes of a -colorable graph can be partitioned into independent sets: . Here, no two vertices in a set are adjacent to each other.

For our vertex-coloring example graph , we have , so and . Both and are independent as and .

In this section, we present a greedy algorithm for determining the chromatic number of a graph. It isn’t an exact algorithm, which means it returns an upper bound on :

We start with the given graph with .

Firstly, we set the colors of all the nodes -1 to denote that all vertices at the start are uncolored (white).

Then, we iterate over the nodes sorted by their degrees. There are options for each node in the beginning (). We disregard the colors assigned to its neighbors and give it the minimal color code remaining in .

After processing all the nodes, the algorithm returns the maximum color code as the chromatic number. Since **this is a greedy algorithm, the returned number is only an estimate** and should be treated as the upper bounds of .

The time complexity of this algorithm depends on how we implement and . If we use hash tables, the overall time complexity will be .

The space complexity is also because of the upper bound on the number of edges in a graph with nodes.

Let’s check out an example:

Initially, all the nodes are white (). Since there are seven nodes, each vertex in the main loop will start with seven available colors. Let their codes be blue=1, green=2, red=3, pink=4, black=5, brown=6, violet=7.

We start with vertex , which has the highest degree (3). Its neighbors are . All are white, so we color as blue since that’s the minimum of :

Next, we take vertex . Its neighbors are . Since is blue, we disregard the color 1 and assign the minimum of the remaining codes (2):

Now comes the turn of . Its neighbors are . The reasoning is the same as for , so we color it green:

Continuing like this, we color this graph using two colors (blue and green), which gives us .

This enables us to run various operations on graphs to solve specific problems.

Here, we consider the problem of scheduling exams in a university. Typically, we have different subjects and will have many students enrolled in each subject. Further, each student can be enrolled in more than one subject, and each subject will have more than one enrolled student.

We need to schedule exams such that no two exams with at least one common student are on the same day. Additionally, we want to schedule all exams in the minimal possible number of days. How do we solve this? Vertex coloring comes to our rescue:

We represent this problem as a graph where we model each subject as a vertex. We introduce an edge between two vertices if the corresponding subjects have at least one student in common. Then, we find the graph’s chromatic number. It’s equal to the minimum number of days necessary to schedule all the exams simultaneously without a clash.

In our example, we’ll have 8 exams over 4 days.

Another application comes from the frequency assignment to radio towers. Here, we have several towers and need to use the smallest number of frequencies for communication.

Again, we model this as a graph coloring problem where we set each tower as a vertex. Then, we construct an edge between two towers if they are in interfering range with each other. After that, we apply vertex coloring and get our chromatic number, which shows us the minimal number of frequencies we need.

In this article, we studied vertex coloring in graphs and finding the chromatic number. An excellent way to understand this problem is to consider it an optimization problem. Given a graph , we minimize the number of colors needed to color it so that no two neighbors have the same color.

This problem has diverse applications, including clustering, data mining, digital image processing, computer networks, resource allocation, unconstraint optimization, and process scheduling.

The post Vertex Coloring in Graphs first appeared on Baeldung on Computer Science. ]]>Make a school timetable by solving a constraint satisfaction problem.

The post How to Make a School Timetable? first appeared on Baeldung on Computer Science.]]>Creating a school timetable is a complex task that involves assigning classes, subjects, teachers, and classrooms to specific time slots.

It’s a classic constraint-satisfaction problem (CSP), where we search for a feasible solution that satisfies all the specified constraints.

In this tutorial,** we’ll show how to use a general-purpose CSP solver to create a school timetable.**

Creating a school timetable is essential for efficient and organized school operations:

- It helps us optimize the utilization of available resources, such as classrooms.
- A well-structured timetable provides consistency in the daily schedule of school activities.
- Well-designed timetables can accommodate extracurricular activities, such as sports, allowing students to engage in other educational experiences.

Before diving into the algorithm, let’s specify all the requirements and constraints for creating a timetable.

We need to determine the number of periods per day, the list of all subjects offered, teachers’ availability, and other factors to specify a timetable:

Let’s use the following notation:

- is the set of available lecturers
- denotes the subjects
- is the set of working days in a week ()
- denotes time slots
- is the set of classes
- is the set of classrooms

For the decision variable, we let be a binary variable that equals if a class has subject with teacher in classroom on day during the time slot . Otherwise, is zero.

Let’s describe the constraints.

Each class has a single lecturer for a particular subject:

(1)

It is specified how many times a class is taught in each subject:

(2)

Further, for each lecturer , subject , working day , and time slot , there should be at most one class in which the lecturer teaches that subject during that specific time and day:

(3)

To guarantee that for each classroom , there’s exactly one combination of lecturer, subject, working day, and time slot assigned, we require that each classroom be occupied by at most one class at any given time:

(4)

Similar to Equation (3), each lecturer can teach at most one class at any given time slot and working day:

(5)

We allow all classes to follow their lectures simultaneously:

(6)

Finally, the decision variable (representing the assignment of a lecturer, subject, working day, time slot, classroom, and subject) must be non-negative:

(7)

We designed constraints (3 – 6) with inequalities rather than strict equalities to introduce flexibility within the scheduling framework. For example, that means allowing a classroom to be empty during a period.

For simplicity, we assumed that each lecturer could teach all the subjects. However, each lecturer can teach a specific set of subjects in a real-world scenario. This doesn’t affect our approach since we can use instead of to denote the subjects that can teach.

We can use a general-purpose CSP solver:

We only have to feed it the variables and constraints specific to this problem.

In , we use a value-ordering heuristic. For instance, when assigning a class or classroom to a particular time slot or teacher, we prioritize those imposing the fewest constraints on the available options for other time slots and related variables.

does forward checking. For example, when a subject is assigned to a time slot in a day and a class, we remove it from the remaining set of subjects that must be scheduled for that class. If it detects a variable has no options, we know we have to backtrack on the current assignment.

Finally, in , we prioritize variables with the fewest available values.

Let’s use the following example:

stands for senior high school.

We start with Monday, assigning to the two classrooms two teachers and subjects to two classes of students in the first time slot. Continuing like this, we get our solution. Here’s the timetable for class :

Here’s the schedule for ::

In these timetables, we ensure that the two classrooms are occupied in every time slot, with no overlapping lectures. All the other constraints are also satisfied.

Any feasible timetable will do if we’re only concerned with satisfying constraints. However, there are reasons we may prefer one timetable over another. For example, teachers can ask not to have free gaps. So, a schedule where each lecturer holds classes consecutively will be preferred to the one in which there are many periods that teachers sit out between classes. Alternatively, we may want students not to take similar subjects one after another.

We don’t include such requests as constraints because the algorithm can treat many acceptable timetables as infeasible. Instead, **we formulate an objective function that evaluates each schedule and indicates which is better.** Optimizing it via our algorithm will give us a feasible solution that considers our preferences.

Let’s check out some examples.

To calculate classroom utilization, we can count the number of time slots the -th classroom is assigned and compute the utilization rate:

(8)

Then, the average classroom utilization rate () will be :

(9)

In our example, the utilization rate is 1.0.

Balancing teacher workloads ensures that no teacher is overburdened with too many classes while others have too few. To calculate teacher workload balance, we can compute the standard deviation of the number of classes taught by each teacher:

(10)

where is the number of classes taught by the -th teacher, and is the number of teachers.

If all the teachers have approximately the same workload, the deviation will be close to zero, indicating a balanced schedule.

We could try to distribute their teaching assignments evenly throughout the week. Balancing teachers’ workload by day aims to achieve a schedule where each lecturer teaches approximately the same number of classes daily. An uneven distribution of classes can lead to stressful peaks in a teacher’s schedule.

Creating a school timetable is a complex problem that can be effectively solved as a constraint-satisfaction problem. There are many tools for constraint-satisfaction solving, so all we have to do is formulate the constraints according to our needs.

The post How to Make a School Timetable? first appeared on Baeldung on Computer Science. ]]>Learn what Infrastructure-as-a-code means.

The post Infrastracture as a Code first appeared on Baeldung on Computer Science.]]>In recent years, Infrastructure as Code (IaC) has become an evolving trend in modern software development.

In this tutorial, we’ll describe IaC in detail, explore its fundamental principles and approaches, and understand why it’s so valuable for modern IT.

First, we can trace the roots of Infrastructure as Code to the rapidly changing landscape of software development and IT operations. With the advent of agile methodologies and DevOps practices, traditional infrastructure management methods showed limitations. Manually configuring servers and networks couldn’t keep pace with the dynamic requirements of modern applications.

So, at its core, **Infrastructure as Code is about treating infrastructure: servers, networks, and databases, as something DevOps can control and manage through code:**

Using IaC, we represent, configure, and maintain our infrastructure using code, scripts, or declarative language. That way, we avoid manual, error-prone, and time-consuming configuration.

We introduced Infrastructure as Code in the previous section and underscored its significance in modern IT environments. Now, let’s describe the key concepts that underpin IaC. Understanding these concepts is essential for grasping the foundations of IaC and comprehending its impact on infrastructure management.

At the heart of this approach is treating infrastructure as code. This concept fundamentally transforms infrastructure components’ definition, configuration, and management. Therefore, individuals represent and manipulate infrastructure using code or scripts instead of manually configuring servers or network devices.

**In an IaC environment, the code becomes the single source of truth for infrastructure.** This means that the code entirely defines the current state of the infrastructure, and any changes to the infrastructure must occur through code modifications. Thus, this approach eliminates configuration drift, where discrepancies between the desired and actual infrastructure configurations can occur over time.

There are two primary approaches to implementing IaC: declarative and imperative.

**Declarative IaC** **defines the desired end state of the infrastructure without specifying the steps to achieve that state.** This approach is often likened to describing what organizations want, and the chosen IaC tool determines how to make it happen.

**Imperative IaC**, **on the other hand, involves specifying the exact steps or commands to reach the desired state.** Thus, it’s akin to providing explicit instructions on achieving a specific configuration.

The choice between declarative and imperative approaches depends on factors like the complexity of the infrastructure, the specific IaC tool in use, and the preferences of the development and operations teams.

This section will explore practical steps and best practices for successfully adopting IaC, laying the foundation for efficient infrastructure management.

**Firstly, before embarking on the IaC path, the organizations must comprehensively assess the infrastructure requirements.** Then, they should examine the current infrastructure landscape and identify pain points, scalability needs, and areas where automation can bring improvements. This analysis serves as the foundation for shaping their IaC strategies.

Secondly, we must choose the appropriate IaC tools based on the technology stack. **Community support, documentation, and integration capabilities must be considered.** Tools like Terraform, Ansible, and AWS CloudFormation offer unique advantages and can significantly impact IaC’s success.

Furthermore, the organization must create version-controlled IaC templates or scripts that blueprint infrastructure components and configurations.

Maintaining version control ensures systematic tracking, testing, and documentation of changes, facilitating collaboration among team members.

The organization should promote collaboration among development, operations, and infrastructure teams. It should **define clear roles and responsibilities for IaC tasks to align everyone toward the common goal** of efficient infrastructure management. A collaborative approach is essential for success.

Then, we need to integrate CI/CD pipelines to automate the deployment of IaC templates. These pipelines streamline testing and deployment processes, reducing the risk of errors and ensuring template compliance. That way, we get a more reliable infrastructure.

Finally, **we should monitor the organization’s infrastructure for deviations from defined templates**. Regularly updating templates to adapt to changing requirements ensures a responsive and adaptable infrastructure. Proactive maintenance minimizes disruptions and enhances overall operational efficiency.

Here’s the workflow of the IaC development process:

The steps are:

**Writing IaC Code.**We translate the design into IaC code using tools like Terraform or Ansible.**Version Control and Collaboration.**We Manage code changes and collaborate using version control systems like Git.**Testing and Validation**. The team ensures the code functions correctly, adheres to security standards, and meets compliance requirements.**CI/CD Integration.**This involves pushing and pulling the IaC code to the Automation API server using CI/CD pipelines.**Deployment and Scaling.**We deploy infrastructure as defined in the code and scale as needed.**Monitoring and Maintenance.**Finally, we continuously monitor and manage infrastructure, updating code as required.

IaC offers numerous benefits but also poses particular challenges.

Firstly, **one of the standout advantages of IaC is efficiency**. With IaC, infrastructure configurations are codified, allowing for rapid and automated provisioning. This means that instead of manually configuring servers, networks, or databases, we can define the infrastructure as code and let automation tools handle the rest. This speeds up deployments, reduces human error, and enhances overall productivity.

Secondly, **IaC brings consistency to infrastructure management**. Since configurations are defined in code, they are consistent across environments. Whether deploying to development, testing, or production, we ensure that the configurations remain the same, reducing the chances of discrepancies and enhancing reliability.

Moreover, IaC promotes version control. Just like application code, **infrastructure code can be stored in repositories, allowing for easy tracking of changes.** Teams can roll back to previous configurations if needed, improving traceability and auditing.

Furthermore, **IaC supports scalability and flexibility.** As organizations grow, they can easily replicate infrastructure components by reusing code. This flexibility ensures that infrastructure can expand to accommodate increasing demands.

Lastly, **IaC lets us rebuild the entire infrastructure quickly in case of an unexpected failure**. This means less downtime and more peace of mind for the team.

However, it’s essential to consider the challenges that come with IaC.

First and foremost, **the initial adoption of IaC can be complex**. Teams need to become proficient in the tools and practices associated with IaC, which may require training and skill development.

Secondly, **maintaining IaC can become cumbersome if not done correctly.** As our infrastructure code grows, it must be well-organized to remain manageable. Otherwise, it can become as intricate as the infrastructure it manages.

Moreover, there might be resistance to change within organizations. Teams accustomed to traditional infrastructure management methods may be reluctant to embrace IaC. A cultural shift may be required to leverage the benefits fully.

Furthermore, while IaC enhances efficiency, **an erroneous change in the code could lead to the rapid propagation of mistakes across the infrastructure**, necessitating thorough testing and safeguards.

Let’s summarize the advantages and disadvantages of IaC:

Different tools and practices may be better suited to specific use cases. Therefore, before choosing IaC, organizations must consider many factors before choosing the right strategy.

In this article, we described Infrastructure as a Code (IaC) in detail. IaC offers efficiency, consistency, and agility but demands careful consideration.

Efficiency and scalability make IaC compelling, but complexity, maintenance, and cultural shifts can be time and resource-consuming.

Infrastructure as a Code isn’t a universal solution for every project or organization.

The post Infrastracture as a Code first appeared on Baeldung on Computer Science. ]]>Explore the Length Extension Attack.

The post Length Extension Attack first appeared on Baeldung on Computer Science.]]>In this tutorial, we delve into the intricate concept of the Length Extension Attack, aiming to demystify its intricacies and reveal its paramount significance within the domain of cybersecurity.

As we explore this topic, we’ll uncover how Length Extension Attacks substantially threaten the integrity of cryptographic systems and data security, highlighting the crucial need for a comprehensive understanding of this attack vector in today’s digital landscape.

A Length Extension Attack is a sophisticated cryptographic exploit that targets hash functions, taking advantage of their predictable nature.

In this type of attack, an adversary extends the length of a hashed message without knowing the original input. Consequently, this deceptive technique can have severe implications in systems that rely on hash functions for security, potentially compromising data integrity and authentication mechanisms.

Length Extension Attacks’ concern stems from their potential to undermine cryptographic security protocols.

**Since hash functions are a fundamental component of many cryptographic applications, such as digital signatures and password storage, a successful Length Extension Attack could lead to unauthorized access, data manipulation, or other security breaches.**

Therefore, recognizing the gravity of this threat is essential for designing robust security measures.

Length Extension Attacks are a sophisticated form of cryptographic attack that can seriously affect security.

Let’s see a few examples to illustrate how these attacks work.

Suppose a web application uses HMAC (Hash-based Message Authentication Code) to verify the integrity of messages. An attacker intercepts a legitimate message and its corresponding HMAC, both sent as part of a request.

They then craft a malicious extension to the message, append it to the legitimate message, and calculate a valid HMAC for the extended message without knowing the secret key. Unaware of the attack, the server accepts the tampered message as legitimate.

In a scenario where user passwords are hashed before storage, an attacker obtains their password hash. They then extend the hash by appending additional characters to it, effectively creating a new hash for a different password without knowing the original password. The attacker can gain unauthorized access if the system accepts this extended hash as valid.

Let’s consider a system that uses cryptographic authentication tokens to grant access. An attacker captures a valid token and extends it with malicious content. They then present the extended token to the server, which, if not properly protected against Length Extension Attacks, might accept it as legitimate and grant unauthorized access.

Length Extension Attacks can also target digital signatures. An attacker who intercepts a digitally signed message can extend it with additional content while keeping the original signature intact. If the recipient doesn’t verify the length of the message properly, they may accept the tampered message as valid.

These examples demonstrate how Length Extension Attacks can compromise data integrity, authentication systems, and cryptographic security.

Protecting against such attacks requires using secure hash functions, following best practices for HMAC usage, and implementing thorough input validation and length checking in applications that rely on cryptographic operations.

Due to their design and properties, certain hash functions are more vulnerable to Length Extension Attacks. For instance, hash functions like MD5 and SHA-1, which lack collision resistance, are particularly susceptible.

To identify hash functions vulnerable to Length Extension Attacks, we follow these steps:

**Identifying vulnerable hash functions involves research, cryptographic analysis, and staying updated with developments in the field, enabling informed choices for secure cryptographic operations.**

Mitigating Length Extension Attacks is vital for cryptographic system security and integrity. These attacks exploit predictable hash functions, enabling unauthorized access and data tampering.

Here’s a concise overview of mitigation strategies:

**Mitigating these attacks strengthens cryptographic system integrity and security.**

In this article, we explored the Length Extension Attack—a sophisticated cryptographic exploit that poses a significant threat to systems relying on hash functions for data integrity and security.

**Understanding this attack’s mechanics is crucial for robust security measures, helping safeguard against potential breaches.** By recognizing its vulnerabilities and implications, security professionals and developers can bolster cryptographic protocols, fortifying sensitive information protection in today’s interconnected digital landscape.

Learn how to convert from radians to degrees and vice versa.

The post How to Convert Radians to Degrees and Vice Versa? first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll review two standard angular units: the degree and the radian. First, we’ll provide their mathematical definitions. Then, we’ll explain how to convert radians to degrees and vice versa.

**The degree is a unit of angular measurement defined as 1/360 of a round angle**. It isn’t the recommended angle unit in the International System of Units (SI) but is commonly used in geometry. The symbol denotes the degree unit.

The precise reason behind selecting degrees as the unit of measurement for rotations and angles remains uncertain. One hypothesis suggests a connection to the fact that 360 is roughly the number of days in a year.

**The radian is the angular unit in the SI**. To define the measure of angles in radians, we consider a circumference with center and radius . Let’s observe an angle in the center. Such an angle subtends an arc of length :

The ratio of the arc length and the radius represents the measure of the angle expressed in radians, i.e.:

(1)

**Being the ratio between two lengths, the radian is a dimensionless quantity**.

We can see its meaning in its definition. If we consider an angle equal to 1 radian, the corresponding arc length will equal the radius:

(2)

In other words, **the radian is the angle subtended at the center of a circle by an arc whose length is equal to the circle’s radius**.

The symbol denotes the radian unit, but angles without any specified unit are generally assumed in radians.

**The following mathematical proportion is fundamental for the conversion between radians and degrees**:

(3)

where denotes an angle expressed in radians and the corresponding one expressed in degrees.

**Given the angle in radians** **, the corresponding angle in degrees can be calculated as**:

(4)

Conversely, **to convert an angle in degrees** **to radians we compute**:

(5)

Now, let’s express the angle of 1 in degrees:

Similarly, let’s convert to radians:

Whether to use radians or degrees to express angles depends on the context.

**In everyday life, people prefer degrees to radians**. Also, degrees are more common when dealing with angles related to building and design in fields such as engineering, construction, and architecture. The degree is also the standard unit for measuring latitude and longitude in geography.

However, radians can simplify many mathematical formulas and calculations. So, we use them more often in physics and trigonometry. For example, the radian is the natural unit for measuring angles when working with circular motion.

In this article, we reviewed the mathematical definitions of the degree and radian, the most common units for angular measurement in geometry. We explained that a simple mathematical proportion allows us to convert radians to degrees and vice versa. Radians are SI units for angles and are more used in maths and physics, whereas we prefer degrees in other fields and everyday life.

The post How to Convert Radians to Degrees and Vice Versa? first appeared on Baeldung on Computer Science. ]]>Learn about the open-source movement.

The post Open Source Explained first appeared on Baeldung on Computer Science.]]>We’re used to seeing the term “open source” frequently. But what does it mean? What’s the difference between open-source and free software? What are some examples of open source?

In this tutorial, we’ll first define what open source means. Then, we’ll discuss its history and check some examples, followed by the difference between open and free software. Finally, we’ll discuss how the open-source movement works and how to contribute to such projects.

We say a software tool is open source if its source code is publicly available and open to everyone to **modify, study, and freely distribute it.**

Usually, such code is developed by several contributors in a collaborative and public environment. As a result, we can access the code, adapt it to our needs, and share our modifications with the rest of the world.

So, the open-source concept is more than a license to change and use code. **It’s a decentralized way of developing and maintaining software.**

But how did this movement start?

Around the 1950s, IBM released some source codes of their programs, and that was one of the first demonstrations of the open-source approach.

Another relevant example is the ARPANET, which led to the Internet as we know it today. In this initiative, researchers shared feedback to build safe telecommunication protocols in the 1960s.

But we can’t talk about open source without mentioning the game-changer Linux. It’s the most significant and most used open-source software in the world.

The birth of Linux dates back to the 1990s with Richard Stallman. He developed a set of tools within the framework of the GNU project that Linus Torvald later used to create Linux.

By doing so, he challenged the way software companies used to sell operating systems. Instead of a company selling proprietary software with after-sales support, anyone could create their own Linux distribution. That was precisely what happened.

Since its inception, Linux has been a free, open-source operating system under the GNU General Public License (GPL). GNU allows us to run, modify, and share the source code. However, we should remember that **any modification to a GPL-licensed code must be distributed under the same license.**

The workflow of an open-source project mainly happens in a repository. This repository can be found in (Git-based) collaboration platforms such as GitHub.

We can access the source code on these platforms, suggest improvements, and report bugs. But, to efficiently develop software as a community, we need a well-defined workflow system.

Let’s say we want to contribute to an open-source project by fixing a bug.

First, we must locate the corresponding code repository and clone the source code to our computer. Then, we locally change the code to fix the problem. This won’t affect any other user since we change it on our computer.

Now, we need to incorporate our local update with the public source. On GitHub, that means making a pull request. Afterwards, **a committer evaluates our update.** That’s usually a very experienced user and developer of the open-source code. We, as contributors, wait to see if our request is approved.

Our change will be approved if we provide enough information about the bug and our solution is clear. Consequently, the source code of the program will be updated, and all the other users will be able to get the latest version with our code:

So, a good way to join the open-source movement is to start reporting and fixing bugs in a repository of an open-source tool.

As an open-source project grows and attracts more and more contributors, we usually create a foundation. **A foundation manages pull requests, releases, and the source code. **

Examples are the Linux Foundation and the Eclipse Foundation.

Researchers found that most foundations had two things in common: providing legal support and offering users expert help. However, an open-source project must reach a level of maturity before establishing its foundation.

Further, although they play a crucial role in the open-source movement, foundations might differ depending on the project. Also, not every foundation has governance, development, or code of conduct guidelines.

Can we have the strengths of open-source and proprietary software in the same world? This is precisely what mixed-source strategies are about.

One of the best examples is the Red Hat Enterprise Linux (RHEL). Its kernel and related software are open-source. However, the Red Hat company offers support and additional services for branded versions sold under paid licenses.

So, we can say that RHEL is a Linux distribution for commercial use and production, with its kernel being open source but merged with licensed elements.

Another thing we can discuss is the difference between open-source and free-source software. Free software posits that proprietary software controls users. As a result, developers control the software, putting the user in an unfair situation.

Let’s begin by clarifying a common misunderstanding. First, when discussing free software, we’re not talking about price. **Free software is a concept that involves a broad vision of freedom and sets it as a high priority. **It considers freedom as a fundamental value of users and the community. Free software doesn’t impose constraints or restrictions on users, such as demanding a changelog for any modifications to the source code.

But what about open-source? Stallman himself stated that open-source and free software aren’t the same. **Open source cares about practical advantages and doesn’t consider the principles such as freedom.** It’s a concept more pragmatic and less based on a vision. For instance, open-source software tools can impose constraints on users. One example of these constraints is requiring users to use a specific license when releasing the software they derived from open-source code. This affects permissions, and failing to comply with this can lead to legal problems. Another example is forbidding third-party software to be incorporated into an open-source code. In contrast, that could never happen with free software.

**Free software can be considered open-source, but not all open-source programs are free. **The operating system Linux is an excellent example of free software. We can run, study, modify, and redistribute its code.

On the other hand, NASA released many open-source software tools that aren’t considered free. NASA allows a user to modify those tools’ codes only if the entire modification is implemented from scratch by the user. That means that changes using a third-party code are forbidden. However, that restriction means the NASA’s tools aren’t free.

Let’s summarize the benefits and shortcomings of the open-source approach:

In this article, we presented the history of open-source software with examples, Linux being the most prominent one. We also explained how to contribute to the movement, starting with a pull request that can be later integrated into the source code.

Later on, we highlighted the differences between open-source and free software. While open-source stands for practical licensing aspects in releasing software, free software incorporates a broader view of freedom to the user. According to this view, no restrictions can be imposed on the user for a source code to be considered free.

The post Open Source Explained first appeared on Baeldung on Computer Science. ]]>Learn what happens when a process or a thread is about to release the CPU.

The post Context Switches in Operating Systems first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll learn about context switches.

Most modern operating systems have a process or task scheduler, which** schedules the execution of various available tasks by allocating the CPU time**. Furthermore, each process stores information about its state, which we call its context.

When it’s time for a running process to release the CPU, we need a robust and fail-safe way to remove the CPU from the currently running process and allocate it to one of the waiting processes. This means we have to save its state to execute it from that point at a later time.

Similarly, a switch happens when a thread within the running process yields the CPU to another thread.

A context switch can occur mainly for three reasons:

The first case is when the time allocated to the currently running process or thread is over, and we need to free the CPU to give it to one of the waiting processes (or threads).

The second case is the invocation of a kernel function during program execution. For instance, sending a SIGKILL interrupt signal to the OS will free the CPU by killing the running process.

Finally, a higher-priority task can preempt the currently running one.

We can define a context switch as a system event in which the operating system or the OS removes the executing job from the CPU and allocates it to another task. It involves saving the context of the switched-out process (or thread) and loading the context of the one taking over. The OS ensures a switch is seamless, fast, and free from conflicts or dependency. **Thus, context switching is vital ****for multitasking and user responsiveness.**

The state contains the extended instruction pointer (EIP), the content of used general purpose registers (GPR), the specific segment registers, the control register (), the paging table entries, etc. As evident from this list, the context switch operation involves the read/write of a large amount of data, so it is one of the most costly OS operations.

In most modern operating systems, we represent a process by a uniform data structure called the process control block or PCB. **A PCB stores the context of a process**: the user address space contents, the contents of hardware registers, and its related kernel data structures. So, **the context of a process is the concatenation of its user-level, register, and system-level contexts.**

A user-level context consists of the process text, process statistics, file and lock descriptors, data, user stack, and shared memory that occupy the process’s virtual address space. The system level contains the process table record, kernel stack, the mapping table from virtual memory to physical memory, etc. Finally, the register context contains the hardware registers for that process. It includes the program counter, process mode, stack pointer, and the data generated by the process during its execution.

On the other hand, when context-switching a thread, we need to store only their private data because they share a lot with other threads from the same process. So, switching them is easier and faster.

Let’s understand the flow of context switching through an example:

Initially, we have task running. Let’s say its time quota expires or we receive an interruption. That triggers a context switch.

First, we save the context of . Then, we free the CPU from . Afterward, we load the context of another task and let it run.

We can do context-switching using hardware and software.

In this method, the processor core includes a unique data segment called the task state segment or TSS.

A hardware switch is implemented as a jump instruction to the specified TSS descriptor in the system-level descriptor table. Although the hardware realizes most of the instructions, this method is slower than the software method. This is so because it saves almost all registers.

This is the dominant method of context switching. Here, the operating system uses kernel routines and data structures for saving and restoring the context.

This method offers us the advantage of speed and consistency. It copies only those registers the task will need once it gets the CPU again. It uses kernel routines and data structures that are fast and data-consistent.

In this article, we presented context switching in modern-day operating systems.

Each process has its context, which contains the data describing its state, such as program counters, CPU registers, and open file descriptors. In a context switch, the OS saves the context of the running process, detaches it from the CPU, and loads the context of a new process. This way, the new process starts executing. Once the old process gets its turn again, the OS loads its saved context and starts running on the CPU. **We need efficient, fast, seamless context switching to support multiprocessing and low latency.**

Learn about confidence intervals.

The post Confidence Intervals first appeared on Baeldung on Computer Science.]]>In this tutorial, we’ll explain confidence intervals and how to construct them.

Let’s introduce them with an example.

Let’s say we want to check if volleyball or basketball has a greater influence on people’s heights. The only way to be sure about the answer is to measure the heights of all professional and amateur volleyball and basketball players worldwide, but that’s impossible.

Instead, we can visit local sports clubs and measure their players’ heights. That way, we get two samples of measurements. For instance (centimeters):

The mean heights in the sample are:

Would it be justified to claim that basketball players will grow taller than those who prefer volleyball? The caveat is that we could have gotten different results had our samples been different. That’s why it isn’t sufficient to compute sample means and proportions. We also have to quantify their uncertainty.

**Confidence intervals do just that: they show us the range of plausible values of a population parameter** given the one we calculated using a (much smaller) sample.

Let’s start with an informal definition.

Let be the unknown value of a numeric parameter, population-wise. For instance, the average heights of volleyball and basketball players or the proportion of a presidential candidate’s voters in a country’s electorate.

We can estimate only by analyzing samples. So, let be a sample, and the value calculated using .

A confidence interval for , given , is a range of values obtained through a procedure with a predefined coverage (or confidence). **The confidence expresses the probability that an interval (produced by the procedure) contains the exact value of the parameter.**

Let’s step back for a second. Why do we say that confidence is a characteristic of the procedure and not a specific interval?

That’s because **confidence intervals are a tool of frequentist statistics.** We differentiate between random and specific (or realized) samples in it.

A specific sample contains specific values; examples are the samples of volleyball and basketball players’ heights.

In contrast, a random sample comprises random variables (denoted as ). Each variable in a random sample models a possible value that a specific sample can contain.

Therefore, specific samples are realizations of the corresponding random samples.

When we apply the formula for to a random sample , we get a random variable called an estimator. Let’s denote it with . For the average value, is:

In contrast, applying the formula for to a realized sample results in a specific sample value we’ll denote as . In our example with heights, the means 189.95 and 193.9 are sample values (means), i.e., realizations of the estimator.

Now, we’re ready for the formal definition.

A confidence interval with the confidence level of , where , for the parameter whose true value is , estimator is , and the sample value is , is a range of values such that:

where:

- and depend on and the distribution of
- The probability is calculated using the distribution of

So, **if we apply the procedure outputting 95% CIs to many different samples, approximately 95% will contain the actual value of the parameter of interest.**

Since the probability is in the equation only through the random sample, we can ascribe the confidence level to the procedure outputting the intervals and not to any specific interval it produces.

In our example, is the mean of independent and identically distributed random variables. Its standardized form:

where is the sample standard deviation (also an estimator), follows the Student’s t distribution with degrees of freedom. Let be its quantile, i.e.:

Since the Student’s distribution is symmetric, we also have:

So, the probability for to fall between and is :

Manipulating the expression between the curly braces, we get:

That’s our confidence interval.

We’ll focus on two cases: comparing the parameters of two populations and comparing one population’s parameter to a predefined value.

When we compute the 99% confidence intervals for our height means, we get for volleyball and for basketball:

The interpretation is that the data aren’t conclusive. So, we can’t conclude which sport influences growth better by considering only those two samples. There’s a chance that the actual means are the same or close to one another, although the sample means differ.

Another way we can take is to compute the pairwise differences:

and check if the confidence interval of the mean difference contains zero. If it does, we can’t rule out that the actual means (in the entire population of volleyball and basketball players) are the same.

This shows an everyday use case of confidence intervals. Usually, there’s a value with a special meaning. For example, the 50% accuracy at guessing binary labels in a balanced set amounts to random classification. So, if the confidence interval of our classifier’s accuracy contains this value, we can’t claim it’s undoubtedly better than a random classifier.

Confidence intervals quantify uncertainty inherent in the sampling procedures, and their confidence level guarantees that they rarely miss the population values. So, it’s justified to use them since they capture the actual values most of the time. The exact meaning of “most of the time” and “rarely” are implied by our choice of .

However, confidence intervals are complex to understand. It isn’t easy to grasp why confidence levels refer to the procedures constructing the intervals rather than the intervals themselves. Further, does it make sense to consider the unseen data (modeled by random samples) to make inferences after observing a specific sample?

The Bayesian school of thought deems this counterintuitive and wrong. Its alternative is what we call credible intervals. Unlike their frequentist counterparts, credible intervals contain the actual values with the predefined probability. However, the nature of that probability is different. For Bayesians, the probability is a degree of belief. For frequentists, it’s the long-term frequency of an event occurring.

Let’s say two intervals don’t overlap or an interval doesn’t contain a value corresponding to a no-effect state (e.g., zero when comparing differences). In that case, we say we have a statistically significant result.

However, statistical significance is not the same as proof beyond doubt. For instance, if the height intervals didn’t overlap, we couldn’t be 100% sure that the population mean heights differ. Sampling is random, so **we always have to account for the chance that our conclusions are due to randomness.** Mathematically, that’s implied by our confidence being lower than 100%.

Replication is needed to accumulate enough evidence. If many studies analyzed basketball and volleyball players’ heights and got non-overlapping intervals with a mean difference of 2 cm, it would be justified to conclude that these two sports have different effects on height.

However, that wouldn’t mean the finding is scientifically significant or useful. The height difference of 2 cm isn’t that big. There’s hardly anything an 189 cm tall person can do that a 187 cm tall one can’t. So, **we have to consider the effect size in addition to statistical significance.**

In this article, we talked about confidence intervals. They quantify uncertainty but are easily misinterpreted. **The confidence denotes the long-term frequency of intervals containing the actual value,** not the probability that our specific interval contains it.