blopker

For those wondering, this is now the default markdown processor in Astro 7: https://astro.build/blog/astro-7/#markdown--mdx-in-rust

Sure, local coding is clearly _possible_, but it's not practical for most people. I've yet to see a reliable setup, if you have one, I'd love to see.

> creating plans, using subagents and compactions

Yes, these are all things that Claude Code does for you. However, for the thought loop issue, these are not the fixes. The canonical fix is to limit the number of thought tokens (llama.cpp's `--reasoning-budget`) or try to mess with the various penalty parameters. In any case, it's not a solved problem as far as I can tell.

I've been working with local models for the past year. There's so many possibilities, but I don't think coding is one. Coding requires so many layers beyond inference; I spent so much time trying to replicate what Claude Code does end to end locally. Understanding all the layers and keeping up with the advancements feels like a slog. Even this article messes up and misunderstands what some of the settings are doing. Qwen in particular seems to work at first, then often gets stuck in thought loops when used for actual work.

However, text-to-speech, speech-to-text, and non-code LLM use cases are so useful to have local, and don't require big hardware.

Having a universal reliable inference engine interface, I think, is the big unlock that needs to happen before app devs can ship these features.

Personal concrete use case: meeting recording app. This uses Parakeet + Qwen to create local transcriptions and post-cleanup, respectively.

Right now this app has to download and manage all these models, then bundle an inference engine to run them. It's a lot of code that probably should belong to the OS, or at least a standard interface.

While apps can offload some of this to llama.cpp or a similar process over http, that's another set of setup for the user to do before they can have a useful app.

Anyway, if you're getting started on a Mac, I'd suggest trying out oMLX (https://github.com/jundot/omlx) before messing with llama.cpp. In particular they have community benchmarks so you can see what kind of performance you're likely to get: https://omlx.ai/benchmarks. I wished each one had more configuration details though.

I've been using this keyboard on and off for a while now. I've always switched back to gboard, however this update made me convert full time. It's really good.

There are a few issues, like it randomly capitalizes words in the middle of sentences. Also, it doesn't seem to take context into account when suggesting words, so words that clearly wouldn't follow the last word will often show up.

It's not as good as gboard yet, but close enough that I'm going to stick with it.

Note that if you have a more powerful device, you can get larger models for voice and larger dictionaries from their site. They make a noticeable difference.

The only fundamental issue I have with it, they seem to be ideologically opposed to adding a GIF search, which I miss occasionally. https://github.com/futo-org/android-keyboard/issues/293#issu...

There are still a few unsolved problems that require tuning for specific applications. Applications that own the video call have a much easier time, they have access to each individual audio stream. Applications like this, however, have to deal with overlapping voices from a single stream. If it's trying to attribute each utterance to an individual, separating the voices is tough, or can lead to confusing transcripts. There are many little problems like this which make it a tough problem in real world usage. Domain specific terms, or proper nouns is another source of inaccuracy.

Nice! I really like how many variations on this idea are coming out. MacWhisper used to be great, but is kinda of a buggy mess now.

I'm making my own, for personal use. I did a survey of many and they all (that I could find) skip the fundamentals.

The major issues that I've run into:

- Crash recovery. Most of these apps are incredibly buggy and crash all the time, taking the recorded audio with them. Macwhisper is incredibly bad at this.

- Disk space. Many of these apps save wav files to disk. After a few hours of meetings, you may end up with gigabytes eaten.

- Microphone bleed. People don't always use headphones, the system mic will pick up the speaker sounds, causing duplicate (approximately) transcriptions.

I've yet to find a solution that handles all these correctly, let alone having high quality transcriptions.

Anyway, most of these apps are built around https://github.com/FluidInference/FluidAudio, if anyone is curious. Their readme has a big list of similar apps as well.

UUIDs are way over used. There is almost always a better key to use, usually a bigint for databases. If you're making some kind of leaderless distributed data store, then maybe, but even then there are other ID sharding strategies I'd go for first depending on the constraints.

For a single database, bigints are smaller and faster, with less footguns.

UUIDs can be nice for an opaque public ID, however I'd still prefer something like a Sqid for space and usability.

Every time I see something like this (turn function calls into a network call), I reflect fondly on the list of fallacies in distributed computing [0]. These are issues that largely have to be handled in an application-specific way, and cannot be solved in the general case.

This list alone has saved me many late debugging nights, just by not making or using systems that ignore the list.

[0]: https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

Google answers this question in the FAQ: https://developers.google.com/speed/webp/faq#does_webp_suppo...

But in my experience, webp is better enough that the whole file loads around the same time the jpg progressive loading kicks in. Given that progressive jpgs are larger than non progressive (so not a 'free' feature), jpg is just a waste of bandwidth at this point.

As always, it really depends on what the source is. Often images are created with some software like Photoshop, would you commit the psd file to git? If you're a photographer, would you commit 20mb+ raw image files? Might make sense for a few images, but git is just not the right solution for binary data in general. Every modification has to duplicate the entire file. This makes working with the repo unpleasant very quickly.

In general, I recommend people back up binary files to cloud storage, like S3, and only commit optimized, deployment ready assets to git. There's also GitLFS, but it's clucky to use.

This post greatly over simplifies how many issues come up optimizing images. Also, the Github workflow doesn't commit the optimized images back to git, so this would have to run before packaging and would have to run on every image, not just new images added.

Ideally, images are compressed _before_ getting committed to git. The other issue is that compression can leave images looking broken. Any compressed image should be verified before deploying. Using lossless encoders is safer. However, even then, many optimizers will strip ICC profile data which will make colors look off or washed out (especially if the source is HDR).

Finally, use webp. It's supported everywhere and doesn't have all the downsides of png and jpg. It's not worth it to deploy these older formats anymore. Jpgxl is ever better, but support will take a while.

Anyway, I made an ImageOptim clone that supports webp encoding a while ago[0]. I usually just chuck any images in there first, then commit them.

[0]: https://github.com/blopker/alic

After my dad died from cancer in 2018, I saw first hand the resulting loneliness and the lack of resources available. Being an engineer, I figured I might as well try to solve it, at least for some people. In 2020, I started a non-profit for small support groups[0]. We're small, and I've been mostly funding it myself, but it's growing. The main issue is we don't have the resources to cover every topic, so it's not for everyone (yet). Happy to chat if you have feedback, email is in my profile.

Everything we do is open source too[1].

[0]: https://www.totem.org/ [1]: https://github.com/totem-technologies/totem-server

This.

The WIP code was committed with the expectation that very few people would see it because it was not linked anywhere in the main readme. It's a calculated risk, so that the code wouldn't get out of date with main. The risk changed when their LLM (wrongly) decided to elevate it to users before it was ready.

It's clear DeepWiki is just a sales funnel for Devin, so all of this is being done in bad faith anyway. I don't expect them to care much.

I brought up this issue because I thought it illustrated my previous points nicely.

Yes, there is a VS Code folder in that repo. However, it doesn't exist as an actual extension. It's an experiment that does not remotely work.

The LLM generated docs has confidently decided that not only does it exist, but it is the primary installation method.

This is wrong.

I dunno, it seems to be real excited about a VS Code extension that doesn't exist and isn't mentioned in the actual documentation. There's just too many factual errors to list.

I took a look at a project I maintain[0], and wow. It's so wrong in every section I saw. The generated diagrams make no sense. The text sections take implementation details that don't matter and present them to the user like they need to know them. It's also outdated.

I hope actual users never see this. I dread thinking about having to go around to various LLM generated sites to correct documentation I never approved of to stop confusing users that are tricked into reading it.

[0]: https://deepwiki.com/blopker/codebook

Yeah, I made a local image compressor/converter for myself that's actually private: https://github.com/blopker/alic

Web version: https://clowerweb.github.io/kitten-tts-web-demo/

It sounds ok, but impressive for the size.

I get the feeling we're going to end up in a place where we don't make docs any more. A project will have a trusted agent that can see the actual code, maybe just the API surface, and that agent acts like a customer service rep to a user's agent. It will generate docs on the fly, with specific examples for the task needed. Maybe the agents will find bugs together and update the code too.

Not exactly where I'd like to see us go, but at least we'll never get outdated information.

The Rust ecosystem needs more high-level frameworks like this. However, I've been shipping Django since 0.96, and I don't think Cot really addresses the main issues Django currently has. Performance isn't in the top 5.

Django's biggest issue is their aging templating system. The `block`, `extend` and `include` style of composition is so limited when compared to the expressiveness of JSX. There are many libraries that try to solve Django's lack of composition/components, but it's all a band-aid. Today, making a relatively complex page with reusable components is fragile and verbose.

The second-biggest issue is lack of front end integration. Even just a blessed way of generating an OpenAPI file from models would go a long way. Django Ninja is a great peek at what that could look like. However, new JS frameworks go so much further.

The other big issue Django has _is_ solved by Cot (or Rust), which is cool (but not highlighted): complicated deployments. Shipping a bunch of Python files is painful. Also, Python's threading model means you really have to have Gunicorn (and usually Nginx) in front. Cot could have all that compiled into one binary.

There is another solution, in this specific case. If all they wanted is to start returning the test results before all the tests are done, a streaming http response can be used.

In Bottle, returning a generator or iterator will send the response in chucks, instead of all at once. The effect would be that the test results load in one by one, providing the user with feedback. No JavaScript needed.

I actually can't think of another language that has all of that built in. Rust doesn't, it needs a run time for async. JavaScript doesn't, it needs typescript and it doesn't compile to native.

Dart is crazy because it runs on every platform, compiles to native, has real parallelism via isolates, native async, and native type safety.

There's not really a backend that takes advantage of all that. In theory, one server binary could handle REST, web sockets, background workers, and have generated type safe client packages for every platform. Dart also has a great Rust ffi story. It would be great to see that leveraged.

ServerPod is a great start, but it's really Flutter focused. The web apis feel like second class.

Additionally, database management isn't a solved problem yet. ServerPod uses yaml to define models, and the other main option is just a Prisma wrapper. Dart needs something like Drizzle.

Nice work! I'm happy to see the server is in Dart, no Firebase!

I wish the Dart server ecosystem was more mature though. Being able to compile Dart into a static binary is so nice for deployment.

In Rust, there's a controversial practice around putting unit tests in the same file as the actual code. I was put off by it at first, but I'm finding LLM autocomplete is able to be much more effective just being able to see the tests.

No clunky loop needed.

It's gotten me back into TDD.

I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it.

However, Vite is pretty complicated. I prefer just esbuild if I don't need all the extra features of Vite, which is usually true with Django. I wrote a post[0] with an example repo[1] if anyone wants to see how everything wires up.

With Solidjs, the minimum JS payload is around 9kb, and you get access to the whole JS ecosystem if you want it.

[0] https://blopker.com/writing/07-django-islands-part-1/ [1] https://github.com/blopker/typesafedjango