Programming, Web and Application Foundations

Introduction

Information technology becomes useful when abstract requirements are transformed into working applications. Programming provides the formal means to describe that transformation; web technologies provide mechanisms for delivering applications and information across networks; application-development practices provide structure for collaboration, quality assurance, and maintenance. Together, these foundations support systems ranging from small scripts and mobile applications to enterprise platforms and cloud services.

Programming is not merely the activity of writing statements in a programming language. It involves analysing a problem, designing an algorithm, representing data, implementing a solution, testing behaviour, and maintaining the resulting software. A competent IT professional must therefore reason at several levels: logically, computationally, technically, socially, and ethically.

This chapter introduces algorithms, flowcharts, pseudocode, variables, control structures, functions, and basic object-oriented programming. It then connects these ideas to the web, APIs, version control, software testing, and low-code/no-code development.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain how algorithms represent computational solutions.
2. Construct and interpret flowcharts and pseudocode.
3. Use variables, data types, operators, control structures, and functions appropriately.
4. Describe the essential ideas of object-oriented programming.
5. Explain how browsers, servers, HTTP, URLs, HTML, CSS, and JavaScript work together.
6. Distinguish APIs, endpoints, requests, responses, authentication, and common data formats.
7. Explain the role of version control and collaborative development.
8. Select suitable software-testing approaches.
9. Evaluate low-code/no-code tools and their limitations.
10. Apply programming and application-development principles to a realistic IT problem.

1. From Problems to Algorithms

A problem specification describes what a system must do, the information it receives, the result it must produce, and relevant constraints. An algorithm is a finite, ordered, and unambiguous set of steps for solving a problem. An algorithm should normally have:

• defined inputs and outputs;
• precise instructions;
• a finite termination condition;
• correct behaviour for valid inputs; and
• acceptable efficiency and resource use.

An algorithm is independent of a particular programming language. For example, calculating an invoice total can be described before deciding whether to implement it in Python, Java, JavaScript, or another language.

A useful design habit is decomposition: divide a complex problem into smaller tasks. An online-order system might be decomposed into validating the order, calculating the subtotal, applying a discount, calculating tax, processing payment, and recording the transaction. Decomposition reduces cognitive complexity and allows individual components to be tested.

1.1 Abstraction and computational thinking

Abstraction focuses attention on important features while hiding unnecessary detail. A payment function may expose processPayment(amount, cardToken) without requiring the caller to know how encryption, network communication, and fraud checks operate.

Computational thinking commonly involves:

• Decomposition: breaking a problem into manageable parts;
• pattern recognition: identifying repeated structures or behaviours;
• abstraction: selecting a useful representation; and
• algorithm design: specifying a sequence of operations.

These practices are relevant even when a person uses a visual or low-code platform rather than typing source code.

1.2 Flowcharts and pseudocode

A flowchart represents an algorithm graphically. Common conventions include an oval for start or end, a rectangle for processing, a parallelogram for input or output, and a diamond for a decision. Arrows indicate control flow. A decision should have clearly labelled branches, such as “yes” and “no.”

Pseudocode expresses an algorithm in structured, language-independent English. It is more precise than ordinary prose but avoids the syntax of a particular programming language.

Worked example: determine whether a learner passes

Assume that the input mark is a number from 0 to 100 and that a pass requires a mark of at least 50.

BEGIN
    INPUT mark
    IF mark >= 50 THEN
        OUTPUT "Pass"
    ELSE
        OUTPUT "Fail"
    END IF
END

The condition mark >= 50 includes 50. A common design error is an off-by-one boundary, such as using mark > 50, which incorrectly classifies exactly 50 as a failure.

2. Programming Building Blocks

2.1 Variables and data types

A variable is a named storage location whose value may change during program execution. A declaration may specify a variable’s name and type. Typical data types include:

A data type determines which values are valid and which operations are meaningful. For example, addition may be meaningful for numbers, while concatenation may be meaningful for strings. Many languages are statically typed, checking types before execution or during compilation; others are dynamically typed, checking more decisions while the program runs. Both approaches can produce reliable software when used carefully.

A variable should have a meaningful name and a suitable scope. Scope is the part of a program in which a name can be accessed. Local variables reduce unintended interactions, whereas excessive global state makes programs difficult to understand and test.

2.2 Operators and expressions

An expression combines values, variables, and operators to produce a result. Common operator categories are:

• arithmetic: +, -, *, /, and remainder;
• comparison: =, ==, !=, <, >, <=, >= depending on the language;
• logical: AND, OR, and NOT; and
• assignment: storing a result in a variable.

Operator precedence can affect meaning. Parentheses should be used when they improve clarity or prevent ambiguity. For financial applications, binary floating-point values can introduce small representation errors; decimal or integer minor units such as cents are often safer, subject to the language and accounting requirements.

2.3 Control structures

The three fundamental control structures are sequence, selection, and iteration.

Sequence executes instructions in order. Selection chooses between alternatives, usually through if, else if, and else, or through a switch/case structure. Iteration repeats instructions while a condition holds or for each item in a collection.

BEGIN
    total <- 0
    FOR each price IN prices
        total <- total + price
    END FOR
    OUTPUT total
END

The loop has an initialization (total <- 0), repeated operation, and termination determined by the end of prices. A while loop is appropriate when the number of repetitions is not known in advance, but its condition must eventually become false. Failure to update the relevant state can create an infinite loop.

When analysing performance, a loop that processes n items once usually has linear time growth, conventionally described as O(n). Two nested loops over the same collection may have quadratic growth, O(n²), although actual performance also depends on hardware, implementation, and data structure. Big-O notation describes an upper growth category rather than an exact execution time.

2.4 Functions and modularity

A function is a named, reusable unit that accepts zero or more inputs and may return a result. Parameters define the inputs; the return value communicates the output.

FUNCTION calculateTotal(prices, taxRate)
    subtotal <- 0
    FOR each price IN prices
        subtotal <- subtotal + price
    END FOR
    tax <- subtotal * taxRate
    RETURN subtotal + tax
END FUNCTION

If prices = [10, 20] and taxRate = 0.10, the subtotal is 30, tax is 3, and the returned total is 33. The example assumes that prices use a consistent currency and that taxRate is represented as a decimal fraction, not as the integer 10.

Good functions generally have one clear responsibility, meaningful names, documented assumptions, and limited side effects. A side effect is an observable change outside the function, such as modifying a global variable, writing a file, or sending a network request. Pure functions, which depend only on their inputs and do not alter external state, are easier to test.

3. Basic Object-Oriented Concepts

Object-oriented programming (OOP) organises software around objects that combine state and behaviour. A class is a design or template; an object is an instance of a class.

For example, a BankAccount object might contain accountNumber and balance, with methods such as deposit() and withdraw(). The class can enforce an invariant such as “balance must not become negative,” subject to the account’s rules.

Four commonly discussed OOP concepts are:

• Encapsulation: keeping internal state and implementation details behind a controlled interface;
• abstraction: exposing essential capabilities while hiding complexity;
• inheritance: deriving a class from another class to reuse or specialise behaviour; and
• polymorphism: allowing objects with a common interface to be used interchangeably.

Inheritance can be useful, but excessive inheritance creates rigid relationships. Composition—building an object from other objects—is often more flexible. For example, an Order can contain a PaymentService without inheriting from it.

OOP is not automatically superior to procedural or functional programming. The appropriate style depends on the problem, language, team expertise, testability, and maintenance requirements.

4. Web Technology Foundations

The web is a distributed system in which clients request resources from servers using standard protocols. A browser is a client application. A web server or application server receives requests, performs processing, accesses data or other services, and returns responses.

A URL identifies a resource. It may contain a scheme such as https, a host name, a port, a path, and a query string. The Domain Name System (DNS) translates a domain name into an IP address so that network communication can occur.

4.1 HTTP and HTTPS

HTTP defines request and response messages. A request commonly includes a method, target URL, headers, and sometimes a body. Frequent methods include:

• GET: retrieve a representation;
• POST: submit data, often causing creation or an action;
• PUT: replace or create a representation at a known location;
• PATCH: partially modify a resource; and
• DELETE: request removal.

A response includes a status code, headers, and optionally a body. Codes in the 2xx range indicate success, 4xx commonly indicate a client-side problem, and 5xx indicate a server-side problem. 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, and 500 Internal Server Error have distinct meanings and should not be treated as interchangeable.

HTTPS is HTTP protected by Transport Layer Security (TLS). TLS provides encryption in transit and helps authenticate the server through certificates. HTTPS does not make an application automatically secure: weak passwords, injection vulnerabilities, excessive permissions, and poor session management remain possible.

4.2 HTML, CSS, and JavaScript

HTML defines the structure and meaning of a web document. CSS controls presentation, layout, and responsive behaviour. JavaScript adds client-side logic and can update a page without a complete reload. These technologies have different responsibilities, although modern frameworks may combine them in development workflows.

Accessibility is a design requirement, not an optional enhancement. Semantic HTML, keyboard operability, useful alternative text, readable contrast, and properly labelled form controls help people with diverse abilities use applications. Responsive design enables interfaces to adapt to different screen sizes and input methods.

4.3 APIs and data exchange

An application programming interface (API) is a defined way for software components to communicate. A web API commonly exposes resources or operations through endpoints. A request may contain an authentication credential, parameters, and a JSON body; the response may contain JSON data and a status code.

For example, a client might request GET /api/students/42. A response could be:

{
  "id": 42,
  "name": "Amina Patel",
  "active": true
}

JSON is widely used because it is readable and supported by many languages. XML remains important in some enterprise and legacy systems. API design should document data types, required fields, error formats, rate limits, authentication, versioning, and privacy expectations.

Authentication establishes who a caller is; authorization determines what that caller may do. An API key may identify an application, while a token-based system may represent a user or service. Credentials should not be embedded in public client code or committed to source-control repositories.

5. Version Control and Collaborative Development

Version control records changes to files over time. Git is a distributed version-control system in which developers commonly work in repositories, create commits, and exchange changes through branches and remote repositories.

A commit is a logical snapshot with a message. A branch is an independent line of development. A merge combines histories, while a pull request or merge request supports review before changes enter a shared branch. A conflict occurs when changes overlap in a way that the tool cannot resolve automatically; a developer must inspect and reconcile the files.

Effective practice includes:

1. making small, coherent commits;
2. writing messages that explain the change;
3. keeping branches focused;
4. reviewing code and tests before merging;
5. excluding secrets and generated files through appropriate configuration; and
6. documenting setup, dependencies, and contribution procedures.

Version control is not a substitute for backup, issue tracking, testing, or secure development. It is a foundation for traceability and collaboration.

6. Software Testing and Quality

Testing provides evidence about software behaviour. It cannot prove that a non-trivial system has no defects, but systematic testing reduces risk.

• Unit testing examines a small component, usually in isolation.
• Integration testing examines interactions among components or services.
• System testing evaluates the complete application against requirements.
• Acceptance testing determines whether the system is suitable for users or a customer.
• Regression testing checks that previously working behaviour remains correct after change.
• Usability and accessibility testing examines ease of use and inclusive access.
• Security testing investigates vulnerabilities, authentication, authorization, and data protection.

A useful test case specifies inputs, preconditions, expected results, and observed results. Boundary-value analysis tests values at and around limits. For a pass threshold of 50, useful tests include 49, 50, and 51. Equivalence partitioning groups inputs expected to behave similarly, such as valid marks from 0–100 and invalid marks below 0 or above 100.

Automated tests are particularly valuable when executed in a continuous-integration pipeline. However, automation does not replace exploratory testing, domain expertise, code review, monitoring, or user feedback. A test that merely executes code without checking meaningful outcomes provides weak assurance.

7. Low-Code and No-Code Development

Low-code platforms provide visual modelling and limited scripting; no-code platforms aim to allow application creation without conventional programming. They can accelerate prototypes, workflows, dashboards, forms, and routine integrations. They may enable domain experts to solve local problems without waiting for a specialist development team.

Their limitations include platform lock-in, subscription dependence, restricted customisation, performance constraints, opaque implementation, data-governance risks, and difficulty migrating applications. “No-code” does not mean “no design”: users still need to understand requirements, data quality, permissions, testing, accessibility, and change management.

A responsible selection process evaluates:

• integration capabilities and API support;
• data location, retention, export, and deletion;
• identity and access management;
• audit logging and regulatory requirements;
• scalability, availability, and total cost;
• vendor lock-in and exit options; and
• maintainability when the original creator leaves.

Low-code tools are best viewed as one layer in an application portfolio, not as a universal replacement for software engineering.

8. Applied Case: University Equipment-Loan Service

The following is an illustrative case.

Background and problem

A university technology centre lends laptops, cameras, and networking equipment. Its spreadsheet-based process produces duplicate bookings, incomplete return records, and limited visibility of overdue items. The centre requires a web application for students and staff.

Analysis

The principal actors are borrowers, service-desk staff, and administrators. Core entities include User, Equipment, Booking, and Return. Business rules include: an item cannot be issued to two borrowers for overlapping periods; only active users may borrow equipment; and a return must record condition and time.

The team decomposes the system into authentication, equipment search, availability checking, booking, issue and return processing, notifications, and reporting. A booking algorithm first validates the user and dates, then searches for conflicting bookings, and finally creates the booking if no conflict exists.

FUNCTION createBooking(userId, equipmentId, startDate, endDate)
    IF user is not active THEN
        RETURN "Rejected: inactive user"
    END IF
    IF startDate > endDate THEN
        RETURN "Rejected: invalid dates"
    END IF
    IF an existing booking overlaps the requested period THEN
        RETURN "Rejected: equipment unavailable"
    END IF
    create booking
    RETURN "Confirmed"
END FUNCTION

The overlap rule must be defined precisely. If periods are inclusive, a requested interval overlaps an existing interval when the requested start is on or before the existing end and the requested end is on or after the existing start. The implementation should also address time zones, cancellation, concurrent requests, and database transaction control; otherwise two simultaneous requests could both appear to succeed.

Approach and solution

The team designs a REST-style API, for example:

• GET /equipment to search equipment;
• GET /equipment/{id}/availability to inspect availability;
• POST /bookings to create a booking; and
• PATCH /bookings/{id}/return to record a return.

A browser client uses HTML, CSS, and JavaScript. The server validates all inputs rather than trusting browser validation. Git branches support separate work on the interface, API, and database. Automated unit tests cover date validation and overlap rules; integration tests cover the API and database; acceptance tests involve service-desk staff.

Outcome and learning points

The resulting system improves traceability and reduces duplicate bookings. Its success depends not only on code but also on accurate requirements, authorization, data protection, operational monitoring, user training, and a procedure for correcting records. The case demonstrates that algorithm design, web architecture, version control, testing, and governance are interconnected.

9. Professional, Ethical, and Contemporary Considerations

Software systems influence access to education, employment, finance, health, and public services. Developers should collect only necessary personal data, protect it in transit and at rest, limit access, retain it for defined purposes, and provide appropriate transparency. Legal obligations vary by jurisdiction and sector, so teams must consult applicable privacy, accessibility, records-management, and cybersecurity requirements.

Security should be considered throughout the development lifecycle. Threat modelling, input validation, parameterized database queries, secure dependency management, least privilege, safe error messages, and timely patching reduce common risks. Artificial-intelligence coding assistants can generate useful drafts, but their output may contain defects, insecure patterns, licensing concerns, or fabricated APIs. Human review, testing, and responsibility remain essential.

Contemporary development increasingly uses cloud-hosted services, containerized deployments, continuous delivery, observability tools, and API ecosystems. These developments increase speed and reach but also expand dependency, privacy, resilience, and supply-chain risks. Professional judgement involves balancing convenience against control and long-term sustainability.

Best-Practice Checklist

Before releasing a small application, a team should be able to answer “yes” to most of the following:

• Are requirements and assumptions documented?
• Are algorithms decomposed into testable functions?
• Are inputs validated at trust boundaries?
• Are names, types, and error conditions clear?
• Are authentication and authorization distinct and correctly implemented?
• Are secrets excluded from source code and repositories?
• Are boundary, negative, integration, and accessibility tests included?
• Are changes reviewed and traceable in version control?
• Are user data, retention, and deletion requirements understood?
• Is there a maintenance, monitoring, and rollback plan?

Chapter Summary

Programming begins with problem analysis and algorithm design rather than syntax alone. Algorithms can be represented through pseudocode and flowcharts, then implemented using variables, data types, operators, sequence, selection, iteration, and functions. Modular design and clear scope improve comprehension and testing. Object-oriented programming combines state and behaviour through classes and objects, while encapsulation, abstraction, inheritance, and polymorphism provide reusable design ideas.

Web applications rely on clients, servers, URLs, DNS, HTTP or HTTPS, and the complementary roles of HTML, CSS, and JavaScript. APIs establish controlled communication between software components, while authentication and authorization address different security questions. Version control supports collaboration, traceability, and review. Testing ranges from units to complete systems and should include boundary, usability, accessibility, and security concerns. Low-code/no-code tools can accelerate development but require careful evaluation of governance, integration, cost, security, and maintainability. Across all approaches, professional software development requires ethical judgement, secure practices, testing evidence, and attention to long-term operation.

Key Terms

Algorithm: A finite, precise sequence of steps for solving a problem.

API: A defined interface through which software components communicate.

Abstraction: Representing essential features while hiding unnecessary detail.

Branch: An independent line of development in version control.

Class: A template defining data and behaviour for objects.

Commit: A recorded snapshot of changes in a version-control repository.

Control structure: A programming construct that determines execution order.

Encapsulation: Restricting direct access to internal state through a controlled interface.

Function: A named, reusable unit of computation.

HTTP: A protocol used for web requests and responses.

HTTPS: HTTP protected using Transport Layer Security.

Iteration: Repeated execution of a block of instructions.

JSON: A commonly used text format for structured data exchange.

Object: An instance containing state and behaviour.

Pseudocode: Language-independent structured description of an algorithm.

Regression testing: Testing to detect unintended effects of a change.

Scope: The region of a program in which a name can be accessed.

TLS: A protocol providing encrypted communication and server authentication.

Version control: A system for recording and managing changes to files.

Review Questions

Short Answer Questions

1. What properties should a well-designed algorithm possess?
2. Distinguish a variable’s type from its scope.
3. What is the difference between authentication and authorization?
4. State two responsibilities of HTML and two responsibilities of CSS.
5. Why are boundary-value tests useful?

Long Answer Questions

1. Explain sequence, selection, and iteration, using a suitable example for each.
2. Discuss the four commonly associated concepts of object-oriented programming and explain one limitation of inheritance.
3. Describe the lifecycle of an HTTP request from a browser to a server and back again.
4. Explain how Git supports collaborative software development and identify common risks in poor version-control practice.
5. Compare low-code/no-code development with conventional programming, including benefits, risks, and appropriate use cases.

Analytical / Application Questions

1. Design pseudocode for a library system that rejects a loan when a user has reached a maximum of five active loans or when the requested item is unavailable. Identify boundary cases for testing.
2. A web API returns 401 when a user has valid credentials but insufficient permission to delete a record. Analyse the error and recommend the more appropriate status category and security design.
3. A team releases an equipment-booking application that passes unit tests but creates duplicate bookings during simultaneous requests. Explain why the tests were insufficient and propose algorithmic, database, and testing improvements.

Multiple Choice Questions with Answers

Question 1

Which characteristic is essential for an algorithm?

A. It must be written in JavaScript

B. It must contain an infinite loop

C. It must be finite and unambiguous

D. It must use a graphical interface

Correct Answer: C. It must be finite and unambiguous

Question 2

A pass requires a mark of at least 50. Which condition correctly includes a mark of 50?

A. mark > 50

B. mark >= 50

C. mark < 50

D. mark == 49

Correct Answer: B. mark >= 50

Question 3

Which control structure repeats instructions?

A. Iteration

B. Declaration

C. Encapsulation

D. Compilation

Correct Answer: A. Iteration

Question 4

What is the primary purpose of a function?

A. To provide a named, reusable unit of computation

B. To replace all data types

C. To encrypt every network connection

D. To create a version-control branch

Correct Answer: A. To provide a named, reusable unit of computation

Question 5

Which HTTP method is commonly used to retrieve a resource?

A. POST

B. DELETE

C. GET

D. PATCH

Correct Answer: C. GET

Question 6

What does HTTPS primarily add to HTTP?

A. A database schema

B. Transport encryption and server authentication through TLS

C. Automatic authorization for every user

D. A replacement for HTML

Correct Answer: B. Transport encryption and server authentication through TLS

Question 7

Which statement best distinguishes authentication from authorization?

A. Authentication identifies a caller; authorization determines permitted actions

B. Authentication deletes data; authorization backs it up

C. Authentication formats HTML; authorization formats CSS

D. They are exactly the same process

Correct Answer: A. Authentication identifies a caller; authorization determines permitted actions

Question 8

What is the purpose of a commit in Git?

A. To record a logical snapshot of changes

B. To execute a web API request

C. To compile a database

D. To replace all testing

Correct Answer: A. To record a logical snapshot of changes

Question 9

Which testing approach examines a small component in isolation?

A. System testing

B. Acceptance testing

C. Unit testing

D. Usability testing

Correct Answer: C. Unit testing

Question 10

Which is a significant risk of low-code/no-code platforms?

A. They cannot ever use data

B. They always eliminate security responsibilities

C. They may create platform lock-in and limited customisation

D. They cannot support any workflow

Correct Answer: C. They may create platform lock-in and limited customisation