Top Tweets for #200DaysOfCodingChallenge

5 months ago

Day 104 0f #200DaysOfCodingChallenge Understanding APIs: How the Web Actually Talks to Itself If you’ve ever wondered how websites fetch data, how apps communicate, or how Web3 dApps pull prices, NFTs, or user data, this is the foundation you must understand: 👉 APIs (Application Programming Interfaces) What is an API? An API is a structured way for one system to request data or actions from another system. Think of it like: A menu (you choose what you want) A waiter (API) A kitchen (server / database) You ask → API processes → Response returns. Understanding API Endpoints An endpoint is a specific URL that performs a specific action. General structure: BaseURL / Endpoint Example: https://t.co/W2TCj5WR5e Here: BaseURL → https://t.co/l7Iu0mRUwc Endpoint → /posts Each endpoint does one clear job. Common HTTP Methods REST APIs rely on standard HTTP methods: GET → Fetch data POST → Create data PUT / PATCH → Update data DELETE → Remove data This consistency is what makes APIs predictable and scalable. GET: Fetching All Posts Endpoint: GET /posts Returns: A list of posts No authentication required Data formatted as JSON Why this matters: Clients don’t need database access They only need the endpoint Server controls everything GET: Fetching a Specific Resource GET /posts/{postId} Example: /posts/1 This uses a path parameter. Path parameters: Identify a specific resource Are fixed in structure Change per request Used when you want one exact item, not a filtered list. Query Parameters vs Path Parameters Query Parameters: /posts?userId=1 Used for: Searching Filtering Sorting Path Parameters: /posts/1 Used for: Identifying a single resource Knowing the difference is critical for API design. POST: Creating Data POST /posts This request sends data inside the request body. Example: { "title": "Hello World", "body": "This is my first post" } Why POST exists: Data is not exposed in the URL Secure Structured Scalable What Is JSON and Why It’s Used JSON (JavaScript Object Notation) is the universal language of APIs. Why JSON? Lightweight Human-readable Machine-friendly Language-agnostic Serialization: JSON.stringify(data) Deserialization: JSON.parse(json) This is how data moves across the internet. Async, Await, and Why APIs Don’t Freeze the Browser APIs are asynchronous because: Network calls take time JavaScript must stay responsive Conceptually: async → This function returns a Promise await → Pause until the Promise resolves This applies to: APIs Databases Web3 smart contracts Blockchain transactions Axios: Cleaner API Requests Axios simplifies HTTP requests. Instead of chaining .then() calls: await axios.get(url) Why Axios is preferred: Cleaner syntax Better error handling Automatic JSON parsing Widely used in production API Authentication vs Authorization This is a critical distinction. Authentication: Who are you? Authorization: What are you allowed to do? You can be authenticated but not authorized. Types of API Authentication 1️⃣ No Authentication Public APIs Rate-limited 2️⃣ Basic Auth Username + password Base64 encoded (not encrypted) 3️⃣ API Keys Simple access control Common in SaaS APIs 4️⃣ Token-Based Authentication Most secure Used in OAuth, JWT, Web3 APIs What Makes an API RESTful? A REST API must: ✔ Use standard HTTP methods ✔ Return structured data (JSON/XML) ✔ Separate client and server ✔ Be stateless ✔ Be resource-based This architecture allows: Scalability Independent development Long-term maintainability Real-World API Examples Weather apps → OpenWeather API Crypto prices → CoinGecko API Email newsletters → Mailchimp API Web3 apps → Blockchain indexers APIs are the invisible infrastructure of the internet. Key Takeaway APIs are not just “data fetchers”. They are contracts between systems. Understanding APIs means: You can build real apps You can integrate any service You can scale products properly You can work confidently with backend & Web3 systems 📘 Full structured guide + examples here: https://t.co/lTBVJg2g5o

$Iris_of_Defi's tweet photo. Day 104 0f #200DaysOfCodingChallenge Understanding APIs: How the Web Actually Talks to Itself If you’ve ever wondered how websites fetch data, how apps communicate, or how Web3 dApps pull prices, NFTs, or user data, this is the foundation you must understand: 👉 APIs (Application Programming Interfaces) What is an API? An API is a structured way for one system to request data or actions from another system. Think of it like: A menu (you choose what you want) A waiter (API) A kitchen (server / database) You ask → API processes → Response returns. Understanding API Endpoints An endpoint is a specific URL that performs a specific action. General structure: BaseURL / Endpoint Example: https://t.co/W2TCj5WR5e Here: BaseURL → https://t.co/l7Iu0mRUwc Endpoint → /posts Each endpoint does one clear job. Common HTTP Methods REST APIs rely on standard HTTP methods: GET → Fetch data POST → Create data PUT / PATCH → Update data DELETE → Remove data This consistency is what makes APIs predictable and scalable. GET: Fetching All Posts Endpoint: GET /posts Returns: A list of posts No authentication required Data formatted as JSON Why this matters: Clients don’t need database access They only need the endpoint Server controls everything GET: Fetching a Specific Resource GET /posts/{postId} Example: /posts/1 This uses a path parameter. Path parameters: Identify a specific resource Are fixed in structure Change per request Used when you want one exact item, not a filtered list. Query Parameters vs Path Parameters Query Parameters: /posts?userId=1 Used for: Searching Filtering Sorting Path Parameters: /posts/1 Used for: Identifying a single resource Knowing the difference is critical for API design. POST: Creating Data POST /posts This request sends data inside the request body. Example: { "title": "Hello World", "body": "This is my first post" } Why POST exists: Data is not exposed in the URL Secure Structured Scalable What Is JSON and Why It’s Used JSON (JavaScript Object Notation) is the universal language of APIs. Why JSON? Lightweight Human-readable Machine-friendly Language-agnostic Serialization: JSON.stringify(data) Deserialization: JSON.parse(json) This is how data moves across the internet. Async, Await, and Why APIs Don’t Freeze the Browser APIs are asynchronous because: Network calls take time JavaScript must stay responsive Conceptually: async → This function returns a Promise await → Pause until the Promise resolves This applies to: APIs Databases Web3 smart contracts Blockchain transactions Axios: Cleaner API Requests Axios simplifies HTTP requests. Instead of chaining .then() calls: await axios.get(url) Why Axios is preferred: Cleaner syntax Better error handling Automatic JSON parsing Widely used in production API Authentication vs Authorization This is a critical distinction. Authentication: Who are you? Authorization: What are you allowed to do? You can be authenticated but not authorized. Types of API Authentication 1️⃣ No Authentication Public APIs Rate-limited 2️⃣ Basic Auth Username + password Base64 encoded (not encrypted) 3️⃣ API Keys Simple access control Common in SaaS APIs 4️⃣ Token-Based Authentication Most secure Used in OAuth, JWT, Web3 APIs What Makes an API RESTful? A REST API must: ✔ Use standard HTTP methods ✔ Return structured data (JSON/XML) ✔ Separate client and server ✔ Be stateless ✔ Be resource-based This architecture allows: Scalability Independent development Long-term maintainability Real-World API Examples Weather apps → OpenWeather API Crypto prices → CoinGecko API Email newsletters → Mailchimp API Web3 apps → Blockchain indexers APIs are the invisible infrastructure of the internet. Key Takeaway APIs are not just “data fetchers”. They are contracts between systems. Understanding APIs means: You can build real apps You can integrate any service You can scale products properly You can work confidently with backend & Web3 systems 📘 Full structured guide + examples here: https://t.co/lTBVJg2g5o$

IRIS ☘️👩🏼‍💻

@Iris_of_Defi

5 months ago

Day 103 of #200DaysOfCodingChallenge Databases, SQL & PostgreSQL: The Foundation of Data Persistence 🧠🗄️ Every serious application starts with one core question: 👉 Where does data live when the app stops running? That answer is data persistence. 🔹 What Is Data Persistence? Data persistence means: Information continues to exist even after the program that created it stops running. If your server crashes, restarts, or updates: • User accounts still exist • Records remain intact • Business logic continues seamlessly Persistent data is stored in non-volatile storage (databases, filesystems, cloud storage). Without persistence: • Every refresh = data loss • No automation • No real applications 🔹 Why Databases Exist Databases solve four fundamental problems: 1️⃣ Structured storage 2️⃣ Fast querying 3️⃣ Data relationships 4️⃣ Integrity & consistency They allow applications to: • Store millions of records safely • Query efficiently • Enforce rules (constraints) • Scale without chaos 🔹 SQL Databases (Relational Databases) SQL databases store data in tables with fixed structure. Example: • users (id, name, email) • posts (id, title, user_id) The user_id connects posts to users. This is what “relational” means. Relationships bring: • Predictability • Safety • Clear data ownership 🔹 CRUD — The Core of All Databases Every database interaction boils down to four actions: • CREATE → Insert data • READ → Fetch data • UPDATE → Modify data • DELETE → Remove data Master CRUD = master database basics. 🔹 SQL Essentials You Must Know Key SQL concepts every developer uses daily: • SELECT — fetch data • WHERE — filter records • INSERT — store new data • UPDATE — change data • DELETE — remove data • JOIN — connect tables • GROUP BY — aggregate data Constraints enforce safety: • NOT NULL → no empty values • UNIQUE → no duplicates • PRIMARY KEY → unique identity • FOREIGN KEY → relationships 🔹 Relationships in SQL Databases mirror real life: • One-to-One • One-to-Many • Many-to-Many Foreign keys create these links and enforce consistency. This prevents: • Orphan records • Invalid references • Broken data models 🔹 SQL JOINs (The Power Feature) JOINs allow data from multiple tables to be combined. Example: • Users + Posts • Orders + Products • Countries + Capitals JOINs turn separate tables into meaningful information. 🔹 NoSQL Databases (When Flexibility Matters) NoSQL databases store data without rigid structure. They shine when: • Data shape changes often • Content is unpredictable • Scale is massive Common types: • Document DBs (MongoDB) • Key-Value Stores (Redis) • Graph DBs (Neo4j) Great for: • Social feeds • Logs • Real-time systems 🔹 Why SQL Still Dominates Production Systems As systems mature, structure becomes an advantage. SQL provides: • Strong data integrity • Clear relationships • Safer updates • Easier debugging That’s why banks, fintechs, and core platforms still rely heavily on SQL. 🔹 PostgreSQL — Production-Grade SQL PostgreSQL is: • Open-source • Extremely powerful • ACID-compliant • Used in real production systems It sits at the heart of many serious backend architectures. 🔹 Backend + Database Architecture A typical flow: Browser / Frontend ↓ Express / Backend Server ↓ PostgreSQL Database The backend: • Handles requests • Applies logic • Talks to the database • Returns responses 🔹 Real Applications Use Queries Constantly From quiz apps to dashboards: • Fetch records • Insert new data • Update state • Maintain relationships Databases are not optional. They are the spine of every real application. 🧠 Final Thought If you understand: • Data persistence • SQL structure • Relationships • PostgreSQL fundamentals You can build: • Auth systems • Dashboards • APIs • Scalable backends 📘 Full structured guide + examples here: 🔗 https://t.co/XfDiPxI4jd Follow @Iris_of_Defi for clear Web Dev, Backend & Web3 education 🚀

Iris_of_Defi's tweet photo. Day 103 of #200DaysOfCodingChallenge

Databases, SQL & PostgreSQL: The Foundation of Data Persistence 🧠🗄️

Every serious application starts with one core question:

👉 Where does data live when the app stops running?

That answer is data persistence.

🔹 What Is Data Persistence?

Data persistence means:

Information continues to exist even after the program that created it stops running.

If your server crashes, restarts, or updates:
• User accounts still exist
• Records remain intact
• Business logic continues seamlessly

Persistent data is stored in non-volatile storage (databases, filesystems, cloud storage).

Without persistence:
• Every refresh = data loss
• No automation
• No real applications

🔹 Why Databases Exist
Databases solve four fundamental problems:
1️⃣ Structured storage
2️⃣ Fast querying
3️⃣ Data relationships
4️⃣ Integrity & consistency
They allow applications to:
• Store millions of records safely
• Query efficiently
• Enforce rules (constraints)
• Scale without chaos

🔹 SQL Databases (Relational Databases)

SQL databases store data in tables with fixed structure.
Example:
• users (id, name, email)
• posts (id, title, user_id)
The user_id connects posts to users.
This is what “relational” means.

Relationships bring:
• Predictability
• Safety
• Clear data ownership

🔹 CRUD — The Core of All Databases

Every database interaction boils down to four actions:

• CREATE → Insert data
• READ → Fetch data
• UPDATE → Modify data
• DELETE → Remove data
Master CRUD = master database basics.

🔹 SQL Essentials You Must Know
Key SQL concepts every developer uses daily:

• SELECT — fetch data
• WHERE — filter records
• INSERT — store new data
• UPDATE — change data
• DELETE — remove data
• JOIN — connect tables
• GROUP BY — aggregate data

Constraints enforce safety:
• NOT NULL → no empty values
• UNIQUE → no duplicates
• PRIMARY KEY → unique identity
• FOREIGN KEY → relationships

🔹 Relationships in SQL
Databases mirror real life:
• One-to-One
• One-to-Many
• Many-to-Many

Foreign keys create these links and enforce consistency.

This prevents:
• Orphan records
• Invalid references
• Broken data models

🔹 SQL JOINs (The Power Feature)

JOINs allow data from multiple tables to be combined.

Example:
• Users + Posts
• Orders + Products
• Countries + Capitals
JOINs turn separate tables into meaningful information.

🔹 NoSQL Databases (When Flexibility Matters)

NoSQL databases store data without rigid structure.

They shine when:
• Data shape changes often
• Content is unpredictable
• Scale is massive
Common types:
• Document DBs (MongoDB)
• Key-Value Stores (Redis)
• Graph DBs (Neo4j)
Great for:
• Social feeds
• Logs
• Real-time systems

🔹 Why SQL Still Dominates Production Systems

As systems mature, structure becomes an advantage.

SQL provides:
• Strong data integrity
• Clear relationships
• Safer updates
• Easier debugging

That’s why banks, fintechs, and core platforms still rely heavily on SQL.

🔹 PostgreSQL — Production-Grade SQL
PostgreSQL is:
• Open-source
• Extremely powerful
• ACID-compliant
• Used in real production systems
It sits at the heart of many serious backend architectures.

🔹 Backend + Database Architecture

A typical flow:

Browser / Frontend
↓
Express / Backend Server
↓
PostgreSQL Database

The backend:
• Handles requests
• Applies logic
• Talks to the database
• Returns responses

🔹 Real Applications Use Queries Constantly

From quiz apps to dashboards:
• Fetch records
• Insert new data
• Update state
• Maintain relationships
Databases are not optional.
They are the spine of every real application.

🧠 Final Thought
If you understand:
• Data persistence
• SQL structure
• Relationships
• PostgreSQL fundamentals

You can build:
• Auth systems
• Dashboards
• APIs
• Scalable backends

📘 Full structured guide + examples here:
🔗 https://t.co/XfDiPxI4jd

Follow @Iris_of_Defi

for clear Web Dev, Backend & Web3 education 🚀

678

474

IRIS ☘️👩🏼‍💻

@Iris_of_Defi

5 months ago

Day 101 of #200DaysOfCodingChallenge Web Authentication & Security. A Practical, End-to-End Breakdown 🔐 Authentication is the foundation of web security. Before anything else, a system must answer one question correctly: “Who is this user?” Everything else, authorization, permissions, sessions, data access, depends on that answer. 1️⃣ Authentication vs Authorization These are not the same thing. Authentication → Proving identity Authorization → Deciding what that identity can access Example: • Logging in → authentication • Accessing admin routes → authorization • Mixing these concepts is one of the most common beginner mistakes. 2️⃣ The Database Layer (Relational Model) Most authentication systems rely on relational databases. Example users table: CREATE TABLE users ( id SERIAL PRIMARY KEY, email VARCHAR(100) UNIQUE NOT NULL, password TEXT NOT NULL ); Why SQL works well here: • Strong structure • Constraints (UNIQUE, NOT NULL) • Predictable relationships • Secure querying with parameterized statements 3️⃣ Why Plain Passwords Are a Security Failure Storing passwords as plain text means: Anyone with DB access sees every password • A single breach exposes all users • Users often reuse passwords across sites • Plain-text password storage is never acceptable. 4️⃣ Encryption vs Hashing (Critical Difference) Encryption: • Two-way process • Requires a secret key • Data can be decrypted back to original form Hashing: • One-way process • No key • Cannot be reversed • Same input → same output (unless salted) 👉 Passwords must be hashed, not encrypted. 5️⃣ Classic Ciphers (Why They Fail) • Caesar Cipher • Letter-shifting technique • Very limited key space • Easily brute-forced Enigma / Early Ciphers: • Historically important, • Broken with enough compute power These are useful for learning cryptography concepts not security. 6️⃣ Blowfish Cipher Blowfish is a symmetric encryption algorithm: • Fast • Secure • Key-based • Reversible Important distinction: • Blowfish = encryption • bcrypt = hashing (built on Blowfish concepts) Blowfish alone is not used for password storage. 7️⃣ bcrypt — The Correct Tool for Passwords bcrypt is designed specifically for password hashing. What bcrypt does: • Automatically adds a salt • Uses adaptive cost (salt rounds) • Slows down brute-force attacks • Produces unique hashes even for identical passwords Why this matters: • Attackers can’t use rainbow tables • Each guess is computationally expensive • Database leaks don’t expose real passwords 8️⃣ Salting & Salt Rounds Explained Simply Salting: • Random data added to the password before hashing • Same password ≠ same hash Salt Rounds: • Number of times the hashing algorithm runs • More rounds = more security • More rounds = slower (intentionally) Example: 10 rounds → industry standard balance bcrypt handles salting and rounds internally. 9️⃣ Authentication Flow (Backend Logic) Registration 1. User submits email + password 2. Password is hashed using bcrypt 3. Hash is stored in the database Login: 1. User submits password 2. bcrypt compares input with stored hash 3. Match → authenticated 4. No match → access denied Passwords are never decrypted. 🔟 Sessions & Cookies Authentication does not end at login. Sessions: • Represent an authenticated user’s active state • Stored server-side Cookies: note: A session is the period of time when a broweser interact with a sever, and cookiesa are a way for companies to detate your behave during the session for marketing retargeting. when you log in to a website that when you session starts and you cookies are created. it also maintain persistent login authentication in your browser. • Stored in the browser • Contain a session identifier • Sent with each request This allows: • Persistent login • User tracking within a session • Secure access control Authentication creates the session. Cookies maintain it. 1️⃣1️⃣ Passport.js (Authentication Middleware) Passport.js simplifies authentication in Node.js. • Supports: • Username & password • OAuth (Google, GitHub, Facebook) • Session handling It abstracts: Login strategies: • Serialization • Session management Result: cleaner, safer authentication logic. 1️⃣2️⃣ Environment Variables (.env) Secrets should never live in code. Use .env files for: • Database passwords • API keys • Session secrets Why: • Prevents accidental leaks • Keeps secrets out of version control • Allows environment-specific configs Security starts with configuration. 1️⃣3️⃣ Password Attacks (Why All This Matters) Common attack methods: • Brute force • Dictionary attacks • Credential stuffing Database breaches. Use this link to see if you email is at risk 👉 https://t.co/RuHmbCPCPO Final Principle 🧠 • Secure authentication is not optional. • It is layered, deliberate, and defensive by design. Strong passwords • bcrypt hashing • salting • sessions environment security = responsible web development. 📘 Full structured notes + code examples here: 🔗https://t.co/XjKrDE3jwl follow @Iris_of_Defi for more education web dev and web3 content.

IRIS ☘️👩🏼‍💻

@Iris_of_Defi

6 months ago

Let’s do 200 days shall we 🌚

467

432

Chibuike Divine Offordile @Bruce1Offordile

12 months ago

TTS 🔥 Who's readyyyyyyy Time: 8pm WAT Date: 15th June, 2025 Speaker: @Greegman Theme: You're not safe just because it works on your laptop. Don't miss out guyss Come let's unpack #200daysofcodingchallenge #tts

Bruce1Offordile's tweet photo. TTS 🔥

Who's readyyyyyyy

Time: 8pm WAT
Date: 15th June, 2025
Speaker: @Greegman
Theme: You're not safe just because it works on your laptop.

Don't miss out guyss
Come let's unpack

#200daysofcodingchallenge #tts https://t.co/ed53cD6pJK

183

Chibuike Divine Offordile @Bruce1Offordile

about 1 year ago

Thank you so much @WZoyaar , it was indeed an impactful session. You did get to put us through the process of "Building impactful products from Idea to Execution". It was well treated 🔥 #tts #200daysofcodingchallenge

Bruce1Offordile's tweet photo. Thank you so much @WZoyaar , it was indeed an impactful session. You did get to put us through the process of "Building impactful products from Idea to Execution".

It was well treated 🔥

#tts #200daysofcodingchallenge https://t.co/VrGvm2Yplv

228

Ujunwa Sylvia @UjunwaSylv72182

about 1 year ago · Enugu

TTS🔥 What’s the value of having a great product idea if it never gets executed? And what’s the point of execution without a clear, thoughtful idea behind it? Don’t miss out! Date: 4th May 2024 Time: 8PM WAT #tts #200daysofcodingchallenge

UjunwaSylv72182's tweet photo. TTS🔥

What’s the value of having a great product idea if it never gets executed?

And what’s the point of execution without a clear, thoughtful idea behind it?

Don’t miss out!
Date: 4th May 2024
Time: 8PM WAT

#tts #200daysofcodingchallenge https://t.co/qWrkpmTcY2

Emerie @emerie_dev

about 1 year ago

Today will be having a tech talk session (TTS) Hosted by @Bruce1Offordile and participants of #200daysofcodingchallenge We’ll also be joined by Winifred Zoyaar, a product manager and web development facilitator based in Ghana. Everyone is invited to come and learn 🤗🤗

Chibuike Divine Offordile @Bruce1Offordile

about 1 year ago

@_bellamond @WZoyaar @Kosiengine @offordilevictor @pascalmonanu @_tappiii @EmmyEdge01 @chigaemezzuu Don’t miss out! Date: 4th May 2024 Time: 8PM WAT Space link: https://t.co/t36AfVdgI2 Set your reminders ready #tts #200daysofcodingchallenge

163

Chibuike Divine Offordile @Bruce1Offordile

about 1 year ago

Roundtable discussion 🔥 Today we had a question session with interns. It was really nice getting to share amongst ourselves nice thoughts. Getting to align our perspective to a desired goal. #200daysofcodingchallenge #tts #roundtablediscussion

Bruce1Offordile's tweet photo. Roundtable discussion 🔥

Today we had a question session with interns. It was really nice getting to share amongst ourselves nice thoughts. Getting to align our perspective to a desired goal.

#200daysofcodingchallenge #tts #roundtablediscussion https://t.co/nHKWinVuAu

Amuul @Amuul13

over 1 year ago

Day-176 #LearnInPublic #200daysofcodingchallenge -->Solved Three LeetCode Problems -->Attended LeetCode Weekly Contest 435 -->Attended Codeforces Round 1002 (Div. 2) #DSA #LeetCode

Amuul13's tweet photo. Day-176
#LearnInPublic
#200daysofcodingchallenge
-->Solved Three LeetCode Problems
-->Attended LeetCode Weekly Contest 435
-->Attended Codeforces Round 1002 (Div. 2)
#DSA
#LeetCode https://t.co/FaeALDA2sk

Blessing||Frontend developer @Chinonyerem1234

over 1 year ago

Day 13 of 100days of coding I attended SUL ON CAMPUS it was a moment of learning more about Blockchain #anambratechies #200daysofcodingchallenge

Anambra Techies @AnambraTechies

over 1 year ago

We've made it to day 13! Keep going even when it gets tough, you're stronger than you think.

375

105

MerlinTheWhiz💡 @madebymichael_

over 1 year ago

I'll like to participate in the 200 days of coding challenge 🔥🙌🏼 @Bruce1Offordile hope I'm not late 🤲🏻 #200daysofcodingchallenge.

Chibuike Divine Offordile @Bruce1Offordile

over 1 year ago

Bruce1Offordile's tweet photo. Register now !

https://t.co/oziF72xodR

Let's goooo

#200daysofcodingchallenge https://t.co/eXJsYMI4es

216

Chima🦉 @_Plane_chima

over 1 year ago

About to start a 200 Days of Coding Challenge with my team! Let's go 🎯 #200DaysOfCodingChallenge @Bruce1Offordile

Chibuike Divine Offordile @Bruce1Offordile

over 1 year ago

To a season of endless possibilities 🎉 Happy birthday to meeee🥺🎊 It been God Always been God The greatest joy is getting to celebrate with family 🥺 This new phase we dive deeper 🤗 Wish me well guysss.... #birthday #200daysofcodingchallenge #codingchallenge