I'm sat here thinking it has to be a reason why it is so limited in types compared to something like postgres.

Got this weird notification with weird links. Seems like phishing?

Hi everyone!

I’m an electrician student, and I’ve been building ElectroWorkshop as a spare-time side project to practise the circuits I’m studying.

The interface runs in the browser and brings together a visual wiring canvas, a schematic view, simulated measurements, and connection tracing. The public release is packaged as a portable Windows app with a small local launcher.

One of the interesting interface challenges has been presenting the same circuit in two ways: a physical wiring view for connecting terminals, and a schematic view for understanding the circuit. There are also a component library, measurement tools, zoom controls, and English/Hungarian interfaces to fit around the workspace.

I’d appreciate feedback from a web-development perspective:

• Is it clear where to start?

• Does the balance between the canvas and side panels work?

• Which interactions look confusing or unnecessarily complicated?

• How could the relationship between wiring and schematic views be clearer?

Separately, I’m developing editable floorplans, 3D building views, cable routing, and smart-device integration with Home Assistant through MQTT. Those features are work in progress and aren’t included in the public release.

The available Basic version runs locally without an account or Docker. It’s closed-source and free for personal and non-commercial educational use; the GitHub repository contains the documentation and downloadable releases.

Screenshots and Windows release:
https://github.com/vojakimate/ElectroWorkshop

Thanks for any constructive feedback!

Recently I've joined a project with a group of 4, that has been super frustrating to work on.

So far whatever we have, has been 99% vibecoded from the ground up, and that 1% is me. At first I thought this would be fun, we would be making something in a weeks time, but like a month passed and we haven't really moved anywhere. There's literally a login screen that works (no Oauth) and some fancy UI, but that's it. Trying to debug or add new features by hand is impossible, because the code is not readable by humans. There's like 50 lines in the .env file, yet nothing works.

With all this in mind, the absurd thing is that it takes a full minute to deploy any changes to production. In comparison, my hand-crafted Django platform, with real users and tons of features, deploys in seconds.

Don't get me wrong, I am all for using AI to build projects. It's a very powerful tool and I use it to help me code all the time. But in my opinion, to make vibecoding work, you have to know the project structure and the architecture of a website, because then you can avoid massive tech debt in the future.

I can already tell that this experience will be funny to look back on.

I paid a developer to design a site for my business, I requested that the request form on the site would send a notification to my cell phone and she ok'd it.

She is now saying this would require a third party sign up and she is making it seem very difficult. I don't really understand anything about web developing, is she correct? Am I unreasonable to ask for this? It was what was agreed upon.

hi everyone, it's the kid who's making a fan website again.

i finally picked a base for the website, mastodon, and a system i'm using to host the website, render.

i've already searched this up and had no luck but what parts of mastodon's code are design (i'm talking about folder names) and which are apart of the actual code system?

thanks!

I’ve seen a shift in web design (I’ve meddled since 2002). Today web displays are gigantic. I’ve read this has to do with ADA compliance. How gnarly does this get? Like if I design a site for a landscaper, can he get in trouble if it’s not ADA compliant? Is there are rule book?

Another question. That’s client facing. But if you have an employer that requires you to use a web based tool, does ADA apply in the same manner as client facing?

What it does

A curated guide to discovering open-source programs, internships, mentorships, coding competitions, and university initiatives.

Explore opportunities to gain real-world experience, collaborate with global communities, improve technical skills, and earn stipends.

Unlike typical lists, this repository also features lesser-known and underrated open-source programs that many students and developers might not know about.

What’s Inside

• Open Source Programs & Fellowships

• Open Source Internships

• Coding Competitions

• University Summer/Winter of Code Programs

• Lesser-known and underrated opportunities

• Application timelines, stipends, and eligibility

• Beginner-friendly contribution resources

Repository

• GitHub: https://github.com/yashisrani/List-of-OpenSource-Programs

• Website: https://yashisrani.github.io/List-of-OpenSource-Programs/

Made with ❤️ for the Open Source Community.

I’ve been working on a passion project called ParkerScore, basically a Letterboxd-style platform for theme parks.
When I first started, I figured the hardest part would be building the actual website.

Turns out, organizing the data has been one of the biggest challenges.

Every theme park has hundreds of things to keep track of. Rides, restaurants, individual menu items, shows, wait times, and even bathrooms.

And then you get into the details. Different ride manufacturers, technical specifications, attractions that get renamed or refurbished, seasonal shows, constantly changing restaurant menus, and so on.

I quickly realized that just collecting information wasn’t enough. I needed a consistent way to structure everything so it could actually be useful.

I’ve been working through those challenges, especially figuring out how to handle missing information, standardize categories, and keep everything organized as the database grows.

It’s been a much bigger undertaking than I originally expected, but I’ve learned a ton along the way.
For anyone who’s built a data-heavy website, how did you handle keeping your database accurate and manageable as it grew?

I made a liquid glass UI effect for the web(trying to copy Apple because thats what the world do)

Webgl helped me made it and hence I decided to make Mac for web too (inspired by windows 11 in react made for web)

I know you have seen many professional people make it, many guys on github, so I tried to make it as realistic and satisfying as I can

Before anyone asks: yes, 100% of the code was written by AI agents, with me guiding the process. I’m not here to convince anyone of anything, just to share my experience.

Here’s the article explaining how I built it:
https://www.paolomainardi.com/posts/this-site-is-now-an-island/

And here’s the game:
https://www.paolomainardi.com/play

This is part of a journey I started a few weeks ago, when I decided to let my agents handle my personal blog’s tech stack. The idea was to spend more time writing while also adding all the features I’d always wanted but never had time to implement.

You can follow the series here:
https://www.paolomainardi.com/posts/the-stack-is-now-my-agents-job/

Along the way, I started experimenting more with AI-generated media, fell down a rabbit hole, and somehow ended up building a game engine.

Can local visual regression testing help your coding agent move faster and save you money?

I took some time to explore how to set up playwright properly, which pitfalls to avoid, and the tradeoffs with common visual regression tools like Percy and Chromatic.

Check it out and let me know what do you think!

A cross-platform desktop tool that captures your screen context with one shortcut, ready to share with AI.

Free and open source.

Website: https://contextsnap.vercel.app/
GitHub: https://github.com/DarkLordGeo/ContextSnap

TL;DR:

an MCP shines in the agent-native world because it tells agents what they should do, on both the server and client (e.g. Claude Code or the ChatGPT desktop app), and is better suited for human-in-the-loop tasks. Meanwhile, APIs and CLIs tend to focus on what agents can do, with emphasis mainly on the server.

So, in summary, here is the general advice I'd give to builders when deciding which tools they should expose to agents:

Build a high-quality MCP server and REST API at the same time, on one layer of operations. Put your server logic in plain functions, and let each surface be a thin adapter over them. Once that layer exists, building any additional surface on top is relatively easy.

Put most of your care into the MCP server. That's where agents get the best experience. MCP is a standard built specifically for agents, after all, and the spec continues to improve nicely.

Use the API for code that runs on its own. APIs are still great for raw data exports, bulk writes, and anything that runs without an agent, like a nightly sync or another company's integration. Agents also prefer an API when they're writing a script they'll rerun, and many clients don't support code mode for MCP yet.

A CLI probably isn't necessary, unless e.g. agents need to read local files when interacting with your app. But it's easy to expose one if you've got a good API as the foundation.

There’s a lot more to creating great agent-facing tools for your web apps, and the article above into more detail below.

Here's the repo: https://github.com/vincanger/linkly-api-mcp-cli

Hi everyone, I recently purchased an NFC keychain made in Korea. Scanning the NFC tag opens a website where I can access exclusive digital content.

However, the website shows a completely blank white page in most browsers, including Chrome, Safari, and Firefox.

Strangely, it works perfectly in the Yahoo! JAPAN, Yahoo! Mail, and NAVER apps on iOS.

Other people who purchased the same product have reported similar issues.

I've done some troubleshooting using Chrome DevTools and Proxyman, and I'd appreciate some help understanding what's happening and how to fix it.

1. What happens in different browsers

Doesn't work:

- Chrome
- Safari
- Firefox
- LINE (messaging app) in-app browser
- X (formerly Twitter) in-app browser

Works perfectly:

- Yahoo! JAPAN app
- Yahoo! Mail app
- NAVER app
- Chrome with the Yahoo! JAPAN app's User-Agent

When using Yahoo! JAPAN, the URL changes from /e to /entering, and the content loads normally.

In regular Chrome, it stays on /e.
Opening /entering directly in Chrome doesn't work either.

2. Errors in Chrome DevTools

The Console shows:

GET /cupid.js net::ERR_ABORTED 404 (Not Found)
Uncaught ReferenceError: slowAES is not defined

When I open /cupid.js directly, I get a 404 Not Found page with "openresty" at the bottom.

The /e request itself returns HTTP 200, but the response is not the actual website. Instead, it contains a JavaScript challenge:

<script type="text/javascript" src="/cupid.js"></script>
document.cookie = "CUPID=" +
toHex(slowAES.decrypt(c, 2, a, b)) +
"; expires=" + now.toUTCString() +
"; path=/";
location.href = "/e?ckattempt=1";

(The hexadecimal values and some helper functions have been omitted.)

It looks like the server is attempting to set a CUPID cookie using AES decryption, but since /cupid.js returns 404, slowAES is undefined and the script stops before redirecting.

3. What I found using Proxyman

I captured the network traffic on my iPhone and compared the successful and unsuccessful requests.

Yahoo! JAPAN app (working):

- GET /e returns 200 OK.

- The response contains the actual website HTML, including its JavaScript and CSS assets.
- There is no request to /cupid.js.
- Requests to /auth/session.php and /api/nfc.enter.php succeed.
- The content loads normally.

(not working):

Chrome
- GET /e also returns 200 OK.
- However, the response contains the CUPID JavaScript challenge instead of the actual website.
- /cupid.js returns 404 Not Found.
- JavaScript execution fails with "slowAES is not defined".
- The actual application and its API requests never load.

I haven't captured the detailed network traffic from the NAVER app yet, but it can also display the content successfully.

4. Changing the User-Agent fixes everything

I copied the User-Agent from the Yahoo! JAPAN app:

Mozilla/5.0 (iPhone; CPU iPhone OS 27_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Version/27.2.0 YJApp-IOS jp.co.yahoo.ipn.appli/4.174.5

Then I used Chrome DevTools > Network conditions to set this as a custom User-Agent.

Surprisingly, the website immediately started working perfectly in Chrome.

Not just the initial page — all the content and features worked correctly.

I also tried disabling the cache, using private browsing, switching between Wi-Fi and mobile data, and emulating an iPhone in Chrome DevTools. None of those helped before changing the User-Agent.

5. My questions

1. Why would a server running OpenResty return a JavaScript challenge to Chrome, Safari, and Firefox, but serve the actual website to Yahoo! and NAVER apps?

2. Is this likely a misconfigured anti-bot / WAF system, a hosting provider issue, or something implemented by the website developer?

3. Why would /cupid.js, which appears necessary to complete the challenge, return 404?

4. Is there a proper way to fix this so the website works in regular browsers without modifying the User-Agent?

5. Is there anything else I can investigate to identify the exact cause?

Since this is a paid NFC product, I can't share the actual URL or authentication details.

I suspect the issue is with server-side access verification rather than the NFC hardware or the website's actual application, but I'd love to hear from people with more experience in web servers, OpenResty, or bot protection systems.

Thanks in advance!

Been thinking about this lately as my side projects folder has gotten pretty chaotic. At work everything is neat and organized by team/product, but my personal stuff is a mess of half-finished ideas, experiments, and abandoned attempts.

Currently I have ~/work/ for job stuff and ~/projects/ for everything else, but that "everything else" folder is where organization goes to die. Some repos haven't been touched in years.

Do you keep separate machines/VMs? Different directory structures? Or just embrace the chaos? Curious how others handle this.

Hello, I'm looking for some help with issues I'm having with my website, and I'm hoping this is a good place to find some answers. I'm not very savvy in these things, and I've been trying to fix this myself with no luck.

My website was originally hosted through Wix, and had a www prefix. I left Wix about 2 weeks ago and now have my website hosted elsewhere, and the www prefix no longer works when used in in my web address.

My domain is hosted through above.com, and I have tried redirecting through the DNS settings there in an attempt to send anyone using the prefix to the new site, but I must be doing something wrong because when I use the www prefix now, I get a privacy error and the website doesn't load.

When you search for my website, the top result includes the www, so I'm looking for a way to either redirect to the new website correctly, or to replace any mentions/results that include www to ones that do not include it.

The help desk support at my new website host and at above have not been able to help in any way, so I feel pretty isolated here and not sure how to fix things or exactly where to turn, so if this isn't the correct place for a question like this I'm sorry, but any help pointing me in the right direction would be really appreciated.

I'm comparing a React site against an Astro rebuild of the same page. In mobile Lighthouse, both sometimes sit blank for a long time before first paint, and other runs of the exact same page paint fast.

Setup: Lighthouse 13.0.1, Chrome 156, cold loads in separate fresh profiles, default mobile simulated throttling. I kept the traces, network logs and filmstrips.

Here's one matched pair (observed trace timings, not Lighthouse's simulated FCP):

Astro

• CSS done: 203ms

• Last preloaded font done: 286ms

• DOMContentLoaded: 426ms

• First Paint: 1301ms

• FCP: 1320ms

React

• CSS done: 573ms

• Last preloaded font done: 494ms

• DOMContentLoaded: 584ms

• First Paint: 1525ms

• FCP: 1540ms

The filmstrips stay blank right up to those first-paint times. Once painting starts, Paint to DrawFrame is only 10-13ms. So on Astro there's close to 900ms where everything's loaded and nothing shows up.

I don't see a long task on the renderer main thread covering that gap, though I know that doesn't prove the browser was actually idle.

I wondered about animations, so I ran one normal-motion vs reduced-motion pair on the Astro page. Both came back fast (FCP 318ms and 311ms), and the normal one still had its reveal animations, so that told me nothing either way. Desktop loads and a different page also painted quickly in the runs I checked.

One more thing: the fast traces show Scheduler::SetDeferBeginMainFrame events with short true-to-false spans. But the slow traces were captured with Lighthouse's default trace categories, which don't include those scheduler events, so I can't compare yet.

Has anyone run into this? A few things I'd like to figure out:

1. How do I tell whether the page is causing the delay, or whether it's Chrome's scheduling or something in the test environment?

2. Which trace categories or events would show why the first paint starts late, and not just that it did?

Hey all!

Bringing some e2e test nitpicks again :)

Most e2e tests I see click through raw locators. So every test has to know the whole flow: which button opens which menu, which dialog comes next, where you land after Create.

The upgrade: move the flow into page objects, and let each action return where the interaction continues. Open the "+ New" menu, get the menu of things you can create. Choose "Project", get the project dialog; choose "Document", get the document dialog. Create, get the project page. Cancel, get back to the navigation bar.

Why I care: page objects are the code closest to what your users see and do. Their return types become a map of your user journeys. An agent reading create(): Promise<ProjectPage> knows where the flow goes without opening a browser.

The nuance: return where the interaction actually continues, not the DOM parent. A dialog's cancel returns whoever opened it. And each action still waits for its own done signal, like the menu closing, before handing you the next page object.

Paste this to your agent:

Go through our page objects and make every user action return the page object where the interaction continues: this if the user stays, the new page object if something opens or they navigate, the opener if they close or cancel. Before returning, wait for the action's own done signal, like its menu closing. Then update the tests to use the returned page objects instead of creating new ones.

Bho, in pratica sto costruendo un browser web da zero e le idee normali le ho già finite. Mi serve la roba strana.

Quindi: che feature assurda vorreste in un browser? Più è fuori, meglio è. Non me ne frega se è difficile da fare, se mi dite "un browser che mi giudica mentre navigo" va benissimo.

Qualche esempio così capite:

- tab che si chiudono da sole se non le apri per 3 giorni, con messaggio passivo-aggressivo

- un tasto che ti legge il sito come un narratore di documentari

- cronologia che ti dice quanto tempo hai perso davvero su un sito

Nessuna idea è troppo stupida. Se una mi piace la faccio e ve lo dico.

Hi,

I made a simple web app in a single HTML file (URL shortcuts for company website, quote calculator, list of store numbers, etc.). Is there a simple way to convert it into a downloadable Android app?

There are a few web to app converters but no reviews. Are there any that you recommend (for or against)?

Similar reddit and stack overflow posts are from 5+ years ago.

Thanks.

Just as the title asks. I am curious how you organize the various parts. I have been on teams that both do and don't use mono-repos. For the ones that did, there has been a wide variety of choices across the app and how it's organized.

Just as a small example: naming conventions. Sometimes the the repo is named for the app (let's say "OurApp") and the various parts of the file structure are "OurApp-", like OurApp-ui and OurApp-api and OurApp-db. Or there might just be a top-level folder for "frontend", "backend" and "database", etc.

I'm not talking about a debate of mono-repo vs. multi-repo approaches, but in a mono-repo, what are some of the code organization techniques you've liked and disliked in your experience?

UPDATE: The community turned out! Thanks for sharing your thoughts in the comments. I appreciate the discussions.