tedyoung

Applies not just to database change-data capture (CDC), but also event-sourcing.

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.

Fun times.

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.

Why not htmx? If your front-end is truly a front-end and there’s not a lot of state needed in the FE, htmx.org might be a great fit.

> 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.

Sorry, I didn't see anything at the top regarding laws that require disclosure of pay ranges. Did I miss it? Is this not relevant to the postings?

I don't see pay ranges listed for the open roles. If hiring in California you have to disclose a pay range in the job listing.

I don't see pay range(s) listed for the open roles. Not sure how many employees you have, but at least in California, if you have 15 or more, you have to disclose a pay range in the job listing. Colorado has a similar laws. New York's takes effect in September 2023 (and applies to 4 or more employees).