richbradshaw

I’m keen to understand speed here etc etc. if I bought a Mac studio with 96GB - what can I realistically run, how’s it compare to fable/opus etc and how fast is it?

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!

We never did it - started but changes were too hard to manage on the large code base - we have L4 running on PHP 8.1/Mysql 8 and all is good currently!

I have a Wifi 6E router, so I wonder if 6GHz vs 5 vs 2.4 acts noticeabley differently here? Is the overall shape the same or does the frequency make a big difference?

Isn't the polishing cloth thinner?

The thing I’m keen for is keeping my open ai function definitions and having Claude (or Llama) return the same “do this function call with these arguments” syntax. Needs a little prompting to do it but by hand it works just need a wrapper so I can talk to Claude with same inputs as functions as Open AI. Does this do that?

I was in same boat, switched years ago. One thing to be aware of is that on newer M series chips (M1, M2) these are ARM, so if you really really need prod to match then that might be an issue.

On the other hand, we are generally deploying to AWS Graviton anyway which is ARM as well, so perhaps it will be more similar!

I tried this out using ship try. I'm not a python dev, so installed pip and Jupyter, then tried the ticket tagging one and the audio transcripts one, but neither worked - one referenced a json file of ticket examples that didn't exist, and the audio one couldn't import utils.

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.

Awesome video - well researched and produced. First thing I’ve seen on YouTube for ages that’s compelling like this!

Where I am it's seagulls, then owls.

Our team moved to VS Code for Typescript and some older PHP, works really really well, and seems to be the 'industry standard' I'd say. https://survey.stackoverflow.co/2022/#section-most-popular-t... results show same - 74.5% of respondents use VS Code.

Interesting - psychologically this super annoyed me that my year old iPad Pro couldn’t do this. Glad they have made it possible!

I presume they mean the landlord will not be able to pay the mortgage and hence have the house repossessed. I'm unclear on what that means for tenants in UK.

Or maybe thinking that rents might suddenly spike due to increased mortgage costs.

Probably start with “when code is run make sure GPU is utilised”.

I’ve had tons of cars and only seen this behaviour in one - think was Citroen.

CO2 sensors are the most common way I believe.

Yeah agree - I used Spotify back in the day, then Google Play Music, then Apple Music when HomePods first came out. It’s just simple, works well, has the awesome lyrics function and has good quality human curated content.

It’s just great!

Safari can generate 2FA codes natively as part of keychain since 2021 - probably the most accessible way to do this for a non technical user. https://9to5mac.com/2021/11/16/use-safari-password-manager-a... Has more details.

I haven't heard of that monitor, but looked it up as looked interesting - people say it has burn in, that it randomly turns off when using M1 Mac Mini, that you can't get full resolution on some Macs (though maybe they used wrong cables) and that can only update the firmware via Windows.

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.

I think it’s more the move to understanding business context and more of a product mindset. Outside of “purely technical” libraries, most applications are sponsored and written to solve business problems and to add value. Under this lens then how the software helps produce value is more important than how it does it.

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'm the opposite, I thought all I saw and heard were real, and everyone I saw was a fake! Scary!

Yes, though I can't seem to do a lot about it.

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.

There is often no time pressure, and no commercial pressure.

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.

How does this compare to the overall death rates? Are LEOs an outlier here?

Unless they have a real blackhead problem I guess!

I have the beta and it currently doesn’t appear to work.

You can do this in the built in notes app, click the camera on the bar at bottom and choose Scan Documents.

The article is from 2015, so doesn't look like this had much impact!

The idea is that people issuing tokens (e.g. AWS, Mailchimp etc) in my example would follow this.

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.

It's common (for novices/experts who are in a rush ) to accidentally commit AWS keys for dev environments, or other API keys (e.g. Mailchimp) or other secrets (2FA, SAML certs etc).

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.

iOS for privacy, security updates, integration with other devices.

Android for customisation, custom roms and more varied hardware functionality (e.g. foldable devices)