⌂ Astra HomeA–Z AcademyPrevious Batch

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

Course 01 · Starting → Advanced

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?

Course 02 · Intermediate → Expert

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?

Course 03 · Advanced → Expert

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?

Course 04 · Advanced → Expert

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 test

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?

Course 05 · Intermediate → Advanced

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?

Course 06 · Starting → Expert

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?

Course 07 · Intermediate → Outstanding

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?