A–Z Practice Lessons · Batch 17
Seven focused professional learning projects · Theory → practical steps → expected result → troubleshooting → independent assignment
Original Astra learning modules remain available. These are guided learning projects, not certified production applications.
English detailed lessons · తెలుగు / हिन्दी full translations pending
HTML/CSS/JavaScript — Searchable Services Directory
Learning objective: A functional searchable directory with accessible cards.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Define the data model
Practical: Create three service records with id, title, category and description.
Explanation: A consistent array prevents mismatched UI fields.
Expected result: A consistent array prevents mismatched UI fields.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Create semantic markup
Practical: Add a header, main, labelled search input and a results section.
Explanation: Semantic regions improve navigation and accessibility.
Expected result: Semantic regions improve navigation and accessibility.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Add responsive CSS
Practical: Use grid-template-columns:repeat(auto-fit,minmax(220px,1fr)).
Explanation: Cards reflow on smaller screens.
Expected result: Cards reflow on smaller screens.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Render safely
Practical: Create elements with document.createElement and textContent.
Explanation: Avoid injecting user-supplied text through innerHTML.
Expected result: Avoid injecting user-supplied text through innerHTML.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Filter records
Practical: Compare the lowercased query against title and category.
Explanation: Search is case-insensitive.
Expected result: Search is case-insensitive.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Handle no results
Practical: Show a clear No matches message.
Explanation: Empty states prevent confusion.
Expected result: Empty states prevent confusion.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Add keyboard support
Practical: Keep native input and button elements; check Tab order.
Explanation: Keyboard-only navigation works.
Expected result: Keyboard-only navigation works.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Test edge cases
Practical: Try empty query, spaces, mixed case, and Telugu text.
Explanation: Filtering remains predictable.
Expected result: Filtering remains predictable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Measure performance
Practical: Use browser Performance panel with 100 sample entries.
Explanation: Identify unnecessary rerenders.
Expected result: Identify unnecessary rerenders.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Publish safely
Practical: Deploy to HTTPS hosting and test mobile viewport.
Explanation: Users can access the working directory.
Expected result: Users can access the working directory.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
const items=[{title:'Logo Design',category:'Design'},{title:'Website Setup',category:'Web'}];
const results=document.querySelector('#results');
function render(q=''){results.replaceChildren();const matches=items.filter(x=>(x.title+' '+x.category).toLowerCase().includes(q.trim().toLowerCase()));for(const x of matches){const card=document.createElement('article');card.textContent=x.title+' — '+x.category;results.append(card)}if(!matches.length)results.textContent='No matches';}
document.querySelector('#search').addEventListener('input',e=>render(e.target.value));render();Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
Flutter — Production Form & Local Persistence
Learning objective: A validated offline form that survives app restart.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Create Flutter project
Practical: Run flutter create astra_forms and open it in your IDE.
Explanation: A project with Android build configuration exists.
Expected result: A project with Android build configuration exists.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Choose state model
Practical: Use a StatefulWidget for the initial single-screen prototype.
Explanation: Input state remains in one place.
Expected result: Input state remains in one place.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Build form
Practical: Add Form, TextFormField and ElevatedButton.
Explanation: The user can enter a record.
Expected result: The user can enter a record.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Validate inputs
Practical: Use a validator for required name and valid email.
Explanation: Invalid values cannot be submitted.
Expected result: Invalid values cannot be submitted.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Manage controllers
Practical: Create TextEditingController objects and dispose them.
Explanation: No controller leak after screen disposal.
Expected result: No controller leak after screen disposal.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Persist locally
Practical: Use a maintained local storage package and follow its current setup guide.
Explanation: Records survive app restart.
Expected result: Records survive app restart.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Show saved records
Practical: Render records in a ListView with stable keys.
Explanation: Saved data is visible.
Expected result: Saved data is visible.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Add edit/delete confirmation
Practical: Show a confirmation dialog before deletion.
Explanation: Accidental data loss is reduced.
Expected result: Accidental data loss is reduced.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Test offline
Practical: Turn on airplane mode and create/edit records.
Explanation: Core workflow needs no internet.
Expected result: Core workflow needs no internet.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Release checks
Practical: Run flutter analyze, flutter test, then a release build.
Explanation: Build and test reports are available.
Expected result: Build and test reports are available.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
final formKey = GlobalKey<FormState>();
TextFormField(
validator: (value) => (value == null || value.trim().isEmpty) ? 'Required' : null,
)
// In submit callback: if (formKey.currentState!.validate()) { /* persist record */ }Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
Firebase — Auth, Firestore & Secure Rules
Learning objective: A user can access only their own profile document.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Create isolated test project
Practical: Use a separate Firebase project for development.
Explanation: Production data is untouched.
Expected result: Production data is untouched.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Register Android app
Practical: Enter the exact applicationId and download configuration.
Explanation: App matches Firebase registration.
Expected result: App matches Firebase registration.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Configure SDK
Practical: Follow current Firebase/FlutterFire setup for your stack.
Explanation: SDK initializes successfully.
Expected result: SDK initializes successfully.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Enable email authentication
Practical: Turn on Email/Password in Authentication providers.
Explanation: Test account can sign in.
Expected result: Test account can sign in.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Design data path
Practical: Use users/{uid} for user-owned profiles.
Explanation: Document ownership is explicit.
Expected result: Document ownership is explicit.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Write restrictive rules
Practical: Allow reads/writes only when request.auth.uid equals uid.
Explanation: Anonymous users are denied.
Expected result: Anonymous users are denied.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Validate document shape
Practical: Restrict allowed keys and field types in rules.
Explanation: Unexpected fields are rejected.
Expected result: Unexpected fields are rejected.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Test with emulator
Practical: Run allowed-owner and denied-other-user tests.
Explanation: Authorization tests pass.
Expected result: Authorization tests pass.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Add account recovery
Practical: Implement password reset with generic success messaging.
Explanation: Users can recover accounts.
Expected result: Users can recover accounts.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Review production settings
Practical: Check App Check, indexes, billing and backup requirements.
Explanation: Launch checklist is recorded.
Expected result: Launch checklist is recorded.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{uid} {
allow read, write: if request.auth != null && request.auth.uid == uid;
}
}
}Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
GitHub Actions — Test & Deploy Pipeline
Learning objective: Pull requests run checks before production deployment.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Create repository
Practical: Commit project and README without secrets.
Explanation: Source is versioned.
Expected result: Source is versioned.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Protect main branch
Practical: Require review and status checks where supported.
Explanation: Unreviewed changes are blocked.
Expected result: Unreviewed changes are blocked.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Create workflow file
Practical: Add .github/workflows/ci.yml.
Explanation: GitHub detects workflow.
Expected result: GitHub detects workflow.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Trigger on PR
Practical: Use pull_request and push for main.
Explanation: Checks run at appropriate events.
Expected result: Checks run at appropriate events.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Set minimum permissions
Practical: Use contents: read unless write is necessary.
Explanation: Token permissions are limited.
Expected result: Token permissions are limited.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Install dependencies
Practical: Use npm ci with committed lockfile.
Explanation: Reproducible dependency tree.
Expected result: Reproducible dependency tree.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Run lint and tests
Practical: Add npm run lint and npm test scripts.
Explanation: Failures block the pipeline.
Expected result: Failures block the pipeline.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Build artifacts
Practical: Run npm run build and upload output if needed.
Explanation: Deployable output is created.
Expected result: Deployable output is created.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Separate deployment
Practical: Require environment approval for production.
Explanation: Publishing is controlled.
Expected result: Publishing is controlled.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Test rollback
Practical: Re-deploy last known-good release in staging.
Explanation: Rollback procedure is documented.
Expected result: Rollback procedure is documented.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
name: CI
on: [push, pull_request]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: npm
- run: npm ci
- run: npm testCommon problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
Google Apps Script — Request Approval Tracker
Learning objective: A Sheet-backed approval tracker with an audit trail.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Create sheet schema
Practical: Columns: ID, CreatedAt, Requester, Type, Status, Approver, DecisionAt.
Explanation: Every request has traceable fields.
Expected result: Every request has traceable fields.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Define statuses
Practical: Use Pending, Approved, Rejected.
Explanation: No ambiguous state names.
Expected result: No ambiguous state names.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Add input validation
Practical: Reject blank requester and unsupported request type.
Explanation: Bad records are blocked.
Expected result: Bad records are blocked.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Generate unique IDs
Practical: Use Utilities.getUuid() rather than row numbers.
Explanation: IDs survive row sorting.
Expected result: IDs survive row sorting.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Append request
Practical: Use appendRow with controlled values.
Explanation: New request is recorded.
Expected result: New request is recorded.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Add approver action
Practical: Check identity/permissions before updating status.
Explanation: Only authorized users approve.
Expected result: Only authorized users approve.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Lock concurrent updates
Practical: Use LockService around status transitions.
Explanation: Simultaneous edits do not race.
Expected result: Simultaneous edits do not race.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Write audit entries
Practical: Append actor, timestamp, request ID and decision to audit sheet.
Explanation: Decisions are traceable.
Expected result: Decisions are traceable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Test duplicate decisions
Practical: Reject attempts to approve an already-decided request.
Explanation: State transition is enforced.
Expected result: State transition is enforced.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Deploy cautiously
Practical: Restrict web app access and avoid publicly exposing Sheet data.
Explanation: Only intended users can access.
Expected result: Only intended users can access.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
function addRequest(requester, type) {
if (!requester || !['Leave','IT','Purchase'].includes(type)) throw new Error('Invalid request');
const id = Utilities.getUuid();
const sheet = SpreadsheetApp.getActive().getSheetByName('Requests');
sheet.appendRow([id, new Date(), requester, type, 'Pending', '', '']);
return id;
}Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
AI Video Creation — Script to Subtitled Tutorial
Learning objective: A 60-second educational video with synchronized captions.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Define learner goal
Practical: Write one measurable learning outcome.
Explanation: Video has a focused purpose.
Expected result: Video has a focused purpose.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Draft 60-second script
Practical: Target approximately 110–140 spoken English words, then time the read.
Explanation: Narration fits target duration.
Expected result: Narration fits target duration.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Split into scenes
Practical: Create six scenes with visuals and timings.
Explanation: Storyboard is actionable.
Expected result: Storyboard is actionable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Verify claims
Practical: Check technical steps against current documentation.
Explanation: Misleading claims are corrected.
Expected result: Misleading claims are corrected.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Record screen
Practical: Capture the real interface at readable resolution.
Explanation: UI text is legible.
Expected result: UI text is legible.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Record narration
Practical: Use a quiet space and consistent microphone position.
Explanation: Speech is understandable.
Expected result: Speech is understandable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Edit audio
Practical: Remove long pauses; normalize loudness conservatively.
Explanation: Speech level is consistent.
Expected result: Speech level is consistent.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Generate subtitles
Practical: Create SRT cues and manually verify terminology.
Explanation: Captions align with speech.
Expected result: Captions align with speech.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Export two formats
Practical: Render 16:9 and 9:16 with safe text margins.
Explanation: No clipped titles.
Expected result: No clipped titles.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Quality review
Practical: Watch entire export, inspect audio sync and captions.
Explanation: Video passes playback review.
Expected result: Video passes playback review.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
1
00:00:00,000 --> 00:00:04,000
Welcome to Astra Learning Hub.
2
00:00:04,000 --> 00:00:08,000
Today we will build a simple web page.Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?
Digital Monetization — Ethical Service Funnel
Learning objective: A measurable service landing page and transparent lead process.
Theory: A professional workflow requires a defined input, controlled implementation, verification of the result, and a repeatable handover. Each step below explains both what to do and why it matters.
Step 01 — Choose one offer
Practical: Specify deliverable, audience and excluded services.
Explanation: Offer is understandable.
Expected result: Offer is understandable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 02 — Research demand
Practical: Review public client questions and competitor positioning.
Explanation: Pain points are documented.
Expected result: Pain points are documented.
Practice check: Repeat this step with a different sample input and record what changed.
Step 03 — Define proof
Practical: Use genuine work samples, not invented testimonials.
Explanation: Claims are supportable.
Expected result: Claims are supportable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 04 — Write landing page
Practical: Include headline, scope, sample and contact action.
Explanation: Visitor understands next step.
Expected result: Visitor understands next step.
Practice check: Repeat this step with a different sample input and record what changed.
Step 05 — Add consent notice
Practical: Explain what lead data is collected and why.
Explanation: Data collection is transparent.
Expected result: Data collection is transparent.
Practice check: Repeat this step with a different sample input and record what changed.
Step 06 — Set conversion event
Practical: Track a submitted form or confirmed contact action.
Explanation: Conversion is measurable.
Expected result: Conversion is measurable.
Practice check: Repeat this step with a different sample input and record what changed.
Step 07 — Set budget limits
Practical: If advertising, choose daily caps and stop rules.
Explanation: Spend is controlled.
Expected result: Spend is controlled.
Practice check: Repeat this step with a different sample input and record what changed.
Step 08 — Compare channels
Practical: Test organic SEO, portfolio outreach and optional paid traffic.
Explanation: Acquisition source is known.
Expected result: Acquisition source is known.
Practice check: Repeat this step with a different sample input and record what changed.
Step 09 — Measure outcomes
Practical: Track visits, qualified leads, proposals and signed projects.
Explanation: Funnel bottlenecks are visible.
Expected result: Funnel bottlenecks are visible.
Practice check: Repeat this step with a different sample input and record what changed.
Step 10 — Deliver and improve
Practical: Use acceptance checklist, invoice and client feedback.
Explanation: Work is handed over professionally.
Expected result: Work is handed over professionally.
Practice check: Repeat this step with a different sample input and record what changed.
Starter code / template
Lead conversion rate = qualified leads / landing-page visits × 100
Proposal win rate = signed projects / proposals sent × 100
Example: 8 qualified leads from 200 visits = 4% lead conversion.Common problems: Missing configuration, wrong file paths, incorrect permissions, or untested assumptions. Check the exact error message, reproduce on a minimal example, then verify the fix before continuing.
Independent assignment: Extend the sample with one additional feature, capture evidence of the working result, test one failure case, and document how to reproduce it.
Knowledge check: What is the input? What output proves success? Which security or quality check would fail if this step were skipped?