This is far and away the biggest problem I have atm. Engineers blowing through an incredible amount of work in a short time, but when an inevitable bug bubbles up (which would happen without AI!), there's noone to question. "Hey, you changed the way transactionality was handled here, and that's made a really weird race condition happen. Why did you change it? What edge case were you trying to handle?" -- "I don't know, the AI did it". This makes chasing things down exponentially harder.
This has always been a problem in software engineering; of course -- sometimes staff have left, so you have to dig through tickets, related commits and documentation to intuit intent. But I think it's going to make for very weird drags on productivity in _new_ code that may not counter the acceleration LLMs provide, but will certainly exist.
Elon may not be _intending_ to pay foreigners to cosplay as patriotic Americans.
However, X pays people based on engagement. A number of people outside the USA have figured out that if they post outrageous shit to Americans, they get engagement -- and therefore earn money. So in fact, Elon _is_ paying foreigners to cosplay as Americans, but it might not have been what he meant to do.
I kind of don't get this comment. Isn't the `jj` default behaviour effectively `git commit --all`? There's no staging area -- and I personally find `git add` or `git add -p` a better UI than `jj commit -i`.
Meanwhile, there are git tools that solve the above three problems. My organisation uses `git-spice` (https://abhinav.github.io/git-spice/) which tightly integrates with Github to give you stacked PRs, editing of branches and management of your stacks in Github.
I've been trying jj for a while now because Steve Klabnik heavily recommended it, and so far it hasn't clicked in as nicely as my existing git setup.
I think everyone uses jj a bit differently. Personally I don't like having a staging area; for me it's an opportunity to forget to add a change to a commit. I don't keep files in my work tree that I'm not going to commit or ignore.
But when I first moved to jj I tried to make it work as closely to git as I could. The model I used back then was to have a commit that I meant to upload eventually, and then a working commit on top of that. Then `git commit --all` was `jj squash` and `git commit foo bar` was `jj squash foo bar`.
Eventually I got lazy. It was an extra command, and I almost never have the situation where I don't want to include a file. In the rare case that I do, I'll create a new commit with `jj new` and squash that file into there (you could have a shortcut for it, but the long form is `jj new -m "foo changes" --no-edit && jj squash --to @+ foo`, and then keep working.
Thanks, I'll try that :). Despite the fact that I've worked my way back to `git` for my mainline work, I've still got some repos that I've left jj live in to keep picking away at it.
I'm not sure why people aren't saying Spring Boot, but Spring Boot. Yeah it has heaps of other batteries included, and it doesn't have a built-in admin, but it gives you pretty decent stuff out of the box
I've been similarly half-interested in it for... more than a decade now. The new release (which is what I assume prompted this post) looks pretty impressive (https://github.com/perkeep/perkeep/releases/tag/v0.12).
Why would this need to work with Tailscale? It just needs to be running on a machine in your tailnet to be accessible, what other integration is necessary?
I'm a co-author of tsidp, btw. You don't need tsidp with a Tailscale-native app: you already know the identity of the peer. tsidp is useful for bridging from Tailscale auth to something that's unaware of Tailscale.
I use `tsnet` and `tsidp` heavily to safely expose a bunch of services to my client devices, they've been instrumental for my little self-hosted cloud of services. Thanks for building `tsidp` (and Perkeep!) :).
The YouTube thing is Google's choice, not Apple's, as those are "premium" features. Install Vinegar (https://apps.apple.com/us/app/vinegar-tube-cleaner/id1591303...) to get a standard HTML5 player in YouTube, which will let you make it full screen, PiP it, background it, whatever.
> The YouTube thing is Google's choice, not Apple's, as those are "premium" features. Install Vinegar (https://apps.apple.com/us/app/vinegar-tube-cleaner/id1591303...) to get a standard HTML5 player in YouTube, which will let you make it full screen, PiP it, background it, whatever.
But it IS Apple's choice. The problem is they have a mixed up conflict of interest, and it's even worse when Apple themselves is trying to sell you their own services.
IMHO the company making the hardware, the company making the software, and the company selling the cloud services shouldn't be allowed to all be the same company. There's too much conflict of interest.
Google sells PiP, background playing etc. as part of YouTube Premium (not Apple!). Google serves browser clients a player that can't do those things, because they want you to pay for them. Vinegar is a browser extension that replaces Google's player with Apple's plain HTML5 player. Apple's plain HTML5 player does all that stuff for free.
I love Django, and the new `tasks` framework to replace `celery` (/whatever processor you prefer) looks great.
I've only recently come back to it, and I do hope they continue to add more batteries to their "batteries included" framework over time. I was surprised just how much stuff I had to add to my little project that will require updating _outside_ the main framework, eg.:
* django-components for little template partials (I'm not sure the new partials feature is robust enough to replace this)
* django-(configurator,split-settings,pick-your-poison-here) for more robust settings management
* structlog for much better logging (feels like this should get baked into Python's stdlib...)
* debug-toolbar
* dj-database-url for parsing database URLs (should be baked in!)
* django-money
There's plenty of other deps that are less annoying/surprising (eg. Sentry, granian, Tailwind), but the set above feel like more or less like they should be baked in, and (to my mind) don't represent an inordinate amount of work to adopt.
Other than that, it's been a real pleasure coming back to it, and I'm excited for its continuation.
EDIT -- oh, and built-in static types, stubs and stubs-ext were a bit of a nightmare to get working well.
I just recently found it and it has been amazing. It logs all your requests and responses by default (but is quite configurable) as well as your SQL queries (and how many/how long they take), in an easily searchable database. It can even profile functions for you.
Makes it very to see at a glance what pages are slow for people, and why, so they can be optimized accordingly.
Absolutely! Just wish half the filters weren't broken... if I try to show only "POST" requests or only things from X seconds ago, it just always shows nothing... several other fields aren't working either.
It’s likely a future left-wing government will reintroduce these funds. The problem is the ratcheting effect: it takes no time at all to destroy something like this. Society reacts; people leave, people retrain, we lose the ability to do the thing we used to do. Then, a new government arrives and we rehire into these positions: it takes a lot more money to find people, attract them back to the country, get their programs established… and then the next government arrives and says “wow this is inefficient” and cans it again.
NZ in general is starting to suffer from the swings in partisan politics, despite our MMP system. Similar problems happen with bread and butter infrastructure projects.
True. The current government has taken a torch to everything the prior government did whether it made sense to torch, or not (replacement Cook Strait ferries for example). And they've enacted a bunch of extreme ideologically driven policies that no government left wing nor center could bear to keep.
We're in for dizzying swings in direction
This government arrived on a promise of “fixing” our financial problems. A lot of these shortfalls have been artificially created; as an example, our healthcare sector went from breaking even to being “hundreds of millions” in deficit after the budget was massaged. That created the “crisis” that let them fire the board in charge and appoint a commissioner who has been aggressively slashing public services in order to meet the new budget. The reduction in service is driving growth in the private insurance sector.
Science is in a similar position. The shortfalls they’re talking about now are shortfalls they created last year and left to rot so they could have a crisis now.
> A lot of these shortfalls have been artificially created
Can you point to a link showing this?
Officially:
Our revised budget for 2024/25 is a $1.1 billion deficit. This is significantly lower than the $1.76 billion deficit we were heading towards without our cost reduction programme,” Ms Apa says
I’m on my phone right now and getting search engines to limit their time frame in a mobile UI is tiresome, so I’ll do that when I’m back at a computer :) (but the core thing to do is compare projected budget under the previous govt and actual budget under this govt). Both of those numbers above are post-new budget. The budgeted “increase” in healthcare was less than the increases in population and inflation. It gets worse when we add in the fact that NZ has an aging population with requisite cost increases.
This govt gave us tax cuts and restored billions of dollars in tax rebate for landlords which decreased the spending pool available for things like healthcare.
Sure, but the framework cares about that for me. I don’t use rails personally but that’s the whole point — someone upstream of me is paying attention and making everything work together.
In contrast, I have work apps made in React that need regular piecemeal updating — routers, form libraries, query managers, CSS — because we’ve chosen to cobble that together ourselves. That’s fine, that’s the path we chose knowingly when we picked the tech we picked, but the point isn’t that frameworks don’t have dependencies — it’s that they take on more of the burden of managing them for you.
Well, Next is kinda like that then. It takes care of the sub-dependencies for you and when you upgrade, you just upgrade to the next major Next version (which isn't necessarily easy, but more so than upgrading 100 individual packages). They provide codemods for some stuff too.
I suspect that most rails, or next, projects add additional dependencies than just the framework. Generally the framework isn't the issue in my experience.
Sure, but it's not an either/or situation. Every big project adds dependencies, but using Next means you have some basic, common functionality included out of the box by default/by convention (like TypeScript, linting, testing, routing, caching, SSR, static builds, serverless definitions, etc.) all done in a predefined way. Maybe your project has 200 deps, but Next would replace like 50 of the big ones that you'd otherwise have to separately install and maintain. Just having a basic page/app router and minimal state system (via contexts and RSC and props and such) reduces a lot of the headaches of the bad old React Router days.
It replaces "React soup of the day" with a more standard "recipe" shared by most Next projects – like "Grandma Vercel's secret React minestrone", I guess. But yes, projects would typically still add their own "spices" on top of those basics.
This has always been a problem in software engineering; of course -- sometimes staff have left, so you have to dig through tickets, related commits and documentation to intuit intent. But I think it's going to make for very weird drags on productivity in _new_ code that may not counter the acceleration LLMs provide, but will certainly exist.