Since I'm between jobs, I've been taking the time to relearn geometry, trig, calc, and linear algebra. I've finished the first two and it's both humiliating and really fun to relearn some math. As an adult, I feel a very different appreciation for how much fundamental math we take for granted. I definitely recommend https://www.khanacademy.org/ and pauls notes (https://tutorial.math.lamar.edu/).
HN user
erdaniels
https://erdaniels.com
Based on the number of comments, upvotes, and recency, I expected it to stay up longer! I think you're right on the flame war part.
Did this get yanked off the front page?
I think if anyone is looking for a concise way to talk about the problems with LLM and agentic coding, it's this. People say AI assisted coding but for much of what I've seen (and tried), it's the tool, gateway, and interface to some people's work now.
This feels AI written as the post goes on. Either way, I'd like for us to stop fetishizing how we can use AI to make us stronger, better, and more valuable engineers. It's exhausting and doesn't consider other ways to use it. I've only been using it lately for tasks that are a step or two above google. Having it write code for me has just been a slippery, unfulfilling slope.
Ah I love this article. I'm now thinking about the idea of encouraging coworkers to orally defend their design documents which are using more AI generated content. People keep saying that we have to focus on what comes before and after code and I think this is a good place to apply friction and avoid building fragile systems.
If you don't know what a reasoning token is, then how can 39 be considered shockingly few?
Yes, full stop. They say they cap the body to 16k and give the LLM a warning, lol. And this is coming from a credit card company.
I'm not trying to be rude here, but this doesn't belong on this site. This is like posting documentation on CloudFlare for a tutorial that isn't remotely a feature.
Yeah it was the same thing with tech force or whatever it was. It's on the last page of the application.
Yet another US Job application where you need to answer "How would you help advance the President's Executive Orders and policy priorities in this role?". Instant pass.
Now we have to trick the models when you legitimately work in the security space.
I love how much time, money, and energy we are wasting on trying to trick these machines. Each day someone has a new bag of tricks.
Yes, as far as I've been told, they are. I imagine (hope) they run on a completely isolated version of it though.
What about it? You are responsible for the software you run.
Preach... thank you
Then people would lose a lot of money
it does support it (https://docs.gitlab.com/administration/settings/scim_setup/) but we're not using it. We just do manual invites for now at our size. As far as kicking users out goes, if they're kicked out of gsuite, they're kicked out of tailscale, and they lose their gitlab access.
Yeah I tried hosting forgejo and the first issue I found was that it was crashing some of the time with our large monorepo and getting actions/runners up and running was proving time consuming; I really did like how lightweight it was, monolith wise. gitlab has a lot more architecture behind it but the documentation is very good at describing how you should configure it for your needs.
I think Forgejo would work fine for smaller projects and teams. We really wanted to stop having to worry about GitHub going and not being able to do CD as well as get away from a lot of the action zero-days happening.
And yes, it's self-hosted and free! You can run a reference implementation pretty easily with non-production components (i.e. they won't backup or scale well).
I just migrated our entire company off of github to gitlab self-hosted. So far so good. It's entirely behind tailscale so we don't have any SSO tax from gitlab and all of our CI runners are on EKS + an on-prem cluster with GPUs. If anyone needs help or motivation accomplishing the same, just reach out!
Good question. To quickly answer, no you don't need it installed locally but you will benefit from having the source available.
Just so we have a common reference, look at https://github.com/edaniels/graft/blob/main/pkg/local_client.... The main idea is that we are always matching the local current working directory to the corresponding synchronization directory. Using that idea, we serve an LSP locally that rewrites all json-rpc messages that utilize URIs (https://github.com/edaniels/graft/blob/main/pkg/local_client...) from local to remote, and back. The local LSP and the remote LSP we launch are none the wiser. Because of this proxy, when you go to definition, you are going to load the local source definition; when you go an lsp format tool, it runs remotely and the file sync gets you results locally.
The lsp functionality is pretty barebones but has been working for me in sublime when I open a project of mine in a graft connected directory. I've tested it on golang and typescript. I believe python should work but I suppose dependencies could be funky depending on how you synchronize dependencies (uv, pip, etc.).
For go, I used this on my lsp settings and it worked great. What doesn't work great is if you get disconnected :(. Making the LSP very reliable is another story for another task for another day.
{
"log_debug": true,
"clients":
{
"super-gopls":
{
"env": {
"GRAFT_LOG_LEVEL": "debug",
},
"command":
[
"graft",
"lsp",
"gopls"
],
"enabled": false,
"initializationOptions":
{
"analyses":
{
"composites": false,
},
},
"selector": "source.go",
},
},
"lsp_code_actions_on_save":
{
"source.fixAll": true,
"source.organizeImports": true,
},
"lsp_format_on_save": true,
}Also check out https://www.restate.dev/. We chose this internally after evaluating it against temporal, hatchet, and dbos. The docs are pretty good and development locally and deployment to k8s was simple.
Agreed that SaaS feels ugly. Agreed on selling it as libre. The only thing I could imagine charging for in a subscribed model would be for services that are hosted (e.g. instance/gpu provisioning/monitoring/maintenance in the cloud) while also offering the ability to self-host the same machinery.
Hey ibobev! I've actually been building something very close to box at a snail's pace for 2 years. I built it since I was working a lot with a bunch of raspberry pis where it was better to compile directly on the pi then on my mac but I didn't want to bother to ssh in or lose my local setup. The major difference with what I have so far is that the tool takes a direnv automagical approach to work with multiple machines across multiple projects/directories. It works across docker and ssh without any extra setup other than the tool on the client side.
I just got native LSP working this past weekend and in sublime it's as much as: { "clients": { "remote-gopls": { "command": [ "tool", "lsp", "gopls" ], "enabled": false, "selector": "source.go", }, } }
From what you built so far, do you think there's any appetite in people paying for this type of tool which lets you spin up infra on demand and gives you all the capabilities built so far? I'm skeptical and I may just release it all as OSS when it gets closer to being v1.0.
No, but it's pretty common IME to create an Atlas cluster that has internet-wide access (0.0.0.0/0) when testing and forgetting to turn this off. According to https://jira.mongodb.org/browse/SERVER-115508, this affects unauthenticated ops. Based on the repro code itself, it looks like this happens way before authentication is checked for the corresponding OP at the OP_MSG decoding level.
So if you're using Atlas, check that your Cluster has auto upgraded already. If you're using 0.0.0.0/0, stop doing that and prefer a limited IP address range and even better, use VPC Peering or other security/network boundary features.
Time to get off for good. We're moving to https://forgejo.org/. With downtime and this, screw them.
I think fixtures generally work fine. If a change to one breaks many tests, introduce a new one and start using that. I also think it's okay to make some manual changes to them in the test and it's distinct from wanting factories; needing factories only in test code feels like a waste.
100% agree with "Test only what you want to test".
This sounds promising. Keep us posted! If there's anywhere we can track progress, please link :)
I was getting frustrated trying to figure out how to get a wheel and pex built in my work's uv monorepo/workspace. I've been used to how easy it is to build a go binary for any platform. Anyway, once I figured it out, I figured I should publish my cleaned up findings. This is great for deploying self-contained python executables and not needing to worry about any packaging non-sense at runtime.
The end of the post disturbs me. I'm finding it hard to believe this writing is AI. I don't want my future to be reading articles written by AI that I mistake for being human written.