For others, here's the paper: https://arxiv.org/abs/2507.00002
3,799 karma · joined July 16, 2013
I tried Zulip (cloud offering) with some techie/designery friends, so we should have been right at home but... the desktop app on macOS and the web app was visually unappealing and clunky, and we ended up going back to a paid Slack plan.
I looked for docs on how to theme Zulip (so I could contribute), or for existing theme packs that would soften the transition but found neither.
tl;dr: The functionality was good (Love the threading!) but the UI feels like the 2000s came calling. Some UI polish would go a long way.
I cannot remember what the platform was called, let me know if you do.
Fully responsive layouts, where sidebar content is interleaved with page content on small screens, but in a sidebar on larger screens.
Demo: https://codepen.io/pbowyer/pen/raLBVaV
Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.
CSS Grid didn't solve this, as it added gaps: https://codepen.io/pbowyer/pen/azNarbZ
And using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them at a time. Eventualy I hope that https://github.com/w3c/csswg-drafts/issues/9098 will land and we'll be able to use this saner way to do it.
That's people doing real-vibe coding prompts, like "Build me a music player with...". I'm using the $20 Codex plan and with getting it to plan first and then executing (in the same way I, an experienced dev would instruct a junior) haven't even managed to exhaust my 5-hour window limits, let alone the weekly limit.
Also if you keep an eye on it and kill it if it goes in the wrong direction you save plenty of tokens vs letting it go off on one. I wasted a bunch when Codex took 25 minutes(!) to install one package because something went wrong and instead of stopping and asking it decided to "problem solve" on its own.
I've been waiting to be able to have a fully responsive layout (where interleave sidebar content in with the page content on small screens, but have it in a sidebar on larger screens) without using any JavaScript, and this finally makes it possible.
Demo: https://codepen.io/pbowyer/pen/raLBVaV
Previous comment: https://news.ycombinator.com/item?id=46228993
Having a standard test input/output format would let test definitions be shared between libraries.
It would be fun if you could share a similar pipeline problem to your take-home (I know you can't share what's in your interview). I started off in scientific Python in 2003 and like noodling around with new programming languages, and it's great to have challenges like this to work through. I enjoyed the 1BRC problem in 2024.
I need to write this up properly, but one of my bugbears with responsive design is that it became normalised to push the sidebar down below the content on small screens. And if you didn't have a sidebar, to interweave everything in the content no matter what screensize you were viewing on.
What I want is a way to interleave content and asides on small screens, and pull them out into 1+ other regions on larger screens. Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.
This CSS Grid approach adds gaps: https://codepen.io/pbowyer/pen/azNarbZ
Using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them.
'Good' old floats get most of the way, but put the item in the sidebar exactly where it falls. Plus they're a pain to work with overall: https://codepen.io/pbowyer/pen/jEqdJgP
Cardinal seems to be almost as responsive, except that the current search doesn't update when you delete a file that's in it - you have to search again for it to be gone. IIRC Everything auto-refreshes the view.
It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.
Which solutions do you have in mind?
- VPS with software installed on the host
- VPS(s) with Docker (or similar) running containers built on-host
- Server(s) with Docker Swarm running containers in a registry
- Something Kubernetes like k3s?
In a way there's two problems to solve for small organisations (often 1 server per app, but up to say 3): the server, monitoring it and keeping it up to date, and the app(s) running on each server and deploying and updating them. The app side has more solutions, so I'd rather focus on the server side here.
Like the sibling commenter I strongly dislike the configuration management landscape (with particular dislike of Ansible and maintaining it - my takeaway is never use 3rd party playbooks, always write your own). As often for me these servers are set up, run for a bit and then a new one is set up and the app redeployed to that (easier than an OS upgrade in production) I've gone back to a bash provisioning script, slightly templated config files and copying them into place. It sucks, but not as much as debugging Ansible has.
Still not up to Cursor standards though :)
You can install MySQL/PostgreSQL on the application server, connect over a unix socket and get the same benefits as if you'd used SQLite on the application server (no network latency, fast queries). Plus the other benefits that come from using these database servers (Postgres extensions, remote connections, standard tooling etc). I'm guessing more RAM is required on the application server than if you used SQLite but I haven't benchmarked it.
Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
Their instructions were fairly good; securing the web interface was the hardest part. AI should solve that for you!
At a high level the WordPress community doesn't mesh because of having the WordPress way of doing things, and having a history of writing for old versions of PHP years after others have moved on and told users to upgrade. The WordPress community is fragmented into separate sub-communities which again don't mesh. There's the users who only build sites with page builders and hardly know how to code, those whose goal is to sell copies of their paid plugin (or hosting services), and those with permission to make changes to WordPress itself.
I've no recent experience of Drupal so can't comment on them.