Fair point. Switching tools is definitely one way to deal with it. The article is more about good practices that can help teams manage their usage better in the first place, based on my real-world experience with large teams.
A browser-based tiny pseudocode IDE for Cambridge AS Level Computer Science students, built using Claude Code.
Try it : https://pseudo-code-ide.onrender.com/
The why : Cambridge AS students write pseudocode for exams — a structured, precise dialect defined by the syllabus. The problem? There's nowhere to run it. Students write code on paper, guess whether it's correct, and find out weeks later when results come back. That feedback loop is challenging for learning. This loop is closed to zero. Also, the compiler that runs entirely on the browser with no requirement for a backend or server.
Repository : https://github.com/nsriram/pseudo-code-ide/
The how : The app presents an exam-style question, gives students a plain editor (no autocomplete — that's intentional, exams are unaided), and compiles their pseudocode the moment they click Compile. If it's clean, it runs against the question's test cases and shows pass/fail instantly. 50 questions. Three difficulty levels. Works on any device.
SCA & Code Quality
90 end-to-end Playwright tests (15 full student journey scenarios). The e2e suite runs against both docker on pipeline and on the deployed app at render.com
515 unit tests, ≥90% branch coverage enforced in CI, Quality Report
Linting with '6' ESLint plugins, pre-push hooks
Auto deployed on Render
Pipeline : https://github.com/nsriram/pseudo-code-ide/actions
Compiler
Writing a tiny pseudocode compiler from scratch involved a lot of learning. The pipeline has five phases, all written in TypeScript and fine-tuned for students with corners cut.
"Lexer → Parser → Validator → Interpreter → Evaluator"
more here : https://github.com/nsriram/pseudo-code-ide/blob/main/COMPILE...
Features :
- 23 real past papers : Feb/Mar sessions from 2021 to 2025, covering every question type students will encounter.
- Full virtual bench : choose glassware, add reagents, heat, stir, filter, and weigh, with realistic colour changes and gas observations.
- Live reaction feedback : the lab responds to what you do: indicators change colour at the endpoint, precipitates form, gases are identified.
- Measurement precision hints : get nudged when a burette reading isn't to 0.05 cm³ or a balance reading isn't to 0.01 g.
- Per-question answer boxes : type written answers alongside each question part, mirroring the Cambridge answer booklet layout. Add results tables and scatter graphs directly within each answer box.
- Free Lab mode : experiment without a set paper; great for exploring reactions and building intuition.
- Automated marking : a built-in rubric engine scores every section against the Cambridge mark scheme and gives criterion-by-criterion feedback.
- PDF report export : download a formatted report of your session including observations, answers, and scores.
- Multilingual UI : switch between English, Tamil, Hindi, Spanish, and Chinese.
- Works offline : your session is saved automatically; nothing is lost on refresh.
---
The app is still in alpha and some outputs may not be accurate.
But, sharing it anyway because something like this could genuinely help students across the world. Education for all.
Contributors are welcome to add reactions, papers, and features to make it closer to a real lab.
Thanks Alex. Those are very kind words.
I would not have made a career in IT, if not for opensource. So contributing my droplet contribution to that ocean.
I use ddg as my default on laptop(Firefox) and mobile(safari), on SE Asia region.
The basic search results are quite reasonable. The challenge comes when I need specific information, or second level info. It gets quite hard and I end up hitting a !g on private mode. Partly, stackoverflow helps.
I would say 80-85% it is ddg.
Having said that, I also feel ddg has come a long way than how it was 3-4years back and I’ll continue to use it.
Thanks. Have covered the add-permission in S3, API Gateway integrations.
Yes Terraform is definitely recommended. This was written for learning purpose.
Basis of the article is questionable. Humans slow down on traffic to avoid accidents. Ants don’t have that constraint. Neither will ants cause a stampede and can suffocate to death.
For me in 2006, when i moved from Java to Ruby, the videos by Dave Thomas (pragprog) changed the dimension of thinking at code level - I did do java reflection, but the whole method_missing to object specific methods etc., explained in a neat fashion by Dave Thomas were amazing !
Good post from Divij. I worked at amazon a decade back and my 2 biggest learning there were from (1) building large scale infrastructure components (2) DevOps is an inherent responsibility of Dev.
People do it and there is no effective tracking system in place. As any media house, the headlines and the content inside are contradicting itself.
A headline like 'Philanthropy challenges in India' would have made sense. Comparing to US is a poor benchmark as well.
Please go and check for contributions made by Indian citizens on crowd funding platforms like 'Rangde', you will realise there is some serious traction on.
Valid points.
- another aspect to consider seriously when designing SPAs is authentication. I have built ReactJs applications and everytime we need a different module that had only the login functionality.
Somehow this always appeared disconnected whereas In traditional apps you have a middleware that watches before rendering, be it client side or server side rendered.
Understand the 15 min and <1min coldstart. The question was more towards test suites with 100’s of tests for really large products and you cannot break them. The scenarios won’t make sense. The feedback from these tests will not be done in 15 mins.
What is the advantage of running automated tests as lambda ?
Typically when automation tests are run, they are long running processes and lambda execution may not be suitable.
The cold start times of lambda is another challenge.
What is a good practice/model for running suites ? One test per lambda or, one spec per lambda ? Still inclined to have ec2 instances created and destroyed via devops tools like terraform to run automation.
Thoughts please.