Forem: Navneet Karnani

Stop Using localhost:8080 - Why Your Dev Environment Needs Production-Grade Network Security

Navneet Karnani — Fri, 05 Dec 2025 21:55:29 +0000

Modern application development increasingly demands security-first approaches, but setting up a secure local development environment that mirrors production constraints is often overlooked. In this post, I'll walk you through a Docker-based Java development environment that enforces network segmentation, egress filtering, secure ingress with TLS, and production-like browser behavior all running locally.

The Problem: Security Theater in Development

Most development environments are security-free zones. Your application can reach any endpoint, pull dependencies from anywhere, and communicate freely with the outside world. Developers typically use http://localhost:8080, which creates a dangerous illusion: if it works on your laptop, it's ready for production.

The reality? Production environments have:

Strict firewall rules blocking unexpected egress
Network segmentation preventing lateral movement
Ingress proxies enforcing TLS and security headers
HTTPS with all its browser security implications
Audit logging of all network activity

Discovering these constraints during deployment is expensive. Worse, it trains developers to see security as friction rather than design.

This article presents a different approach : a Docker-based development environment where security constraints are the default, not an afterthought. You'll learn production network patterns while writing code, not while debugging a failed deployment.

The patterns shown here translate directly to production Docker deployments. Whether you scale to orchestration later or keep it simple with Docker Compose in production, these principles remain the same.

The Solution: Network-Segmented Docker Environment

This architecture enforces network boundaries at the container level, giving you production-like security constraints during development.

Architecture Overview

                        Internet Egress egress-net (Squid) Ingress ingress-net App (Caddy) (Java) ports 80/443 (host exposed) Database db-net (PostgreSQL)

Four isolated networks enforce strict communication paths:

db-net : App Database only
ingress-net : App Ingress proxy only
egress-net : App Egress proxy only
internet : Egress External internet only

The app container cannot reach the internet directly all outbound traffic must go through the Squid proxy.

What This Environment Provides

This setup gives you:

Network segmentation - Services can only communicate on explicitly allowed networks

Egress filtering - Outbound traffic is whitelisted by domain

Ingress hardening - HTTPS termination, security headers, log sanitization

Production parity - The same constraints your production environment should have

HTTPS in development - Real browser security behavior, not localhost shortcuts

Portable security - Works identically on any machine running Docker

This is not :

A Kubernetes replacement (it's simpler by design)

A complete security solution (you still need authentication, authorization, input validation, etc.)

A performance-optimized production setup (though it can run in production for simpler applications)

Philosophy : Docker Compose is sufficient for many production applications. This architecture scales from development through production without requiring orchestration complexity unless you actually need it.

Implementation Deep Dive

1. Docker Compose Network Definition

The base docker-compose.yml defines the infrastructure layer:

networks: ingress-net: internal: true egress-net: internal: true internet:x-proxy-env: &proxy-env http_proxy: http://egress:3128 https_proxy: http://egress:3128services: ingress: image: mandraketech.internal/ingress build: context: ./ingress ports: - name: https published: 443 target: 443 - name: http published: 80 target: 80 networks: - ingress-net depends_on: - app egress: image: mandraketech.internal/egress build: context: ./egress networks: - egress-net - internet volumes: - ./egress/squid.conf:/etc/squid/squid.conf:ro - ./egress/domain-lists.d:/etc/squid/domain-lists.d:ro app: environment: <<: *proxy-env networks: - ingress-net - egress-net

Key points:

Networks marked internal: true have no external connectivity
The x-proxy-env YAML anchor injects proxy settings into the app container
Only the internet network allows external access, and only the egress container uses it

Understanding Docker's Internal Networks

The internal: true flag prevents networks from routing to external destinations. However, Docker's port publishing bypasses this restrictionit operates at the host level, not the network level.

This might seem contradictory: How can ingress-net be internal yet expose ports 80/443?

The answer : Internal networks restrict container-to-external routing, not host-to-container port forwarding. The ingress container:

Cannot initiate connections to the internet (internal: true enforces this)
Can receive connections from the host (port publishing allows this)
Can communicate with other containers on the same network

This is intentional architecture, not a workaround. It demonstrates an important principle: network isolation is about controlling who can initiate connections, not just who can receive them.

If you want to understand Docker networking at a deeper level, explore the iptables rules Docker creates: sudo iptables -L DOCKER-ISOLATION-STAGE-2 -n -v. You'll see how internal networks are enforced at the packet filtering level.

2. Egress Filtering with Squid

The egress proxy uses Squid to whitelist allowed domains. Here's the core configuration:

http_port 3128# Define local network (containers)acl localnet src 172.16.0.0/12acl localnet src 10.0.0.0/8acl localnet src 192.168.0.0/16# Load allowed domains from consolidated fileacl allowed_domains dstdomain "/etc/squid/all-allowed-domains.txt"acl Safe_ports port 80 # httpacl Safe_ports port 443 # httpsacl HTTPS_ports port 443acl CONNECT method CONNECT# Access ruleshttp_access deny !Safe_portshttp_access allow localnet allowed_domains HTTPS_ports# Deny everything elsehttp_access deny all

The whitelist approach means only explicitly allowed domains are accessible. Domain lists are organized by purpose:

allowed-domains-dev.txt (development tools):

# github vscode extensionraw.githubusercontent.comapi.github.com# version controlgithub.comgitlab.com# vscode extensions marketplacemarketplace.visualstudio.commain.vscode-cdn.net.vsassets.io

allowed-domains-app.txt (Java ecosystem):

# java dependenciesapi.spring.iorepo.maven.apache.orgmaven.apache.orgsearch.maven.orgservices.gradle.orgdocs.oracle.com

3. Dynamic Configuration Reload

The egress container includes a file watcher that automatically reloads Squid when domain lists change:

#!/usr/bin/env shconsolidate_files() { echo "Consolidating domain lists..." CONSOLIDATED_DOMAINS_FILE="/etc/squid/all-allowed-domains.txt" echo "" > "$CONSOLIDATED_DOMAINS_FILE" for file in /etc/squid/domain-lists.d/*.txt; do if [-f "$file"]; then cat "$file" >> "$CONSOLIDATED_DOMAINS_FILE" fi done}# Initial consolidationconsolidate_files# Watch for changes and reloadinotifywait -m -e modify,create,delete,move /etc/squid/domain-lists.d |while read -r path action file; do consolidate_files squid -k reconfiguredone &exec /usr/sbin/squid -NYCd 1

This means you can add new allowed domains without restarting containers.

4. Secure Ingress with Caddy

The ingress proxy provides HTTPS termination with security headers baked in. Critically, it also sanitizes logs to prevent credential leaks:

{ admin off skip_install_trust log "console_logger" { format filter { wrap json fields { request>headers>Authorization delete request>headers>Cookie cookie { replace session REDACTED delete secret } request>remote_ip ip_mask { ipv4 16 ipv6 32 } } } format console }}www.localhost { tls internal log "console_logger" header { # HSTS Strict-Transport-Security max-age=31536000; # Prevent MIME sniffing X-Content-Type-Options nosniff # Hide server identity server "super-secure" # Clickjacking protection X-Frame-Options DENY # Referrer policy Referrer-Policy no-referrer # XSS Protection X-XSS-Protection "1; mode=block" } handle /healthy { respond "Running !!!!" 200 } handle /* { reverse_proxy app:8080 } handle_errors { @5xx expression `{err.status_code} >= 500 && {err.status_code} <600` handle @5xx { respond "It's a 5xx error." } }}

Key security features in this configuration:

Log sanitization : Authorization headers are completely removed, session cookies are marked as REDACTED, and IP addresses are masked to /16 and /32 to protect user privacy
Security headers : HSTS, X-Frame-Options, X-Content-Type-Options protect against common web vulnerabilities
TLS handling : Caddy automatically generates and manages self-signed certificates for local development

TLS Configuration for Development

www.localhost { tls internal # ... rest of config}

The tls internal directive tells Caddy to generate a self-signed certificate for www.localhost. This gives you:

Real TLS handshakes : Your application sees HTTPS requests exactly as it would in production
Browser security context : APIs that require secure contexts work correctly
Security header testing : HSTS, CSP, and other headers behave as they would in production

First-time setup : When you access https://www.localhost, your browser will warn about the self-signed certificate. This is expected. Click through the warning (the exact process varies by browser):

Chrome/Edge : Click "Advanced" "Proceed to www.localhost (unsafe)"
Firefox : Click "Advanced" "Accept the Risk and Continue"
Safari : Click "Show Details" "visit this website"

After accepting once, your browser remembers the exception for this domain.

Why not use localhost? The domain www.localhost is used instead of plain localhost because it allows testing subdomain behavior (cookies, CORS policies) and more closely mimics production domain structures.

The Hidden Value of TLS in Development

Most developers use http://localhost:8080 during development and only encounter HTTPS in production. This creates a dangerous blind spot: browsers behave fundamentally differently under HTTPS.

What you miss without HTTPS in development:

Mixed Content Blocking : Browsers block HTTP resources (scripts, stylesheets, images) loaded from HTTPS pages. You won't discover this until production.
Secure Cookie Behavior : Cookies marked Secure are only sent over HTTPS. Session management that works on localhost can fail in production.
Service Worker Restrictions : Service Workers only function over HTTPS (except localhost). Progressive Web App features won't work without TLS.
CORS Preflight Differences : Cross-Origin Resource Sharing behaves differently for HTTPS vs HTTP, particularly with credentials.
HTTP/2 and HTTP/3 : Modern protocols require TLS. Performance characteristics differ significantly from HTTP/1.1.
Browser Security Features : Features like geolocation, camera access, and clipboard API require secure contexts (HTTPS).
Referrer Policy Enforcement : Browsers strip or modify referrer headers differently based on protocol security level.

Caddy makes this effortless : It automatically generates and manages self-signed certificates for local development. You get real TLS behavior without certificate management overhead.

This environment uses https://www.localhost instead of http://localhost:8080. Your browser will show a certificate warning (expected for self-signed certificates), but after accepting it once, you experience production-like HTTPS behavior during development.

Teaching Moment : The first time you encounter a mixed content warning during development instead of production, you'll understand why this matters. HTTPS in development isn't about securityit's about production parity.

5. The Java Application Container

The app container uses BellSoft Liberica JDK on Alpine for a minimal footprint:

ARG JDK_VERSION=25FROM bellsoft/liberica-openjdk-alpine-musl:${JDK_VERSION}RUN apk update && \ apk add --no-cache \ bash \ git \ curl \ tar \ unzip \ libstdc++ \ ca-certificates \ && mkdir /codeVOLUME ["/code"]CMD ["sleep", "infinity"]

The CMD ["sleep", "infinity"] is intentional for this development environment. This keeps the container alive for interactive developmentyou exec into it, run builds, start services manually. This is a development pattern, not a production deployment strategy. It allows you to iterate on your application without rebuilding containers constantly.

The application config extends this in docker-compose.override.yml:

networks: db-net: internal: trueservices: database: image: postgres:16-alpine environment: POSTGRES_USER: psqladmin POSTGRES_PASSWORD: secret POSTGRES_DB: app_db networks: - db-net app: environment: DB_HOST: database DB_PORT: 5432 volumes: - code_m2:/home/dev/.m2 - code_vol:/code networks: - db-net depends_on: - database

Debugging Network Restrictions

When egress filtering blocks a request, you need a systematic approach to diagnose and resolve it.

Testing Egress Filtering

The repository includes a test script that validates your proxy configuration:

docker compose exec egress /usr/local/bin/tester.sh

This script attempts connections to various domains and shows which are allowed. View the full script to understand the test cases.

Manual Testing from Application Container

Test specific domains from within the app container:

# This should succeed (if whitelisted)docker compose exec app curl -v https://repo.maven.apache.org# This should fail (not whitelisted)docker compose exec app curl -v https://random-site.com

Reading Squid Logs

When a request is blocked, Squid logs the denial:

docker compose logs egress | grep TCP_DENIED

You'll see entries like:

1733500800.123 0 172.18.0.5 TCP_DENIED/403 3918 CONNECT random-site.com:443 - HIER_NONE/- text/html

This tells you:

Timestamp : When the request occurred
Client IP : Which container made the request (172.18.0.5 is the app container)
Action : TCP_DENIED/403 means the request was blocked
Domain : What the app tried to reach

Decision Tree: Whitelist or Refactor?

When you find a blocked domain, ask:

1. Is this domain expected?

Yes Add to appropriate whitelist in egress/domain-lists.d/
No You've found unexpected behavior (possible supply chain issue, investigate)

2. Does my application really need this dependency?

Example: A logging library that phones home for telemetry
Consider: Do I need this feature, or can I use a simpler alternative?

3. Can I cache or vendor this resource?

Maven dependencies Cache in your own artifact repository
External APIs Consider if you need real-time access during development

The friction is intentional. It forces you to understand your application's network footprint.

Adding Allowed Domains

When you determine a domain should be whitelisted:

# For application dependenciesecho "api.example.com" >> egress/domain-lists.d/allowed-domains-app.txt# For development toolsecho "vscode-extension-cdn.com" >> egress/domain-lists.d/allowed-domains-dev.txt

The proxy automatically reloads within seconds (via inotifywait). No container restart needed.

Common Issues

Maven dependencies fail to download:

# Check if Maven Central is whitelistedgrep "repo.maven.apache.org" egress/domain-lists.d/allowed-domains-app.txt# Verify proxy environment variables are setdocker compose exec app env | grep proxy

HTTPS connections timeout:

# Ensure port 443 is in Safe_portsdocker compose exec egress grep "Safe_ports port 443" /etc/squid/squid.conf# Check if CONNECT method is alloweddocker compose exec egress grep "acl CONNECT method CONNECT" /etc/squid/squid.conf

Domain is whitelisted but still blocked:

Check for typos in the domain list (extra spaces, wrong TLD)
Verify the file is mounted: docker compose exec egress cat /etc/squid/all-allowed-domains.txt
Ensure Squid was reloaded: docker compose logs egress | grep reconfigure

TLS and Certificate Issues

Browser shows certificate warning every time:

This suggests your browser isn't remembering the certificate exception. Check:

Are you using incognito/private mode? These don't persist certificate exceptions.
Is your browser profile corrupt? Try a fresh profile.
Did the ingress container restart? Self-signed certificates regenerate on restart, invalidating previous exceptions.

Mixed content warnings in browser console:

Mixed Content: The page at 'https://www.localhost/' was loaded over HTTPS, but requested an insecure resource 'http://api.example.com/data'. This request has been blocked.

This is expected behavior under HTTPSbrowsers block insecure resources. Solutions:

Update your code to use HTTPS URLs: https://api.example.com/data
Use protocol-relative URLs: //api.example.com/data (inherits page protocol)
For local resources, ensure they're served through the Caddy proxy

Service Worker registration fails:

// This fails: Service Workers need HTTPSnavigator.serviceWorker.register('/sw.js') .catch(err => console.error('SW registration failed:', err));

Verify you're accessing via https://www.localhost, not http://localhost. Check browser console for security context errors.

Cookies not being sent:

If you're setting cookies with Secure flag:

Cookie cookie = new Cookie("session", sessionId);cookie.setSecure(true); // Only sent over HTTPS

Ensure your application is accessed via HTTPS, and the cookie domain matches www.localhost.

Why This Matters for Your Team

1. Security Becomes Muscle Memory

When egress filtering is part of your daily workflow, you naturally think about:

What external services does this library contact?
Do I trust this dependency's network behavior?
Can I vendor or cache this resource?

These aren't theoretical security questionsthey're practical development constraints you encounter immediately.

2. Production Surprises Become Development Discoveries

Scenario : Your application uses a Java library that contacts a license server.

Without this environment : You discover this during production deployment when your firewall blocks it. Now you're in an emergency change request to whitelist an unknown domain.

With this environment : You discover it when you add the dependency. You research the library, understand why it needs network access, and make an informed decisionbefore it's an emergency.

3. Supply Chain Visibility

Modern applications depend on hundreds of transitive dependencies. Some of these dependencies make network calls you don't expect:

Analytics that phone home
License validation checks
Automatic update checks
Telemetry collection

Egress filtering makes these visible immediately. You can't ignore what's explicitly blocked.

4. Simplified Compliance

Many compliance frameworks (PCI-DSS, HIPAA, SOC 2) require:

Network segmentation documentation
Egress traffic controls
Audit logs of network activity

This environment provides all three by default. Your development setup becomes documentation of your security model.

5. Docker in Production, Simplified

This architecture scales to production for applications that don't need orchestration complexity:

Small to medium workloads
Internal tools and dashboards
Applications with stable traffic patterns
Teams that value simplicity over horizontal scaling

The same docker-compose.yml that runs on your laptop can run in production with environment-specific overrides. No translation layer, no impedance mismatch.

Design Decisions

Why Network Isolation Over Firewall Rules

Instead of using firewall rules to prevent communication, we use Docker networks to make prohibited communication impossible. This is more reliable because:

Network isolation is enforced by the platform itself, not by rules that can be misconfigured
It's self-documentinglooking at the compose file shows exactly what can communicate
There's no "forgot to add a rule" risk

Why Whitelist Over Blacklist for Egress

The egress proxy uses domain whitelisting rather than blacklisting. This fail-closed approach is superior because:

You can't blacklist threats you haven't thought of
A whitelist explicitly documents what your application needs
Unknown domains are denied by defaultthe secure path of least resistance

Why Containerized Infrastructure

Every component (app, database, ingress, egress) is containerized. This provides:

Consistency : Same behavior across development machines and production
Reproducibility : New team members get the exact same environment
Resource management : CPU and memory limits prevent runaway containers
Clear dependencies : Each service's requirements are documented in code

Why Docker Compose Override Pattern

Separating base infrastructure from application configuration in two compose files allows:

Reusability : The same infrastructure can support multiple projects
Customization : Applications can override settings without modifying core infrastructure
Clean separation : Infrastructure concerns stay separate from application concerns

Real-World Applications

This architecture is particularly valuable for:

Teams New to Security : The egress proxy makes security violations visible and immediately actionable. It's harder to ignore a blocked request than to overlook a security best practice document.

Regulated Industries : Healthcare, finance, and government applications need defense-in-depth from day one. Starting with network segmentation in development means your security model is baked in, not bolted on.

Supply Chain Risk Management : With increasing supply chain attacks (SolarWinds, Log4Shell), understanding your dependencies' network behavior is critical. This environment makes that behavior explicit.

Docker Production Deployments : If you're running Docker Compose in production (and many successful companies do), this gives you a development environment with identical security constraints.

Progressive Web Apps (PWAs): Service Workers require HTTPS to function. With this environment, you can develop and test PWA features locally without deploying to a staging server or dealing with certificate management.

API Development with Secure Cookies : When building APIs that use Secure and SameSite cookies, HTTPS in development ensures your authentication flow works identically locally and in production.

Third-Party Integrations : Many OAuth providers and payment gateways require HTTPS redirect URIs, even for development. This environment satisfies those requirements without tunneling services like ngrok.

Microservices Training : Even if you plan to use Kubernetes eventually, understanding network segmentation at the Docker level builds intuition for NetworkPolicies and service mesh concepts.

Security-Conscious Startups : Early-stage companies can afford to build security in from the start. This environment makes secure-by-default the path of least resistance.

Getting Started

Clone the repository and run:

mkdir -p secretsdocker compose build --no-cachedocker compose up -d

Access your app at https://www.localhost.

Important : Your browser will show a certificate warning because this uses a self-signed certificate. This is expected and safe for local development. Accept the warning to proceed.

Why HTTPS and not HTTP? Because production applications use HTTPS, and browsers behave differently under HTTPS. This environment helps you discover HTTPS-specific issues during development:

Mixed content blocking
Secure cookie requirements
Service Worker restrictions
API security contexts

Test the HTTPS setup:

# Should return "Running !!!!" with a 200 statuscurl -k https://www.localhost/healthy# The -k flag tells curl to accept self-signed certificates

You can also verify the TLS configuration:

# View certificate detailsopenssl s_client -connect localhost:443 -servername www.localhost < /dev/null# You'll see Caddy's self-signed certificate information

Test egress filtering:

docker compose exec egress /usr/local/bin/tester.sh

Customization

Add new allowed domains by creating files in egress/domain-lists.d/:

echo "api.example.com" >> egress/domain-lists.d/allowed-domains-app.txt

The proxy automatically reloads within seconds.

Conclusion

Security shouldn't start at the deployment gate. By bringing production security constraints into your development environment, you:

Learn production patterns while writing code
Catch network issues before they're emergencies
Build intuition about your application's security posture
Create self-documenting network architectures
Experience real browser security behavior with HTTPS

This Docker-based approach is simple enough for daily use but sophisticated enough to translate directly to production. No orchestration required unless you actually need it.

Start by cloning the repository and running docker compose up. The first time egress filtering blocks something unexpected, you'll understand why this matters.

The full source code, including the tester script and additional examples, is available at java-secure-dev-env.

Next Steps:

Clone the repository and explore the configurations
Add your own application to the app service
Customize domain whitelists for your dependencies
Use the patterns as a template for your team's projects

If you adapt this for other languages or find interesting edge cases, open an issue or PR. The goal is a reusable pattern for secure-by-default development across ecosystems.

Quick Reference

Credits

The code for this blog was written manually first, and fine tuned with rigorous usage. The initial article draft was generated using AmpCode Free (https://ampcode.com), and then substantially revised and enhanced with Claude (Anthropic) to improve technical depth, add comprehensive debugging sections, emphasize TLS/HTTPS production parity, and refine the strategic positioning.

Back Link

This article was originally published here on the MandrakeTech Blog

About the Author

The Author, Navneet Karnani, began coding with Java in 1997 and has been a dedicated enthusiast ever since. He strongly believes in the "Keep It Simple and Stupid" principle, incorporating this design philosophy into all the products he has developed.

Navneet works as a freelancer, mentor, advisor and a fractional CTO in startups that build technology products.

Driven software engineer (Java since 1997) with a hands-on passion for building impactful tech products. Possesses over 25 years of experience crafting solutions to complex business and technical challenges.

Have questions or improvements? Open an issue or PR on the repository!

]]>

Bring Your Own Library

Navneet Karnani — Tue, 22 Jul 2025 11:41:45 +0000

Stop waiting for your college or employer to fund your future. In today's digital economy, the most successful students and early professionals in India are building their own productivity arsenalsand you should too.

Just as you wouldn't attend college without buying your own textbooks or start a job without bringing your phone, investing in your personal toolkit of AI, learning platforms, and productivity software has become essential for academic and career success. The best part? With student discounts and India's growing digital infrastructure, smart investing is more accessible and impactful than ever.

The Hard Reality: Your Institution Won't Provide Everything You Need

While India's higher education system serves 4.33 crore students across 58,643 institutions , most colleges provide only basic software access. Meanwhile, freshers entering the job market face average starting salaries of 36 lakhs per annum , often with limited access to premium productivity tools that could accelerate their careers.

The students and professionals who stand out aren't necessarily the smartestthey're the best-equipped. They've learned what successful freelancers and contractors figured out long ago: owning your tools gives you ownership of your growth.

Set an Absolute Tool Stack Budget

As with everything that involves a cost, do not forget to budget for your toolkit. You should treat this cost as your fees for learning, not as an expense. Increase the allocation as you are able to afford more, but never compromise on the toolsetjust like you wouldn't for the reading material for your coursework, or for your lab equipment.

Aim for an absolute annual budget of 20,00025,000 to build your essentials, and 40,00060,000 if you want advanced or specialized tools.
Start lean with basics and scale as you progressthis approach works whether you're a student, intern, fresher, or junior exec.

Remember: these budgets are tiny compared to your potential return in job offers, better grades, and skill growth.

Recommended Toolkits by Domain

1. Technology (Programmers, QA/Testers)

Budget: 20,00040,000/year

ChatGPT Plus or Perplexity Pro: 21,600/year
GitHub Copilot: Free (Student Pack)
GitHub, JetBrains: Free student IDE licenses
Notion, Trello: Free (student plans); upgrade as needed
Udemy: ~1,800/year (23 deep-dive tech courses)
Extras: Microsoft Azure for Students, Kaggle (free)

2. Designers (UI/UX, Graphic, Creatives)

Budget: 25,00060,000/year

Adobe Creative Cloud Student: 21,600/year
Figma Education: Free
Canva Pro Student: 15,120/year (optional)
Notion, Behance: Free
Miro: Free (education plan)
Learning: Udemy or Domestika, ~2,000/year

3. Tech Business Analyst/Product (PM/PO)

Budget: 20,00035,000/year

ChatGPT Plus or Perplexity Pro: 21,600/year
Notion, Google Workspace: Free/6,48019,500/year for business tools
Miro, Whimsical: Free student/education plans
Analytics: Google Data Studio (free), Power BI (free tier)
Learning: Udemy/Coursera, ~2,0004,000/year

4. Non-Tech Professionals (Writers, Commerce, Social Science)

Budget: 15,00030,000/year

Microsoft 365 Personal: 6,200/year, or
Google Workspace Individual: 19,500/year (premium AI plan free for students until Sept 2025)
ChatGPT Plus/Perplexity Pro: 21,600/year
Canva Pro: Free/15,120/year if needed
Courses: Udemy/LinkedIn Learning/Coursera, ~2,0004,000/year
Notion, Obsidian: Free

Why an Absolute Budget Makes Sense As You Grow

As your career progresses, the fixed investment you make in your digital toolkit shrinks rapidly as a percentage of your income but its positive effects continue to multiply. What might feel like a significant outlay as a fresher becomes a negligible cost as you hit higher salary bands, even though the advantages (faster learning, better output, greater career flexibility) accelerate your earning potential.

Early investment pays for itself: Certifications, AI skills, and better quality work lead to higher salaries, side projects, and freelance gigsrecouping your spend many times over.
Compounding returns: The learning curve and productivity edge you gain early stay with you for years, making you more competitive at every career stage.

The ROI: Immediate and Long-Term Benefits

📚 Academic Upside

Faster research and writing: AI tools cut assignment time.
Higher quality output: Premium design and submission tools make a difference.
Skill certification: Verified, global credentials fast-track opportunities.

💼 Career & Earning Power

Better internships and placements: Stand out in competitive fields.
Quicker promotions: Industry-leading tools shorten learning curves.
Freelancing & business readiness: Want to launch side projects? You're already equipped.

Practical Steps to Build Your Own Library

Start with free student offers: Use your .ac.in/edu email for JetBrains, GitHub, Figma, Notion, Canva, Microsoft, Azure, and more.
Budget for one premium AI/learning tool first: ChatGPT Plus, Perplexity Pro, or Courserapurchase annual plans when possible.
Expand with specialized platforms: Add design, business, or tech tools as you identify your needs.
Max out discounts: Buy during festival/academic sales, look for group/family/student plans.
Track your gains: Record time saved, achievements unlocked, or opportunities gainedit will keep you motivated and demonstrate ROI.

Mindset Shift: Why This Works

The most successful professionals invest in themselves earlyoften before their employer does. This bring your own library approach signals initiative, makes you adaptable, and future-proofs your career. As you grow, the cost fades but the benefits compound, helping you get ahead of peers who waited for permission or reimbursement.

Call to Action

Start with 20,00025,000/yearone subscription at a time.
Prioritize free student plans and festival/family discounts.
Upgrade smartly; let your toolkit grow as your ambitions do.
Every rupee invested now becomes trivialand incredibly valuableas your career takes off.

Your phone likely cost more than your first-year software stack. Your annual coffee bill or occasional fast food habit probably does too.Choose tools that move you upmarket, boost learning, and multiply your valueyour future self (and your bank account) will thank you.

The contractors and freelancers charging premium rates arent necessarily more talentedtheyre just better equipped. Its time students and freshers caught up to this fundamental truth.

Credits

This article was generated using Perplexity Pro Research model ( https://www.perplexity.ai/search/write-a-linkedin-post-that-tal-WqRFsdzTS0iA2a41iD1bCg#2 )

Back Link

This article was originally published here on the MandrakeTech Blog

About the Author

Navneet works as a freelancer, mentor, advisor and a fractional CTO in startups that build technology products.

]]>

Docker Community Edition on macOS

Navneet Karnani — Sat, 28 Jun 2025 06:31:12 +0000

If you're a developer on macOS looking to use Docker without Docker Desktop whether due to licensing, performance, personal preference or usage of VSCode DevContainers this guide is for you. We'll walk through setting up a fully functional Docker environment using Colima and the Docker CLI , all without relying on Docker Desktop.

Why Use VSCode DevContainers Without Docker Desktop?

Docker Desktop has long been the go-to solution for container development on macOS. However, recent changes to Docker's licensing model have introduced significant considerations for professional and enterprise users:

Docker Desktop Licensing Restrictions

Docker Desktop is no longer free for all users. According to Docker's official license agreement:

Docker Desktop is free only for :

All other commercial use cases require a paid subscription. This means many developers working at mid-sized or large companies are no longer legally allowed to use Docker Desktop for free.

What About Docker Community Edition (CE)?

Docker CE (Community Edition) refers to the open-source Docker Engine and CLI tools. These remain free and open-source under the Apache 2.0 license. However, Docker Desktop is a separate product that includes a GUI, VM management, and integrationsand it is not covered under the same open-source license.

So while you can still use Docker CE freely, using Docker Desktop in a corporate environment without a license may violate Dockers terms.

This guide walks you through setting up a fully functional DevContainer environment using Colima , Docker CLI , and VSCode , all without Docker Desktop.

Step 1: Uninstall Docker Desktop

First, remove Docker Desktop and its associated components:

brew remove --cask --force docker docker-desktop

This ensures a clean slate for your new container runtime setup.

Note: docker cask was recently renamed to docker-desktop. So, best to clean it all up.

Step 2: Install Colima and Docker CLI Tools

Install the necessary tools using Homebrew:

brew install colima docker docker-completion \ docker-compose docker-buildx docker-credential-helper

What These Tools Do:

colima : Lightweight VM to run containers on macOS.
docker : Docker CLI to interact with the Docker daemon.
docker-compose : Manage multi-container applications.
docker-buildx : Extended build capabilities with BuildKit.
docker-credential-helper : Secure credential storage.

Step 3: Link Docker Socket

Colima creates its own Docker socket. To make it accessible system-wide (e.g., for VSCode), link it:

ln -sf $HOME/.colima/default/docker.sock /var/run/docker.sock

🔒 You may need sudo for this command depending on your system permissions.

Step 4: Configure and Start Colima

Customize the configuration of the colima virtual machine. Below is the one I used on my M1 Pro Mac:

colima start --cpu 4 --memory 8 --disk 20 --vm-type vz --runtime docker --save-config

Breakdown of Options:

--cpu 4: Allocates 4 virtual CPUs to the VM.
--memory 8: Allocates 8 GB of RAM.
--disk 20: Allocates 20 GB of disk space.
--vm-type vz: Uses Apples native Virtualization.framework (vz) for better performance on Apple Silicon.
--runtime docker: Specifies Docker as the container runtime.
--save-config: Persists this configuration for future colima start commands.

Step 5: Test Your Setup

Verify Docker is working:

docker versiondocker run hello-world

You should see Docker client and server versions, and the hello-world container should run successfully.

Step 6: Use LazyDocker (Optional but Awesome)

Launch LazyDocker for a terminal-based UI:

brew install lazydockerlazydocker

lazydocker is a terminal UI for managing Docker containers and images. This tool gives you a clean interface to monitor containers, images, volumes, and logs.

Its light weight, clean interface, and has most of the everyday management asks.

Conclusion

With this setup, you get a fast, open-source, Docker Desktop-free development environment on macOS. Its lightweight, efficient, and gives you full control over your container runtimeperfect for developers who want to stay within Dockers licensing terms while maintaining a powerful local dev setup.

Back Link

This article was originally published here on the MandrakeTech Blog

About the Author

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University, Pune, India

]]>

Enterprise Applications vs Speed of Building: What Are We Trading Off?

Navneet Karnani — Fri, 23 May 2025 18:30:00 +0000

Over the last few years, Node.js and React have become the default stack for many new applications. Theyre fast to pick up, have thriving communities, and make it easy to ship an MVP quickly especially for self-taught developers or bootcamp graduates.

But this speed often comes with compromises.

In many of these applications, critical elements like input validation, error handling, and layered architecture are either implemented inconsistently or overlooked entirely. Not always but often enough to observe a trend. It echoes the early PHP days: fast development, low structure.

In contrast, enterprise systems commonly built with Java or .NET tend to attract developers who come through more formal training pipelines. This usually includes grounding in:

Data structures and algorithms for efficiency and scalability
Design patterns for modular, maintainable code
Architectural principles for long-term stability
Structured exception handling and validation layers as standard practice

These applications may take longer to build initially, but the gains show up later in maintainability, resilience, and the ability to evolve over time without breaking.

In my experience working with fresh grads and interns, Ive noticed a reluctance to go deeper into the computer science stack. Many are quick to adopt labels like backend developer or full stack engineer, but often lack understanding of how systems actually work from memory management to concurrency, from data flows to architectural trade-offs. Its becoming increasingly difficult to find true product engineers people who can think in terms of long-term system design, not just code delivery. And its even harder to explain why slow is actually faster when done right.

This isnt about dismissing modern stacks. Node and React are powerful, and used well, can scale just fine. But when foundational computer science concepts are skipped in the rush to just build something, we often pay for it later in performance, reliability, and developer burnout.

Back Link

This article was originally published here on the MandrakeTech Blog

About the Author

The Author, Navneet Karnani, began coding with Java in 1997 and has been a dedicated enthusiast ever since. He strongly believes in the "Keep It Simple and Stupid" principle, incorporating this design philosophy into all the products he has developed.

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University, Pune, India

Driven software engineer (Java since 1997) with a hands-on passion for building impactful tech products. Possesses decades of experience crafting solutions to complex business and technical challenges.

]]>

VSCode DevContainer for Python Programmers

Navneet Karnani — Fri, 24 Jan 2025 18:30:47 +0000

In today's article, we will explore how to set up a VSCode devcontainer for Python programmers. We will cover the basics of what is a devcontainer and why it's useful, how to create one, and some tips on how to use it effectively.

What is a DevContainer?

A devcontainer is a lightweight, reproducible, container that provides a consistent development environment for your projects. It allows you to develop, run, and debug your code in an isolated environment, which can help you focus on writing code rather than setting up your development environment.

Why Use a DevContainer?

There are several reasons why using a devcontainer is beneficial for Python programmers:

Consistency : A DevContainer ensures that everyone on your team has the same development environment, which can make it easier to collaborate and work together.
Isolation : A devcontainer provides an isolated environment for your code, which can help prevent conflicts with other dependencies or tools you may be using.
Reproducibility : A devcontainer makes it easy to reproduce your development environment on any machine, which can be useful if you need to work remotely or share your project with others.
Efficiency : By setting up a devcontainer once and then simply opening it whenever you want to work on your Python project, you can save time and effort by avoiding the hassle of setting up your development environment every time.

This article delves into getting a VS Code DevContainer Development environment based setup for early Python programmers. The environment runs on Debian, and hence is a good place to start for all School / College students too.

As part of my investigations for my college teaching environments, I was in a situation where I needed to teach Python. And, as some of my readers know, I am compulsively obsessed with not installing any compiler, or programming environment, on my local machine. It has to run in a throwaway-able environment.

So, I looked at the default DevContainer setup that Microsoft ships as part of their images. The environment created a 2GB image on my machine. That was really not something I like working with. So, here are the things you to be more efficient, and nimble.

Prerequisites

This article assumes you have the following already installed and configured:

Docker Desktop
Visual Studio Code , and extension Dev Containers

Getting started

Create an empty project folder in a location of your choice on the machine. And then:

mkdir .devcontainer

This will create a .devcontainer folder inside that. The below files will go inside this folder.

The `Dockerfile`

I used the following Dockerfile for the environment:

FROM debian:stable-slimRUN apt-get update \ && apt-get install -y git python3 python3-pip \ && apt-get cleanWORKDIR /rootCMD ["sleep infinity"]

This gets us in a good place. It has support for the tools mentioned in the install line, and generates an image the size of approximately 820MB. A far cry from the 2GB+ from the Microsoft Container repository. Plus, I have control over the linux version, and more.

The DevContainer

The Dockerfile is never enough. It has to be supplemented with an appropriate devcontainer.json to be effective. So, here is the my version of that file.

{ "name": "python-dev", "build": { "dockerfile": "Dockerfile" }, "customizations": { "vscode": { "settings": { "remote.downloadExtensionsLocally": true, "telemetry.enableTelemetry": false, "extensions.ignoreRecommendations": false, "workbench.remoteIndicator.showExtensionRecommendations": false }, "extensions": ["mhutchie.git-graph", "ms-python.python", "VisualStudioExptTeam.vscodeintellicode", "samuelcolvin.jinjahtml", "donjayamanne.python-environment-manager", "ecmel.vscode-html-css", "twixes.pypi-assistant", "redhat.vscode-yaml"] } }}

There you go. Now you are ready to Ctrl+P or Cmd+P and Reopen in Container .

Have fun coding in Python !!

About the Author

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University.

]]>

Java, SpringBoot and MySQL in devcontainer

Navneet Karnani — Fri, 17 Jan 2025 07:58:53 +0000

In this tutorial, we'll walk through the steps to create a simple Java Spring console application that connects to a MySQL database running in a Docker container, creates a "test" table, and lists all the tables. We'll use a devcontainer.json file to set up the development environment and Docker Compose to define the services.

Step 1: Set Up the Environment

Create `devcontainer.json` file

{ "name": "Java Dev Environment", "dockerComposeFile": "docker-compose.yml", "service": "java", "workspaceFolder": "/workspace", "extensions": ["vscjava.vscode-java-pack", "pivotal.vscode-spring-boot"]}

Create `docker-compose.yml` file

services: java: image: mcr.microsoft.com/vscode/devcontainers/java:0-11 volumes: - .:/workspace command: sleep infinity mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpassword MYSQL_DATABASE: testdb

Step 2: Develop the Java Application

Create a new Spring Boot project

Use Spring Initializr to generate a new Spring Boot project with the following dependencies:

Spring Web
MySQL Driver

Configure the application properties

In src/main/resources/application.properties, add the following configuration:

spring.datasource.url=jdbc:mysql://mysql:3306/testdbspring.datasource.username=rootspring.datasource.password=rootpassword

Create a `Main` class

package com.example.demo;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.CommandLineRunner;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import javax.sql.DataSource;import java.sql.Connection;import java.sql.ResultSet;import java.sql.Statement;@SpringBootApplicationpublic class DemoApplication implements CommandLineRunner { @Autowired private DataSource dataSource; public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } @Override public void run(String... args) throws Exception { try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement()) { // Create a test table stmt.executeUpdate("CREATE TABLE IF NOT EXISTS test (id INT AUTO_INCREMENT, name VARCHAR(255), PRIMARY KEY (id))"); // List all tables ResultSet rs = stmt.executeQuery("SHOW TABLES"); while (rs.next()) { System.out.println(rs.getString(1)); } } }}

Step 3: Run the Application

Open the Codespace

Open the project in your Codespace. The devcontainer.json will set up the development environment and start the containers automatically.

Run the Spring Boot application

In the terminal, navigate to the project directory and run:

./mvnw spring-boot:run

Step 4: Verify the Connection and Execution

Check the terminal output to verify that the connection to the MySQL database was successful and that the "test" table was created and listed.

Built using Microsoft Copilot, with the following prompt:

Can you create a tutorial for me for the following:Create a simple Java Spring console application that connects to a MySQL database, running in a Docker container, create a "test" table, and list all the tables.Set up the environment:Use a devcontainer.json file to use a docker-compose.yml file to define the Java dev environment and MySQL.Develop the Java application:Create a Java Spring Boot application that establishes a connection to the MySQL database using JDBC.Run the application:Build and run the Java application within the Codespace. Verify the successful connection to the database and the execution of queries.

About the Author

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University.

]]>

Managing Multiple GitHub Accounts: A Comprehensive Guide

Navneet Karnani — Mon, 23 Sep 2024 08:05:38 +0000

A lot of organisations these days use Github for hosting their repositories. With BYOD as a normal practice, everyone wants to be able to differentiate their Git access for work from the one for personal use. Here is a way in which SSH based git access can be streamlined, so that you can easily switch between work and personal work, and never make errors

### The intention

In todays digital age, many developers find themselves juggling multiple GitHub accountsone for personal projects and another for work. Managing these accounts efficiently can be a bit tricky, but with the right setup, you can seamlessly switch between them. This guide will walk you through the process of configuring your Git and SSH settings to handle multiple GitHub accounts on the same machine.

Why Separate Accounts?

Using separate email addresses for personal and work repositories on GitHub is a good practice for several reasons:

Privacy and Security : Keeping your work and personal emails separate helps protect your privacy and maintain security. Your work email might have different security policies and access controls compared to your personal email.
Organization : It helps in organizing your repositories and contributions. You can easily distinguish between work-related and personal projects.
Professionalism : Using your work email for professional repositories ensures that your contributions are recognized by your employer and colleagues.

Setting Up SSH Keys

First, generate separate SSH keys for your personal and work accounts:

    # Personal account ssh-keygen -t rsa -b 4096 -C "your_personal_email@example.com" # Save the key as ~/.ssh/id_rsa_personal # Work account ssh-keygen -t rsa -b 4096 -C "your_work_email@example.com" # Save the key as ~/.ssh/id_rsa_work

Add the generated SSH keys to the SSH agent:

    # Start the SSH agent eval "$(ssh-agent -s)" # Add personal key ssh-add ~/.ssh/id_rsa_personal # Add work key ssh-add ~/.ssh/id_rsa_work

Configuring SSH Config File

Edit your ~/.ssh/config file to include both keys and block direct access to github.com:

    # Block direct access to github.com, to never make an error Host github.com HostName github.com User git IdentityFile /dev/null # Personal account Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_rsa_personal # Work account Host github-work HostName github.com User git IdentityFile ~/.ssh/id_rsa_work

Cloning Repositories

When cloning repositories, use the appropriate host alias:

    # Personal repository git clone git@github-personal:username/repo.git # Work repository git clone git@github-work:username/repo.git

Configuring Git for Each Repository

Ensure you set the correct email for each repository:

    # For personal repositories cd path/to/personal/repo git config user.name "Your Name" git config user.email "your_personal_email@example.com" # For work repositories cd path/to/work/repo git config user.name "Your Name" git config user.email "your_work_email@example.com"

Using Gits `includeIf` Directive

You can set up Git to use different user.name and user.email configurations based on the repository path using Gits includeIf directive. Heres how:

Open your global Git configuration file :
Add the includeIf directive:
Create the additional configuration files :

Restricting Access to Private Repositories

To restrict access to private repositories and ensure that only public repositories are accessible, you might need to use network-level controls or firewall settings. This approach can be complex and might require additional tools or configurations.

Conclusion

By following these steps, you can effectively manage both your personal and work repositories on GitHub without confusion. Whether you choose to use different SSH keys, configure Git settings based on repository paths, or employ network-level restrictions, these practices will help you maintain a clear separation between your personal and professional projects.

If you have any questions or need further assistance, feel free to reach out!

Originally published at https://blog.mandraketech.in/managing-multiple-git-accounts
About the Author

Navneet Karnani is a Full Stack Ployglot veteran, and explores technology to build great products, always striving to extract more productivity from the tools he uses. You can follow him at:

]]>

Installing Docker for Windows Home for Standard User

Navneet Karnani — Mon, 15 Jul 2024 12:24:56 +0000

As a learning requirement during my internship recently, I was required to learn the use of Docker. Now there will be people like me, who are new to the concept of what Docker is, this is how it is explained on the Amazon Web Services page for Docker.

Docker is a software platform that allows you to build, test, and deploy applications quickly. Docker packages software into standardised units called containers with everything the software needs to run including libraries, system tools, code, and runtime. Using Docker, you can quickly deploy and scale applications into any environment and know your code will run.

While setting up docker Windows Home, I ran into a few issues in getting docker to run. After a lot of debugging, I realised that the issue I was facing was because I was using a standard user as opposed to the system administrator.

Why Should You Use a Standard User on Windows Home?

A standard account has no power, while an admin account can do anything. So why would you want to use a standard account? That's a good question, and the answer is that it's because it lacks power. We are human. We are going to make a mistake sooner or later. In an admin account, we could end up ruining something crucial very easily, or maybe even make the entire computer unbootable.

However, a standard account won't have such issues due to the lack of power. Additionally, this account will also stop malicious programs like malware from damaging your Windows system.

So if you don't already use a separate standard user account on your computer, this is your sign to start.

Setting Up Docker Desktop

The first step in setting up Docker is to install Docker Desktop. After downloading and running the correct version of the Docker installer, follow the steps to completely install it. You can follow this guide to install it, or use this one to install it backend on WSL 2. Once you are done with the basic steps, is where the debugging comes in.

To check whether docker has been properly installed, type 'cmd' in your Windows search bar and run your Command Line as administrator. Enter the following command.

docker version

If your output looks like this:

Client:
 Version:           26.1.4
 API version:       1.45
 Go version:        go1.21.11
 Git commit:        5650f9b
 Built:             Wed Jun  5 11:29:54 2024
 OS/Arch:           windows/amd64
 Context:           default

Server: Docker Desktop 4.31.1 (153621)
 Engine:
  Version:          26.1.4
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       de5c9cf
  Built:            Wed Jun  5 11:29:22 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.33
  GitCommit:        d2d58213f83a351ca8f528a95fbd145f5654e957
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Then docker is working fine. If not, then it can have one of many fixes.

Changing User Type

If you are a standard user, as recommended earlier, you will need to give yourself the required permissions to be able to use Docker.

To check if you have the required permissions, press [WINDOWS + R] and enter 'netplwiz'. This will take you to the Advanced User Accounts Control Panel. Here you will be able to see your user type. If you don't aren't part of the 'docker-users' group, here is the fix for it.

Open up the command line as an administrator, and enter the following command.

net localgroup docker-users "user-id" /ADD

Your "user-id" is your local windows username, and can be found by looking at the folder name under C:\Users\ .

Now when you go back to Advanced User Accounts Control Panel, docker-users should be added as a group for your user account.

Enabling Docker Daemon

If while using docker, you get an error message like the one shown below:

Client:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   d8d3314
 Built:        Tue Nov  1 03:05:34 2016
 OS/Arch:      windows/amd64
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.25/version: open //./pipe/docker_engine: The system cannot find the file
specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.

In the case of this error, open up the Docker Desktop app and go to the settings page. Check the box which says 'Expose daemon on tcp://localhost:2375 without TLS', and then apply the changes before trying again.

If you have followed all of these steps, then you should now be able to use Docker properly.

This article was originally published at: https://blog.mandraketech.in/installing-docker-for-windows-home-for-standard-user

A Privacy Practice Reminder

Navneet Karnani — Sat, 22 Jun 2024 06:30:25 +0000

As a matter of privacy, please change your user ids to not have your birth dates, other dates of relevance, in there. You will be surprised how many times a username / password is leaked. Preferably, use a password manager.

Apple, Google, Microsoft and Firefox ship very capable tools for password management. Some people do not like to use those, and for them there are third party offerings, with both free and paid licenses. I have evaluated Bitwarden and LastPass in the past, and finally settled on my OS provided one, because it allowed me to remember only one credentials for access. Yes, it puts me at risk if I lose that, or if the vendor decides to lock me out. But, I am safer that way then forgetting the password to the password store itself.

If you already have accounts what have the above combination, and the site allows you to change it, please act on priority.

If the site does not support renaming, and the accounts are "not important" from a "losing data" perspective, please delete them and create new ones with random names / passwords generated by the password manager.

For email, you should create a new one without those numbers, and have the emails "forward" to the new account. And, in the future, use the new email address.

No matter your age, you still have a long life of sharing contact details with people, so it will be worth upgrading now.

End of the 16gb RAM era ?

Navneet Karnani — Fri, 21 Jun 2024 08:42:41 +0000

Until recently, I always bought computers with 16gb RAM. As a developer, this was important, but also necessary for optimal performance. Specially with tools like Docker, and IntelliJ needing the resources they do. I don't mention Chrome, because that is a choice people make. And I make different decisions. 🙂

I am seeing that with the advent of Large Language Models, and integration of GenAI tools in the core operating systems, the need for better models, and more memory will show up very soon. Also, I am seeing that the 70b (10+ gb) models are way better than the 3b (1.5+ gb) ones. I know the small ones are only going to get better from here, but remember that the large ones will benefit from that technology too.

Plus, supporting large context windows will be a requirement, and the "hosted" versions will get increasingly cheaper (like Gmail made "unlimited" email storage mainstream). But, we have to be careful, and remember that one fine day, Google did come back and say that unlimited only means 17gb.

Also, as developers, we tend to work better when we are disconnected ( Airplane mode anyone ? ). So, having a model that works when on the road / plane is always a good idea. And for this reason alone, I prefer running the models on device.

But running these models does not come cheap. With 16gb RAM, I can run the 3b models today, for code completion, blog writing, etc. But, as time passes, I want more out of them. I also have situations where there are multiple models loaded. One for Chat, another for Tab completion. And we will now also get MacOS and Windows run a LLM for OS features. So, memory will start vanishing faster than we will know.

So, my feeling is that my next machine will be a 32GB one. And Apple makes it even more attractive by changing the nomenclature of memory available, from 16gb to 18gb, and from 32gb to 36gb. More the merrier, right ?!

VSCode DevContainer setup for C/C++ programmers

Navneet Karnani — Fri, 14 Jun 2024 10:35:20 +0000

This article delves into getting a VS Code DevContainer Development environment based setup for early C/C++ programmer. The environment runs on Debian, and hence is a good place to start for all School / College students too.

As part of my investigations for my college teaching environments, I was in a situation where I needed to teach C++. And, as some of my readers know, I am compulsively obsesses with not installing any compiler, or programming environment, on my local machine. It has to run in a throwaway-able environment.

Getting started

Create an empty project folder in a location of your choice on the machine. And then:

mkdir .devcontainer

This will create a .devcontainer folder inside that. The below files will go inside this folder.

The `Dockerfile`

I used the following Dockerfile for the environment:

FROM debian:stable-slim

RUN apt-get update \
    && apt-get install -y git g++ gcc make gdb \
    && apt-get clean

WORKDIR /root

CMD ["sleep infinity"]

The DevContainer

The Dockerfile is never enough. It has to be supplemented with an appropriate devcontainer.json to be effective. So, here is the my version of that file.

{
    "name": "cpp-dev-container",
    "build": {
        "dockerfile": "Dockerfile"
    },
    "customizations": {
        "vscode": {
            "settings": {
                "remote.downloadExtensionsLocally": true,
                "telemetry.enableTelemetry": false,
                "extensions.ignoreRecommendations": false,
                "workbench.remoteIndicator.showExtensionRecommendations": false
            },
            "extensions": [
                "ms-vscode.cpptools",
                "kunalg.library-documentation-cpp",
                "danielpinto8zz6.c-cpp-compile-run"
            ]
        }
    }
}

There you go. Now you are ready to Ctrl+P or Cmd+P and Reopen in Container .

When you open the container, there is an extension called CompileAndRun that will allow you to run the current C/C++ file using the default settings. You can also set the breakpoints.

Have fun C++ing

About the Author

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University.

Web application, Need they be complex ?

Navneet Karnani — Tue, 30 Apr 2024 09:36:21 +0000

Over the past few weeks, I have started learning #Python , because all the students I teach, and mentor, come with that as the background. Until recently, I was helping them learn "different" programming languages, but with the noise around AI, LLMs and the works, they seem to be more inclined to stay with that.

So, I created a "proof of concept" application for a friend. And I am amazed at the fact that my understanding of "low complexity application is the norm" actually is true. The problem domain is fairly complex, and the security requirements very stringent. But I have been able to put together a foundation that will allow her to get help from just about anyone in the world to keep her application updated.

In my opinion, it cannot get more #lowcode than this. Anything else, is just lock-in. And will come back to bite people very quickly.

By the way, I had a similar experience when I built the same app, using Java, H2DB and the internal HttpServer that ships with Java. The only external thing I needed to use was the Thymeleaf templating engine, and I think it was an overkill. Should have just relied on Java Server Pages.

Yes, you heard that. No Kubernetes. No microservices. No microfrontends. Just plain simple HTML (server rendered). Scales for most users, and keeps the costs low.

Let's talk about the solution I built. The implementation has:

Every user has their own db, so no chance of crossing over of data
No one can query for "all the data" at any point, until the tools for that are built
The app will build more security for the db, that will run password rotation regularly, making the data even more secure
Built using Python, and Flask - the programming language, and library, with a long history, and every student learns this in college
Uses SQLite as the database, the smallest, fastest and most popular database in the world. Probably sitting on your computer right now if you use Firefox. If you use an Android or iOS device, then you are using SQLite. SQLite also does not need a server, so we do not keep "unnecessary" data in memory.
We follow a "keep it light" philosophy, so our server does not use more memory, or CPU than is necessary. We use a "just in time" fetching of data, and release it immediately.

In production, the app will use a secure-by-default strategy with the Caddy Server sitting before our actual python server, that serves certificates to your browser from the most popular, and trusted, certificate provider LetsEncrypt. The certificates are rotated every 60 days, so there is reduced chance of spoofing continuing for longer than is needed.

In the hosted dev deployment, we use an approach called "ssh tunneling" that allows us to host our application without it being exposed to the internet at all. The server we run on, is initiating a onnection to the internet, and then traffic is routed from there. We use Cloudflare, the most trusted provider for internet security for our security.

In local dev, we use Docker Compose, and Caddy to mimic our production setup as far as we can. Caddy allows us to use https, even for localhost urls, and hence build the html pages with the right security warnings addressed.

I use Gitlab CI for building the production image, and Docker Compose for the deployment.

About the Author

Navneet works as a freelancer and is available for contracts, mentoring, and advisory roles related to technology and its application in software product development.

Additionally, Navneet serves as a visiting faculty member at FLAME University, teaching the Distributed Systems (CS402) course to the BSc(CS) Hons. batch graduating in 2024.