Video summary

MAD I Revision Session Quiz 1

Main summary

Key takeaways

Educational

Main ideas / lessons from the revision session

1) Quiz strategy and study plan (Weeks 1–4)

  • Focus on concepts first, then solve problems.
    • Rationale: recurring question patterns in prior quizzes/past papers (PYQs) are concept-based.
  • Don’t over-focus on too-old PYQs.
    • Prefer the last 2–3 terms.
  • Time-manage revision across multiple topics.
    • Assign time per topic/concept.
    • If a concept has many PYQs, you don’t need to solve them all at once.
    • Instead: solve fewer questions but understand the concept thoroughly.
  • What to rely on for coverage
    • Professor lectures: required concepts/theory basics.
    • Instructor live sessions / TA sessions: quiz-relevant applied coverage (deemed sufficient for Quiz 1).
    • Supplementary content (course dashboard tabs):
      • “Supplementary contents” → SWAS Source (includes instructor/TA material and session code).
  • Mock vs quiz difficulty guidance
    • Mock tests are easier; quiz difficulty increases gradually.
    • Quiz 1: easy-to-slightly challenging, but still requires careful thinking.

2) Week 1: Performance/Networking numericals (Latency + Bandwidth + Concurrency)

A. Latency / delay numericals (key methodology)

Core definitions

  • Speed: speed = distance / time
  • Latency: delay between sending request and receiving response
  • Commonly:
    • RTT (Round-trip time) = request time + response time
    • On-way latency = one-way time (only request path or only response path)
  • If extra delays are given, add them to the computed travel time(s).

Speed values to remember

  • Default speed in air: 3 × 10^8 m/s
  • Speed in cable: 2 × 10^8 m/s

Unit balancing (critical)

  • Bytes vs bits
    • 1 byte = 8 bits
    • Capital B = bytes, small b = bits
  • SI prefixes
    • kilo/mega/giga/tera: 10^3, 10^6, 10^9, 10^12
  • Time conversions
    • 1 second = 1000 milliseconds
    • Convert seconds ↔ milliseconds based on what the question asks.

Typical problem pattern

  1. Identify what’s asked:
    • request time only
    • response time only
    • round trip (RTT)
  2. Compute travel time using distance/speed
    • use the correct medium speed
    • balance units to match the answer format
  3. Add any stated delays (e.g., medium-change delay).

Special case: change of medium

  • If request and response travel through different media:
    • compute request time and response time separately using their respective speeds
    • add medium-change delay(s)

Comparison: faulty vs healthy network

  • Healthy network: same medium end-to-end, no extra faults/delays
  • Faulty network: modified medium(s) and/or added delays
  • Compare faulty RTT vs healthy RTT:
    • faulty RTT larger → increasing
    • faulty RTT smaller → decreasing
    • equal → remaining same

B. Bandwidth numericals (key methodology)

Formula

  • bandwidth = (number of requests per second) × (size of each request)
  • Equivalent view: data per second

Remember units

  • Bandwidth is typically bits per second (e.g., Gbps/Mbps/Kbps).
  • If request size is in bytes, convert to bits using ×8 when needed.

Example workflow

  • Given bandwidth and request rate → solve for request size
  • Given bandwidth and request size → solve for request rate, etc.

“Additional data” bandwidth

  • If request rate stays constant, bandwidth changes in direct proportion to request size.
  • Compute:
    • initial request size
    • new request size (initial + added bits/converted added bytes)
    • initial bandwidth vs final bandwidth
  • Additional bandwidth required = final bandwidth − initial bandwidth

C. Bandwidth over time with coverage range

Scenario

  • A client moves away from a tower; connection lasts only within range.

Steps

  • Compute time in coverage: time = distance / speed
  • Data consumed: data = bandwidth × time
  • Convert units carefully (bits ↔ bytes, and seconds ↔ required output units).

D. Multi-user bandwidth graph problem

  • Bandwidth varies by time intervals shown in the graph.
  • For each user:
    • determine bandwidth value during each interval when they are active
    • compute time duration of each active segment
  • Per user:
    • data = bandwidth × duration
    • convert hours → seconds using 3600
    • convert megabits → megabytes/bytes using /8 and prefix conversions
  • Sum across users for total data consumed.

E. Concurrency (RAM requirement)

Concept

  • Each concurrent viewer creates an additional in-RAM instance (e.g., one per active viewer session).

Formula

  • RAM required = (number of concurrent viewers) × (memory per video instance)

Conversions

  • Use million = 10^6, then convert bytes to TB based on the given size units.

3) Week 2: HTML/CSS essentials (encoding + styling + selectors + elements)

A. Encoding basics (ASCII/Unicode and fixed encoding)

Fixed encodings mentioned

  • ASCII: 7-bit or 8-bit
  • UCS: 8-bit
  • UCS2: 2 bytes = 16 bits
  • UCS4: 4 bytes = 32 bits

Key methodology

  • File size:
    • size in bits = (number of characters) × (bits per character)
  • If asked for bytes:
    • convert bits → bytes: /8

Minimum encoding with a given character set

  • If a character set has C distinct characters:
    • find smallest n such that 2^n ≥ C
    • bits per character = n
  • If C increases past capacity, n increases → file size increases.

B. CSS styling priority and syntax

Styling types

  • Inline CSS: style="color: red;"
  • Internal CSS: <style> ... </style> inside the document
  • External CSS: <link rel="stylesheet" href="...">

Order of precedence

  • Generally: inline > internal > external
  • !important overrides precedence:
    • !important has the highest precedence regardless of order.

Syntax/order notes

  • External stylesheet link placement can matter (they emphasized correct ordering in exam-style questions).

C. CSS selectors and precedence

Selector types

  • ID selector: #idName
  • Class selector: .className
  • Element selector: elementName (e.g., div, p)

Selector precedence

  • ID > class > element

Additional notes

  • Without !important, higher specificity wins.
  • Multiple classes:
    • different properties can come from different classes (e.g., one sets font color, another sets background)
    • if the same property is set multiple times, the later rule wins (as discussed in examples).

Lists in HTML

  • Ordered list: <ol> with <li> items (type can control numbering style)
  • Unordered list: <ul> with <li> items (type can control bullet shape)
  • Description list: <dl>, <dt>, <dd>

D. HTML tags: links, anchors, images, basics of layout

  • Link tag (<link>)
    • used to attach an external document (commonly CSS).
  • Anchor tag (<a>)
    • creates a hyperlink; uses href
    • anchor text is the clickable part between <a>...</a>
  • Image tag (<img>)
    • src for image URL
    • alt displayed if the image fails to load
  • Navigation in links
    • may require attributes like target="_blank" depending on the question.

E. Block vs inline elements + display properties

  • Block-level elements
    • take full width and commonly start on a new line
    • examples discussed: headings (h1–h6), div, p
  • Inline elements
    • take only needed width and can sit beside other inline content
    • example: span
  • Inline-block vs flex
    • inline-block: allows width changes while behaving inline-like
    • flex: layout managed through flex properties on a parent container
  • Flex/inline-block used when two child blocks must appear side-by-side.

4) Week 3: Jinja templating + command line arguments + filters

A. Jinja templating basics

Syntax

  • Format string (non-Jinja example): single curly braces {...}
  • Jinja variables: {{ ... }}
  • Loops: {% for item in data %} ... {% endfor %}
  • Conditions: {% if condition %} ... {% endif %}
  • End tags are required (endfor, endif).

Rendering concepts

  • “Rendered output” depends on context:
    • terminal output vs browser-like HTML rendering when template contains HTML.

B. String templating module vs Jinja

Behavior difference

  • Jinja: missing variables generally produce blank/ignored output (not necessarily an error)
  • string.Template:
    • substitute: missing variable can cause KeyError
    • safe_substitute: missing variable remains as literal text rather than error

C. Loop/if inside Jinja templates

  • Use nested {% for %} and {% if %} as required.
  • Use {{ }} to print/display values.

D. Command line arguments (sys.argv)

  • Program arguments come after the script name.
  • sys.argv returns a list split by spaces.
  • Index mapping:
    • sys.argv[0] = script name
    • sys.argv[1], sys.argv[2], … = subsequent args
  • Key/value mapping depends on how the question structures arguments.

E. Jinja filters

  • Filters used to transform data (e.g., rejecting odd values).
  • Filters are applied using the pipe operator | (e.g., value | filter_name).

5) Week 4: Flask fundamentals (routes, templates, methods, forms, request data)

A. Flask app and routing

Core elements

  • Import Flask
  • Create app instance
  • Define routes using @app.route("path")
  • Run server:
    • app.run(debug=True/False, port=...)

Templates

  • render_template("file.html", variables...)
  • If the template file isn’t in templates/ → Template not found error.

Routing rules

  • Duplicate endpoint function names can cause assertion errors.
  • Missing routes → 404 Page not found
  • Dynamic endpoints with converters:
    • /user/<username> (string by default)
    • converters like int enforce accepted input type (as per question).

B. HTTP methods: GET vs POST (browser limitation emphasized)

  • Browser mainly triggers:
    • GET: retrieve resource; form data becomes query parameters
    • POST: send form data; goes as request form payload
  • Flask logic pattern:
    • if request.method == "POST": ...
    • else show the form (GET)

C. Forms in HTML → Flask request handling

Form attributes

  • action: endpoint URL
  • method: usually post to avoid query-string passing
  • name: key used to store input value

Flask access patterns

  • Command line args: sys.argv
  • Form data: request.form[...]
  • Query parameters: request.args[...]

D. Redirect and template rendering

  • render_template renders HTML template directly.
  • redirect(url_for("function_name")) redirects to another route by route name.

E. Error handling

  • Flask can define custom error handlers (e.g., for 404) to show custom error pages.

F. Misc additional notes emphasized

  • localhost corresponds to 127.0.0.1
  • In local static serving (Python http server), if index.html is absent:
    • browser may show directory listing.

Speakers / sources mentioned

  • Ma’am (primary instructor/lecturer): main speaker throughout the subtitles.
  • Muskan: student questioner (asked about mock questions and clarifications).
  • Other students / participants: brief interjections (e.g., “Yes ma’am”).
    • Mukund: mentioned in an example about concurrency/watching behavior.
    • Mujt/Mjit/Musan: names appear in example contexts (not confirmed as distinct speakers).
  • Ginga/Jinja documentation / course materials: referenced as sources:
    • SWAS/SWAS Source, supplementary contents, TA sessions, professor lectures, and course dashboard resources.

Original video