Kitten now has a lovely new multi-page Settings screen and… drumroll… a new 🐢 interactive shell (REPL) for you to play with the running state of your Small Web site/app/place and debug your app, inspect/manipulate its database, etc.
I plan on recording demos of each of them tomorrow but you can play with them now.
And here’s a little tutorial to get you started with the shell:
LLaVA (Large Language-and-Vision Assistant) was updated to version 1.6 in February. I figured it was time to look at how to use it to describe an image in Node.js. LLaVA 1.6 is an advanced vision-language model created for multi-modal tasks, seamlessly integrating visual and textual data. Last month, we looked at how to use the official Ollama JavaScript Library. We are going to use the same library, today.
Basic CLI Example
Let’s start with a CLI app. For this example, I am using my remote Ollama server but if you don’t have one of those, you will want to install Ollama locally and replace const ollama = new Ollama({ host: 'http://100.74.30.25:11434' }); with const ollama = new Ollama({ host: 'http://localhost:11434' });.
To run it, first run npm i ollama and make sure that you have "type": "module" in your package.json. You can run it from the terminal by running node app.js <image filename>. Let’s take a look at the result.
Its ability to describe an image is pretty awesome.
Basic Web Service
So, what if we wanted to run it as a web service? Running Ollama locally is cool and all but it’s cooler if we can integrate it into an app. If you npm install express to install Express, you can run this as a web service.
The web service takes posts to http://localhost:4040/describe-image with a binary body that contains the image that you are trying to get a description of. It then returns a JSON object containing the description.
Wrote my first programming related blog post in a little while: How to redirect the user back to the previously requested URL after login with Adonis.js:
The Evergreen Web section in Kitten’s¹ settings now has its own page too (and uses Kitten’s new Streaming HTML² workflow).
If you have the previous version of your site up somewhere, you can use the 404-to-307 technique³ to forward missing pages to your old site so as not to break the Web.
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).
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