Fannon

A lot of good arguments which I think are often under looked. "We need to go into the cloud" often feels more like a peer pressure thing. It might be difficult to get a Hetzner server through the ordering processes of your company, compared to self-service rent something from AWS or the like (feels like this may be equal reason why they're so successful?).

But the article completely mises out on the aspect of availability, which would be quite risky with a single server.

Why not do mix & match smartly? A CDN is already "the cloud". Having your static content hosted (and pre-generated fully) in the cloud and only go on dynamic generated / rendered responses if you really have to. Then you have good latency, high availability and still low costs.

There is one simple trick that helped me a lot with writing code and gives me clearly better ergonomics. Maybe a bit caused by the issue of German keyboard layout not working very well for this purpose.

For Windows devices you can download the Microsoft Keyboard Layout Creator and create your own custom keyboard layouts.

I didn't want to change the German layout per se, but make the special character for programming more accessible and close to each other. Most notably [], {}, <> and `.

So I mapped them to AltGr (right thumb) + ASDFYXW in a way that they are very ergonomic to type. E.g to write {}, I just have to press AltGr + df.

Like the author suggests, I've also setup Autohotkey to save me writing common things, but this is well known and if I had to pick, I'd prefer having that custom keyboard layout over typing expansion.

Ok got it now, thanks!

Wouldn't a vector DB be nice to have, so you can use it directly for search?

I understand the argumentation of the article. But I can imagine that waiting so long for a LLM to react that I would actually prefer to do a search instead on a vector database on my "additional information layer" and find relevant information myself. In that case, having a vector DB would then serve two purposes and that could change the considerations whether it is worth the added complexity.

Not an expert here, just a question that came to mind - it might be based on wrong assumptions.

As someone who plays instruments via audio interface:

I'm really confused by their definition of low-latency. For me, everything above 10ms is not low latency and I can -feel- that things get sluggish and a little less responsive.

And btw. I've achieved ~5ms latency on Windows devices 10+ years ago.

It's too bad, because as of today you cannot really use Android devices for live-music making on them.

I've build a few Semantic MediaWikis in my past and share the concern about scalability. But also be aware that in many cases you might not need such a scalability like managing semantic data for all of Wikimedias major wikis in different languages. For small to medium sized companies or communities, I think SMW can scale well enough - depending on how you use it.

The advantage of SMW imho is still that it brings the semantic / structured data features right into the MediaWiki itself and that there's a big ecosystem of related extensions around it (like Page Forms). So far I don't know of an open-source information management system which comes close in capability to this. Setting this all up and maintaining it is difficult, though - I even had to start developing custom tools to assist me with that once it got more complex.

My guess it that there is some cross-pollination and benefits from and to both sides. Machine Learning / LLMs benefit from having higher quality data that they can be trained from or that you can use to automatically add more relevant context behind the scenes.

Semantic technologies or let's say "structured data entry" can benefit from having better auto-suggestions and validations from machine-learning.

The part that I find real interesting is how we put the users in between, so they're in full control and can use AI as an "assistant", but improve on it. And that the "structured data entry" helps the users to give him structure (that will later be helpful to the end-consumers).

> Premise 2: No Quantum Shenanigans > But for most of us, this is an easy premise to accept.

I'm baffled by this statement and wonder if that really is true, I would assume otherwise if you look outside the western IT bubble.

But even if you don't have religious reasons for rejecting this statement, how can you know that there aren't aspects to intelligence that we completely overlook (an unknown unknown) today?

The whole situation could look like the cargo cult situation, where we build something that looks like the real thing but we're far from understanding the real thing. Historically we've done this mistake again and again.

But I get that working like such premises were true might be necessary to make progress. And progress is basically iterating into the right direction.

I really wondered why this is not an explicit thing in most task / issue trackers. There should be some semantic relations between issues which are standardized and come with special feature support.

If we know the dependencies and the priorities, we could also backtrack the graph and assign an "implicit (virtual) priority" to all issues which block issues with higher prio. It would also be nice to mark if something is on a critical path (that has been defined).

The overhead to write down dependencies is imho well worth when you consider how much that information can help you prioritize and save time by not starting something that will end up being blocked later. This is an issue I see repeatedly, also in companies who use Jira.

How would you ever be able to trust such a trustless, decentralized database? Wouldn't all the same problems that you addressed with Google appear again?

With google, the most notable difference seems to be that it is big enough (due its single entry point nature) that people invest in gaming it.

This free and open source software synth really blows me away. It's better than most paid alternatives and I really love how visual interactive and well laid out this synth is.

Due to it being free, there's a huge community growing around creating presets, sharing tutorials, and more. For example, here are many presets incl. audio preview: https://presetshare.com/presets?instrument=2&orderby=likes

The simplest solution here would be to use JSON5 (https://json5.org/) if you're after comments.

It still doesn't support / standardize dates, though.

But realistically, it's also all about the ecosystem. VSCode for example doesn't come with JSON5 support out of the box. GitHub and many other tools / renderers and supports it at least in syntax highlighting.

Ok, yes I see your point - I should have be more differentiated here. I can see that there are games which could also force you to keep focus. What I had in mind were more of the "almost instant reward" game mechanics.

So I come from where you come from.

However, I have mostly (60-80%?) retained my ability to focus on reading without distraction. But there has been something lost and sometimes it feels like an uphill battle to retain your ability to concentrate on one thing at a time. Would be curious what makes a difference here?

I did some conscious choices, not sure how they contribute but I have the impression that each of them helps a bit:

* Not using social media and treating messengers more like email. A real-time conversation may happen, but does not need to.

* I (mostly) avoid browsing news sites where there is endless scrolling / content. I try to mostly read and almost never comment (as this makes me curious on what the reactions on it are)

* I bought a Kindle to read without distractions. It's in airplane mode most of the time, too.

* I separate my work and private equipment

* Only play games casually and sometimes not at all for longer periods of time. I mention this, as games usually have "optimized" on (rather quick) reward feedback and I can imagine that this is very similar as social media in some sense.

Just to add an aspect that I haven't seen so far.

TypeScript makes your interfaces and their documentation much more explicit than with vanilla JS. If you work on your code in a team, you actually want to very clearly document the inputs and outputs of your functions and the types of your data structures. Doing this with JSDocs is cumbersome and error prone in my experience and actually more work than just using TypeScript.

Having explicit types with TypeScript helps both machines (better / safer refactoring) and the humans to reason about the code.

So the bit of extra effort to add the types is very well invested. And keep in mind that developers spend much more time reading code than writing it.

This will only happen if ECMAScript adopts types, which does not seem to be planned in the near future, afaik. Otherwise I can't see how it would supersede TypeScript, because that's the core reason to use it.

I do a agree with you, but we should also keep in mind that there's a distinction between dependencies and dev dependencies.

Building and bundling for the web platform (where you have multiple browser, environments, users on different versions) is a real challenge and you actually want to have good tooling for this.

With NPM, you just bundle all of the tooling along with the dependencies you need for your actual app.

I think that's still a big improvement over projects where you first had to setup your dev environment in very specific ways just to get started (I remember this could even take days to get right for some projects I worked on).

Although I would really wish for a better standard library, or at least some "core NPM modules" which are officially agreed upon, promoted and security checked as an almost-standard-library.

Thanks to your feedback, I've added a new option to display "dateAdded" for bookmarks and two new options how the recentness of dateAdded affects the score. By default this is very low. (It will take a while until this is published at the stores).

See https://github.com/Fannon/search-bookmarks-history-and-tabs#... (first example, and for more details the options.js).

Regarding the sorting / filtering: I see the value in it, but this would be more work and I want to think it through first. Maybe I'll find the time to add it. If yes, maybe I'll add a "sort" mode that cycles between "score" (default)" "last visited" or "date added". Although only score is available for all types of results.

Yes, sorting sounds like a good option. I've just built in some additional scoring that increases points if last visited was recently. This only works for very recent visits (history/lastVisited), within the time frame that history is being fetched, though.

For bookmark/dateAdded, it might help to display the date added and to allow sorting by it as you suggest. I'm thinking about it.

However, the scope of the extension is rather not being a complete bookmark / history manager replacement. Rather a quick search / navigation tool.

Yes. that's interesting. dateAdded is actually part of what the bookmark API returns, so this one would be rather easy to handle.

Last date visited is more complicated. This extension only has it because it merges the results from history API with the bookmarks API. But then it can only go back as far as we fetched the browser history and as far as that exists.

How would you imagine such a query would look like? Right now, the extension only has "search modes" which limit the search results to certain types of entries.

Thanks for the feedback!

How would you define age here? Last time visited?

I have thought about introducing a way to increase score based on "recentness". There is one problem with the history in general, though: It's quite expensive to load a big browsing history so the plugin will only get a fixed amount of history for a few days back. This is configurable, but I don't think it would scale back as long ago as you're hinting at.

Thanks! What permission exactly does trouble you? I guess the tab permission is a bit unusual. However, with the Manifest V3, the extension couldn't make any outside calls anyway without explicit permission to do so (and this isn't the case).

The reason for the tab permission is not just to index them, but to also to merge bookmarks and history with open tabs. If you go to a bookmark, you've already opened it will just switch to the tab.

YAML (and JSON of course) has the big advantage, that you can use JSON Schema to validate it and to provide realtime code intelligence in many Editors (VScode, IntelliJ, Monaco Editor in the web, many Web IDEs. Allthough you might need a plugin for YAML, where JSON works out of the box).

So it's easy to hate on the feature overload of YAML or on the lack of features of JSON, but it's hard to throw out the rich ecosystem along with them they already have established.

One format I personally like is JSON5 (https://json5.org/) as it's very much just JSON, but with some more modern JavaScript (ES5) syntax allowed, including comments. Looks like a parser / serializer for it is also still rather consise.

Although, I'm always wondering which features of YAML to best not use / touch. My personal approach would have been to leave some advanced features to optional pre-processors or real programming / template languages.

For a good talk that discusses the boundaries of unit tests and the type system and how they overlap (or don't) I can highly recommend this video:

https://www.destroyallsoftware.com/talks/ideology

A really good talk on the myth of "testing makes static types unnecessary" from Gary Bernhardt (Wat Talk)

https://www.destroyallsoftware.com/talks/ideology

And there I'm unsure what we consider essential characteristics of a database.

This characteristic you're mentioning is essential for your persistence database, but maybe not so much for a derived read-only databases (e.g. when using the CQRS pattern). Those guarantees and characteristics are often a trade off anyway.

It would have been better to frame it more generically as "adding another store or db".

But the official self-description of Redis is the following:

> Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker.

Quote: https://redis.io/

I'd be interested on why exactly you think that Redis shouldn't be called a DB?

If you already have Postgres in your project and now you get the requirement for an additional cache store, I think it will be less complicated to reuse what you already have instead of adding another DB to your stack.

Of course, at some point of scaling needs a dedicated cache store will make sense anyway.

(Just some justifications from a german engineer :) )

Actually this is exactly the point that the video makes and it offers a very good explanation on the why.

But you're right, this description is for sure clickbaity.

Some people claim that unit tests make type systems unnecessary: "types are just simple unit tests written for you, and simple unit tests aren't the important ones". Other people claim that type systems make unit tests unnecessary: "dynamic languages only need unit tests because they don't have type systems." What's going on here? These can't both be right. We'll use this example and a couple others to explore the unknown beliefs that structure our understanding of the world.