henrikn

Recipe and accompanying video here: https://www.tastinghistory.com/recipes/switchel

Tried making it. Certainly interesting! But not something I’ll make again.

I was going on a train journey, wanted something to read and wondered if there was anything with the premise "someone secretly invented Claude Code before LLMs were a thing and used it as a secret superpower".

Then I thought I'd try asking Claude to write it, as an experiment. The prompt was a sentence or two with the given premise. This is the result.

Sharing it as a conversation piece. Is it any good? Are AI stories ethical? Are stories pointless without a real human behind them?

Speaking of random third-party JS code, do you know of anything supporting this is actually being run by Fastly, other than it being in the domain name? I did some minor sleuthing here but no clear support yet: https://github.com/polyfillpolyfill/polyfill-service/issues/...

Agreed, this can be difficult.

An approach like BEM can help somewhat because you rely less on cascading.

But then again, because it's tediously explicit, one may generate BEM class names in Sass or with PostCSS in a way that makes those long, explicit names harder to grep for…

Hi! Blog post author here.

I agree that tests are super valuable for many things, but it isn't enough here – at least not with the way my team writes tests.

(Our) tests wouldn't catch unused CSS classes or i18n keys.

(Our) tests wouldn't catch an unused method that is unit-tested. The unit test would happily pass because the unused method is still around and does what it should… in a vacuum.

Tests are great for catching live code that was incorrectly removed, but I'm not sure how they would help catch dead code that was incorrectly left in – but would love to hear more about it :)

Another option is to do away with blocking on pull requests altogether and review after the fact. It has some benefits (and some downsides).

I blogged about that here: http://thepugautomatic.com/2014/02/code-review/

We use a home-grown tool on top of GitHub to review commit-by-commit after the fact: https://github.com/henrik/remit

Wrong: I'm sure it is. I did it without tests and didn't go through the logic carefully since that wasn't at all the point. The design was.

Performance: could be. If your context is one where performance is paramount and trumps readability/maintainability, that may certainly be easier to achieve with less factored code. I spent zero time trying to optimize the code.

I suspect this design doesn't make that as hard as you make it sound, though. My team writes code in the style of my example, and we don't have problems optimizing when it's called for. Though we avoid optimizing at the expense of readability unless we see a real problem.

I find it interesting that you think my example is clearly "more complex" and "less readable". I, of course, feel it is the other way around.

The fact that you've worked (mostly on your own, going by the contributor stats) on this library for ten years will of course mean that you know your way around it.

As a visitor to the codebase, I see big classes and big chunks of code that require me to load a lot into my head and digest it before I can make sense of it. Breaking that up a little means I can make sense of a smaller piece of more self-documenting logic, then dig down to lower abstractions as needed.

If you're saying that you find your way around your code better than my refactored code, I believe you.

If you're saying you think the refactored code would be harder to understand for the average developer, I think you're dead wrong.

Also glanced at the load_from_v1 code.

I can't argue with the "deprecated code" bit – if you never need to understand or edit that code again, by all means leave it. There will be no payoff for spending time reducing the complexity.

But "splitting into multiple methods only complicates the logic flow" sounds less like Code Climate being wrong and more like you not having found good refactoring techniques, maybe.

I see several things that I think have a good chance of helping readability: extracting the whole thing to an object, then replacing the inline error handling with an error handling method ("begin" is a smell), extracting (and naming) whatever happens on each iteration of the "data" and so on.

> They're wrong: it's the smallest it can possibly be while still correctly performing the necessary goal; any smaller, and you have to break it into multiple smaller methods that provide no value except keeping Code Climate happy.

Wrong? Smallest it can possibly be? Those are strong claims.

I definitely disagree with Code Climate from time to time. But I try to keep an open mind.

I've found that trying to follow dumb rules can be enlightening, even when my first reaction is that I disagree. This goes for Code Climate as well as arbitrary rules, such as Sandi Metz': https://gist.github.com/henrik/4509394

I looked at your `priority_compare`, for example. As someone who did not write that code, I find it a little hard to follow. It has conditionals four levels deep (counting the ternaries). Your `Mime::TYPE` class is quite long, as is its test.

I would let the Code Climate feedback inspire me to attempt to extract a method object in this case, along these lines: https://gist.github.com/henrik/9355101

That would result in more code overall, but smaller objects on average, and to my eyes readability is improved because the complexity is a little abstracted. Do you truly feel it provides no value?