altschuler

To give another perspective from the generally negative comments here, I've found Orbs to be just fantastic! The "it's just a VM, everybody has that" argument misses the point, the real value lies in just how easy it is to use and the surrounding functionality. Portals, multiplayer, local machine syncing, Puck (something like a meta assistant), referencing threads/Orbs from each other, etc. all just work as you'd hope and expect.

It's the best $20/month I'm spending on any dev tools, the Amp coding agent in itself is worth that much (I actually came for that and stayed for the orbs). I can only encourage anyone to give it a try and maybe you'll be pleasantly surprised :)

You would benefit from using a streaming subscription. If you use a live query, you have to manually maintain a "cursor" (ie last message you fetched) and update your graphql subscription accordingly every time a new message is received or sent. If you don't you'll be refetching the same messages repeatedly, and they'll just grow as more messages are added.

With a streaming subscription this is all taken care of, you simply do something like this: 1) Load the last 50 messages (or whatever number of existing messages suits you) 2) Run your streaming subscription using the most recent of the messages from above as you cursor 3) When you send a message, do nothing and let the subscription handle getting the message you just sent

This approach is also used/encouraged by JUCE: https://docs.juce.com/master/tutorial_rectangle_advanced.htm... (see "Layout by subdividing rectangles")

The text editor is this one https://github.com/BalazsJako/ImGuiColorTextEdit, it's listed on the third-party attributions page (https://www.tejotron.com/thirdparty.html)

There is only little game-specific in this talk. The Epic store was an example (out of many) of software failing on a daily basis.

It's white to move

I built an ERP-like application for a small production company entirely with Airtable as the backend, but wrapped in a GraphQL schema. The Airtable app fetches the schema of a base when you load it, complete with all type columns, data types, select options, lookup ids, etc. You can use that to generate a GraphQL schema and fetch the data from Airtable in your resolvers. The rate-limiting and general speed when fetching a lot of data makes it unsuited for things that need to scale, but having the excellent Airtable UI for raw data entry and a custom application for everything else (complex data entry, reporting, kpis and such) was very nice.

That said, if I were to do it again today I'd probably go with Hasura or something more suited as an actual backend.

Beyond a certain size and complexity (which is not that much), I find that the argument of typescript (and other typed languages) being less productive than untyped dynamic ones, is not true when you look at it as a whole. It might feel slower, especially to begin with, but once you get used to the language and semantics you save a vast amount of time, by the bugs you _don't_ debug and by not having to jump through the code all the time to find out what that function or module was called or what parameters it accepted. This of course is less true if you're using a lot of untyped packages, but as you said, most do have types either natively or in the DefinitelyTyped project. For most modules it's also feasible to declare the module typings manually, even doing it gradually for the parts that you happen to need at a given time.

They do have ads[1], but they don't use (or have) tracking data for it.

1: https://help.duckduckgo.com/company/advertising-and-affiliat...

An alternative to this and Apollo codegen is GraphQL Code Generator[1]. Like codegen it takes the opposite approach by generating typescript from graphql. It's similar to codegen, with the main two differences being 1) it's not centered around queries, it will generate types for all schema parts as well as queries defined client-side. This is useful for getting typescript types for all the individual schema parts without being "wrapped" in the type of a query, and 2) it's template based and relatively easy to extend modify how the code is generated.

[1]: https://github.com/dotansimha/graphql-code-generator

I learned a lot from the SQLite documentation. It's not only very thorough, but it's full of insightful bits of information that is not strictly necessary but which gives a deeper understanding of the engine.

It was also the first time I encountered the flow diagram type of syntax explanation which I found to be a fantastic way to grasp the details of each command. Eg https://sqlite.org/lang_createtable.html.

https://sqlite.org/docs.html

Very cool. I'm curious about how it compares to MobileOrg (http://mobileorg.github.io), which is also available for Android btw. From a first glance it seems much more polished.

Vimium: https://vimium.github.io

Let's you navigate and control the browser using the keyboard in a very clever vim style.

At Plotist[1] we're taking a slighty different approach to the writing process, where the writing module (which is coming soon) will stand alongside the world building parts of the application.

We've found this to be a great way to keep yourself organized and to make use of all the notes about characters, locations, events, etc. that build up over time.

This doesn't mean that the actual writing view has to be cluttered, but it's available when you need it. And we agree with the people here who like working with their chapters as a tree :-)

[1] https://www.plotist.com

stackEqual stacks neighboring blocks of the same color on top of each other.

What's with the red ball always rolling by in the RethinkDB videos? :)

Nifty little tool. I would make the sliders much wider, since 70% of the space in the property window is unused anyway, and it's easier and more fun to drag sliders and watch the result real-time than changing text values.

A detail I've noticed when compiling to JavaScript is that Kotlin is not a reserved word, and if you bind something to it, it breaks the generated JavaScript.

fun main(args : Array<String>) {

  println("Hello, world!")

  val Kotlin = 0

}

will result in a type error

Exactly my thought, the video seems satirical. Especially when the guy pours beer in the cup and it tells him that it's beer, after which he gives it a "that's right" nod.

I can highly recommend going through this tutorial if you're interested in LLVM or just compilers in general. While it lacks some polish here and there, it's still quite easy to follow and what you end up with is some actually "useable".

It's also rather easy to extend upon what is made, adding your own features.