DEV Community: freelancing

Designing a Privacy-Conscious Appointment Reminder

freelancing — Thu, 29 Oct 2026 13:29:10 +0000

Appointment reminders are a common feature in scheduling applications. Although the idea seems simple, a reliable reminder service needs to handle time zones, duplicate messages, cancellations, and personal information carefully.

In this tutorial, we'll explore a small scheduling function and the design decisions needed to turn it into a production feature.

1. Define an Appointment

Start with a minimal data structure.

const appointment = {
  id: "APT-204",
  startAt: "2026-11-02T09:30:00+11:00",
  status: "confirmed",
  reminderSentAt: null
};

The example intentionally excludes names, contact details, diagnoses, and treatment information.

2. Check Whether a Reminder Is Due

function isReminderDue(
  appointment,
  now,
  leadTimeMs
) {
  const appointmentTime = Date.parse(
    appointment.startAt
  );

  if (!Number.isFinite(appointmentTime)) {
    return false;
  }

  if (appointment.status !== "confirmed") {
    return false;
  }

  if (appointment.reminderSentAt !== null) {
    return false;
  }

  const remaining = appointmentTime - now;

  return remaining > 0 && remaining <= leadTimeMs;
}

The function checks whether an appointment is confirmed, has not already been marked as reminded, and falls within a configured time window.

This is a simplified example. A production scheduler also needs to handle malformed records and define how reminder state is updated.

3. Avoid Duplicate Messages

A common mistake is checking whether a reminder has been sent and then sending the message in a separate step.

If two workers process the same appointment simultaneously, both might observe that the reminder has not been sent.

A production implementation should use an atomic database operation, transaction, or job-claiming mechanism to prevent concurrent workers from sending duplicate reminders.

Retries also need careful handling. A message provider may accept a request even when the application does not receive the expected response.

4. Keep Notification Content Minimal

A reminder might say:

"You have an appointment scheduled for Monday at 9:30 AM. Please contact the practice if you need to change your booking."

Avoid including sensitive details unless they are necessary and appropriately authorised.

Consider shared devices, notification previews, and whether the recipient has consented to the selected communication channel.

5. Protect the Entire Workflow

A secure reminder system should consider authentication, least-privilege access, encrypted communication, secret management, data retention, and operational logging.

Logs should contain enough information to diagnose delivery problems without unnecessarily exposing personal information.

Requirements depend on the jurisdiction and application. A real healthcare-related system should receive an appropriate privacy and security review before deployment.

Conclusion

Appointment reminders illustrate an important software engineering principle: a feature that appears simple to users can require careful design behind the scenes.

By considering duplicate prevention, scheduling, data minimisation, and access controls from the beginning, developers can build systems that are more reliable and respectful of user privacy.

Building a Loan Repayment Calculator with JavaScript

freelancing — Thu, 29 Oct 2026 13:28:42 +0000

A loan calculator is a useful project for learning how to combine mathematics, input validation, and frontend programming.

In this tutorial, we'll implement a monthly repayment function for a loan with a fixed interest rate and regular monthly repayments.

The example is for educational purposes. It does not include every fee, product condition, or circumstance that can affect a real loan.

1. Understand the Formula

For a loan with a positive monthly interest rate, the standard repayment formula is:

[
M = \frac{P r(1+r)^n}{(1+r)^n-1}
]

Where:

(M) is the monthly repayment.
(P) is the principal.
(r) is the monthly interest rate as a decimal.
(n) is the total number of monthly repayments.

For a nominal annual interest rate expressed as a percentage:

[
r = \frac{\text{annual rate}}{100 \times 12}
]

When the interest rate is zero, the principal can simply be divided by the number of repayments.

2. Implement the Function

function calculateMonthlyRepayment(
  principal,
  annualRatePercent,
  years
) {
  const values = [principal, annualRatePercent, years];

  if (!values.every(Number.isFinite)) {
    throw new Error("Inputs must be finite numbers.");
  }

  if (
    principal <= 0 ||
    annualRatePercent < 0 ||
    years <= 0
  ) {
    throw new Error("Invalid loan inputs.");
  }

  const months = years * 12;

  if (!Number.isInteger(months)) {
    throw new Error("The term must produce whole months.");
  }

  const monthlyRate = annualRatePercent / 100 / 12;

  if (monthlyRate === 0) {
    return principal / months;
  }

  const growth = Math.pow(1 + monthlyRate, months);

  return (
    principal * monthlyRate * growth / (growth - 1)
  );
}

The function validates its inputs and handles a zero interest rate separately.

3. Try an Example

const payment = calculateMonthlyRepayment(
  400000,
  6,
  30
);

console.log(payment.toFixed(2));

This example assumes a principal of $400,000, a nominal annual interest rate of 6%, and a 30-year term. The output is an estimated monthly repayment before additional costs.

4. Add Unit Tests

Basic tests help confirm that the function behaves as expected.

console.assert(
  calculateMonthlyRepayment(1200, 0, 1) === 100
);

console.assert(
  calculateMonthlyRepayment(400000, 6, 30) > 0
);

console.assert(
  calculateMonthlyRepayment(400000, 6, 30) < 400000
);

For a real project, use a test framework such as Vitest or Jest and verify results against independently calculated examples.

5. Production Considerations

A production calculator should account for input formatting, currency precision, fees, rate changes, and the actual repayment rules of the relevant loan product.

Also validate empty form fields explicitly. In JavaScript, converting an empty string with Number() produces zero, which can create unexpected behaviour if the form does not distinguish empty input from a genuine zero.

For financial software, make assumptions visible rather than presenting an estimate as a guaranteed repayment amount.

Conclusion

A loan calculator is a practical example of how mathematical logic becomes a working web feature.

By separating the calculation from the user interface and testing edge cases, developers can create code that is easier to understand, maintain, and extend.

Analysing Swimming Pool Sensor Data with Python

freelancing — Thu, 29 Oct 2026 13:28:15 +0000

Analysing Swimming Pool Sensor Data with Python

IoT systems often collect measurements from the physical world and transform them into useful information. Swimming pool monitoring is one example: a system might record water temperature, pH measurements, and equipment status.

Before building a dashboard, developers need a reliable way to validate and process those readings.

In this tutorial, we'll create a small Python program that analyses simulated pool sensor data.

1. Define Sample Readings

readings = [
    {"temperature": 27.4, "ph": 7.3},
    {"temperature": 28.1, "ph": 7.4},
    {"temperature": 27.8, "ph": 7.2},
    {"temperature": None, "ph": 7.3},
    {"temperature": 29.0, "ph": 7.5}
]

These values are simulated for demonstration. They are not live measurements or recommendations for pool water treatment.

2. Validate the Data

A sensor may send incomplete data or values that cannot be processed safely.

import math

def valid_reading(reading):
    temperature = reading.get("temperature")
    ph = reading.get("ph")

    for value in (temperature, ph):
        if not isinstance(value, (int, float)):
            return False

        if not math.isfinite(value):
            return False

    return True

This function checks that both values are numeric and finite. A real application should also validate expected ranges, units, timestamps, and sensor identity.

3. Filter Invalid Records

valid_readings = [
    reading
    for reading in readings
    if valid_reading(reading)
]

print("Total records:", len(readings))
print("Valid records:", len(valid_readings))
print("Rejected records:", len(readings) - len(valid_readings))

Rejecting invalid records prevents missing measurements from accidentally being treated as zero.

However, invalid readings should not simply disappear in a production system. Logging them can help identify failing sensors or communication problems.

4. Calculate an Average

def average_temperature(records):
    if not records:
        return None

    values = [
        record["temperature"]
        for record in records
    ]

    return sum(values) / len(values)


average = average_temperature(valid_readings)

if average is None:
    print("No valid temperature data.")
else:
    print(f"Average temperature: {average:.1f} °C")

Notice how the function handles an empty list. This avoids a division-by-zero error when no valid records are available.

5. Design the Next Version

A more complete monitoring system could store readings in a database, plot changes over time, and send alerts when configured conditions are met.

Developers should also consider timestamp consistency, sensor calibration, duplicate messages, missing data, and access control.

Water-treatment decisions should rely on appropriate testing procedures and qualified guidance rather than a software dashboard alone.

Conclusion

Reliable monitoring starts with reliable data processing. Separating validation, filtering, and analysis makes the program easier to test and maintain.

This approach is useful far beyond pools: it also applies to weather stations, greenhouse systems, industrial equipment, and environmental monitoring projects.

Building a Simple Tyre Pressure Monitoring Simulator with Python

freelancing — Thu, 29 Oct 2026 13:27:29 +0000

Vehicle monitoring systems collect measurements and use them to help identify conditions that may require attention. The same general idea can be explored with a small Python program.

In this tutorial, we'll build a simple tyre pressure monitoring simulator that accepts sample readings, validates the input, and generates alerts when a reading falls outside a configurable range.

This is an educational simulation, not a replacement for a real tyre pressure monitoring system or vehicle manufacturer's recommendations.

1. Create Sample Data

Let's represent each tyre using a dictionary.

tyres = {
    "front_left": 34.0,
    "front_right": 33.5,
    "rear_left": 32.0,
    "rear_right": 34.0
}

These numbers are illustrative values in PSI. The appropriate pressure depends on the specific vehicle, tyre configuration, and operating conditions.

2. Validate the Readings

Sensor data should not be trusted automatically. It may be missing, malformed, or outside the range the application can process.

import math

def validate_pressure(value):
    if not isinstance(value, (int, float)):
        return False

    if not math.isfinite(value):
        return False

    return value > 0

The math.isfinite() check rejects values such as NaN and infinity.

3. Generate Alerts

For this simulation, let's define a configurable lower threshold.

def check_pressure(tyres, minimum_pressure):
    alerts = []

    for tyre, pressure in tyres.items():
        if not validate_pressure(pressure):
            alerts.append(f"{tyre}: invalid reading")
        elif pressure < minimum_pressure:
            alerts.append(
                f"{tyre}: pressure below configured threshold"
            )

    return alerts

Run the simulation:

alerts = check_pressure(tyres, minimum_pressure=32.5)

if alerts:
    for alert in alerts:
        print(alert)
else:
    print("No readings below the configured threshold.")

The threshold is only an example for demonstrating conditional logic. A real system must use vehicle-specific pressure specifications and account for measurement conditions.

4. Test Edge Cases

A monitoring system should be tested with more than normal readings.

test_values = [
    34.0,
    0,
    -5,
    None,
    float("nan"),
    float("inf")
]

for value in test_values:
    print(value, validate_pressure(value))

Testing edge cases helps prevent invalid measurements from being mistaken for valid sensor readings.

5. How Would This Work in a Real System?

A production implementation would require more than a dictionary and a threshold.

It would need to consider:

Sensor calibration and measurement accuracy.
Vehicle-specific recommended pressures.
Temperature-related pressure changes.
Missing or delayed sensor messages.
Warning thresholds and alert severity.
Logging, testing, and failure handling.

It is also important to distinguish a low-pressure warning from a sensor fault. These are different conditions and should not be represented by the same alert.

Conclusion

This small project demonstrates a useful programming pattern: collect measurements, validate them, evaluate rules, and report meaningful results.

The same pattern can be adapted to equipment monitoring, industrial sensors, energy systems, and other applications where data needs to be checked before it is acted upon.

Designing Privacy-Conscious Appointment Reminders for Web Applications

freelancing — Sun, 25 Oct 2026 16:19:58 +0000

Appointment reminders are a common feature in scheduling systems. They can reduce missed appointments, but they also introduce privacy and reliability challenges.

A reminder system should send the right message to the right recipient at the right time without unnecessarily exposing sensitive information.

Let's explore the design using a fictional appointment application.

1. Store only the information needed

A basic appointment record might look like this:

const appointment = {
  id: "APT-204",
  startAt: "2026-11-02T09:30:00+11:00",
  status: "confirmed",
  reminderSentAt: null
};

The example deliberately excludes a patient's name, phone number, diagnosis, and treatment details. Those details should be handled only where required, with appropriate access controls.

2. Check whether a reminder is due

function isReminderDue(appointment, now, leadTimeMs) {
  const appointmentTime = Date.parse(appointment.startAt);

  if (!Number.isFinite(appointmentTime)) {
    return false;
  }

  if (appointment.status !== "confirmed") {
    return false;
  }

  if (appointment.reminderSentAt !== null) {
    return false;
  }

  const timeUntilAppointment = appointmentTime - now;

  return timeUntilAppointment > 0 &&
    timeUntilAppointment <= leadTimeMs;
}

For example, a system might check whether an appointment is within a configured reminder window.

const now = Date.now();
const oneDay = 24 * 60 * 60 * 1000;

console.log(isReminderDue(appointment, now, oneDay));

The sample uses a fixed lead-time window. A real scheduler should run periodically and account for time zones, daylight-saving changes, and delivery delays.

3. Keep message content minimal

A reminder might say:

You have an appointment scheduled for 2 November at 9:30 AM. Please contact the clinic if you need to change your booking.

Avoid including diagnoses, procedures, or other sensitive details in notifications unless necessary and appropriately authorised.

Also consider whether the person has consented to the communication channel and whether shared phones or email accounts could expose the message to others.

4. Prevent duplicate reminders

A simple check in application code is not enough when multiple workers can process the same appointment simultaneously.

A more robust design uses a database transaction or atomic state change. For example, a database can mark a reminder as claimed before a worker attempts delivery.

The process should account for:

Two workers processing the same appointment.
Failed message delivery.
Appointment cancellation or rescheduling.
Retry limits and backoff.
Logging without exposing sensitive details.

An idempotency key can help the delivery provider recognise repeated requests, but it does not replace database-level coordination.

5. Protect the system

A production reminder service should use authentication, least-privilege access, encrypted transport, controlled secrets, and suitable retention policies.

It should also record enough operational information to troubleshoot delivery failures without storing unnecessary patient information in application logs.

Requirements depend on the jurisdiction and the system's role. A real healthcare application needs a proper privacy and security review before deployment.

Conclusion

Appointment reminders appear simple, but reliable implementation requires careful scheduling, duplicate prevention, access control, and privacy-aware message design.

These principles also apply to booking platforms, service appointments, consultations, and other systems that communicate with people about scheduled events.

Processing Pool Sensor Readings with Python

freelancing — Sun, 25 Oct 2026 16:17:24 +0000

IoT applications often collect readings from sensors and turn them into information that people can understand. A pool-monitoring application is one example: it might collect water temperature, pH readings, and equipment status.

The first challenge is not creating a dashboard. It is deciding whether incoming readings are valid and how to process them consistently.

In this tutorial, we'll create a small Python data-processing pipeline using simulated readings.

1. Create sample data

readings = [
    {"temperature": 27.4, "ph": 7.3},
    {"temperature": 28.1, "ph": 7.4},
    {"temperature": 27.8, "ph": 7.2},
    {"temperature": None, "ph": 7.3},
    {"temperature": 29.0, "ph": 7.5},
]

These readings are illustrative, not live sensor data or a recommendation for pool water chemistry.

2. Validate each reading

Sensors may produce missing values, malformed data, or readings outside expected physical ranges.

import math

def is_valid_reading(reading):
    temperature = reading.get("temperature")
    ph = reading.get("ph")

    if not isinstance(temperature, (int, float)):
        return False

    if not isinstance(ph, (int, float)):
        return False

    if not math.isfinite(temperature) or not math.isfinite(ph):
        return False

    return True

This example validates data types and rejects non-finite numbers. A real deployment should define acceptable ranges based on sensor specifications and the intended use.

3. Filter valid records

valid_readings = [
    reading
    for reading in readings
    if is_valid_reading(reading)
]

print(f"Received: {len(readings)}")
print(f"Valid: {len(valid_readings)}")
print(f"Rejected: {len(readings) - len(valid_readings)}")

Filtering lets the application distinguish between missing data and real measurements rather than silently treating both as zero.

4. Calculate summary statistics

def average_temperature(records):
    if not records:
        return None

    values = [r["temperature"] for r in records]
    return sum(values) / len(values)

average = average_temperature(valid_readings)

if average is not None:
    print(f"Average temperature: {average:.1f} °C")
else:
    print("No valid temperature readings available.")

The function also handles an empty dataset, which is an important edge case in data processing.

5. Design a more reliable pipeline

A production IoT system needs more than averages. Consider this flow:

Receive a sensor message.
Validate its schema and timestamp.
Check whether the reading is duplicated.
Store the original reading.
Flag suspicious values for review.
Generate summaries for the dashboard.

It is also useful to track sensor identifiers, calibration dates, units, and communication failures. A missing reading should not automatically be interpreted as a safe reading.

Conclusion

Reliable dashboards begin with reliable data. By separating validation, filtering, and aggregation, developers can make monitoring systems easier to test and maintain.

The same design can be applied to weather stations, greenhouse monitoring, energy meters, and other sensor-based applications.

Building a Vehicle Maintenance Data Validator with JavaScript

freelancing — Sun, 25 Oct 2026 16:16:35 +0000

When building a vehicle maintenance application, accepting user input is easy. Making sure that input is valid, consistent, and useful is the harder part.

Consider an application that records tyre pressure, tread depth, and vehicle registration details. Incorrect values can make reports unreliable, so validation should happen before data is stored.

In this tutorial, we'll build a small JavaScript validator using reusable functions.

1. Define the data structure

A maintenance record might look like this:

const tyreRecord = {
  vehicleId: "CAR-102",
  tyrePressure: 34,
  treadDepth: 5.2,
  checkedAt: "2026-10-25"
};

These are example values, not recommendations for every vehicle. Correct tyre pressure depends on the vehicle manufacturer's specifications and operating conditions.

2. Validate individual fields

Instead of putting every condition inside one large function, create small validators.

function isValidVehicleId(value) {
  return typeof value === "string" &&
    value.trim().length > 0;
}

function isValidPressure(value) {
  return typeof value === "number" &&
    Number.isFinite(value) &&
    value > 0;
}

function isValidTreadDepth(value) {
  return typeof value === "number" &&
    Number.isFinite(value) &&
    value >= 0;
}

Notice that the numeric validators use Number.isFinite(). This prevents values such as NaN and infinity from passing validation.

These functions check data structure and basic validity. A real application would also need domain-specific limits and appropriate warnings.

3. Validate the complete record

function validateTyreRecord(record) {
  const errors = [];

  if (!isValidVehicleId(record.vehicleId)) {
    errors.push("Vehicle ID is required.");
  }

  if (!isValidPressure(record.tyrePressure)) {
    errors.push("Pressure must be a valid positive number.");
  }

  if (!isValidTreadDepth(record.treadDepth)) {
    errors.push("Tread depth must be a valid non-negative number.");
  }

  return {
    valid: errors.length === 0,
    errors
  };
}

Test the validator:

const result = validateTyreRecord(tyreRecord);

if (result.valid) {
  console.log("Record is valid.");
} else {
  console.error(result.errors);
}

For production code, also check that record is a non-null object before reading its properties.

4. Add unit tests

A validator should be tested with both valid and invalid values.

console.assert(isValidPressure(34) === true);
console.assert(isValidPressure(-5) === false);
console.assert(isValidPressure(NaN) === false);

console.assert(isValidTreadDepth(5.2) === true);
console.assert(isValidTreadDepth(-1) === false);

These lightweight assertions are useful while learning. Larger applications should use a test runner such as Vitest or Jest.

5. What changes in a real application?

Client-side validation improves the user experience, but it is not a security boundary. Users can bypass browser validation and send requests directly to an API.

A production system should also:

Validate requests on the server.
Use a consistent schema for incoming records.
Store timestamps in a consistent format.
Keep an audit trail for important maintenance changes.
Separate invalid data from legitimate safety warnings.

Conclusion

Good data validation starts with small, reusable functions and clear error messages. The same approach works for vehicle inspections, equipment inventories, repair logs, and many other applications.

The important lesson is simple: validate data before trusting it, and test the edge cases before deploying it.

Build an Accessible Daily Habit Tracker with HTML, CSS and JavaScript

freelancing — Thu, 22 Oct 2026 15:30:40 +0000

A daily habit tracker is a simple project for practising front-end development. It can also teach important lessons about accessibility, semantic HTML and clear user feedback.

In this tutorial, we'll build a checklist that tracks completion of a few daily habits. The example uses generic habits and can be adapted for personal routines, study goals or reminders.

Step 1: Create the HTML

Save the following as index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Daily Habit Tracker</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <main class="container">
    <h1>Daily Habit Tracker</h1>
    <p>Mark each habit when you complete it.</p>

    <ul id="habits">
      <li>
        <label>
          <input type="checkbox">
          Morning routine
        </label>
      </li>
      <li>
        <label>
          <input type="checkbox">
          Evening routine
        </label>
      </li>
      <li>
        <label>
          <input type="checkbox">
          Prepare for tomorrow
        </label>
      </li>
    </ul>

    <p id="progress" aria-live="polite">
      0 of 3 habits completed
    </p>
  </main>

  <script src="script.js"></script>
</body>
</html>

Step 2: Make it responsive

Create style.css:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  padding: 24px;
  font-family: system-ui, sans-serif;
  line-height: 1.6;
  color: #20252b;
  background: #f4f6f8;
}

.container {
  max-width: 560px;
  margin: 40px auto;
  padding: 24px;
  background: white;
  border-radius: 12px;
}

ul {
  padding: 0;
  list-style: none;
}

li {
  margin: 12px 0;
  padding: 12px;
  border: 1px solid #ddd;
  border-radius: 8px;
}

label {
  display: flex;
  align-items: center;
  gap: 12px;
  cursor: pointer;
}

input[type="checkbox"] {
  width: 20px;
  height: 20px;
}

@media (max-width: 480px) {
  body {
    padding: 12px;
  }

  .container {
    margin: 16px auto;
    padding: 18px;
  }
}

Step 3: Add progress tracking

Create script.js:

const habitList = document.querySelector("#habits");
const progress = document.querySelector("#progress");

function updateProgress() {
  const checkboxes = habitList.querySelectorAll(
    'input[type="checkbox"]'
  );

  const completed = [...checkboxes].filter(
    checkbox => checkbox.checked
  ).length;

  progress.textContent =
    `${completed} of ${checkboxes.length} habits completed`;
}

habitList.addEventListener("change", updateProgress);

updateProgress();

Why accessibility matters

A useful interface should work for people who navigate using a keyboard or assistive technology.

This example uses semantic HTML, connects each checkbox to a label and provides a status message with aria-live="polite".

The browser can announce progress changes to assistive technology without forcing the user to search for the updated text.

You should also test keyboard navigation, visible focus indicators, contrast and behaviour at different screen sizes.

Ideas for extending the project

Once the basic version works, consider adding custom habits, a date selector or a weekly progress summary.

You could also save the checklist between sessions. If you use local storage, remember that the information stays in the browser and is not automatically synchronised across devices.

Avoid collecting sensitive personal information unless your application has a clear need and appropriate privacy protections.

Conclusion

This small project combines HTML structure, responsive CSS and JavaScript event handling. More importantly, it shows how accessibility can be considered from the beginning rather than added as an afterthought.

Building a simple interface well is a valuable step towards developing more complex web applications.

Build a Monthly Loan Repayment Calculator with JavaScript

freelancing — Thu, 22 Oct 2026 15:30:00 +0000

A loan repayment calculator is a practical beginner project for learning JavaScript functions, mathematical formulas, input validation and DOM manipulation.

In this tutorial, we will create a calculator that estimates the monthly repayment for a standard fixed-rate amortising loan.

Understanding the formula

The monthly repayment is calculated using:

[
M=P\frac{r(1+r)^n}{(1+r)^n-1}
]

Where:

P is the principal.
r is the monthly interest rate expressed as a decimal.
n is the total number of monthly payments.
M is the estimated monthly repayment.

The annual percentage rate is divided by 100 and then by 12 to obtain the monthly rate.

When the interest rate is zero, the formula needs a separate case: divide the principal by the number of payments.

Step 1: Create the HTML

Save this as index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Loan Calculator</title>
</head>
<body>
  <h1>Loan Repayment Calculator</h1>

  <form id="loan-form">
    <label for="principal">Loan amount</label>
    <input id="principal" type="number" min="0.01"
           step="0.01" required>

    <label for="rate">Annual interest rate (%)</label>
    <input id="rate" type="number" min="0"
           step="0.01" required>

    <label for="years">Loan term (years)</label>
    <input id="years" type="number" min="1"
           max="50" step="1" required>

    <button type="submit">Calculate</button>
  </form>

  <p id="result" aria-live="polite"></p>

  <script src="script.js"></script>
</body>
</html>

Step 2: Implement the calculation

Save this as script.js:

const form = document.querySelector("#loan-form");
const result = document.querySelector("#result");

form.addEventListener("submit", (event) => {
  event.preventDefault();

  const principal = Number(
    document.querySelector("#principal").value
  );

  const annualRate = Number(
    document.querySelector("#rate").value
  );

  const years = Number(
    document.querySelector("#years").value
  );

  if (
    !Number.isFinite(principal) ||
    !Number.isFinite(annualRate) ||
    !Number.isFinite(years) ||
    principal <= 0 ||
    annualRate < 0 ||
    years < 1 ||
    years > 50 ||
    !Number.isInteger(years)
  ) {
    result.textContent = "Enter valid loan details.";
    return;
  }

  const monthlyRate = annualRate / 100 / 12;
  const payments = years * 12;

  let monthlyPayment;

  if (monthlyRate === 0) {
    monthlyPayment = principal / payments;
  } else {
    const factor = Math.pow(
      1 + monthlyRate,
      payments
    );

    monthlyPayment =
      principal * monthlyRate * factor / (factor - 1);
  }

  result.textContent =
    `Estimated monthly repayment: ${monthlyPayment.toFixed(2)}`;
});

Step 3: Test the calculator

Try different loan amounts, interest rates and repayment periods.

Useful test cases include:

A positive interest rate.
A zero interest rate.
A very small principal.
Invalid or missing inputs.
The maximum supported loan term.

For example, with a principal of 100,000, an annual rate of 6% and a term of 20 years, the estimated monthly repayment is approximately 716.43 in the same currency units as the principal.

The result is an estimate, not a quote from a lender.

Possible improvements

You could extend the project by adding:

Currency formatting.
Total repayment and total interest.
An amortisation table.
Input fields for additional fees.
Automated tests for the calculation function.
A responsive CSS layout.

Separating the mathematical calculation from the user interface would also make the code easier to test and maintain.

Conclusion

This project demonstrates how a mathematical formula can become an interactive web application. It is also a useful reminder that software outputs depend on assumptions.

The example assumes regular monthly payments and a fixed interest rate. Real loan products may include fees, variable rates and other conditions that are not represented by this calculator.

Use it as a programming exercise rather than as personalised financial guidance.

Build a Simple Water Quality Monitoring Dashboard with JavaScript

freelancing — Thu, 22 Oct 2026 15:29:10 +0000

Water-quality monitoring is a useful example of how web development can connect data with real-world systems.

A dashboard can display measurements such as pH and water temperature, show the time of the latest reading, and flag values that need review.

In this tutorial, we will build a small front-end prototype using HTML and JavaScript. The example uses simulated readings, not real sensors.

What are we building?

Our dashboard will:

Display a pH reading.
Display a water-temperature reading.
Show when the readings were updated.
Reject invalid sensor values.
Indicate when a reading falls outside configurable example limits.

Important: The example limits below are for demonstrating software logic only. They are not a validated pool-safety standard and must not be used to determine whether water is safe to swim in.

Step 1: Create the HTML

Create a file named index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Water Quality Dashboard</title>
</head>
<body>
  <main>
    <h1>Water Quality Dashboard</h1>

    <section aria-labelledby="ph-heading">
      <h2 id="ph-heading">pH reading</h2>
      <p id="ph-value">Waiting for data...</p>
      <p id="ph-status" aria-live="polite"></p>
    </section>

    <section aria-labelledby="temp-heading">
      <h2 id="temp-heading">Water temperature</h2>
      <p id="temp-value">Waiting for data...</p>
      <p id="temp-status" aria-live="polite"></p>
    </section>

    <p id="updated"></p>
  </main>

  <script src="script.js"></script>
</body>
</html>

Step 2: Add the JavaScript

Create script.js:

const phValue = document.querySelector("#ph-value");
const phStatus = document.querySelector("#ph-status");

const tempValue = document.querySelector("#temp-value");
const tempStatus = document.querySelector("#temp-status");

const updated = document.querySelector("#updated");

// Illustrative thresholds for this demo only.
const demoLimits = {
  phMin: 6.5,
  phMax: 8.0,
  temperatureMin: 10,
  temperatureMax: 40
};

function isValidNumber(value) {
  return typeof value === "number" && Number.isFinite(value);
}

function renderReading(data) {
  if (
    !isValidNumber(data.ph) ||
    !isValidNumber(data.temperature)
  ) {
    phValue.textContent = "Invalid reading";
    phStatus.textContent = "Check the incoming data.";

    tempValue.textContent = "Invalid reading";
    tempStatus.textContent = "Check the incoming data.";

    updated.textContent = "";
    return;
  }

  phValue.textContent = data.ph.toFixed(2);
  tempValue.textContent = `${data.temperature.toFixed(1)} °C`;

  const phInDemoRange =
    data.ph >= demoLimits.phMin &&
    data.ph <= demoLimits.phMax;

  const temperatureInDemoRange =
    data.temperature >= demoLimits.temperatureMin &&
    data.temperature <= demoLimits.temperatureMax;

  phStatus.textContent = phInDemoRange
    ? "Within demonstration range"
    : "Outside demonstration range";

  tempStatus.textContent = temperatureInDemoRange
    ? "Within demonstration range"
    : "Outside demonstration range";

  updated.textContent =
    `Updated: ${new Date(data.timestamp).toLocaleString()}`;
}

const simulatedReading = {
  ph: 7.2,
  temperature: 26.5,
  timestamp: Date.now()
};

renderReading(simulatedReading);

Step 3: Understand the data flow

The dashboard receives an object containing measurements and a timestamp.

The renderReading() function first validates the values. It then updates the page using textContent, which avoids interpreting the readings as HTML.

Finally, it compares the readings with the example thresholds and displays a status message.

In a real application, the simulated object could be replaced with data from an API or an IoT gateway.

What would a production system need?

A real water-monitoring system would need more than a front-end dashboard:

Calibrated sensors and documented measurement accuracy.
Secure communication between devices and the server.
Validation for missing, stale or implausible readings.
Appropriate thresholds based on the application and relevant guidance.
Error handling and alerts for sensor failures.
Regular maintenance and verification against suitable testing methods.

A dashboard should never claim that pool water is safe solely because a few sensor readings appear normal.

Conclusion

This small project demonstrates how JavaScript can turn structured measurements into a readable dashboard. It also highlights a key principle of monitoring software: presenting data clearly is important, but validating the source and understanding the limitations are equally important.

From simulated sensor projects to real IoT applications, good monitoring starts with reliable data and honest reporting of uncertainty.

How Tyre Pressure Monitoring Systems Work: Direct vs. Indirect TPMS

freelancing — Thu, 22 Oct 2026 15:27:28 +0000

Modern vehicles use sensors and electronic systems to help drivers identify potential problems. One useful example is the Tyre Pressure Monitoring System (TPMS), which can warn drivers when tyre pressure may be too low.

Understanding how TPMS works is an interesting intersection of automotive engineering, sensors and embedded software.

What is TPMS?

TPMS monitors tyre pressure or estimates pressure changes and alerts the driver when the system detects a condition that meets its warning criteria.

There are two common approaches: direct and indirect monitoring.

1. Direct TPMS

A direct TPMS uses pressure sensors installed in the wheels or tyre assemblies.

These sensors measure tyre pressure and communicate information to the vehicle's monitoring system. Depending on the design, the system may also report temperature or other sensor information.

Advantages:

Measures pressure directly.
Can identify pressure changes in individual tyres.
May provide tyre-specific readings on the dashboard.

Limitations:

Sensors require power.
Sensor batteries may eventually need replacement.
Sensor servicing and replacement can require specialised equipment.

2. Indirect TPMS

An indirect TPMS generally uses data from the vehicle's wheel-speed sensors, which are also used by systems such as ABS.

When a tyre loses pressure, its rolling characteristics can change. The monitoring software analyses wheel behaviour and looks for patterns consistent with pressure loss.

Advantages:

Can use existing vehicle sensors.
Does not require a pressure sensor inside every tyre.

Limitations:

Estimates pressure loss rather than measuring pressure directly.
May require calibration or a reset procedure.
Performance depends on the system design and operating conditions.

Why the warning light matters

A TPMS warning can indicate that one or more tyres need attention, but the exact meaning depends on the vehicle.

If the warning appears, check the owner's manual and inspect tyre pressures when safe to do so. Use the manufacturer's recommended pressure rather than the maximum pressure printed on the tyre sidewall.

A TPMS warning does not replace visual inspections. Tyre damage, embedded objects and other problems may require attention even when no warning appears.

A useful lesson for developers

TPMS is an example of a larger engineering principle: sensor data becomes useful when software interprets it and communicates the result clearly.

The same pattern appears in industrial monitoring, smart-home devices and Internet of Things applications:

Collect sensor data.
Validate incoming measurements.
Apply detection logic.
Identify abnormal conditions.
Communicate an actionable warning.

Reliable monitoring systems need to consider sensor errors, communication failures and the possibility of false alarms.

Conclusion

Direct and indirect TPMS systems use different methods to identify potential tyre-pressure problems. Both demonstrate how sensors and software can help drivers make more informed decisions.

Technology is most effective when users understand its limitations and combine automated alerts with appropriate physical inspections.

This article is for educational purposes. Follow the vehicle manufacturer's instructions for tyre pressure and TPMS maintenance.

Digital Imaging in Healthcare: From Sensor to Clinical Image

freelancing — Sun, 18 Oct 2026 15:34:19 +0000

Digital imaging is an important part of modern healthcare. It allows information captured by imaging equipment to be converted into a digital representation that can be viewed, stored and reviewed by qualified professionals.

Understanding the general workflow helps explain how hardware and software work together to produce useful clinical images.

Step 1: Capturing the Signal

A digital imaging system starts with a detector. Depending on the technology, the detector records incoming energy and converts it into an electrical signal.

In digital dental radiography, for example, an intraoral sensor detects X-rays that have passed through the relevant structures. The sensor's response varies according to the energy reaching different parts of its surface.

Step 2: Converting the Signal into Data

The detector's electrical response is converted into numerical data using electronic processing and analogue-to-digital conversion.

Each pixel in the resulting image represents a sampled measurement. The range of recorded values depends on the sensor, exposure conditions and processing pipeline.

Step 3: Image Processing

Software may apply corrections that compensate for detector characteristics or improve the presentation of the image.

Common operations in digital imaging include brightness adjustment, contrast enhancement and noise reduction. These processes can make information easier to view, but they cannot reliably recover every detail that was never captured.

Image processing should preserve clinically relevant information rather than create a misleading appearance.

Step 4: Storage and Display

The processed image is displayed on a monitor and stored using suitable software and file formats.

Healthcare systems must consider data integrity, access permissions, privacy and reliable retrieval. Image metadata may also contain information needed to interpret or manage the study.

Step 5: Professional Interpretation

A digital image is not a diagnosis by itself. Its meaning depends on the imaging technique, the quality of the capture and the clinical context.

Qualified healthcare professionals interpret the image alongside relevant examination findings and other information.

Why Quality Assurance Matters

Image quality can be affected by detector condition, positioning, exposure settings, movement and software processing. Healthcare facilities use appropriate procedures to reduce avoidable errors and maintain equipment performance.

In dental imaging, radiation exposure should also follow the applicable clinical justification and optimisation principles.

Conclusion

Digital imaging combines sensors, electronics, software and professional interpretation. Understanding this pipeline provides a useful foundation for studying medical technology, image processing and healthcare information systems.