Once again I get foiled by switching languages. :blobcatfacepalm2:
In Javascript, you have to compare strings with ===, not ==, or else you'll run into type coercion problems, because Javascript thinks 1 == "1" is a totally fine thing to be true. (it's not)
But in Kotlin, === compares identity not equality for strings. But in the JVM, string values are aggressively cached, so === actually does what you want most of the time. Unless your strings come from weird places, like JNI code. Then you get awful non-deterministic behavior that's incredibly hard to debug, but it totally goes away when you use the correct comparison operator == for strings.
sigh I'm not really as good at this whole programming thing as I should be by now.
Only a few years ago, there was a considerable effort in #dotnet to make interoperability with #nodejs a thing... now it seems like all those projects are gone or woefully behind. Bummer :(
We just released Execa 9, which is our biggest release so far.
If you're currently using Execa, you should check out the new features! Also, if you're currently using zx or Bun shell, you might be interesting in this alternative.
This is a niche one but it might help someone in the future:
How to include multiple directories from different places in the file system hierarchy in an archive without including the whole directory structure for any of them.
Just published a minor update (version 5.1.1) to JavaScript Database (JSDB) that optimises the custom data type¹ serialisation code by removing a redundant return statement:
This change is backwards compatible and shouldn’t require and updates to your projects, including the ones you have in Kitten (which uses JSDB internally).
• Forgetting to pass a custom class that’s persisted in your database in your JSDB.open() call now throws instead of corrupting your database by falling back to using an untyped object.
• Added JSDF ver. 2 to 3 database migration script (i.e., JSDB version 2-4 to 5)²
How do I tell Heroku to not install install the #nodejs buildpack at all?
(and remediate this WARNING on every deploy)
WARNING:
Installing a default version (20.9.0) of Node.js.
This version is not pinned and can change over time, causing unexpected failures.
Heroku recommends placing the heroku/nodejs buildpack in front of heroku/ruby to install a specific version of node
100% test coverage doesn’t mean your code’s bug free but it did just lead me to find and fix an issue in JavaScript Database (JSDB)¹ with a code path that wasn’t being hit that I would have otherwise missed because it was causing the relevant test to pass.
¹ JSDB is a zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database for the Small Web that persists to a JavaScript transaction log (an append-only log).
To really drive home the above 👆 point that 100% test coverage does not mean ‘bug free’, just found a bug in JSDB¹ 5.0.0 where running JSON.stringify() on a complex custom object (actually: the automatic Proxy of the custom object created by JSDB) results in an error.
Already have a failing test and about to implement fix.
(It’s at this point where the test harness is invaluable.)
Come and help us maintain and enhance a fully open-source operating system and cloud stack that has been battle-tested in very large production environments.
There are plenty of interesting problems to solve, all the way from writing device drivers and debugging early boot issues, to writing new UIs in Rust.
I think we're a pretty friendly team to work alongside too ;)
Pytanie do obeznanych z technologiami #JavaScript#NodeJS - czy kojarzycie jakiś framework, który w bardzo prosty sposób pozwala tworzyć CRUDy w celu budowania panelu administracyjnego/CMS-a dla istniejącej bazy (frontend i backend)?
Realised last night that JavaScript Database (JSDB) doesn’t run the constructor on persisted custom objects (https://codeberg.org/small-tech/jsdb#custom-data-types) when deserialising them because I didn’t know that you apparently have to define your constructor manually when using Object.create().
Will fix it today but it’s something to watch out for if you’re using Object.create() directly.
So every app using it has all of #Electron’s disadvantages:
• lowest-common-denominator #GUI obviously foreign to the host OS
• non-portable shims to integrate with host OS features
• an individually bespoke runtime consuming storage, memory, and compute as if it were a separate virtual machine
@boo_@andros I didn’t foresee anyone turning Google’s #Chrome browser #JavaScript engine V8 (2008) into the server (#NodeJs, 2009) and desktop (#ElectronJs, 2013) runtimes that ate the world, but here we are.
And Electron was originally developed for #GitHub’s #Atom text editor (2008) before they were acquired by #Microsoft in 2018, subsequently discontinued in favor of #VSCode in 2022.
Don’t tell me what you can’t see happening if you don’t remember what already did