“Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick.” - Bruce Lee
Given the example of Pfizer in the article, I would tend to agree with you that ‘search’ in this context means augmenting GPT with RAG of domain specific knowledge.
I still remember a time when recursivedoubts posted about intercooler.js which is the predecessor to htmx, and almost every comment was dismissive and a varition of “what’s the point of this?”.
It seems now the majority of commenters are positive about htmx now and I feel happy for recursivedoubts.
Most web applications today would benefit from using htmx more than JavaScript-heavy frameworks with the exception of applications like Figma and the like of it.
I tried to operate my own email server as well on a VPS, and I have been thinking that the way to solve these problems is to solve the problem of spam itself. Detecting spam puts the costs on the email providers... when the costs should be born by spammers.
Perhaps some sort of digital stamp (digital signatures similar to stamps on physical envelopes) for each email sent paid for with micropayments in a cryptocurrency like nano (note: I don't own any crypto). Small cost per email like 0.01 cents that is trivial for legitimate senders but not for bulk-sending spammers. SMTP servers should put all incoming unsigned emails into spam folders. This will disincentivize spamming (probably not eliminate it) enough that self-hosting emails might be possible again without having to swim against the tide.
I agree with you that it is an anecdote, but I don't see anything wrong with sharing personal experiences of using a certain technology... this is a discussion forum after all and not a scientific paper.
There are learning Javascript resources targeted at non-technical people and children interested in learning how to code... one of the more promising that make it easy to start coding and experimenting with code is p5js (https://p5js.org/learn/) a Javscript port of the wonderful Processing framework... beautiful and simple APIs to start coding...
These internal conversations you have are sometimes referred to as "rumination" or "chatter". Here are some links you might wish to visit that have tips that have helped me somewhat.
https://www.bbc.com/news/magazine-24444431
Actually, archivists and technologists have been working together to solve the problems of digital preservation for a long time. There is an ISO Standards for digital preservation systems - ISO 14721:2012 originally authored by and still maintained by The Consultative Committee for Space Data Systems (CCSDS, which part of NASA). There are commercial systems that were developed to these standards, among them Preservica (http://preservica.com/) which is used in many archives in Europe.
Archivists are acutely aware of the obsolescence of digital formats and media. And the solution cannot be just printing them out on vellum or archival paper because increasingly records are being created digitally that cannot be meaningfully or adequately converted into printed formats. I am talking about records that are audio, video, high resolution photographs (like those that NASA is seeking to preserve digitally) etc. Even emails when printed out onto paper would be missing a lot contextual information that would have been kept if you preserved it as a digital format like EML or MSG.
So, existing digital preservation systems may still be imperfect, but nevertheless we still need find improved solutions for preserving them digitally.
I don't work for CCSDS or Preservica. I work for a national archive as a specialist on digital records and archives, but my background is in IT having spent about 15 years in software development.
Agree with this 100%. In the past the way different applications integrate with each other was through sharing the same database tables. Hence the need to keep the schema synchronized across multiple applications. Nowadays applications should integrate through well-defined APIs and service interfaces. See this Martin Fowler short essay on database styles: http://martinfowler.com/bliki/DatabaseStyles.html
"Its unique concept allows Marketing people to design and build sophisticated websites using widgets created by the Technical programmers."
"By allowing this widget to be programmed and then assembled by non-technical marketing folks, your time to market for a change or a new page is substantially reduced."
http://www.tooltwist.com/ttsvr/whatis.html
"ToolTwist ensures that the websites you create using our technology are fast – pages are loaded swiftly using ToolTwist proprietary technology."
http://www.tooltwist.com/ttsvr/whatis.html
Wouldn't that only work if the json/javascript is pretty-printed and not minified?
I'd think this problem of comments in JSON requires a solution that is part of the JSON specifications rather than dependent on individual parsers implementations.
Or perhaps JSON only really shines as a data interchange format and not much else.
I find that one thing you can do in XML but not in JSON is comments. There isn't any equivalent of XML Comments in JSON. Frequently, my configuration files require comments to show what options are available, or to easily turn off an option temporarily by commenting it out. I don't see how to do that if my configuration files are in JSON.
I think StackOverflow is Knowledge-Management.It facilitates the collection of expert's knowledge from all over the world, stores it, rates it, allows others to search on it and comment/correct/elaborate on it. But at the moment it is a push-model - someone has to ask a question first and the experts reply to it.