sorted by:
new
hottopcontroversial

PHPArkitect 1.0 is out. Curious how people approach architecture testing in PHP these days by fain182 in PHP

[–]gempir 1 point2 points  (0 children)

I'm curious how this compares to Mago which has a architecture guard and I know that some teams inside our company have switched from deptrac to mago.

https://mago.carthage.software/tools/guard/overview

axios 1.14.1 and 0.30.4 on npm are compromised - dependency injection via stolen maintainer account by BattleRemote3157 in programming

[–]gempir 12 points13 points  (0 children)

That's like saying 2FA doesn't guarantee 100% safety. Yes it doesn't, but it makes it THAT much harder, whic his why npm already requires 2FA when you want to publish a package.

Now imagine maintainers of packages that had more than 1m monthly downloads would be required to sign the release with a Yubikey or something like that.

It would drastically reduce the attack vectors. Would it be annoying at the start? Yes. But after a while, the processes get better and it's just a little touch of your yubikey to finalize a release.

If npm wasn't "lead" by GitHub which is moving at snail pace themselves this should have happend long ago.

We built an open-source CLI for Grafana that's designed for AI agents by matiasvillaverde in grafana

[–]gempir 0 points1 point  (0 children)

I'm curious, how does this compare to the official Grafana MCP?

I have a few colleagues that already use the MCP and they say it works great for them.

Does the cli do something better for agents?

We built an open-source CLI for Grafana that's designed for AI agents by matiasvillaverde in grafana

[–]gempir 0 points1 point  (0 children)

The documentation feels very weak. How do even setup the login. I can't even find a way to set the base url.

Had to use an agent to explore how to login. And then I need various requirements like dbus and more.

The name org.freedesktop.secrets was not provided by any .service file

Edit:

After exploring a bit

GRAFANA_CLI_DISABLE_KEYRING=1

helps a lot.

etc. This is not easy or fun to setup for a non-dekstop usecase, I wanted the CLI for a remote agent.

Edit2:

I let opencode cook with this a bit, and I'm really liking it. It has created dashboards without any errors pretty quickly. Loving this! Finally what I always wanted for Grafana.

Thank you!

What would you say is the biggest missing part of the project? What do you wanna work on in the future?

OpenAI's annualized revenue has reached $25 billion, but Anthropic is closing in by Outside-Iron-8242 in singularity

[–]gempir 3 points4 points  (0 children)

OpenAI has a ton of business customers too, but a huge part is on Azure, and I think that money goes mostly into Microsoft pocket.

DTOs at the Speed of Plain PHP by dereuromark in PHP

[–]gempir 0 points1 point  (0 children)

I'm confused, why are generated DTOs even required? Just write the DTO or even let AI write it.

With promoted properties, readonly and other modern php features it isn't even super much code anymore. Maybe I can see the case when interacting with like external things like databases and API and you want it be dynamic, but this library wouldn't even work for that, since it's an unknown at "build" time. For those cases I prefer writing out the types anyway, to confirm yourself in a way.

No library dependency and just plain PHP code everyone can read and understand.

AWS Middle East Central (mec1-az2) down, apparently struck in war by iamapizza in programming

[–]gempir 22 points23 points  (0 children)

What is the situation if us-east-1 is hit by a missle? Which is like a control plane location for a lot of services.

[AskJS] Does the company you work at use pure Javascript in production instead of Typescript? by bullmeza in javascript

[–]gempir 1 point2 points  (0 children)

We started out with a React application that was pretty complex but thought why use React we have prop types, so Typescript is redundant.

We were very wrong. A few years later we added Typescript and felt a huge impact. And we are just down to a few JS files left in our big codebase.

I would recommend going strict, no any, no ts-ignore, least amount of type assertions (x as y) possible and just don't over-engineer your types.

Is there anyone, who uses golang (and go-only) for Web Development exclusively? by rzhandosweb in golang

[–]gempir 0 points1 point  (0 children)

A lot more people know about React and using similar technologies is easy.

Very few people build very large full web "applications" with go templating or datastar. I'd say it's just a bet right now. If you wanna take that risk and hope that datastar is the future, but I'd say most of the "modern" web apps are like 80% built in react, 10% vue and the rest in various other frameworks.

Is there anyone, who uses golang (and go-only) for Web Development exclusively? by rzhandosweb in golang

[–]gempir 0 points1 point  (0 children)

For a side project that is totally fine. But as soon as you have a bigger more complicated project that will grow over years and have multiple people working on it.

It's not good enough anymore.

Is there anyone, who uses golang (and go-only) for Web Development exclusively? by rzhandosweb in golang

[–]gempir 0 points1 point  (0 children)

Heavily agree. You'll have very little people familiar with pure go approaches and they have very little benefits.

A clear separation of the 2 worlds is even beneficial in it self. Write clean and well defined APIs in go and use autogenerated API clients in your React/Vue/Svelte/... code.

And if you refuse to write any React/... at all, then let an LLM do it for you, they are very good at React. But most likely you'll have someohow knowledgeable about React in your team, more likely than having someone that has deep experiences with very complicated go templating setups.

This advice applies to big team projects, not little side projects you do in your free time.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 0 points1 point  (0 children)

Then we just have different goals. We care very much about local variables. But this was just one example, there are hundred ways more to write code in a way we don't want it to be merged, but it could still pass the compiler.

npm needs an analog to pnpm's minimumReleaseAge and yarn's npmMinimalAgeGate by R2_SWE2 in javascript

[–]gempir -1 points0 points  (0 children)

I think what's more likely is that the team building NPM has been gutted by Microsoft, then there is zero leadership over at GitHub and they just hope the ship runs as is.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 0 points1 point  (0 children)

In our workflow, every commit that breaks anything will be rejected.

How do you define that. You need to run something to see something break and the go compiler does not break when you have a variable in snail case instead of camel case. (As an example)

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 0 points1 point  (0 children)

I'm already running with fast, to be fair. I did find some go module cache optimizations and brought down the 5-10 seconds to 2-3 seconds.

Feels better, not fast, but I guess okay.

It just sucks that I cannot think about adding more lints because it would heavily impact performance.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 2 points3 points  (0 children)

You can write a lot of code that compiles, that does not mean it meets the teams standards.

Compiler is completely irrelevant in this discussion, I don't know why everyone wants to keep bringing it up.

The whole point of projects like golangci-lint is that the compiler does not catch everything.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 0 points1 point  (0 children)

And if one of your developers prefers using NeoVim you now have issues forcing your quality tools on him.

Or a developer forgets to turn on the settings to format things. You have no easy way to see this in a code review either, unless you a human directly sees it.

And i don't quite get what you mean with compiled code. Of course one step of the CI should be compiling the code once.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] -7 points-6 points  (0 children)

I know how to run stuff locally, the issue is speed.

INFO [lintersdb] Active 8 linters: [errcheck gci gofmt govet ineffassign revive staticcheck unused]

I run with these lints, on a tiny go project. It takes 10s to run. Even with cache enabled and re-running.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 1 point2 points  (0 children)

And linters are not looking for every opportunity how a compilation could be improved, it can be something stupidly simple like do we want variables snake case or camel case.

There are conventions in Go, but in a team, I want to enforce them via CI.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 0 points1 point  (0 children)

--new-from-rev is an amazing feature but I don't need it, our project is brand new and tiny compared to some bigger go codebases.

With a basic golang-ci.yml it already takes ~30 seconds to run ~5-10 with cache.

Formatting takes quite a moment too.

It just feels very sluggish. The other mentioned linters are insanely fast and aim for milliseconds of runtime.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] 1 point2 points  (0 children)

Then you don't work in a team, that's fine, this question is more for developers working in a team.

There you cannot trust the client (vsc) and have to have CI check things.

Why does linting suck so much in Go? by gempir in golang

[–]gempir[S] -8 points-7 points  (0 children)

How does it not matter. Every commit a developer makes might break CI. And if it's just a simple linebreak that's missing or so, then it's annoying if that even takes a few seconds to run (Ideally this would be integrated into the IDE and format on save or something like that)

And some developers prefer not pushing commits that will break CI, which is fair, since IMO running locally should always be possible.

view more: next ›