Roger Tito —
Full-stack web developer

My role

A team of four. I took part in all five phases, from exploring the challenge to the final presentation.A team of four. I took part in all five phases of the programme, from exploring the challenge through to the final presentation to the company and the jury.

The five phases

1. 01

   Challenges and exploration — understand the real problem before proposing anything.

2. 02

   Creativity — open up options, drop what the business won't support.

3. 03

   Prototyping — bring the idea down to something showable.

4. 04

   Accelerator — sharpen the proposal with company and programme.

5. 05

   Final presentations — defend the result to the jury.

1. 01

   Challenges and exploration — understand the company's real problem before proposing anything.

2. 02

   Creativity — open up options and drop the ones that don't survive contact with the business.

3. 03

   Prototyping — bring the idea down to something you can show and try.

4. 04

   Accelerator — sharpen the proposal with support from the programme and the company.

5. 05

   Final presentations — defend the result in front of the company and the jury.

My role

One of the four developers, with 71 commits. Model, view, controller and part of the technical documentation.One of the four developers, with 71 commits on the repository. I worked across model, view and controller, and took on part of the project's technical documentation.

Technical decisions

1. 01

   MVC by hand in PHP, with MySQL access centralised in a Database class over PDO.

2. 02

   Prepared statements, password_hash, and access control by session and role.

3. 03

   A JSON events API with real HTTP status codes and owner-based permissions.

1. 01

   MVC by hand in PHP: MySQL access centralised in a Database class over PDO, with separate controllers for users and events.

2. 02

   Security as a baseline rather than an extra: prepared statements against SQL injection, passwords via password_hash / password_verify, and access control by session and role.

3. 03

   A JSON API to read and delete events, answering with real HTTP status codes and checking that whoever deletes is the owning organiser.

My role

My own project: technical decisions, implementation and deploy. Every number comes out of the build itself.My own project: the technical decisions, the implementation and the deploy. Every number in this case comes out of the build itself, so none of it has to be taken on trust.

Technical decisions

1. 01

   Workers static assets rather than Pages: room for Cron, Queues and logs without migrating anything.

2. 02

   A WebGL shader with no library in the hero, with an equivalent CSS composition underneath for anyone without WebGL or asking for less motion.

3. 03

   The halftone is a CSS filter, not a build step.

4. 04

   Images are prepared by the machine's own Chromium, not sharp: not one new dependency.

5. 05

   Astro's native i18n, and en.json typed against es.json: a missing key fails the build.

1. 01

   Workers static assets rather than Pages — they do the same job today, but this leaves room for Cron, Queues and logs without migrating anything.

2. 02

   The hero background is a WebGL shader with no library behind it, and an equivalent CSS composition underneath: with no WebGL, or with reduced motion asked for, the page looks the same and downloads nothing extra.

3. 03

   The halftone treatment on the images is a CSS filter, not a build step: changing it means editing one rule, not reprocessing the files.

4. 04

   Images are prepared by the Chromium already on the machine instead of adding sharp: resizing, single-colour logos, the .ico and the share cards, all without a new dependency.

5. 05

   i18n is Astro's native routing with JSON dictionaries, and en.json is typed against es.json — a missing key fails the build.