HackerLangs
トップ新着トレンドコメント過去質問紹介求人

hakunin

2,207 カルマ登録 16 年前
https://max.engineer, mastodon:ruby.social/@maxim, x.com/hakunin, bsky.app/profile/max.engineer

meet.hn/city/43.1009031,-75.2326641/City-of-Utica

---

投稿

1Password Is Down (Resolved)

status.1password.com
5 ポイント·投稿者 hakunin·3 か月前·4 コメント

AI Orchestrators Decision Table

gist.github.com
2 ポイント·投稿者 hakunin·5 か月前·1 コメント

Don't Build a General Purpose API to Power Your Own Front End (4 Years Later)

max.engineer
1 ポイント·投稿者 hakunin·7 か月前·0 コメント

Don't Build a General Purpose API (4 Years Later)

max.engineer
2 ポイント·投稿者 hakunin·7 か月前·0 コメント

Don't Build a General Purpose API (4 Years Later)

max.engineer
1 ポイント·投稿者 hakunin·7 か月前·1 コメント

Commento.io Has Been Down

commento.io
2 ポイント·投稿者 hakunin·7 か月前·2 コメント

OCRmyPDF-AppleOCR plugin now supports LiveText

github.com
2 ポイント·投稿者 hakunin·8 か月前·0 コメント

Rails, Omarchy, Geo Proxy: Rails World Opening Keynote [video]

youtube.com
2 ポイント·投稿者 hakunin·10 か月前·0 コメント

コメント

hakunin
·13 時間前·議論
There was a phase, which I also got sucked into at the time, that comments are bad. Problem is, to make your code be so self-explanatory that it conveys business decisions, background stories for how you've arrived here, research-based choices made, you would have to name your variables and functions in a batshit_insane_way_that_obfuscates_behavior_among_the_names. It doesn't make anything better.

Use short names where they're contextually clear. Use long names where they're contextually weird/non-belonging. Use comments to explain the "whys" of your code.
hakunin
·14 時間前·議論
I have been on a quest to get AI to code like me, using pi harness, and any model that it can support. I'm mostly a Ruby programmer, so here's my journey so far.

1. Created a "coding" skill with every practice I posted on my blog website, as well as a bunch I had in the queue to blog about but never got a chance, summarized into "do this" kind of language. This is more or less good for any PL, but a bit Ruby-slanted.

2. Created a "rails" skill because that's my framework, where similarly I explained my approach to architecting Rails apps.

3. Created a "writing" skill where I literally fed it my entire blog, and tried to get it to write more like me (mixed success, weaker models did better for some reason, but I haven't tried the GPT-5.6 series yet).

4. Next, I really wanted it to format code exactly like I would, even things like "let's make this `if` into a ternary, let's split these assignment groups with a line break, let's vertically align here, but not there", but with GPT-5.5 (my primary driver up until yesterday) there's almost no way to make a skill of reasonable size that will be consistently applied. So instead I instructed the agent to write me a Rubocop cop for every single situation I ever encounter where I would've formatted code slightly differently. This was quite powerful, because I usually thought of linters as enforcers of objective consistency decisions in the codebase, but this was me going full format nazi on the agent. And the nice part is that these cops can contain some non-autocorrectable feedback, which AI will follow.

5. I'm working on a review loop where the most easily missed parts above get double checked. This is the first thing I'm doing with pi subagents. (I feel like I'm getting better results if I don't use subagents for code exploration, other tool calls). The idea here is that I want reviews to be in the implementation loop. I always read/review code in the end, but so want it to have gone through the review loop before it gets to me. Since implementation is already context-heavy, I want to be able to orchestrate this loop without adding to the implementation context.

6. I'm also adjusting all of the above for GPT-5.6, because it requires less guidance, so I'm carefully trimming the verbiage to save tokens.

So far the results have been surprisingly good. I want to experiment with GLM-5.2 running under these constraints.

One invariant in all of this: I read the code. My end product is not working software, it's good code (which also incidentally produces working software).
hakunin
·5 日前·議論
I think this is not quite right.

There are news, and there's entertainment which covers all opinions and punditry.

News actually have journalistic standards. They try to stay truthful and retract errors.

But what most people follow are shows/personalities that aren't even allowed to be officially called news, and independent media online influencers who are much more easily and directly corruptible and audience captured by much less money, with basically zero accountability.

The truth is, mainstream news (the actual news) are still good. But it's so easy nowadays to get on a platform and discredit everyone with almost no evidence, and have thousands of people believe you. And then sell your sponsors to that audience, because you sound trustworthy. It's so much easier to discredit everyone else than to build your own true credibility.

The goal is not to make you believe that "we are better than them". The goal is to make you believe that "everyone is equally bad, everyone is lying to you". It's like when phone scammers tell you that the other phone scammers are real scammers to appear more trustworthy.

I think the problem is with independent media and "opinions" replacing news. If everyone yells bullshit for personal gain at the top of their lungs and creates cults (as I agree these become), that's basically not free speech anymore.
hakunin
·9 日前·議論
I think the author is right.

There are many peripheral nice-to-haves you can get from a code review. Bugs, security, performance, correctness issues are all possible bonus findings you may get sometimes.

But there is only one _must_ in reviews: another person reading and understanding the code, possibly suggesting architectural improvements, or asking questions that should be answered by rephrasing the code for clarity, or by adding code comments. In other words: maintainability. That's the one thing that's not a bonus point, and is a constant for all code reviews.
hakunin
·9 日前·議論
Be careful what you’re centering yourself between. If one side is trying to build decent policy with a small fringe that has almost no political power, and the other side’s fringe has cemented itself as the new mainstream and fights classic liberalism, institutions, and science, you’re now in a very different center.
hakunin
·9 日前·議論
Yeah. We love the comfort of "getting it", but most of the easy problems have been solved, and we're only left with the hard ones.

People are pleasure-seekers, not truth-seekers. People demand what they can understand and feel good about, even if wrong. There's plenty of supply too. Radical free speech allows anyone to spread lies for huge financial upside, and we don't have any check on this particular type of weapon which is mass-destroying society.
hakunin
·10 日前·議論
That’s if you are trying to learn. Many of these know exactly what they’re doing, on purpose.
hakunin
·10 日前·議論
Agree, mostly. On the internet, I like to be selective about only addressing new substantial claims.

In person, at work, etc, it makes sense to spend more energy, be more patient to get on the same page, and you get more benefit if you succeed.
hakunin
·10 日前·議論
That's how claims work. Why would I argue against nobody? Happy to engage if you disagree with the claim.

I only somewhat disagree with the post in the second part, with reasons enough to start the conversation.
hakunin
·10 日前·議論
One of the most cancerous developments of our generation is a bunch of people isolating themselves from everyone else, and having their perfect unchallenged audience captured views spread far and wide.

On a more personal level, the reason people are frustrated about arguing is because they can’t fully articulate their reasons. They don’t realize it themselves. The older you get and the more practiced you get at arguing, the less contentious it becomes, as you can simply say what underpins what you’re saying in an easily understandable way, and then if that didn’t convince the other side, you did all you could.
hakunin
·10 日前·議論
I use it because it’s a simple, convenient and cheap OCR api. Specifically via my ringbinder[1] tool.

[1]: https://github.com/maxim/ringbinder
hakunin
·11 日前·議論
Just use smart lights that feed video into an llm to check if lights should shut down.
hakunin
·11 日前·議論
Not the comment author, but I use pi and customize it with my own extensions. Pi automatically tells models how to customize itself, so it's a pretty easy process.
hakunin
·16 日前·議論
Not the commenter, but the reason is the same as the choice to use direct db driver vs ORM - you get to take full advantage of special features and intricacies of one system, rather than trying to maintain a lowest common denominator of functionality between multiple ones.

You can always build multiple clients however. It could be one thorough integration with one API, and a simpler backup via RubyLLM.

Unless of course RubyLLM supports all of the above, but even then, are they going to be able to keep up as much as a native client in the long term?

The answer is almost always that a native client for a more critical integration is the right call. You can always add another if you need it.
hakunin
·19 日前·議論
I think what this advice is really getting to, is that you should prefer everything generally build-time/hardcoded/static rather than runtime/dynamic. Wrote about this in 2013 (calling it a CMS trap[1], back then seemed pertinent).

[1]: https://max.engineer/cms-trap
hakunin
·30 日前·議論
Yeah, for perfect positioning/overlaying I would be much stricter with my requirements. For that type of OCR I used Apple’s own LiveText framework that comes with MacOS. But in this use case I only care about standalone plain text and descriptive text to store in the database, not overlay over original content, so never tested Mistral on that front.
hakunin
·先月·議論
IME way better. It may not be the best out there, but it's cheap (2c per page), fast, easy to integrate API, and sufficient for my needs. It does things like describe what's drawn in pictures and shown in graphs, which all helps when searching.
hakunin
·先月·議論
Yeah, for me it was all about not letting mail and kids schoolwork pile up. I like to scan ads that local businesses leave in my mailbox, so that I can ask "show me lawn care services near me". A lot of them don't really have any other online presence.

Btw, I tried to keep the Mistral part modular, so that another OCR could be integrated.
hakunin
·先月·議論
A SQLite based sweeper of all the scans, notes, PDFs and images I have on my filesystem, that stores their paths and allows searching their OCR’ed descriptions and text, as provided by Mistral OCR. I can ask things like “when does my car need maintenance” or “find me that picture my kid drew for Mother’s Day”. I use pi-based bash executable to launch a doc chat like that. https://github.com/maxim/ringbinder
hakunin
·2 か月前·議論
Your point 3 is a non sequitur. If air travel is magical and valuable, that doesn’t automatically mean it needs subsidizing. We sometimes allow magical and valuable things to go away if we find them not to be popular enough to garner widespread political support.

My statement is correcting a fact (descriptive) not proposing what to do about it (I.e. not prescriptive).

It’s very hard to imagine what the world would look like without subsidized air travel. I have to think long and hard to figure out if subsidies would actually be sensible for something like this. I can be convinced either way right now, but it would take a lot of good historical data on something very similar, perhaps has to be specifically air travel in countries that do and don’t subsidize it, and their economic outcomes, controlled for other factors.

But saying that air travel is somehow the same in kind as other kinds of travel is incredibly shallow and reductive. We get to travel orders of magnitude faster and to places we wouldn’t even be able to reach otherwise.