Forem: Opeyemi Stephen

Compressed NFTs in Production: A Campus Tour Case Study

Opeyemi Stephen — Sat, 17 Jan 2026 22:03:18 +0000

520 students attended the Solana Students Africa Campus Tour. We visited five Nigerian universities (University of Lagos, Federal University of Agriculture Abeokuta, University of Uyo, Olabisi Onabanjo University, and University of Abuja) over several weeks in the last quarter of 2025. They learned to build on Solana. Some just attended. Others actually shipped programs on-chain.

We wanted to give them something permanent. Not a PDF certificate that lives in a forgotten email folder. Not a LinkedIn badge. Real, on-chain credentials they own forever. Stored on Solana, verifiable by anyone, and portable to wherever they go next.

Two tiers of recognition. A Participation POAP for everyone who showed up and engaged. And a Builder POAP for those who went further, who actually deployed a program on-chain during the tour. Proof of attendance is meaningful. Proof of execution opens doors.

The Builder credential isn't just a collectible. It's a signal. It unlocks early access to SSA programs, eligibility for builder spotlights, and priority consideration for future opportunities. For students building their on-chain reputation from scratch, this matters.

I minted 214 POAPs (109 Participation and 105 Builder) for a total cost of about 0.05 SOL. Roughly $7. About 6 hours of work.

This is the story of how I built it, what broke along the way, and what I learned.

The Credentials

Participation POAP: awarded to everyone who attended and submitted a wallet address

Builder POAP: awarded to those who deployed a program on-chain during the tour

Why Compressed NFTs?

Regular NFTs on Solana cost around $2 each to mint. That's the account rent, the SOL you pay to store data on-chain. For 200 POAPs, that's $400. For a student organization running campus events, not viable.

Compressed NFTs change the math entirely. Instead of storing each NFT as a separate on-chain account, they use a data structure called a Merkle tree to store ownership proofs. The actual NFT data lives on Arweave, a permanent storage network. The on-chain footprint shrinks to almost nothing.

The result: minting drops from ~$2 per NFT to ~$0.0001. That's a 10,000x cost reduction.

	Regular NFTs	Compressed NFTs
Cost per mint	~$2.00	~$0.0001
200 POAPs	$400	$0.02
Storage	On-chain account	Arweave + Merkle proof
Complexity	Low	Medium
Best for	Small collections, 1/1s	Large-scale drops, credentials

The tradeoff is complexity. You need to create the Merkle tree upfront. You need to upload metadata to Arweave. You need to understand how Metaplex's Bubblegum protocol works. But for this use case (hundreds of POAPs on a tight budget) the tradeoff was obvious.

The Stack

Here's what I used:

Bubblegum: The machine that mints cheap NFTs. It's Metaplex's protocol for compressed NFTs on Solana.
Arweave: Where the images and data live forever. Think of it as a hard drive that never dies and no one controls.
Irys: The delivery truck that gets your files onto Arweave.
Umi: The remote control. It's Metaplex's TypeScript library that lets your code talk to Bubblegum.

No smart contract writing required. Bubblegum already exists on Solana. I just called it from Node.js scripts.

The Architecture

I didn't build a frontend. This was an ops task, not a product. A CLI pipeline made more sense: no users to serve, just data to process.

The system is six scripts, run in order:

Consolidate data: Merge registration data (Luma) with wallet submissions (Google Sheets)
Validate: Check wallet addresses, find duplicates, flag issues
Upload: Push POAP images and metadata to Arweave
Create trees: Deploy Merkle trees on Solana
Mint: Issue compressed NFTs to each wallet
Email: Notify participants with links to view their POAPs

Each script reads from the previous script's output. Config and state live in JSON files. No database. No server. Just Node.js scripts and a funded wallet.

The Data Problem

This is where it gets messy.

Who Opted In

520 people attended across five campuses. We asked them to fill out a Google Form with their Solana wallet address. 122 did. After cleaning invalid entries, I had 109 usable records.

109 of 520 attendees submitted valid wallet addresses. Those are the ones who received credentials. The rest either weren't ready for a wallet, didn't complete the form, or simply didn't opt in. And that's okay. On-chain credentials are opt-in by nature.

"You can't airdrop recognition to someone who didn't raise their hand."

The lesson: on-chain credentials require off-chain onboarding. If you want more people to opt in, you need to meet them where they are. A Google Form asking for a base58-encoded address (Solana's wallet address format) creates unnecessary friction.

Two Sources, Zero Alignment

I had two data sources that refused to talk to each other.

Luma gave me registration data: names and email addresses for 379 people across all campuses.

Google Sheets gave me wallet data: names, wallet addresses, Program IDs (for builders), and GitHub profiles for 122 people.

The problem: names didn't match. Luma had "Oluwaseun Jolaoso." The spreadsheet had "Seun Jolaoso." Same person. Different strings.

I built a fuzzy matching script using Levenshtein distance, a measure of how many edits it takes to turn one string into another. Names with 85%+ similarity matched automatically. Names between 70-85% went to a manual review queue. Below 70%, I assumed no match.

This worked. Mostly. I still had to eyeball edge cases where someone registered with their full government name and submitted their wallet with a nickname.

The Wallet Validation Nightmare

122 wallet submissions. 5 were broken. That's a 4% error rate in "clean" user-submitted data.

The failures were creative:

Solana Explorer URLs: Someone pasted https://solscan.io/account/7xKX...AsU instead of just the address
Clipboard artifacts: One entry read 4nY...xyz copied! because they'd pasted the "copied" toast message
Wrong length: A 45-character address when the max valid length is 44
Invalid characters: Base58 doesn't include 0, O, I, or l. One address had an O.

I built validation into the pipeline:

import { PublicKey } from '@solana/web3.js';

function isValidSolanaAddress(address) {
  try {
    const pubkey = new PublicKey(address);
    return PublicKey.isOnCurve(pubkey.toBytes());
  } catch {
    return false;
  }
}

Anything that fails gets flagged, not silently dropped.

"Never trust user-submitted wallet addresses. Validate before you mint."

The Verification Pivot

I wanted the Builder POAP to mean something. Not just "attended" but "shipped." The original plan was straightforward: query each wallet's on-chain history, look for program deployments or significant transactions during the tour dates.

This worked for about 40 wallets. Then Solana's public RPC (the API endpoint you use to read blockchain data) started returning 429 errors. Too Many Requests. I was being rate-limited.

I could have paid for a dedicated RPC endpoint. But I was already over budget in time, and the deadline was approaching.

Then I looked at the spreadsheet again.

The Google Form had a "Program ID" column. Students who'd deployed a program were asked to paste their Program ID as proof. I'd been ignoring it because I wanted to verify on-chain. But the data was already there. Self-reported, yes, but present.

116 entries had a Program ID that wasn't empty or "Nil." Cross-referenced with my cleaned participant list, that gave me 105 verified builders.

The pivot took ten minutes. The original approach would have taken hours of RPC wrangling and probably still failed.

"Sometimes the answer is in the data you already have."

Cost Optimization

With data cleaned and builders identified, I was ready to create the Merkle trees. This is the upfront cost of compressed NFTs: you pay for the tree once, then minting is nearly free.

I ran the tree creation script. Estimated cost: 7.70 SOL.

My wallet had 0.50 SOL.

The default Merkle tree depth is 14, which supports 16,384 NFTs (2^14). I needed capacity for maybe 300. I was paying for infrastructure sized for a protocol, not a campus tour.

I reduced the tree depth to 9. That's 512 capacity, plenty of headroom for the 214 POAPs, with room for future events. The cost dropped to about 0.02 SOL per tree.

Two trees (one for Participation, one for Builder) cost me roughly 0.04 SOL total. Add upload fees and minting costs, and the whole deployment came in under 0.05 SOL.

The lesson: defaults are configured for scale you probably don't need. Right-size for your actual use case.

Production Day

Pre-flight checklist:

Switch .env to mainnet-beta
Fund the wallet with 0.5 SOL (more than enough with my optimized trees)
Add myself to the participant list (dogfooding)
Run the validation script one more time
Deep breath

I ran the minting scripts. 109 Participation POAPs first. The terminal scrolled with wallet addresses and transaction confirmations. Around wallet 40, I hit rate limits again: 429 errors. But this time I had retry logic with exponential backoff. The script waited, retried, and kept going.

15 minutes later, 109 Participation POAPs minted. I ran the Builder script. 105 more POAPs in another 12 minutes.

Then emails. I used Resend's free tier (100 emails per day). I had 106 to send, so I split across two days. Each email included the POAP image, a link to view it on Solscan, and instructions for finding it in their wallet.

Final cost: ~0.05 SOL. About $7 at the time.

Bugs I Hit

I caught most issues before mainnet. But not all.

Bug	Symptom	Cause	Fix	Prevention
CSV parser	`val.includes is not a function`	Library returned numbers, not strings	Wrap value in `String()`	Type-check CSV outputs
Overwritten file	Lost 30 min of manual edits	Background process overwrote `builders.json`	Re-do the work	Don't run competing processes on same file

Nothing complex. Just the kind of things that happen when you're moving fast with real data.

What I'd Do Differently

Validate wallets at registration. Don't let people submit invalid addresses. Use a library like @solana/web3.js and check PublicKey.isOnCurve() client-side. Show a red border and clear error message ("This doesn't look like a valid Solana address") before allowing submission.

Use a dedicated RPC from day one. Public endpoints are fine for testing. For production, the rate limits will bite you at the worst moment. Services like Helius or Triton cost around $20/month and save hours of debugging.

Build a simple frontend for wallet collection. A Google Form with a text field introduces multiple failure points: partial copies, clipboard artifacts, accidentally pasting Explorer URLs. A Connect Wallet button eliminates all of this. User clicks "Connect," approves the popup, and you capture the address directly from their wallet. Zero manual copying, guaranteed-valid address. This takes about 30 minutes to build. I built it after the fact. Should have done it first.

Add idempotency checks. If the script crashes mid-mint, you should be able to re-run it without double-minting. Store minted wallets in a JSON file and skip them on retry. I didn't build this. I got lucky and didn't need it.

Results

Metric	Value
Total event attendees	520
Wallet submissions	122
Participation POAPs minted	109
Builder POAPs minted	105
Emails sent	106
Total cost	~0.05 SOL (~$7)
Total build time	~6 hours
Time to mint	~30 minutes

What I Learned

Compressed NFTs make at-scale credentials viable. $7 for 214 on-chain credentials is a fundamentally different cost structure than $400+. This unlocks use cases that weren't economically possible before.

Data wrangling is 60% of the work. I spent more time cleaning data, matching names, and validating wallets than I did on the actual blockchain integration. If you're building a similar system, budget accordingly.

Right-size your infrastructure. Don't pay for 16,384-NFT capacity when you need 300. Don't use a database when JSON files work. Don't build a frontend when a CLI will do.

The data you need might already exist. I almost burned hours on RPC calls when the Program ID column was sitting in the spreadsheet the whole time. Look at what you have before building what you think you need.

Eliminate copy-paste errors. Even experienced builders make mistakes when manually copying wallet addresses. A "Connect Wallet" button captures the address programmatically: no clipboard artifacts, no accidentally pasting Explorer URLs, no truncated strings.

What's Next

109 students now have on-chain proof they attended the SSA Campus Tour 2025. 105 have proof they shipped code. These aren't just collectibles. They're credentials that can unlock future opportunities: early access to SSA programs, builder spotlights, and priority consideration for grants and accelerators.

These credentials live in their wallets, permanent, verifiable, and theirs. For some, this might be their first on-chain asset. For others, it's the start of a builder reputation that could open doors to opportunities we haven't even created yet. That's the point of on-chain credentials: they compound over time.

The system I built is open source. The scripts, templates, and documentation are on GitHub. If you're running events, hackathons, or bootcamps and want to recognize your participants with credentials that actually mean something, not PDFs, not emails, fork it and adapt it.

520 attendees. 109 opted in. 214 credentials minted. $7 spent.

The infrastructure is built. The playbook exists. Next time, I'll make opting in even easier.

GitHub: github.com/resourcefulmind/ssa-poap-metaplex

Questions? Reach out @devvgbg on Twitter.

Built for Solana Students Africa. Powered by Metaplex Bubblegum, Umi, Irys, and Resend.

When Payments Own the Base Layer: What Corporate L1s Mean for L2s, and for Africa v2.0

Opeyemi Stephen — Fri, 22 Aug 2025 17:40:58 +0000

TL;DR
The spark (and why I’m writing this)
Baseline: what L2s actually do today (so we measure impact correctly)
Why payments firms might go L1 (and not just “use an L2”)
Africa lens: what could really change (and what won’t)
Scenarios, not predictions (how big could the shift be?)
Dollarization pressure vs domestic units (cNGN, etc.)
Risks & trade-offs (clear-eyed, not alarmist)
Who wins / who loses (by segment)
What to watch (so this doesn’t devolve into vibes)
90-day action plan (operators & builders)
Pushback corner, quick answers to big doubts
Conclusion: track the metrics, not the memes
Sources & methods (selected)

TL;DR

Circle just announced Arc, a stablecoin-native Layer-1 (USDC as gas; EVM-compatible) with private testnet in weeks, public testnet this fall, mainnet beta in 2026. (Circle)

Circle wants USDC to be the engine and the fuel.
Fortune reports Stripe is building “Tempo,” a payments-first L1 with Paradigm; it’s stealth and Ethereum-compatible. Not officially confirmed beyond the report and subsequent coverage. (Fortune, CoinDesk)

Stripe may move from using blockchains to running one.
Today, Ethereum L2s carry ~10× L1’s transaction throughput by user-ops, with Base, Arbitrum, and OPleading; Arbitrum ~$19.2B TVS, Base ~$15.8B. (L2BEAT)

Today’s crypto “busy streets” are L2s, not L1s.
Stablecoins settled >$12T in 2024 and are on track for much more in 2025, the real prize isn’t “users” but dollar settlement at scale. (5264302.fs1.hubspotusercontent-na1.net)
For Africa: this could lower remittance and B2B costs and normalize USD rails—but raises centralization, compliance gating, and dollarization risks. SSA’s average remittance cost is still ~8.37%; any new rail must beat that. (Business Insider Africa)

Faster, cheaper money, if the rules and partners line up.

The spark (and why I’m writing this)

A founder described this event, when it was announced, as “9/11 for L2s.” I don’t endorse that phrasing, but I get the sentiment: when payments companies start owning the base layer, incentives and gravity change. Circle is bringing USDC into the substrate with Arc; Fortune says Stripe is quietly building Tempo. This isn’t “just another chain.” It’s a bid to vertically integrate settlement, fees, FX, and compliance in one place. (Circle, Fortune)

In other words, the companies that move money want to own the road, not just drive on it.

Baseline: what L2s actually do today (so we measure impact correctly)

Throughput: Over the last year, L2 user-ops per second ≈ 10.2× Ethereum L1. In plain English: most activity by count has moved to L2s. Base currently tops the board by activity. (L2BEAT)
Capital: Arbitrum ≈ $19.18B TVS, Base ≈ $15.76B, OP Mainnet ≈ $3.89B (rolling 1-year window). (L2BEAT)

L2s exist to scale existing L1s: cheaper fees, higher throughput, and a familiar developer toolchain. This is why people are anxious: L2s are where devs ship and where users click, they are express lanes bolted onto a busy highway.

Why payments firms might go L1 (and not just “use an L2”)

Control and predictability. If you run the base layer, you can:

Compress the fee stack (less paid “up the chain”).
Ship native stablecoin gas (Arc: USDC for fees) and sub-second finality tuned for merchant UX.
Bake in compliance primitives and FX (KYCable on/off-ramps, programmable rules, fiat pairs).
Reduce vendor ambiguity for enterprises (one throat to choke). (Circle)

Stripe’s reported Tempo fits the same logic: own the moment of settlement for stablecoin payments instead of renting it. It’s cheaper, simpler, and safer (for them) if they run the whole stack. Depending solely on L2s means inheriting upstream fees, governance timelines, and bridge risks. A bespoke L1 reduces those dependencies. If you rent your rails, your landlord sets the rules.

That said, it’s stealth, we have a Fortune report and secondary coverage, not official docs. Treat it as directional, not done. (Fortune, CoinDesk)

Africa lens: what could really change (and what won’t)

Let’s talk about costs and speed. Sub-Saharan Africa remains the most expensive region for remittances: ~8.37% average to send $200 (Q2 2024). If Arc (and possibly Tempo) land credible partners in-country and squeeze spreads with stablecoin-native FX, corridors like NG↔UK/EU or KE↔GCC could finally see structural cost drops and near-instant settlement. That’s the bar. (Business Insider Africa)

You’ll see trials first, not instant miracles. If the pipes connect, sending money could get cheaper and quicker.

As for Rails we already use. Stablecoins are not theoretical here. Nigeria alone saw ≈$59B in crypto inflows (Jul 2023–Jun 2024), with stablecoins a top use case for remittances, savings, and commerce. Corporate L1s will try to formalize what people already do informally. (Chainalysis)

Local infrastructure players. Providers like Blockradar (wallet-as-a-service for stablecoins) and Paycrest(decentralized liquidity/payments network) are the last-mile glue. If Arc/Tempo become default rails, these players either (a) abstract and localize them for banks/fintechs (KYC, payouts, reconciliation), or (b) get disintermediated if corporate L1s ship turnkey SDKs plus local bank partnerships. My bet: Africa still needs local abstractions to connect to Naira/KES/mobile-money reality. (blockradar.co, Mariblock)

The winning play is being the easy adapter, not another chain.

Policy direction. Nigeria has been signaling openness to regulated stablecoin businesses under the new Investment and Securities Act 2025; Kenya’s VASP Bill (2025) is progressing in Parliament. Translation: on/off-ramps will tighten and formalize. That’s good for enterprise adoption, but it also raises the compliance bar for users. (Cointelegraph, parliament.go.ke)

Scenarios, not predictions (how big could the shift be?)

The target isn’t “daily active users”, it’s settlement volume. Stablecoins settled >$12T in 2024 across chains; 2025 is tracking higher. If Arc (and later Tempo) captured even a single-digit share of settlement over time, that’s hundreds of billions annually flowing on corporate L1s, with some of that migrating from L2s, some from L1, and some from non-ETH chains. (Cannibalization won’t be L2-only.) (5264302.fs1.hubspotusercontent-na1.net)

A small slice of a huge pie is still enormous, and it won’t come only from L2s.

In numbers, here’s a conservative scenario using a $12T annual stablecoin-settlement baseline (2024).

Assumption: Global stablecoin settlement ≥ $12T in 2024 (Coin Metrics). This is scenario math, not a prediction.

Share captured by corporate L1s	Annual flow redirected	Monthly flow redirected	In plain terms
5%	$600B	$50B	A sliver of a huge pie is still a big rail.
10%	$1.2T	$100B	Starts to dent L2/L1 and non-ETH settlement.
20%	$2.4T	$200B	Clear structural shift in where value settles.

What decides the number?

Who onboards the banks/PSPs/MTOs in NG, KE, GH, ZA.
FX quality and fee transparency (does it actually beat today’s ~8% benchmarks?).
Exchange listings and market-maker depth (liquidity follows incentives).
Bridges and CCTP-like mechanisms to move balances in/out safely. (Circle)

Partners, prices, and liquidity decide winners.

Dollarization pressure vs domestic units (cNGN, etc.)

Dollar rails are sticky because they solve inflation and FX pain. But cNGN, a Naira-pegged stablecoin from the Africa Stablecoin Consortium operating with CBN oversight via sandbox, is an attempt to digitize NGN and keep commerce in local units where appropriate. It can ease dollar pressure if it achieves real acceptance, corridor liquidity, and easy conversion to/from USD stables in compliant venues. Otherwise, users default to USDC/USDT for depth. (Mariblock, Securities and Exchange Commission)

Net-net: If Arc’s FX and partner stack support cNGN↔USDC cleanly (and similarly for KES/ZAR-pegs), domestic units could coexist with dollar rails instead of being crowded out. That’s a design choice, not a given. (Circle)

Good plumbing lets naira and dollars live side by side.

Risks & trade-offs (clear-eyed, not alarmist)

Centralization & freezing risk. Corporate L1s and centrally issued stablecoins can freeze or block addressesunder orders. That’s essential for compliance, but it’s also exclusion risk for high-friction jurisdictions. (You’re trading censorship-resistance for predictability.) Safer for institutions, but some users can be switched off.
Liquidity bootstrapping. Even with USDC as gas, Arc must win market-makers, listings, and DeFi venues; Stripe’s Tempo is even earlier. Until liquidity is deep, the UX won’t match the theory. (Circle, Fortune)

Empty malls look great on paper.
Bridge and fragmentation risk. Moving value across multiple chains creates attack surface. CCTP-style systems help, but operational risk doesn’t vanish. (Circle)
Policy chokepoints. Real benefit requires licensed on/off-ramps in-country. Nigeria and Kenya are moving, but policy implementation matters more than headlines. Without legal doors in and out, the highway is a dead end. (Cointelegraph, parliament.go.ke)

Who wins / who loses (by segment)

Enterprise fintechs & banks in Africa: Win if they integrate early and pass savings to users; lose if they stall and let shadow channels own the rails. Move first, or play catch-up later.
L2s: Lose some payments settlement over time if corporate L1s nail UX + compliance; still win on DeFi/experimentation and as middleware for other use cases. L2s won’t die; they’ll specialize.
Local infra (Blockradar, Paycrest, etc.): Win by abstracting Arc/Tempo for local compliance and payouts. Lose if they try to compete with base-layer SDKs instead of complementing them. (blockradar.co, Mariblock)

Be the plug, not the socket.
Users: Win on speed and (hopefully) cost; risk hard KYC gating and freezing in edge cases. Faster and cheaper, inside a tighter rulebook.

What to watch (so this doesn’t devolve into vibes)

Milestones: Arc public testnet (fall 2025), mainnet beta (2026); any named African partners (banks, MTOs, PSPs). Official Stripe/Tempo confirmation. (Circle, Fortune)

Dates and logos, not vibes.
Benchmarks: World Bank RPW for SSA corridors, we want sustained drops from ~8% toward <5%. (Remittance Prices Worldwide)

If fees don’t drop, nothing changed.
Share shifts: L2 activity share and TVS (L2BEAT), plus stablecoin settlement share by chain (Coin Metrics / Visa Onchain). (L2BEAT, 5264302.fs1.hubspotusercontent-na1.net)

Follow the money, not the tweets.

90-day action plan (operators & builders)

Pilot a corridor. Pick one high-volume route (e.g., NG↔UK) and run a sandbox: stablecoin collection → FX → local payout. Measure all-in cost (including spread), settlement time, reconciliation errors.

Test a lane before rebuilding the highway.
Abstract the base layer. Whether it’s Arc or an L2, build behind a rail-agnostic interface so you can swap infra as liquidity/fees change.

Don’t hard-code a winner yet.
Compliance first. Align early with Nigeria’s SEC posture and Kenya’s VASP bill trajectory; secure KYC/AMLprocesses and audit trails now. (Cointelegraph, parliament.go.ke)

Paperwork first, then scale. You know what happens if you do not do so, ask those before you.
Merchant UX. Don’t ship “crypto.” Ship predictable receipts, chargeback policies, support SLAs, and Ledger-like clarity on fees.

Sell outcomes, not chains.

Pushback corner, quick answers to big doubts

“Will L2s die?”

No. They’ll likely lose some payments settlement if corporate L1s deliver, but L2s still dominate on throughput and remain fertile ground for apps and experiments. Less Visa, more App Store, as at today. (L2BEAT)

“Isn’t this just marketing?”

Arc has concrete timelines and design choices (USDC gas, FX, EVM). Tempo is still a reported project; all of this as at press time, so treat it as speculative until Stripe goes on-record. Believe shipping code, not press. (Circle, Fortune)

“Will this actually help Africa’s costs?”

Only if licensed partners enable fiat legs and FX spreads compress. The yardstick is the World Bank RPW. Tech helps, policy and partners decide. (Remittance Prices Worldwide)

“What about cNGN?”

It’s real and progressing under a sandbox/oversight model; impact depends on acceptance and liquid FX paths with USD stables. Utility beats branding. (Mariblock, Securities and Exchange Commission)

Conclusion: track the metrics, not the memes

This isn’t an obituary for L2s; it’s a re-segmentation of the stack. If payments giants own the base layer for stablecoin settlement, some flows will consolidate where fees, FX, and compliance live natively. For Africa, that could mean cheaper, faster, more predictable rails, or just new chokepoints if execution and policy stall. The next 6–18 months will tell. I’ll be watching Arc’s partner map, Tempo’s confirmation, RPW costs, and where stablecoin settlement actually lands. This can be a win, but only if pipes, partners, and policy line up. (Circle, Fortune, Remittance Prices Worldwide, 5264302.fs1.hubspotusercontent-na1.net)

Sources & methods

Circle: Arc announcement and timelines. (Circle)
Stripe/Tempo: Fortune report; subsequent coverage. (Fortune, CoinDesk)
L2 metrics: L2BEAT activity (UOPS scaling factor) & value secured snapshots. (L2BEAT)
Stablecoin settlement: Coin Metrics (>$12T in 2024; higher in 2025). (5264302.fs1.hubspotusercontent-na1.net)
SSA remittance costs: World Bank RPW; Q2 2024 SSA average 8.37%. (Remittance Prices Worldwide, Business Insider Africa)
Nigeria adoption: Chainalysis Nigeria ~$59B (’23–’24). (Chainalysis)
Policy: Nigeria SEC stance and ISA 2025 signals; Kenya VASP Bill (official PDF). (Cointelegraph, parliament.go.ke)
Local rails: Blockradar (site); Paycrest (founder interview). (blockradar.co, Mariblock)

Why Web3 Keeps Losing Users (And How We Actually Fix It in 2025)

Opeyemi Stephen — Tue, 08 Apr 2025 14:20:33 +0000

Introduction: The Promise and the Problem

Web3 promises a decentralized future, blockchains, NFTs, DeFi, DAOs - they’re reshaping how we own, trade, and interact online.

Yet most projects do “absolutely everything but tell the user at a base level what to do.”

Need examples?

Take MetaMask’s cryptic setup. Or OpenSea’s infamous wallet wall during the NFT boom. Newcomers get lost in the maze. The fallout? High drop-off, niche users, and Twitter posts calling Web3 “too hard” or “a scam.”

The tech’s revolutionary, but if no one can use it, what’s the point?

This is a call to action. Web3’s adoption hinges on fixing onboarding. It should be on a T-shirt by now…“Onboarding matters” - and sold out already. But there’s still no real headway.

In this piece, I talk about why MetaMask(wallet) confusion, NFT churn, and DeFi drop-offs aren’t bugs, but signals we need to fix onboarding at the root. With 3 fixes grounded in 2025 reality. Here’s why it’s broken, who’s stumbling, and how to get it right.

Introduction: The Promise and the Problem
The State of Web3 Onboarding: A Few Ugly Truths
The Founder Factor: Caught in the Builders’ Trap
The Stakes: Adoption or Bust
Ideas to Fix It: A Blueprint for Better Onboarding
- Fix 1: Reverse Onboarding, “Experience First, Wallet Later”
- Fix 2: Web3-Wide User DAOs — “Onboarding as an Incentivized Coalition”
- Fix 3: Persistent AI Concierges, “Web3’s UX Co-Pilot”
The Payoff: Web3 for Everyone
Counterpoints: The Pushbacks You’ll Hear (and How They Fall Apart)
- 1. “Onboarding’s a Feature, Not a Bug, Web3’s Meant to Be Hard”
- 2. “We’re Still Early”
- 3. “Builders First, Users Come Later”
- 4. “Decentralization Means No One Owns Onboarding”
- 5. “Focusing on Newbies Slows Innovation”
Conclusion: Founders, Break the Bubble

The State of Web3 Onboarding: A Few Ugly Truths

Web3 projects consistently botch the basics. Real examples tell the tale:

MetaMask: Install it, get a seed phrase, then…silence. No nudge to buy ETH, no gas primer. X users ask, “Set it up, now what?”
OpenSea: No wallet? No help. Got one? Here’s a flood of listings, no guide. DappRadar’s 2023 stats show most first-timers never buy.
Uniswap: “Liquidity pools” and “slippage” with zero context. Twitter threads: “Tried swapping, gave up.”

Why? Many devs assume blockchain fluency. Rushed launches favor hype over UX. The “community will sort it out” mindset skips design. But the root runs deeper, I would know as I have been in these “war rooms” a few times myself.

The Founder Factor: Caught in the Builders’ Trap

Founders drive Web3’s vision, but they’re tangled in a double bind.

UX pros, product leads, and designers push for onboarding: “Users need this, or they’ll bounce!” Yet founders often lean on speed, ship the MVP, hype the token, patch later.

“Early adopters get it,” they say. It’s a startup reflex: move fast, fix on the fly. Understandable, but it’s not the full picture.

Too many founders build ecosystems, not for end users, but for other builders, caught in a recursive loop where focus where the focus never leaves the mirror.

FUEL kicked off as an Ethereum rollup, now a modular layer with FuelVM and Sway, parallel processing and dev-friendly tools galore. It’s a builder’s dream, but onboarding’s a slog for normies; Twitter posts in 2024 ask, “Cool tech, but how do I use it?”

Polkadot offers a “blockchain of blockchains” for devs to plug in parachains, yet its wallet and docs stump regular folks.

The Sandbox hands creators a metaverse toolkit, but casual players drown in NFT jargon.

Optimism scales Ethereum for dApps, but “rollups” mean nothing without a lifeline.

Builders build for builders who build for more builders, who then build for even more builders while they all promise the next builder will bring in the users, users get left behind.

It’s not malice though, it’s perspective. Founders swim in Web3’s bubble…crypto X, Discord, meetups, where everyone’s a coder or speculator. They assume that’s the crowd, so dev tools and “ecosystem potential” outrank entry points. A certain Layer 2’s $81.5M raise hyped scalability, not usability.

UX gets sidelined. Onboarding is seen as grunt work, not a VC dazzler. Failed 2022 NFT drops show the cost: dead not from bad tech, but from stranding users.

The crypto-nerd pool’s drying up, mass adoption won’t wait for insiders to pivot.

The Stakes: Adoption or Bust

This isn’t nitpicking, it’s make-or-break. DappRadar pegs Web3’s daily active wallets at an average of ~26.4 million in 2024 year-end. (We all know what those wallets really are). Web3’s complexity isn’t the hurdle; its refusal to bridge the gap is. Somehow, we keep refusing to meet users halfway. And the longer it ignores onboarding, the more glaring the fallout becomes.

Nowhere is this clearer than in the NFT space.

Despite early hype, NFT trading volume in 2024 saw its weakest performance since 2020. According to DappRadar’s quarterly breakdown, volumes surged in Q1 to over $5.3 billion, only to plummet to $1.5 billion in Q3, before rebounding slightly in Q4.

The sales count tells a deeper story. Even when volume rose in Q4, sales continued to decline, indicating fewer users transacting and NFTs becoming pricier—likely due to ETH’s price hike. The result? Newcomers saw a confusing, expensive market with little help navigating it.

Zooming out to the yearly view, 2024 recorded a 19% drop in trading volume and an 18% decline in NFT sales compared to 2023. It marked one of the worst years since the NFT boom began.

The message is clear: with the current systems of onboarding, even the most hyped verticals bleed users.

Ideas to Fix It: A Blueprint for Better Onboarding

Documentation’s a start, but users won’t read it. Web3 needs active, intuitive solutions:

Guided Onboarding Flows

UI steps, “connect wallet here,” “fund it this way.” MetaMask could prompt ETH buys; OpenSea could demo an NFT purchase. The things the “gigabrains” think are not needed are actually very much needed.
Smart Defaults

Pre-set gas or slippage for beginners. Uniswap’s “safe swap” mode; OpenSea’s affordable NFT nudge. Ease in, don’t overwhelm.
In-App Education

Tooltips (“gas pays for this”), quick videos, gamified tasks like “swap your first token, earn a badge.” Active learning trumps passive docs.
Seamless Wallets

One-click setups could actually help. Imagine OpenSea bundling MetaMask with $5 in ETH. One click, zero friction. Cut friction, keep users.
Feedback Loops

“I don’t get this” buttons for real-time fixes. DAOs fund what users flag. Decentralized doesn’t mean clueless.
Concierge Layer

AI is all the rave now and rightly so. Why not temporary chatbots “how do I buy this?” Phase it out as tech and user matures.

The usual advice above - better docs, smart defaults, cleaner UIs, is of course table stakes by now. Those aren’t strategies. They’re hygiene.

I have always maintained that if Web3 wants to escape its own echo chamber and onboard millions, it needs to stop iterating on dev-first workflows and start designing for human-first experience.

Here are three deep, Web3-native fixes, not based on hope, but built from what’s live and loud in April 2025. They reflect the actual friction, tools, and behavior happening right now across DeFi, DAOs, gaming, NFTs, and infrastructure.

Fix 1: Reverse Onboarding, “Experience First, Wallet Later”

My Premise? Right now, onboarding starts with what users hate: wallet setup, seed phrases, network switches, gas fees. The friction hits before they’ve felt any value.

So let’s flip it.

Instead of forcing new users to configure crypto tools upfront, they first play in a safe, sandboxed version of your product — with no wallets, no real tokens, no cost or commitment. Think of it like a simulation that’s fun and frictionless, where the value is felt immediately.

How It Works(Ideally):

Projects launch experience-first sandboxes on testnets. A user enters without connecting anything. They’re assigned a temporary “shadow wallet” and fake tokens (e.g. test ETH, FuelCoins, etc). They can:

Swap tokens on a mock Uniswap
Mint and trade NFTs with no gas fees
Cast votes in DAO simulations

Only once they’ve completed a few actions does the product say:

“Looks like you’re ready. Want to keep your progress and go live?”

One tap bridges the sandbox wallet to mainnet, seeds it with a starter amount via LayerZero or Alchemy Pay, and boom, they’re active Web3 users!

Why This Matters:

You’re not asking users to read before they ride. You’re letting them feel the power of Web3 before asking for trust. It’s UX-as-a-hook.

Real-World Signals:

Axie Infinity proved “play-first” onboarding can bring in millions—then lost them to wallet friction.
Sandbox Metaverse has a $1B valuation but onboarding still kills retention.
Testnets are developer tools today. We make them user gateways.

The Impact? Even a 10% stick rate from sandbox-to-mainnet could mean millions of new users.

From “Sign up to learn DeFi” → “Play DeFi and learn by doing.”

Fix 2: Web3-Wide User DAOs — “Onboarding as an Incentivized Coalition”

My Premise? No single dApp owns onboarding, but every dApp suffers when it’s ignored. So instead of scattered, siloed efforts, imagine a cross-project, token-incentivized User DAO model, funded and governed by the protocols that benefit from adoption.

How It Works(Ideally):

Web3-native onboarding DAOs, let’s call them uDAOs, form to coordinate onboarding across ecosystems. Aave, Polkadot and others pool a small slice of treasury (~1%) to fund them. In return:

New users get a pre-linked wallet
They complete a chain of onboarding tasks (e.g., swap, mint, stake)
They earn a utility token, say, $USER, that unlocks vesting rewards over time

Participation is on-chain, gamified, and visible. uDAOs collect user friction points, push product feedback upstream, and manage mentorships or tutorials like an L2 support layer, but decentralized.

Why This Matters:

This isn’t a loyalty program. It’s a coalition for collective onboarding, backed by incentives and shared governance. It creates an entry layer built by users, for users, but funded by protocols that depend on adoption.

Real-World Signals:

MakerDAO partnered with Huntingdon Valley Bank (HVB). DAOs aren’t toys anymore.
Aave’s $27.45B TVL shows liquidity flows to where users are incentivized.
Polkadot and Axelar’s multichain infra can handle cross-ecosystem rewards.

The Impact? Even 100 projects contributing can fund 1M+ new wallets a year.

It’s the Web3 version of shared infrastructure, but for people instead of data.

Fix 3: Persistent AI Concierges, “Web3’s UX Co-Pilot”

My Premise? Wallet UX hasn’t fundamentally changed in years. Every app assumes the user understands gas, L2 bridging, asset security, slippage, transaction history… the list goes on.

But what if an AI agent embedded in every major dApp could act as your co-pilot—learning how you use Web3, explaining actions in plain language, and even executing low-risk commands for you?

How It Works:

Call it a Web3 Concierge Agent, an AI layer that lives inside MetaMask, OpenSea, Axelar, Uniswap or any other protocol/project. It’s personalized. It has memory. It reads your wallet and the current app context.

Examples:

“Gas is 0.013 ETH right now. Want me to submit the transaction when it drops to 0.009?”
“You’re swapping ETH for USDC. Want me to confirm the slippage is safe?”
“Need help? You tried this 3 times, want a walkthrough?”

It doesn’t just explain, it takes action with permission. All interactions are logged transparently. These agents could be open-source and deployed via Optimism’s sequencer model or similar trustless infra.

Why This Matters? Even experienced users lose money to gas mistakes and bridging errors. For beginners, this AI layer is the difference between "I gave up" and "I got through."

Real-World Signals:

Chainlink’s oracles have exploded in AI-integrated data services.
SingularityNET and Fetch.ai already explore autonomous agents.
Wallets like Rabby and OKX are toying with UX nudges—but lack true AI memory/context.

The Impact? An AI concierge could reduce onboarding friction by 70%+.

You don’t need to read another tutorial, you just need someone (or something) that knows what you’re doing and helps you do it better.

The Payoff: Web3 for Everyone

These aren’t tweaks, they’re trajectories. They don’t require centralization. They require creativity, coordination, and courage.

This flips Twitter posts from “impossible” to “Web3 finally gets it.” Newbies stay, pros thrive, Web3 grows. It’s not dumbing down, it’s opening the door.

Counterpoints: The Pushbacks You’ll Hear (and How They Fall Apart)

No good critique lands clean without acknowledging the friction. Web3 folks will have rebuttals, and some of them are valid. Let’s walk through the most common ones.

1. “Onboarding’s a Feature, Not a Bug, Web3’s Meant to Be Hard”

Some will argue that complexity filters for commitment. “Early Bitcoin adopters didn’t need step-by-step guides, they figured it out”. Builders say ease-of-use risks watering down the ethos. Sway, FuelVM, or parachains? They're not for casuals, they're for the technically curious.

Why It Comes Up? The DIY, cypherpunk roots of crypto treat accessibility as an afterthought. You’ll see this sentiment on X:

“If you can’t figure out MetaMask, you don’t deserve DeFi.”

That gatekeeping mindset made sense in 2013, not in 2025. Bitcoin didn’t scale because it got harder, it scaled because wallets got easier.

Complexity for builders is fine. But users? They need a ramp, not a wall.

2. “We’re Still Early”

Everything's still experimental. Expecting polish during infrastructure phase is premature. Ethereum was rough at launch too, look where it is now.

It’s our default cop-out. “It’s early” is used to deflect critiques and buy time.

Early was 2017. It’s been a decade. The space has matured, funding has flowed, is flowing and will still flow(maybe not as much), and users expect more. Web2 doesn’t wait, and users won’t either. Mass adoption won’t happen while we act like it’s still day one.

3. “Builders First, Users Come Later”

Our current 2024 and 2025 mantra. Prioritize devs. Nail the tools, stack the ecosystem, and users will follow. MetaMask didn’t show up on day one, Ethereum still flourished.

Why? VCs fund protocols, not UI. Founders are told to scale infra first, UX later. “L2s are infra, not apps” is a common refrain.

That playbook worked once. The space is too crowded now for “build it and they will come.” Look at Arbitrum’s growth, strong onboarding brought TVL and developers. Good UX isn’t the opposite of good tech, it accelerates it.

4. “Decentralization Means No One Owns Onboarding”

There’s also the argument that in Web3, no one’s supposed to own the funnel. Let wallets, DAOs, or the community do the lifting. If a dApp takes over onboarding, it risks becoming Web2 again.

The truth as to why that comes up is not far fetched. Decentralization is the hill many will die on, anything that smells like “top-down” draws fire.

Guidance isn’t centralization. UX doesn’t mean giving up control, it means giving people clarity. The idea that “the community will figure it out” is great until no one actually does. Even in a trustless system, users still trust someone to show them the front door.

5. “Focusing on Newbies Slows Innovation”

Heard this at an offsite last year, and it floored me. Time spent making Web3 easier is time lost from cutting-edge tech, ZK-rollups, modular execution, parallelism and every other lingo we can think about. Onboarding is busywork for interns.

There’s a cultural divide: builders vs. UX folks. Twitter is full of devs lamenting time “wasted” on education when they could be shipping.

What good is innovation no one uses? Onboarding isn’t dilution, it’s acceleration. If you want 100x adoption, you need more users.

More users = more builders = more feedback = better protocols.

Ethereum didn’t explode because of cryptography, it exploded because people could use it.

The tech is mature. The excuses aren’t.

You don’t lose decentralization by helping people onboard.

You lose users by leaving them in the dark and calling it “freedom.”

Purists might cry “centralization!” Concierges and defaults lean that way, sure. But it’s a stepping stone, early help fades as users learn. The alternative? Stay niche while Web2 tears us a new one with each passing day.

Conclusion: Founders, Break the Bubble

Web3’s potential is massive, but its onboarding is a chokehold. Projects doing “everything but the basics” aren’t quirky, they’re floundering.

Founders, you’re not villains, you’re just stuck in a trap. The builders-only lens and shifting focus to doing what everyone else in the herd is doing - chasing every flashy trend. It doesn’t scale with the vision

Listen to your pros, prioritize users, and build for people, not just blueprints. With guided flows, smart design, and pragmatism, Web3 can onboard the masses without losing its soul.

The tools are here. The stakes are clear.

Stop chasing the echo chamber—start welcoming the world.

Web3 has the tools.

It has the capital.

It has the builders.

It just needs to stop leaving its users at the door.

Late to React 18? My Top 4 awesome features and real-use examples.

Opeyemi Stephen — Fri, 08 Jul 2022 17:23:17 +0000

Reading this, you probably know what React is and might have upgraded to React 18. This article is aimed at informing code newbies in detail and increasing beginner understanding of the awesome feature updates of React v18.0 which I discovered while using it myself.

First up, what is React?

React is an open-source, JavaScript front-end library for building user interfaces. It works fast, is easy to learn, and is efficient, especially in creating scalable and reusable UI components.

Back in March, the React team announced the release plan for the upcoming stable version of React. With that being said, let’s explore...

You might have to upgrade to React 18 if you haven't already done that.

How to upgrade to React 18.

Install React and react-dom. You can use npm and then create a react application here.
Change ReactDOM.render to ReactDOM.createRoot. Do this by finding the index.js file in the root and changing accordingly:
Create root with
const root = ReactDOM.createRoot(container);
Render app to root with
root.render(<App />);
Root is how React updates the DOM tree. It makes all of the new features such as concurrent rendering and automatic batching available to the developer.
New features and concurrent rendering will be turned off if the root isn’t added. The app will behave like it’s on React 17.

So what changed?

With React 18, the concept of Concurrency/ concurrent React is no longer all-in or nothing as you can pick wherever you want to have the concurrency feature enabled. It doesn’t have to be bound to the entire app
The new features of v18 include:

Automatic Batching
Transitions
Suspense on the server.

Automatic Batching:

This is simply making a list of items so you can perform a list of micro-tasks at once. React does not have to spend time re-rendering the same work over and over again when it can do it at the end of the micro task.

Take a look at the code block of the event handler with 3 set states below;

function handleClick() { 
  setIsFetching(false); 
  setError(null);
  setFormStatus(‘success’);
 };

React could batch all three, look at them one by one and re-render them in the previous version. What React couldn’t do was batch and re-render anything that wasn’t an event handler like an async callback or a promise.
React 18 fixes that as all updates, even within promises, the function will be batched which will improve the performance of the app.

Concurrency:

It is a feature by which React can pause and resume rendering events to improve performance.
For instance, say you have a work call with a teammate in your team and your wife calls you while on the call for an urgent conversation. You can leave the call with your teammate, go on to speak to your wife, and then come back to the call. That is Concurrent rendering.

It is the ability for React18 to interrupt, pause or abandon a render in order to improve performance or perform urgent updates.

Rendering was a single synchronous task that could not be interrupted once started before React 18.
Concurrent rendering can be said to be a technical foundation that most features of React18 are built upon.
It happens behind the scenes and the dev doesn’t need to bother about it.
It enables React to prepare multiple new screens.
It also enables reusable state, such that sections of UI from the screen can be removed and added back later while reusing the previous state, for example, tabbing away and coming back to the screen.
Concurrent mode before React 18 usually meant that concurrency was used in all of the app but now it is used in only the parts the dev wants. Cool right?

Transitions:

This simply means how you as a dev instructs React to prioritize certain updates and mark non-urgent updates as transitions.
Take a random google search for instance, two feedbacks from character and population of the query are two different experiences a user would have.
Transitions will help to prioritize the display of characters typed in by the user as urgent and then the query as a non-urgent priority.
This can be quite helpful for people with slow computers or slow internet connections.   Anything that is an urgent state is put in a normal state and anything that is not urgent is put in a startTransition.

import { startTransition } from ‘react’;

// Urgent: show what was typed
setInputValue(input);  // Mark any state updates as transitions

startTransition(() => {
   // Transition: Show the results    
   setSearchQuery(input);
});

This means that if a user for instance is searching for the term “Soccer”, the transition will prioritize displaying the letter “s” and other letters after every keystroke before querying the search parameters.

And if you want to do something while transition is happening, you can use a hook called useTransition that gives access to two parameters, isPending and startTransition. Real-life use cases?

isPending can be used for loader states
startTransition can be used when there is a slow rendering from maybe a heavy data app like Slack or Jira, startTransition can help. startTransition can also be used in cases where the network is slow but with libraries like Relay which has it in-built because it needs Suspense.

Suspense on the Server

In React 18, it is now powered by code-splitting too. What this means is that, take, for instance, you have an app and certain parts of your app are really slow, in the other versions of React, you had to wait for the app to finish loading completely before the HTML could be shipped. (before the entire rendering process could be done and shipped to the client-side).
Recall that server rendering is simply when HTML is created on the server and sent over to the client. It helps end-users in the sense that they can see at least a UI much faster than any other thing like JS has been loaded as opposed to rendering on the client-side.

However, despite that seeming improvement brought, certain components could not be isolated/split, and the rest "server-rendered" separately. It was all or nothing.
With React 18, if one part of your app is slowing down the rest of the app, you can put that component in suspense and tell React to load that particular component separately and send the rest of the page to the user while that isolated part can get a loader or spinner state.

When that part is ready, React 18 will send the HTML in the same stream and it all happens before any JS is loaded so it is pretty fast for the user and decreases the time it takes for the user to see the first page. Do not forget images to represent server rendering.

<Suspense fallback={<Spinner />}>
   <Comments />
</Suspense>

In summary, suspense on a server will make sure:

one slow part of an app or page doesn’t slow down the whole page
to show initial HTML early and stream the rest
code splitting fully integrated with server rendering is achieved

Other awesome changes of React 18 include:

Client-side features include changes from render to createRoot, unmountComponentAtNode to root.unmount and ReactDOM.Hydrate to hydrateRoot.
React 18 also has hooks like useId, useDeferredValue, useSyncExternalStore, useInsertionEffect which are new Library APIs.
Server API changes include renderToPipeableStream(Node) and renderToReadableStream.(edge env).
Updates have also been made to strict mode
ReactDOM.render and renderToString have been deprecated.

How does it affect the codebase when updated? The React team has stated that;

The code should work just fine.
Some components might behave slightly differently with concurrent rendering.
Some components may require migration efforts.
New rendering behavior is only enabled in parts of your app that use new features.

What Strategy to update when upgrading to React 18?

Upgrade to React 18 without breaking code.
Gradually start adding concurrent features. Use a library that powers concurrent features
Use StrictMode to surface concurrency-related bugs in the dev environment.
Start using concurrent features after upgrading to React 18. Overall, most apps should work fine after the upgrade without too many issues.

Edge cases to watch out for

StrictMode is stricter but can be disabled
flushSync() will disable automatic batching
Concurrent features might require library updates.

That's all for now. I hope this helps a newbie get comfortable with React 18.
So I decided to do this thing where I refer you to a song at the end of every article because what's coding without a little music. Others give lofi, I recommend Afrobeats. For this article's edition, I recommend listening to the new Burna Boy album titled Love, Damini.
PS: These things are not sponsored, I just want to share good music while giving you great articles.

Level Up Your Skills By Mastering Git, Github, and The Terminal.

Opeyemi Stephen — Sun, 05 Jun 2022 23:34:20 +0000

This article is intended for beginners and for those who want to get started on learning about Git technology.

I could have made a title like "Learn Git in 5 minutes" but nobody can really understand the basics of Git at that time.

Git can be really scary for new developers and many make the mistake of trying to learn/cram the syntax instead of first understanding the Git technology and workflow.

I will break Git down into the simplest terms I know and in the end, you will have more confidence in using Git, whether through the terminal or using a GUI.

Let’s get started!

What is the Terminal?

It is a place where you type commands on the computer that cause actions.

What is a CLI?

It is short for Command Line Interface. It is the actual place where you type the commands to use the computer. What you see in most Sci-Fi movies like The Matrix. A good example is the Apple II

What is a GUI?

It is short for the Graphical User Interface. That is tech jargon for the computer with the screens that you see these days with the beautiful folders and screens and stuff.

For macOS, you probably already have a Terminal on your system. (Applications --> Terminal)
For Linux, you can download it
For Windows, you can download GitBash and later on you can use WSL (Windows Subsystem for Linux)

Common Commands On The Terminal

Some common commands on the Terminal are:

pwd stands for "Print Working Directory" and it will show the user where they are inclusive of the path. A directory simply means folder as well.
mkdir stands for "Make Directory" and will create a folder.
cd means "create directory" and enables a user to open a new folder. eg cd Desktop
cd .. will make the user go up a level in the directory path. It's like going from a child-folder to the immediate parent-folder.
cd will take you inside a folder and cd .. will take you out one level from child to immediate parent.
cd ~ will take you all the way back to the home folder
cd <folder>/<subfolder>/ is used when you want to proceed to a specific path.
clear will clear the terminal.
touch <name-of-file> will create a new file eg touch index.html
ls will show you a list of all the files contained in the current folder at any given time.
ls -l will give us the list and more information like the name, the date of creation, and permissions on the file
ls -la will show you the list and all the information about the files including the hidden stuff.
rm <name-of-file> will remove a file. eg rm index.html.
rm -r <folder> will remove/delete a folder.
rm -rf <folder> will remove forcefully/permanently.
code <filename> will open a file in VScode.
The user has to go to the command palette in their VS code --> View --> Install code command with PATH and then they can use this if they are using macOS

Now that we know some commands on the CLI, let's talk about GIT.

Why is GIT important?

Recall that before the advent of modern technology as we know it, saving documents on your computer, say a Micorsoft Word file would have been done via the following ways:

Floppy Disks
Flash and sometimes hard drives depending on your level of paranoia, lol.
Saving it and e-mailing it to yourself and sometimes to others because you know your computer might be bad or because you want to collaborate with them.
Other ways which I am sure you are thinking about in your mind now.

The above ways were the early days of what we know now as "Version Control".

Git solves this version control problem for our codes and right now some people like myself even keep my notes on there too. Other types of version control are Google Drive, etc

How does Git work?

Git is a version control system that gives a user the ability to make "save points" and track changes to code that you or your team members make.
Save points are snapshots of your code at different times while you are working.

A more concise definition would be that Git is a distributed version control system (DVCS) that allows multiple developers or other contributors to work on a project. It provides a way to work with one or more local branches and push them to a remote repository. Git is responsible for everything GitHub-related that happens locally on your computer. Key features provided by Git include:

It's installed and used on your local machine
Handles version control
Supports branching

WHILE

GitHub is a cloud platform that uses Git as its core technology. It simplifies the process of collaborating on projects and provides a website, command-line tools, and overall flow that allows developers and users to work together. GitHub acts as the "remote repository" mentioned previously in the Git section.
Key features provided by GitHub include:

Issues
Discussions
Pull requests
Notifications
Labels
Actions
Forks
Projects

Git makes it possible to make those save points and to also place those save points on servers like Github so you can share your code with everyone for easy collaboration.

Git also enables the user to be able to backup these save points on the cloud in case the user somehow loses access to all the data and files on their local machine.

Git also enables you to rollback your code to previous versions. Say you wrote a bunch of code and you want to take it back because you have sort of written rubbish (we all do that, you are not alone), Git gives you this power.

Some Git Terminologies

commit is what enables the user to make that snapshot(create that save point). Sort of the same thing like the user zipping up the file and emailing it to themselves back in the day.
branch is like a bus-stop that leads to a street. You are on a journey on the main road for instance, a git branch is the bus-stop you get down and start walking into the street...You can always get back to the main road if you hit a dead end at the street or you can always discover a new path and add it to your map(merging the branch with the main file).
repository is the special folder that holds all of your snapshots(commits). There is a local repository which is the folder on your PC(local machine) and then there is the remote repository which is going to be in the clouds, i.e on Github and where your codes are going to live. Also called repo.

How To Install Git

For Windows, visit Git Bash or WSL.
For mac OS, you can first install homebrew by entering this in your command line when you open your terminal

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

And then install Git using

$ brew install git

NB: take note that you are not to use the $ sign when you see it in a code entered. The $ sign is simply telling you to enter the code after it and not before it.

For Linux If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the package management tool that comes with your distribution. If you’re on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use dnf:

$ sudo dnf install git-all
If you’re on a Debian-based distribution, such as Ubuntu, try apt:

$ sudo apt install git-all
For more options, there are instructions for installing on several different Unix distributions on the Git website.

What to do after git is installed;

Enter this in your command line almost immediately after Git has been installed

git config --global user.name "<your name>"
git config --global user.email "<preferably the email you used in signing up for github>"

The above commands will be able to place a tag of your identity whenever you make a commit and tell anyone looking at the code where you have made a commit or written a piece of code.

Also, you can see other people's commits too so it helps when you are in a team as well.

Basic Git Commands

It is important to note that these are not all the commands but will get you on your merry way into the exciting journey of Git.

git init will create that special folder to hold all your snapshots and if you check with ls -la you can see the folder along with other folders in your repo.

git add <file> will add whatever file you want to take a snapshot of to what is called a staging area. Think of a staging area as you putting all your files in one file jacket first before putting it in the special folder(repository) and sending it to your safety deposit box(Github). Kindly note that you can add these files one after the other or you can use git add . to add all of the files at once.

git status will show you the items that are in the staging area and ready to be committed(ready to have their snapshots taken). Items highlighted in green are the ones in the staging area and ready for a commit while the ones in red are the ones still on the local machine that haven't been added to the staging area yet.

git rm --cached <file name> will enable a user to remove a file from the staging area.

git commit is used to take the snapshot of everything that's in the staging area.
Ideally commits should always have a message which would inform anyone reading about the code on what has been done so you will often see something like this;

git commit -m "<add text>"

Make sure to always use the Ideal so you don't get stuck in the terminal's editor. If you get stuck there however(by typing just git commit), use the steps below

i --> <type commit message> --> escape --> type :wq --> Hit Enter

Once you hit enter after that, you just successfully took your first snapshot. It's like checkpoints in a game. When the power goes out or you get tired, you can always come back to meet your code at the last point you were.

Whether you are adding more changes to the new file or creating a new file all together, you just have to repeat the process again to make a new commit.

Why is this important?

This is important because as a developer, you need to have a last saved point before you tackle a new and almost always more difficult feature.

Github typically expects a user to be on the branch "main" instead of the old "master" version.

You can do that by entering the following command to switch from "master" to "main"

git branch -M main

More on Branches

Sometimes, you don't want to roll back your code but you want to try a feature that might be risky or mess up the code.

This is where the branch comes in. You can move away from your code with a copy of everything intact and work on something else so even if you make a mistake, it does not affect the original version of the code.

If it works out well, you can merge that branch with the original code and if it does not, then you can just delete the branch.

To create a new branch,

git branch <name of new branch>

After creating this branch, then you have to move it to where you can make changes without affecting the rest of the code. This is what "checkout" does as shown below;

git checkout <branch name that was just created>

When you do a git status, it shows you that you are this new branch you have just created so you can keep working for as long as you want and make your changes without affecting the original code.

Now you add and commit as usual.
But let's say those changes you were trying to make turned out to be a dead-end and you just want to go back to the original code, all you have to do is type the code below to take you back to where you were before

git checkout <name of branch you want to go back to>

You can do stuff you want to do and if you do not like it, you can just go back to where you started.
Let's say that you were successful with your new feature or changes you were trying to make and want to add the new branch to the original code, you do the below;

git merge <name of branch>

Ideally, as a junior engineer, you might only get to do this when you are working alone and on your personal projects. You will usually be required to push your changes/features of the new branch to the repo and open up a Pull Request where a senior will review your changes and then do the merging.

What next after the commits?

After saving your snapshots, it is always advisable to take those snapshots and put them in the remote repository which is on Github. Github makes collaboration easier with other engineers.

Make this a rule

"ANYTIME YOU MAKE A CHANGE, PUSH YOUR CHANGES TO YOUR REMOTE REPOSITORY"*

So how to push?

Go to your Github and create a new repository (Look for the plus sign)
For the sake of convention, make sure the name of this Github repository is the same as the one on your local machine.
After naming, you can add a README.md to give a description of what happens in the repository.
Then you add remote (where you want to send it in the clouds on Github) by using:
git remote add origin <link to repo>
After this, input the below command to make the first git push to the online repository.
git push -u origin main

Subsequent file pushes can only then be made for that repo by just using git push.

If you want to host your new code online for free, open a new branch on the online repo called gh-pages and then you can view your live link by entering this in your browser

.github.io//index.html

Make sure it is the exact same name

Just like that ladies and gentlemen, your code has been stored safely in the cloud, it is in public and can be seen. I bet you feel like a hacker now right? You are no longer a beginner, lol.

Additional Notes

When you create a pull request, include a summary of the changes and what problem they solve. You can include images, links, and tables to help convey this information. If your pull request addresses an issue, link the issue so that issue stakeholders are aware of the pull request and vice versa. If you link with a keyword, the issue will close automatically when the pull request merges.
There are two primary ways people collaborate on GitHub:

Shared repository
Fork and pull

With a shared repository, individuals and teams are explicitly designated as contributors with read, write, or administrator access. You most likely achieve this by cloning the repo.

For an open source project, or for projects to which anyone can contribute, managing individual permissions can be challenging, but a fork and pull model allows anyone who can view the project to contribute.
A fork is a copy of a project under a developer's personal account. Every developer has full control of their fork and is free to implement a fix or a new feature.
Work completed in forks is either kept separate or is surfaced back to the original project via a pull request. There, maintainers can review the suggested changes before they're merged.

You can find a full git cheatsheet here

What are Issues?

Issues are where most of the communication between a project's consumers and the development team occurs. An issue can be created to discuss a broad set of topics, including bug reports, feature requests, documentation clarifications, and more. Once an issue has been created, it can be assigned to owners, labels, projects, and milestones. You can also associate issues with pull requests and other GitHub items to provide future traceability.

What are Pull Requests?

A pull request is a mechanism used to alert that the commits from one branch are ready to be merged into another branch. The developer submitting the pull request will often request one or more reviewers/maintainers to verify the code and approve the merge. These reviewers have the opportunity to comment on changes, add their own, or use the pull request itself for further discussion. Once the changes have been approved (if approval is required), the pull request's source branch (the compare branch) may be merged in to the base branch

What are labels?

Labels provide a way to categorize and organize issues and pull requests in a repository. As you create a GitHub repository several labels will automatically be added for you and new ones can also be created.

Examples of Labels include:

bug
documentation
duplicate
help wanted
enhancement
question

You can take Microsoft's short course on Github to really finetune your Github skills by following this link

Rules to live by for commit messages:

Don’t end your commit message with a period.
Keep your commit messages to 50 characters or less.
Add extra detail in the extended description window if necessary. This is located just below the subject line.
Use active voice. For example, "add" instead of "added" and "merge" instead of "merged".
Think of your commit as expressing intent to introduce a change.

I Do Not Know Object Oriented Programming!

Opeyemi Stephen — Thu, 30 Dec 2021 19:29:08 +0000

If you are a beginner who is currently getting their butts whooped by JavaScript or swimming in tutorial hell, I'm quite sure you must have read the title of this article and given me an imaginary hug because you can also resonate. Truth is, I do not have a ready made blueprint to help you understand OOPs, but as I once read somewhere that the best way to learn is to teach...so here I am, Fun and Janae Monelle's "We Are Young" playing in the background, about to share my own personal notes about Object Oriented Programming. I hope this helps a newbie somewhere.

PS: I would welcome contributions, resources and comments that would help other newbies. We can burn brighter than the sun if we all help each other.

So the first thing we all need to know is the conventional definition...

Object-oriented programming combines a group of data attributes with functions or methods into a unit called an "object. Multiple independent objects may also be instantiated—or represented—from the same class and interact with each other in complex ways."

Typically, OOP is class-based, which means that a class defines the data attributes and functions as a blueprint for creating objects, which are instances of the class.

I happen to love cars alot so my first simple example would be to consider a class representing a car. The "car" class will contain attributes to represent information such as the car's name, model, number of wheels, color, etc. Maybe this would be more familiar;

let car = {
     name: "Mercedes Benz",
     model: "CLA 4DR Coupe", 
     numOfWheels: 4, 
     chassisNum: 0123456789, 
     color: "white"
};

I'd like to go on and talk about what everyone refers to as the 4 basics of Object Oriented Programming which would be Encapsulation, Abstraction, Inheritance and Polymorphism...but before I start throwing these words around, wouldn't it be better if we really understood how to use OOPs and then saw these 4 basics in action for ourselves?

We already successfully created our first class with their different properties and values. We can access the properties and subsequently, the values in our "car" object using the Dot Notation. Take a look at the code below;

console.log(car.model); //"CLA 4DR Coupe"

In the code above, we used the dot notation on the object named "car" and then followed by the property "model" to access the value which is "CLA 4DR Coupe"

Cool right? We might have private data in the class, such as "chassisNum" that should not be exposed to other objects in the program. By encapsulating this data member as a private variable in the class, outside code would not have direct access to it, and it would remain safe within that person’s object.

In OOP, we encapsulate by binding the data and functions which operate on that data into a single unit, the class.

By doing so, we can hide private details of a class from the outside world and only expose functionality that is important for interfacing with it. When a class does not allow calling code access to its private data directly, we say that it is well encapsulated. There there, you just understood Encapsulation.

It will be pointless to learn about OOPs without knowing what METHODS are. Methods are a special type of property that objects have. They are simply properties that are functions. They add a different behavior to an object. I like to think that they make objects a little more flexible in doing stuff. For instance,

let car = {
  name: "Range Rover Evogue", 
  price: 70000, 
  describeCar: function() {
    return "That car speeding on the highway is a " + car.name + " and it costs " + car.price + " USD.";}
};

car.describeCar(); //"That car speeding on the highway is a Range Rover Evogue and it costs 70000 USD."

The block of code above has a method describeCar which is a function and returns a statement telling us the name and Price of the car.(BTW, I have no idea about the price of the Range Rover).
Notice that the method accessed the name and price property in the return statement using the car.name and car.price. Now think about the many awesome things you can do with Methods...sweet right?

There is another way to access the name and price properties though...yeah, you probably heard about it...the "this" keyword (At this poin, you're probably like...who was behind naming these coding concepts, because what is literally "this" right? lol)

"this" in my own opinion, which I would like to think is shared by others, exists to make code reusable and very much easier to read.

In the last example, we had a method describeCar which used car.name and car.price dot notation to access the values for the name and price property within the return statement.
Recall,

 describeCar: function() {
    return "That car speeding on the highway is a " + car.name + " and it costs " + car.price + " USD.";}

Although, it is a very correct way of accessing the object "car" 's property, have you ever asked yourself what happens when you have accessed this object and its properties on lines 235, 410, 720, 850, 1100, 1425, 1658, 1780 and 3800 of your codebase and for some reason, the variable name changes from "car" to "automobile" while working for a large company such as Mercedes?

Your work gets extra stressful as you have to update all those lines of code which references the original name that was changed and we both know how stressful that can get. This is where the this keyword comes in. You can have your initial code in our last example re-written like this;

let car = {
  name: "Range Rover Evogue", 
  price: 70000, 
  describeCar: function() {
    return "That car speeding on the highway is a " + this.name + " and it costs " + this.price + " USD.";}
};

car.describeCar();

Now, we have barely scratched the surface and this is a very deep and sometimes complicated subject and the above is definitely not the only way it can be used. Here, we just used this in referring to the object that the method describeCar is associated with, which is car. By virtue of this, if the object variable car is changed to automobile or even locomotive, it is not necessary to find all the references to car in the code. There you go...easier and reusable across board.

Now that we have got that out of the way, let's be civil engineers for a bit and talk about Constructor Functions(this is me trying to make a joke that's not funny btw)...

Now, imagine that you are seeing the function below for the first time as a beginner...which is probably what's happening right now;

function Truck() {
  this.name = "Ford Ranger 2018";
  this.color = "Black";
  this.price = 100000;
  this.numWheels = 4;
  this.yearOfProduction = 2018;
}

Looks weird right? Because it did look weird to me when I looked at it for the first time ever too. Functions are supposed to return a statement or value or whatever else you read up yeah? It also looks like an object or even a method but methods ar always inside the object and this isn't how "normal" objects are written...Don't fret, this is a Constructor Function

Constructors are functions that create new objects. They define properties and behaviors that will belong to the new object. What this means is that like the example above, functions written that way will create a new object called "Truck" and append the name, color, numOfWheels and yearOfProduction properties and their corresponding values to the object. The this refers to the new object that has been created.

Take note that the Truck object was defined with a capital letter. Constructors are defined this way to differentiate them from other functions that are not constructors and will not return values like other functions would.

And as usual, a new problem will always arise from an existing one...what if we want to create a new object which will have the same properties as our initial "Truck" constructor from the our previous example? We simply add the following line of code beneath the previous code block like so;

let fordTruck = new Truck();

The new operator will instruct JavaScript to create a new copy of the Truck object called fordTruck.

Take note that if you do now include **new, you will not get the result as no new object will be created even if you troubleshoot and console.log from here to Bethlehem**

So ultimately, if you type fordTruck.name in your console, the result will give the value of our initial Truck's this.name because fordTruck now has all the properties of Truck.

Now you know what constructors do, but if you are the obsrvant genius I know you are, then you would notice that when we created the new constructor fordTruck, it took the name property along with the other properties such as color, numOfWheels and yearOfProduction. We can keep changing the names as we go by if you want different values for each new Truck but supposing you are in charge of keeping track of hundreds of thousands of trucks produced at the Ford Plant?

You can change or easily create new instances of the Trucks by designing the initial Truck constructor to accept whatever parameters might need to be changed like the name of the truck, the price, the color and still leave the other values to remain the same if you want. So we re-write the original constructors to accept arguments as shown below;

function Truck(name, price, color) {
   this.name = name;
   this.color = color;
   this.price = price;
   this.numWheels = 4;
   this.yearOfProduction = 2018;
}

And then we can say;

let fourWheel = new Truck("Ranger", 175000, "gray");

When you do this, you create a new instance of Truck which will be named fourWheel and will set the properties to the new properties of the new fourWheel object.

With the above, the constructor function is now very flexible as it can accept parameters and we can define new properties for each truck when they are created.

Always keep in mind that constructor functions group objects together based on shared characteristics and behavior and define a blueprint that automates their creation

If you want to check if the new object you created is an instance of the constructor, use the instanceof operator.

For instance, in our last example above,

fourWheel instanceof Truck;

It will return true because the fourWheel object was created using the Truck constructor.

But if we say,

let saloonCar = {
   name: "Ford Focus", 
   color: "white", 
}

And then we check the same saloonCar instanceof Truck;, it will return false because saloonCar was not created using the Truck constructor.

Also, the Truck constructor defines five properties (name, color, price, numOfWheels, yearOfProduction) which are defined directly inside it. These properties are called "Own Properties".

Let's assume we are setting up 3 new instances of Truck called firstCar, secondCar and thirdCar respectively, we would have something like this;

let firstCar = new Truck("edge", "red", 30000);
let secondCar = new Truck("broncos", "black", 120000);
let thirdCar = new Truck("focus", "blue", 65000);

The other two properties numOfWheels and yearOfProduction will remain unchanged as no new parameters were passed in for those.

All 5 properties are referred to as Own Properties because they are defined directly on the instance object Truck. This means that firstCar, secondCar and thirdCar all have their own separate copy of these properties and every other instance of Truck will also have their own copy of these properties.

What is the essence of all of this and what might we do with the Own Property you might ask...well we could push them to an empty array while writing our code like so;

let ownProps = [];
for(let property in secondCar) {
   if(secondCar.hasOwnProperty(property)) {
       ownProps.push(property);
   }
}

So that when we console.log(ownProps), it will print the different properties from secondCar into the empty ownProps array.

If you take a close look at our code, you should definitely see that numOfWheels has the same value for all instances of Truck. In other words, it is sort of a duplicated variable.

It is not much of a problem if you have only a couple of instances or say 5 instances of the original car object...but...you will likely be working at the Ford HQ and using your code to keep track of millions of 4-wheeelers which means millions of instances.

In situations like the above-listed, a prototype comes in very handy. What does the prototype do you might ask? Simple..A prototype shares a particular property amongst all instances of the original object.

Truck.prototype.numOfWheels = 4;

Now all instances of Truck will have the numOfWheels property.

The prototype for firstCar and secondCar is part of the Truck constructor as Truck.prototype.

In summary, when it comes to properties, own properties will always be defined directly on the object itself while prototype properties will be defined on the prototype.

So what if we have to add more than one property to our prototype? You already know that would be very cumbersome of we had to do that one after another. A more efficient way would be to set the prototype to a new object that already contains the properties. We have this below;

Truck.prototype = {
   numOfWheels: 4, 
   sound: function() {
     console.log("Vroom! Vroom!!")
   }
}

And then we want to add a quality method to the prototype. All the properties can be added at once in this manner like so;

Truck.prototype = {
   numOfWheels: 4, 
   sound: function() {
     console.log("Vroom! Vroom!!")
   },  
   sound: quality() {
     console.log("It is a super fast " + this.name);
   }
};

NEVER FORGET to always define the constructor property whenever a prototype is manually set to a new object. Why? Well the reason is quite simple, it is beacuse when you set the prototype manually, it will erase the constructor property and if you check which constructor function created the instance, the results will be false.

Summarily, for a better understanding of the prototype chain, you need to always take note of the following;

All objects in JavaScript have a prototype(save for a few exceptions).
The prototype of an object is an object. If this confuses you, you can bet it confused me too. You should check out Javascript.info
A prototype can also have its own prototype because a prototype is an object. For instance;

function Car(name) {
  this.name = name;
}

typeof Car.prototype; //the result for this will be "object"

let bugatti = new Car("Veyron");
    bugatti.hasOwnProperty("name");

From the above,
Car = supertype for bugatti
bugatti = subtype for Car
Car = supertype for bugatti
Object is a supertype for both Car and bugatti
Object is a supertype for all objects in JavaScript, therefore, any object can use the hasOwnProperty method.

There's another important principle to be observed before I take a pause on this is the principle of Inheritance.

Repeated code is usually a problem because any change in one place requires fixing the code in multiple placesbwhich would just give devs more work and make them more likely to make errors. Now let's say we have two constructor functions which I will name after two of the biggest artistes in Africa(just because I can and we don't have to always be boring);

Wizkid.prototype = {
   constructor: Wizkid, 
   describe: function() {
      console.log("My name is " + this.name +  " and I always come late to my concerts in Nigeria");
  }
};

Davido.prototype = {
   constructor: Davido, 
   describe: function() {
      console.log("My name is " + this.name + " and I always come late to my concerts in Nigeria");
  }
};

As we can see, the describe method is repeated in two places and we can use what we call the DRY principle (Don't Repeat Yourself) to refine this code by creating a supertype called **Artistes** like so;

function Artiste() {};

Artiste.prototype = {
    constructor: Artiste, 
    describe: function() {
       console.log("My name is " + this.name + " and I always come late to my concerts in Nigeria");
   }
};

Since you have the above supertype Artiste which includes the describe method, you can then remove the describe method from Wizkid and Davido.

Wizkid.prototype = {
  constructor: Wizkid
};

Davido.prototype = {
  constructor: Davido
};

There you go, you just successfully created a supertype called Artiste that defined behaviors shared by all musicians/artistes.

I will stop here for now...you can learn more about the basics of Object Oriented Programming as well as advanced concepts on Javascript.info

You can also chip in via the comments for other newbies to learn more as I have barely even scratched the surface. Godspeed and Happy New Year in advance to you and yours.

HNG Internship 8.0

Opeyemi Stephen — Mon, 16 Aug 2021 19:42:32 +0000

Hotels.ng Internship, partnered by Ingressive For Good have thrown the gates wide open for the 8th edition of the HNG Internship 8.0.

The Mark Essien and Seyi Onifade-led internship has proven time and again to be one of Nigeria's best accelerator programs for tech geniuses all over Africa to showcase their skill and hopefully get absorbed into a full time role when they apply for jobs after the 8 week program.

For a lot of rookie and even expert developers, this internship offers the opportunity of improving their collaborative skills in the tech ecosystem, building lifelong friendships and networks as well as the invaluable experience of realtime work environment simulations. Applications to join the internship will be closing on Tuesday and prospective applicants can join here.

I am currently trying to advance my skills as an expert Frontend developer and I have decided to join this internship with the aim of achieving the following goals:

To attract valuable work contacts and hopefully get an important stepping-stone to securing a job and climbing the first rung on my career ladder.
To develop critical and requisite work skills and get the edge over competition in the industry.
I would also like to get even further out of "tutorial hell", gain experience beyond the books and explore unexpected avenues.
To work on exciting work projects and have valuable experiences to talk about with future recruiters at interviews.

At the end of 8 weeks, I want to have attained a level of independence in starting out my own major projects. Taking away lots of experience is really key for me

If you somehow stumbled on this article and want to make a quick transition into tech, you can take a refresher course to get familiar with the following links to help you kickstart your journey.

TAKE NOTE THAT THE FOLLOWING LINKS ARE TO GET YOU FAMILIAR WITH THE SPACE.

I recommend starting with HTML and CSS
HTML AND CSS
https://youtu.be/mU6anWqZJcc

You could then have a look at JavaScript or a programming language like python. It all really depends on which appeals to you but I took the liberty of adding JavaScript and Python.

Full Javascript course for beginners
https://youtu.be/jS4aFq5-91M

Python for beginners
https://youtu.be/_uQrJ0TkZlc

You should also learn version control because you would need it every other time for collaborating with other developers in building projects.
Getting started with GIT
https://youtu.be/8JJ101D3knE

You should also check out this refresher to know how to implement pixel perfect designs from Figma.

Figma tutorial for beginners
https://youtu.be/Gu1so3pz4bA

If backend is more like your thing, you could check this out too
Backend with Node.js
https://youtu.be/Oe421EPjeBE

And if you like Mobile Development, you could start here as well.
Mobile development with Flutter
https://youtu.be/pTJJsmejUOQ

It is a fast-paced internship but I will do my best to share my experiences. Ciao.

Learn to code using FreeCodeCamp Especially If You Do Not Have 24/7 Internet Access

Opeyemi Stephen — Thu, 03 Jun 2021 18:19:37 +0000

My previous post was supposed to be a rant...a way of releasing my pent-up anger and frustration at the system and the very scarce resources it was swallowing, with little returns and immense presure all because I wanted to make a difference. The reception and similar experiences I read in the comments section is a source of motivation I will never take for granted.

I am working with a few people to build solutions which would help the average developer and while that would take some level of planning, implementation and even donations, I thought of other non-monetary(if there's a word like that) ways of helping newbies.

So...lots of research, a bout of serious typhoid fever, speaking with awesome developers including Jay, Trevor and Sebastian and my laptop getting spoilt by a power surge on the very day I wanted to POST this later, I was able to come up with this...now ask yourself...

HOW WOULD YOU LIKE TO BE ABLE TO USE FREECODECAMP AND ITS AMAZING LEARNING RESOURCES AND CERTIFICATIONS WITHOUT THE INTERNET?

Awesome yeah? Check out FreeCodeCamp here Link

You're probably thinking this is hard and it might take a long time to set up, well it isn't. You should be done in an hour or less.

Preliminary Requirements

First you need to have a working computer/laptop.(Thankfully I was able to get this post compiled before mine got spoilt).
You would also need initial internet connectivity.(This is so you can download the necessary FreeCodeCamp files from GitHub).
Lastly, you would need a resilience like no other. This is because it is one thing to download and set this up and it's a whole different thing to actually PUT THESE RESOURCES TO USE AND LEARN. Do not procastinate, start learning!

First Step: Setting Up Your Database On Your Local Machine

We will be making use of a document-oriented database called MongoDB. To learn more about MongoDB and why it is used, i have a helpful article here Link

Let's go on and install MongoDB. You can find the necessary documentation to install on all supported Operating Systems here

Link

I will be using Windows 10 so kindly follow the steps below if you use windows 10 as well.

Download the latest version(mine was 4.4.6) at Link (make sure to select "On-Premises MongooDB locally" and on the right-hand side select "msi" as Package. Learn more about "msi" here Link

After the Download is complete, navigate to your file location and install.
When you get to the prompt that says "Custom SetUp", make sure all features are selected and the "Server" is set to "install on the local hard drive, C:".

Click "Next"
You should be in "Service Configuration" now. Unselect the checkbox which says "Install MongoDB as a service". We are doing this so MongoDB doesn't use up all your computer's memory and we will only run it before starting up FreeCodeCamp. You are not Google or Netflix my friend, winks. Click "Next".

Keep Clicking "Next" to complete the rest of the installation.

Second Step: Setting Up Node.js and NPM

Node.js is an open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser.

NPM stands for Node Package Manager and is always installed with Node.js

To learn more about NPM, you can check this resource Link

To learn more about node.js, you can check this resource Link

Download and install node.js by clicking Link

Make sure to download the recommended msi version (14.17.0 LTS).

When this prompt below comes up, select the checkbox

This will enable your system to also install additional packages and dependencies when you need them and build stuff on FreeCodeCamp as well. Chocolately, Python and other packages will also be installed with this step

Third Step: Cloning FreeCodeCamp From GitHub

First thing to do is to install Git using your computer's package manager.

You can type "choco install git"

If you still do not know how, you can install normally here Link

Open a new folder titled "FreeCodeCamp" on your computer.

Then Open your terminal or Windows Powershell and follow the following sub-steps;

Using "cd" and "ls" commands, navigate to the FreeCodeCamp folder(directory) which you opened in 1.
Clone FreeCodeCamp and its necessary accompanying files using git by typing the following command in your Powershell or Terminal

git clone --depth=1 https://github.com/freeCodeCamp/freeCodeCamp

Fourth Step: SetUp and Install FreeCodeCamp On Your Local Machine

Use "cd" to navigate into the FreeCodeCamp directory you just cloned and then type the command below to begin installation(might take a while but you've already come this far so be patient my friend)

"npm ci"

DO NOT CLOSE THIS POWERSHELL/TERMINAL WINDOW YET

Fifth Step: Starting Up The MongoDB Database

You will need to always start the service in 2 below before you can run FreeCodeCamp everytime so you can do well to note it down somewhere.

Open up a new window in your terminal or Powershell while waiting for the installation in the Fourth Step above.
You can start up the MongoDB database by following the steps below:

Windows Users: Navigate as seen below and then type in the command

"C:\Program Files\MongoDB\Server\3.6\bin\mongod.exe" --dbpath=/path/to/freeCodeCamp

Linux Users: Navigate as seen below and then type in the command

mongod --dbpath=/path/to/freeCodeCamp

DO NOT CLOSE THIS POWERSHELL/TERMINAL WINDOW YET

Sixth Step: Seeding the MongoDB Database

Remember the installation in Step 4? It should be completed by now.
Go back to that Powershell or Terminal window and then type in the command below just once;

"npm run seed"

Note: In subsequent times, you do not have to run the above command again because your would have already been initialized.

7th Step: Start FreeCodeCamp

Go back to the Powershell terminal in the Sixth Step.
Run this command to start FreeCodeCamp

"npm run develop"

It might take an awful lot of time but as long as you have a stable internet connection, trust the process and let the building sun its full course. it took about 8 minutes on my end.

How do i know it's done? You should see this line

success Building development bundle - 497.330s

Step 8:

Open up your preferred browser and type in [Link}(http://localhost:8000)
Click "Get Started Now, It's Free!"
You should see " Welcome back, development user".
Congratulations, you can access all the courses now without the internet. Your progress will be saved in the MongoDB commands run in Step 5.

Question: What I want to start FreeCodeCamp later, do i need to go through all the steps again?

Answer: Of course not, next time you can do so without the internet by following the instructions on Step 5 and 8 in two different terminals/powershells.

May The Stars Align For You Fellow Dev....Major shoutouts to every resource I previously read and a few blogs that already did something like this. I hope this helps us all.

A beginner’s journey into software development in Nigeria.

Opeyemi Stephen — Thu, 29 Apr 2021 07:36:32 +0000

No one really writes about the pain involved in learning to code in Nigeria and I don’t know why.

First of all, peep the the cover picture on this post, it represents an art-work for a song by a music artiste in Nigeria titled “Thunder Fire You” by Ric Hassani. Literal meaning...may thunder strike a person dead.

It was sung as a song for a heartbroken man but I put that up there because there’s a lot of forces designed to frustrate the average young Nigerian mind by the Government.

I started my developer journey, no prior computer science degree, delving into a new career because well, there are simply not enough jobs. I said what I said.

And now, it has only gotten worse...

Laptop prices have doubled and are now tripling due to the weak strength of the Naira against the dollar. Some developer advocates like Hack Sultan, Prosper Otemuyiwa and Adora Nwodo have been doing their best to help the Nigerian community but for how long? Trust the government to try and take the plaudits when a Nigerian dev builds a world class product tho.
Data!!!! A successful developer needs to learn to know how to ask the right questions on Google and StackOverflow yeah?

But you see,in order to use Google, you actually have to be connected to the internet...Now the average Nigerian earns 2000 naira daily and the least internet plans go for half that price!
Funny story? Many people do not even earn that...tell me again how it’s supposed to be easy to just be in the “zone” to code?

The way I see it, to use YouTube and the plenty resources available online for self-study, you’ve got to have access to the internet and how are you supposed to cope with spending at least 12-20 thousand naira on data monthly when you haven’t even started getting paid? And to plunge you into further depression, you’re given an option of “borrowing” data...sighs.

Now to the most annoying part...EPILEPTIC...nah scratch that...NO POWER SUPPLY!!! Paint this scenario in your head...

Young and defiant newbie dev who is trying their best to scale through, has been able to get a laptop, buy/borrow data and joined a free boot camp or tried to do some self study. This young developer wants to maximize their time and draws up a study schedule so they can also get their tasks and assignments submitted early enough.
There’s a problem tho...”PHCN”(the corrupt organization in charge of supplying power) only gives them electricity 3 hours(phased irregularly) daily and coupled with that, they still have to “share” light in their street because the transformer is not powerful enough to supply the 12 streets using it.
Their street uses the epileptic power for two days and there’s a total blackout for the third day.
In total they have +/- 6 hours of a possible 72hours to power their devices, get studies in and also do their assignments. Then you find them at Bet9ja shops (sports betting kiosks) trying to charge and learning to code with street kings(agbero and urchins) shouting in the background trying to stake bets on virtual football games.

That is just a peek into the life of most newbie Nigerian developers. I just thought you should know. I deliberately excluded some parts because it gets ugly as you go. Feel free to add your experiences and draw strength from each other. Selah.

Despite all this, we still do our best yeah? But think of the talents being wasted because they do not have the psychological capacity to cope with these kinds of problems...just think about it for a minute?

Thank You! Feeling Good This Morning

Opeyemi Stephen — Thu, 19 Nov 2020 08:11:44 +0000

I made a post yesterday and I can honestly say I am overwhelmed by the amount of support and encouragement I received.

I woke up feeling good about myself and willing to go even harder this time. I love this community.

Might just make this my personal blog where I write my feelings as regards being a programmer each day.

It is hard.

Opeyemi Stephen — Wed, 18 Nov 2020 10:27:57 +0000

I started coding sometime in February. I was in a really bad place, depressed and almost suicidal. I tried to find purpose in my previous career, Structural Engineering but it just wasn't for me.

I met my mentor through a mutual friend and he put me on the right path.

I don't know if I am going to be a good developer. I find myself forgetting things and feeling like there is so much to catch up on and study on and it makes me feel like I am not doing enough.

I cannot seem to understand JavaScript and how to apply it. Been studying JavaScript since march and it just seems like I am moving around in circles. I get the hang of it right away when I study and then I forget the next day.

Coding is hard!!!!

But with the right experience and mentorship...I will touch the clouds.

Forem: Opeyemi Stephen

Compressed NFTs in Production: A Campus Tour Case Study

The Credentials

Why Compressed NFTs?

The Stack

The Architecture

The Data Problem

Who Opted In

Two Sources, Zero Alignment

The Wallet Validation Nightmare

The Verification Pivot

Cost Optimization

Production Day

Bugs I Hit

What I'd Do Differently

Results

What I Learned

What's Next

When Payments Own the Base Layer: What Corporate L1s Mean for L2s, and for Africa v2.0

Table of Contents

TL;DR

The spark (and why I’m writing this)

Baseline: what L2s actually do today (so we measure impact correctly)

Why payments firms might go L1 (and not just “use an L2”)

Africa lens: what could really change (and what won’t)

Scenarios, not predictions (how big could the shift be?)

Dollarization pressure vs domestic units (cNGN, etc.)

Risks & trade-offs (clear-eyed, not alarmist)

Who wins / who loses (by segment)

What to watch (so this doesn’t devolve into vibes)

90-day action plan (operators & builders)

Pushback corner, quick answers to big doubts

Conclusion: track the metrics, not the memes

Sources & methods

Why Web3 Keeps Losing Users (And How We Actually Fix It in 2025)

Introduction: The Promise and the Problem

Table of Contents

The State of Web3 Onboarding: A Few Ugly Truths

The Founder Factor: Caught in the Builders’ Trap

The Stakes: Adoption or Bust

Ideas to Fix It: A Blueprint for Better Onboarding

Fix 1: Reverse Onboarding, “Experience First, Wallet Later”

Fix 2: Web3-Wide User DAOs — “Onboarding as an Incentivized Coalition”

Fix 3: Persistent AI Concierges, “Web3’s UX Co-Pilot”

The Payoff: Web3 for Everyone

Counterpoints: The Pushbacks You’ll Hear (and How They Fall Apart)

1. “Onboarding’s a Feature, Not a Bug, Web3’s Meant to Be Hard”

2. “We’re Still Early”

3. “Builders First, Users Come Later”

4. “Decentralization Means No One Owns Onboarding”

5. “Focusing on Newbies Slows Innovation”

Conclusion: Founders, Break the Bubble

Late to React 18? My Top 4 awesome features and real-use examples.

How to upgrade to React 18.

So what changed?

Automatic Batching:

Concurrency:

Transitions:

Suspense on the Server

Other awesome changes of React 18 include:

How does it affect the codebase when updated? The React team has stated that;

What Strategy to update when upgrading to React 18?

Edge cases to watch out for

Level Up Your Skills By Mastering Git, Github, and The Terminal.

Let’s get started!

What is the Terminal?

What is a CLI?

What is a GUI?

Common Commands On The Terminal

Now that we know some commands on the CLI, let's talk about GIT.

Why is GIT important?

How does Git work?

Some Git Terminologies

How To Install Git

What to do after git is installed;

Basic Git Commands

Why is this important?

More on Branches

What next after the commits?

So how to push?