Is there a smart watch that would connect to two phones at the same time? I’d immediately buy one which showed notifications from my personal and work phones.
The `json` gem is implemented in C, so it's a black box for YJIT (the reference implementation's JIT).
The TruffleRuby JIT used to interpret C extensions with sulong so it could JIT across languages barrier, but AFAIK they recently stopped doing that because of various compatibility issues.
Also on TruffleRuby the JSON parser is implemented in C, but the encoder is in pure Ruby [0]
Sorry about misuse of “intrinsics”. There is a simdjson library that uses SIMD instructions for speed. Would such an approach be feasible in the ruby json library?
TL;DR; it's possible, but lots of work, and not that huge of a gain in the context of a Ruby JSON parser.
`ruby/json` doesn't use explicit SIMD instructions, some routines are written in a way that somewhat expects compilers to be able to auto-vectorize, but it's never a given.
In theory using SIMD would be possible as proven by SIMDjson, but it's very (edit) UNlikely we'll do it because of multiple reasons.
First for portability, we have to stick with raw C99, no C++ allowed, so that prevent using SIMDjson outright.
In theory, we could implement the same sort of logic with support for various processors that have various level of SIMD support and have runtime dispatch for it would be terribly tedious. So it's not a reasonable amount of complexity for the amount of time I and other people are willing to spend on the library.
Then there's the fact that it wouldn't do as big as a difference as you'd think. I do happen to have made some bindings for simdjson in https://github.com/Shopify/heap-profiler, because I had an use case for parsing gigabytes of JSON, and it helps quite a bit there.
But I'll hopefully touch on that in a future blog post, the actual JSON parsing part is entirely dwarfed by the work needed to build the resulting Ruby objects tree.
My naive/clueless mind always wonders if it wouldn't make sense to make a new class of Ruby objects that are much simpler and would yield both less memory consumption and GC optimizations that could be used for such cases.
Without a different object model it's hard to imagine optimizations that could greatly improve Ruby execution speed for CRuby, or make the GC much faster (huge issue for big applications), but maybe it's because I don't know much :-)
> I refuse to live my life as if these things aren't important to me. I refuse to average my entire life style down to my median day. My median day is boring.
Surprised nobody mentioned externalities yet. Carbon tax, and then you can take a more wholistic view when planning your life.
By the way, landscaping as a hobby does not automatically imply trucks, not outside US at least. Unless you actually do it often and need to transport large loads—then yeah, go for it. You’re part of a small minority that might actually need a truck.
An important topic I do not see discussed on HTMX and other such tools is testing.
Frontend frameworks all have a way to unit- and integration-test their components without resorting to Cypress or Playwright. How do you integration-test the effect of your hypermedia enhanced applications without a (headless) browser? Using Chrome for a few end-to-end tests is fine. But it is not a replacement for in process RackTest (to give a Rails specific example).
From a quick glance testing is not addressed in this book either.
You can write tests just like you would test a JSON API. But instead of testing the JSON structure, you can test the HTML structure. Depending on how deep you want to go, you can parse the HTML response and check for the components, but sometimes just checking for bare strings is enough. For example, taking the FastAPI testing docs[0], instead of:
assert f"<b>Item already exists</b>" in response.render().decode()
One thing I found using HTMX (or just HTML) is that the apps are less fragile. I know that if I return a chunk of HTML, the browser will render it the same way every time. With a JSON-based SPA, maybe that chunk of JSON ends up triggering multiple side effects, re-renders, etc. which can behave differently depending on the current application state. This all affects the amount of testing that I feel comfortable with.
If I was to test things that were part of UI code, but were still "mechanical" enough to test automatically, I would throw responses into an HTML parser to make sure I'm presenting the right data. (In a way, HTML strings are also a kind of "virtual DOM")! If you need to test interactions though, I don't think a headless browser is avoidable.
I would think that because HTMX == less JavaScript that there’s less of a need to test functionality. And the testing that remains will need a browser to be tested.
Complex logic will still be written in JavaScript so then one can use regular JS testing tools again.
We do not test because of a language used but because there are assumptions expressed in code. “Clicking a button validates the email address” is a test you need to have regardless of if it’s implemented as `hx-get` or `onSubmit`. I would argue having good test coverage for the former is more important because the action happens further (another controller+template instead of the same React component).
Yeah I wasn’t expressing myself clearly, let me try again.
HTMX writes quite a bit of the logic for us. We don’t need to test that logic because we can assume that it’s been tested. We only need to test the remaining logic, of which there is less and it’s less messy because it’s more declarative (if I understand HTMX).
If we use an input of type “email” we also don’t test if its validation works.
Nikola is one of Crystal lang largest sponsors[0]. I wonder if this is going to have repercussions. It's no fault of the Crystal community but might cast a shadow nevertheless.
I see Mozilla always complaining about privacy matters and violations of its largest partner, critiquing the very hand that feeds them and they still take in the money that keeps them alive and accounts for 80% of their entire revenues YoY.
That partner is Google, the anti-privacy company that stands against what Mozilla is fighting for and supporting (and also funds many other open-source projects). Nothing has happened or changed and zero repercussions for Google's actions. The same for Crystal.
I do not think you will find any clean hands in the tech industry and everyone knows it.
80% of their revenues, but probably 200-300% percent of their profits. Google just hands them an enormous amount of money, regularly, for nothing but a token in return, and everything else they do fails.
So long as Crystal was never influenced by Nikola, I see no conflict from Crystal's perspective. Money is money. It's only tainted by the morality of its origins if you let it.
Except that a commonly used user name is already "personal information". And your eMail address you've used to register to the forum. And the IP address that you use to access the forum.
AND EVEN THE RANDOM UUID THAT YOU ASIGN TO USERS ON YOUR FORUM BECAUSE YOU'VE GIVEN UP AND ONLY IDENTIFY USERS BY THAT AND THEIR PASSWORD.
In effect everything where a user has to input something instead of being just a recipient, or where the user is connected to any persistent identifier contains PI according to GDPR.
Say bye bye to most kinds of technical server logs used to debug stuff, to your database, and storing stuff in general.
The only way to be truly GDPR compliant if you followed the law to the letter would be to just provide TV and Teletext service via radio waves.
Is there a smart watch that would connect to two phones at the same time? I’d immediately buy one which showed notifications from my personal and work phones.