I was lucky to get in on the _Thunder_ VB 1.0 beta and, as an "expert" QuickBASIC developer at the time, was just blown away by how easy it was to create a Windows application (which previously was _very_ difficult).
I remember submitting a stock charting application that Michael Risse and Nevet Basker used to love showing during the VB 1.0 launch demos (and road shows), because they could plot the chart of Microsoft (up and up) vs. IBM (not so up).
For me, VB 3.0 was peak Visual Basic, and I was on to doing Java stuff by the time VB 6.0 was released.
Your FAQ mentions "free version you can only use it for your personal purpose", yet the license for the components on GitHub is MIT. Can you clarify what exactly is free and what you're selling?
These positions are all labeled as "Hybrid" (2-3 days on-site). Could you clarify that these are 100% remote? If not, please change your post to reflect this.
Is this actually a fully remote position? The job posting does not say clearly that it is. It says "remote" at the top, but in the posting it only says "This job operates in a professional office environment or remotely as needed/required."
Are you hiring folks who live in California? If so, you're missing the (required by law) salary range. (As well as other states who have similar laws.)
I dread upgrading my 2020 iMac, because the screen is still gorgeous, but there's no way to use the screen as a secondary monitor (or is there?).
I find the Studio Display to be 2X what I'd be willing to pay for a monitor—for me the Thunderbolt Display was the best: reasonable price and great quality.
"JDK21 is a version, for which many vendors offer support."
tl;dr: the Java version is not what gets "long-term support", it's a specific runtime JDK released by some Java vendor, e.g., Oracle, Eclipse Adoptium, Azul, Microsoft, Amazon (Coretto), etc.
> POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached.
But that only means that specific instance of the search query is cacheable, not the search query itself, no? I presume the POST would create a new identifier for the resource, so that yes, that specific resource is cacheable. (Even if the server says "oh, I've just seen this POSTed query, let me return the same resource ID", another client will still have to POST to the server, a non-cacheable action.)
The idea of cacheable isn't just by the server, but by anything in between the client and the resource. By using QUERY, the query itself can be cached.
