🎓 Internship180-day curriculumMy dashboardLearning libraryIncome & careers

Phase 4 / 6 · Day 100 / 180

CodeIgniter and framework comparison

CodeIgniter offers a lightweight MVC approach with routing, controllers and models. Use the current CodeIgniter 4 documentation. Compare frameworks by requirements, operational constraints and team familiarity; a larger feature list does not automatically make one framework better for a project.

Milestone review · video demo recommended

Submit day 100All days

Today’s working brief

Use the shared service-request product: customers raise requests, the team triages them and customers track their progress. Choose the assignment for your approved role. Scope the work to one demonstrable improvement and state what is not yet covered.

Suggested study session: read and plan for 20 minutes, practice for 60–90 minutes, check the result for 20 minutes, then record evidence and a short reflection. This is a suggested learning schedule, not required employment hours.

💻 Software engineering

Compare Node PHP Django Laravel and CodeIgniter

  1. Keep the change small and runnable; record the exact setup commands and supported environment.
  2. Implement the named task in the service-request project, or an isolated practice branch if it does not belong in the main stack.
  3. Check one normal case, one invalid input and one failure or empty state. Record the results and commit the work.

Evidence: A GitHub repository, commit, pull request or report showing today’s work and how to review it.

🎨 UI design

Present a framework-neutral design specification

  1. State the user goal, assumptions and screen or flow addressed by today’s assignment.
  2. Create the named artifact in Figma with clear frames, component names and annotations. Distinguish assumptions from observed research.
  3. Check readable text, keyboard/focus intentions, error and empty states. Explain one design trade-off and update the handoff notes.

Evidence: A viewable Figma file or prototype, with relevant frame names in your work log.

🔎 Software QA

Present a comparative quality report

  1. State the feature, environment, test data and scope before testing. Use synthetic data.
  2. Create the named QA artifact in your evidence repository. For test cases, include preconditions, steps, expected results and actual results.
  3. Record reproducible findings, severity and evidence. Mark tests not run honestly and identify one remaining risk.

Evidence: A GitHub repository, commit, pull request or report showing today’s work and how to review it.

Definition of done

  • The artifact addresses today’s named role task.
  • Your notes identify what you personally completed and how it was checked.
  • Links are accessible to the reviewer; private repositories need a reviewer invitation.
  • No passwords, access tokens, customer data or other people’s personal details appear in evidence.
  • You have written one learning point, blockers and actual time spent.
  • An optional YouTube demo can explain the work, shows the result and names one limitation. Unlisted videos are acceptable; check access before submitting.

For a seven-person team, a useful starting split is three engineers, two designers and two QA learners. Rotate coordination and review duties. Your individual submission must distinguish your contribution from shared work.

Read, then apply

Read the current official documentation for the feature you use. Record versions in your project README; avoid copying tutorials without understanding their assumptions.

Career & income practice

Job preparation · Prove your contribution

Write a short portfolio case study: problem, your role, decision, evidence and limitation. Link to a relevant commit, Figma page or test report. Include only results you actually measured.

Apply this exercise to today’s codeigniter and framework comparison work. Save the result in your career notes. Income depends on demand, quality, effort and ongoing support; no earnings are promised.

Explore active income, passive-income experiments and jobs →

Technical practice · day 100

Test a risk, not just a line of code

Pick a failure that would harm the user: lost data, unauthorized access or a misleading success message. Define a reproducible check and its expected outcome. Prefer stable user-facing selectors for browser tests. Record environmental assumptions so another person can reproduce the result.

Apply it today: connect this check to your assigned task, record the actual outcome, and explain one limitation in your work note.

Browse official documentation and role-based resources →

design · freeCodeCamp.org

UI design and prototyping in Figma

Practice frames, auto-layout and component variants. This foundation course was published in 2022, so some interface controls may look different today.

Watch on YouTube ↗ · Course details

Reflection questions

  1. Which decision made the biggest difference to your result today?
  2. What evidence supports your claim that it works?
  3. What would you change after another teammate’s review?
Open submission form