wmanley

> Browsers have become so nice to work with, that these days, I get away with just the following two lines of code to simplify DOM manipulation: > > dqs = document.querySelector.bind(document); > dqsA = document.querySelectorAll.bind(document);

Sounds useful and reasonable.

> I usually import the two functions from a module like this: > > import { dqs, dqsA } from '/lib/js/dqs.js';

Utterly absurd. Just copy and paste. It’s only two simple lines, how could it be worth a dependency?

I don’t think this would be such an issue. There’s about 500x as much oxygen in the air as carbon dioxide.

Increasing the amount of carbon dioxide by 140ppm is a 50% increase in carbon dioxide levels since pre industrial times.

Reducing the about of oxygen, currently at 209,000ppm, by 140ppm seems like it would have a negligible effect.

The far greater likely issue with natural hydrogen is that we simply don’t find any deposits of it that are both significant and economically extractable. And in the mean time we use it as an excuse to not do anything about carbon emissions.

Maybe just stop shitting on the carpet.

To clarify: My point is not that Firefox sucks, my point is that Firefox is great - better at handling the web than these new other web-browser engines will be for a long time, and yet it still hasn't broken the moat. It's not enough to make a great non-chrome web-browser - we already have one. It wouldn't make any difference toward that goal if we had 4 of them.

What is needed to break the moat are users - and enough for website operators to care. This is what Apple/Safari has. This is what Firefox increasingly lacks.

For and for that someone will have to do something other than make a great browser.

I use Firefox too, and I agree it is great - which goes to show that having a great browser engine is not enough to break the moat.

> I hope to one day be able to jump in and contribute to break that moat!

The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome.

I'd love for the moat to be broken, and contributing to a browser engine like ladybird would be fun - but it doesn't contribute to breaking the moat. I'd love to know what would.

Here's the link where he discusses functional programming style:

https://web.archive.org/web/20170116040923/http://gamasutra....

He does not say that that his email is completely outdated - he just says that calling pure functions is exempt from the inlining rule.

He's not off writing pure FP now. His approach is still deeply pragmatic. In the link above he discusses degrees of function purity. "Pure FP" has a whole different connotation - where whole programs are written in that constrained style.

Possibly the gp means the four quadrants (two axes)?:

https://dunnhq.com/posts/2023/documentation-quadrants/

Yeah, the aires are great. I only used the Tesla superchargers in the aires as they were cheaper than the others, and my car would automatically find them. I had no problems at all.

> Never seen this in the US. I don't even know what the cable would be.

The cable I have is like this:

https://www.amazon.co.uk/MENNEKES-36213-c%C3%A2ble-%C3%A9lec...

Then the chargers (and the car) just have a socket - but the sockets have locking pins on both ends. Thanks to your response I now realise that the stopping charging issue is related - the cables are locked in place until you stop. If the charging station provided their own cables all we'd have to do is disconnect from the car to stop charging.

> Wow, that is awful. In general slow (AC) charging in the US is half the price or less of fast (DC) charging. In fact, usually public AC chargers are even cheaper than charging at home (for me, very expensive kwh at home).

That sounds lovely. The cheapest slow charger in France that I used was €0.30/kWh ($0.33/kWh). A typical Tesla supercharger on the autoroute was a comparable ~€0.35/kWh ($0.39/kWh). Still, beats the socks off the £0.56/kWh ($0.75/kWh) I pay at the slow charger near my house.

> This is annoying but necessary. If chargers let you idle for free, it would be impossible to find an empty space many places. I think the idle fees (usually $1-3/hour in the US) are a reasonable compromise.

At home it's £3/hr ($4/hr), so if I charge overnight and don't play games with my charging rate I can easily spend more on idle fees than electricity.

See also: Hugin - Panorama photo stitcher. I used to use a lot back in ~2006 for making panoramas. It automatically finds "control points" in your photos, figures out which ones are shared between the photos and uses that information to determine the relative positions of the photos, and your lens parameters.

Once it does that it can stitch the photos together. It does this by projecting the photos onto a sphere, and then taking a picture of that sphere using whatever lens parameters you want.

https://hugin.sourceforge.io/

I also completed my first big road trip with the Tesla during the summer holidays. This was around France.

With a long trip my preference was to slow charge overnight so as to start the day at >90%, and sometimes we'd also have a single supercharge during the day. The supercharger experience is great - you plug in and it works. When you're done you unplug and continue your journey.

The slow charge experience was less good. In France there are a lot of charging points in car parks, but to actually start charging it involves a load of faf.

1. Slow chargers typically involve using an app or website, so you need to find that, figure out how to tell it which charger you're at, enter your payment details. Hopefully you've got internet access in the underground car park that you've selected.

2. Each provider has a different app or website - they're typically difficult to use and buggy, but each in its own unique way.

3. Slow chargers don't don't come with their own cables, so you need to get your one out of the boot, and put it away again.

4. Stopping charging typically involves navigating the website/app again, hopefully you haven't closed the tab, otherwise it's going to be a pain getting back there.

5. There's no indication on how much it's going to cost until after you've gone through all the trouble. Even then it can be unclear - for example do I need to pay for parking while I'm charging or not?

6. It often costs as much or more than the supercharger - although all the prices I saw were cheaper than the UK.

7. There are typically idle fees, so you might find yourself having to disconnect your car and move it in the middle of the night (assuming you put it on charge in the evening)[^1], or you might find yourself having to rush back to the car in the middle of your sightseeing.

I want to slow charge when I'm parked, because I'm away from the car anyway. My dream slow-charging experience is:

1. Broad availability in any given car park, let me just plug in if I happen to be stopped

2. Streamlined payment process, preferably automatic and through the touchscreen of the car, rather than involving a phone or website. Don't make me enter payment card details - I want something like the apple pay experience, but "Tesla pay".

3. No idling fees so I can change my mind and have a dessert if I fancy without worrying about getting back

I don't care about speed if I'm not waiting. 7kW is more than enough.

[^1]: My trick here is to adjust the charging current in the Tesla app, such that it will take longer to charge. This way I'm never idling, even though I'm taking up a space for the same time anyway.

Warning: only click that link if you want to see a cyclist get hit by a train

Yes to India and the USA. China and Europe are roughly on par.

See also:

acoup - Why No Roman Industrial Revolution?

https://acoup.blog/2022/08/26/collections-why-no-roman-indus...

and also you have to copy (probably allocating) to get a substring.

Dependency injection means that the caller explicitly provides dependencies to functions/classes rather than having the classes/function getting their dependencies from the environment.

Taking an example like the article. Lets say you have a game with a ghost which randomly moves left or right. This would NOT be dependency injected:

    class Ghost:
        def __init__(self):
            self.pos = 5

        def move(self):
            match random.randint(0, 1):
                case 0:
                    self.pos -= 1
                case 1:
                    self.pos += 1

It's constructed like this:

    ghost = Ghost()

Ghost's behaviour depends on the state of the global RNG, but that isn't obvious from the perspective of the user of this class.

So instead we apply DI, and pass a random number generator in:

    class Ghost:
        def __init__(self, rng):
            self.pos = 5
            self.rng = rng

        def move(self):
            match self.rng.randint(0, 1):
                case 0:
                    self.pos -= 1
                case 1:
                    self.pos += 1

It's constructed like:

    ghost = Ghost(rng=random)

Now the fact that the class uses random numbers is explicit, and you can pass in an alternative RNG for testing purposes.

DI is a very useful technique that can make the construction of your system understandable, and make it easy to mock out dependencies. Much like mocking however - it shouldn't be over-used. If you use DI too much your code will become opaque as you'll never know what the concrete type of code you're calling is. Python's progressive typing can help here to some extent.

-----------

Dependency injection is not to be confused with dependency injection systems, which are complicated beasts that obscure what dependencies are actually constructed or provided. They make DI implicit again with the argument that it's better because you don't have to pass parameters manually. I would argue that if you need a dependency injection system, maybe you've over-used dependency injection.

-----------

I like to think of it as being related to capability based security[1], where you have to explicitly provide your dependencies, otherwise you won't be able to access them.

[1]: https://en.wikipedia.org/wiki/Capability-based_security

I’d love to see something like that applied to a project like Debian. The tools already exist. The cost of switching is too great, and you’d need everyone to learn your new system before you’d see the benefit.

I wrote a bit about this here: https://blog.williammanley.net/2020/05/25/unlock-software-fr...

I understand that nix have made some progress in this direction, but I don’t know any more than that.

It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.

This is known as "The Tyranny of Structurelessness": https://www.jofreeman.com/joreen/tyranny.htm

The argument goes that there is always a power structure and it's better that it's explicit rather than implicit.

Reading that article changed the way I viewed organisations and structure, and how one should act within one.

Of all the hypotheses they considered, they seem to have missed the obvious one: Cosimo I de' Medici is Eastside and Jesus, God and Mary Magdalene are Westside.

Found it: https://www.youtube.com/watch?v=0VFgzneS0Dw

Disappointed to read that this is an April fools. I honestly believe that practical application of software freedom is held back by tooling, and that through the use of their monorepo and build system Google can actually benefit more than normal users from software freedom.

https://blog.williammanley.net/2020/05/25/unlock-software-fr...

I feel like I’m missing something here. How would having a library on the system help with serving zstd compressed assets?

Try adding the response header:

    Vary: HX-Request

IIRC they walked directly north and measured at midday.

Thanks, I've added that to the blog post.

> I was curious what it is called when the growth rate itself is going up exponentially

The derivative of the exponential function is the exponential function.

d/dx eˣ = eˣ

So if it’s growing exponentially the rate of growth is exponential and the rate of that acceleration is also exponential.

It looks like it would be a great space lover.

It’s worth a try. I’d recommend buying a separate spray for your nose though.