https://griptonite.io/ my gym uses this, qr/nfc on routes with ability to take video and it shows you as stick man and where weight is etc. its new but seems good!
674 karma · joined April 24, 2010
Currently maxing out two Claude code accounts every x hours when working on large code migrations or setting up new iOS apps etc - most of time it’s fine but occasionally it’s mega frustrating!
On the other hand, we are generally deploying to AWS Graviton anyway which is ARM as well, so perhaps it will be more similar!
Not a python person, so not sure if this is me or not, but just very unclear what this is doing/what it's meant to do.
Idea sounds useful, but I can't tell what this is meant to do/what I can do with this.
No pricing also means that hard to understand if this is something I can use in production or not.
I'm usually a typescript/lambda kinda guy for reference, and have already used openai in production on that stack.
Or maybe thinking that rents might suddenly spike due to increased mortgage costs.
It’s just great!
I think this is where Apple 'just does stuff right' - you know if you buy the Studio Monitor that it will just work, having built in webcam is really nice, I presume it will charge a laptop etc.
Price is steep though.
As a counterpoint though, good software practices ensure the application is reliable and easy to modify as the business needs change, so it’s not just about shipping features with no regard for software quality.
I use an app to pay a small amount each month to offset emissions.
I'm vegetarian, partly due to climate issues.
I'd like solar panels, but they are expensive and won't offset my whole electricity usage.
I'd like an electric car, but currently drive a petrol car, but will change when I can.
I very rarely fly, and only once every 10 years fly long haul, though generally due to budget rather than emission based constraints!
I'd like to cut more, but it's tough to see how to make cost effective cuts.
This means that polishing around the edges, e.g. documentation can have more time applied.
There is also different context - for internal tools, the scope is often well understood. The team who are using it are long term colleagues. There is no need for a logo, flashy landing page etc to convince people to use the tool. There is no need to sell it to stakeholders - they asked for it in the first place.
We can also make really good assumptions about what features can be cut. In an internal tool we know our users, we know which teams need the tooling etc. We can do training. So we can very deliberately ignore certain use cases etc.
In OSS we don't know any of that, so often have to cater to everyone, hence building a much more robust tool.
It's also some survivorship bias - the incredible OSS projects rise to the top and do have all this stuff. There are 10,000 internal tools built for every 1 popular OSS tool. The 'bad' OSS projects aren't being seen or used, so we don't notice how bad quality those ones are.
This would then allow other tools (e.g. git, GitHub, pre commit linters, frameworks) to flag this as a problem, either with a warning or an error, depending on the tool.
The idea is that then the novice/rushing expert is prevented from this easy to make mistake.
We all know how to do it right, but particularly early on in a project it's easy to test something with a hardcoded API key, then forget and commit it.
Picking a framework that makes this a less obvious choice (e.g using a .env file that's already in gitignore by default) helps a lot here.