Automatic headphone equalization

Этот документ содержит список (roadmap) навыков, которые часто требуются backend разработчику web-приложений. Документ разделён на этапы (темы). Каждый этап разделён на пункты. Каждый пункт, в документе, подразумевает что:

• бекендер знает что это и какую проблему решает.

• бекендер знает для чего и когда следует применить.

• бекендер знает как с этим работать или знает где подсмотреть.

• при разработке или проектировании бекендер помнит про них и учитывает в приложении.

Some of Stephen Wolfram’s “productivity hacks” to make his days and projects more productive. Daily life, desk environment, outside the office, presentation setup, filesystem organization, Wolfram Notebook systems, databases, personal analytics.

At an intellectual level, the key to building this infrastructure is to structure, streamline and automate everything as much as possible—while recognizing both what’s realistic with current technology, and what fits with me personally.

a tiny camera that takes pictures every 30 seconds, so I can remember what I saw.

Author proposes to replace modern browsers with the following architecture. You make HTTP requests, server return you WASM blobs, they get executed. No built-in DOM.

DOM and its three languages are among the best technologies ever made, despite being so misused. It not being the default way will probably be disastrous. Think about accessibility!

But the idea is cool 🤔

Our design goals are safety, performance, and developer experience. In that order.

Contrary to popular belief, simplicity is also not the first attempt but the hardest revision

code, like steel, is less expensive to change while it's hot.

Safety

NASA's Power of Ten — Rules for Developing Safety Critical Code

• Use only very simple, explicit control flow for clarity.

• Put a limit on everything. Fail Fast

• Assertions detect programmer errors. The only correct way to handle corrupt code is to crash.

• Assertions are a safety net, not a substitute for human understanding.

  • Build a precise mental model of the code first.

  • encode your understanding in the form of assertions,

  • write the code and comments to explain and justify the mental model to your reviewer,

  • and use VOPR as the final line of defense, to find bugs in your and reviewer's understanding of code.

• No memory may be dynamically allocated (or freed and reallocated) after initialization.

• Declare variables at the smallest possible scope, and minimize the number of variables in scope.

• Good function shape is often the inverse of an hourglass: a few parameters, a simple return type, and a lot of meaty logic between the braces.

• Centralize control flow. When splitting a large function, try to keep all switch/if statements in the "parent" function, and move non-branchy logic fragments to helper functions.

• Centralize state manipulation. Let the parent function keep all relevant state in local variables, and use helpers to compute what needs to change, rather than applying the change directly.

Developer Experience

• Add units or qualifiers to variable names, and put the units or qualifiers last, sorted by descending significance. latency_ms_max rather than max_latency_ms.

• Callbacks go last in the list of parameters.

• Order matters for readability (even if it doesn't affect semantics). On the first read, a file is read top-down, so put important things near the top. The main function goes first.

• Don't overload names with multiple meanings that are context-dependent.

1. Use as few tags as possible.

2. Limit yourself to a self-defined set of tags.

3. Tags within your set must not overlap.

4. By convention, tags are in plural.

5. Tags are lower-case.

6. Tags are single words.

7. Keep tags on a general level.

8. Omit tags that are obvious.

9. Use one tag language.

10. Explain your tags.

Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules.

The best components are those that provide powerful functionality yet have simple interface.

Do not add layers of abstractions for the sake of an architecture. Add them whenever you need an extension point that is justified for practical reasons.

This is a card game for teaching kids how to combine unix commands through pipes.

• https://www.ultratechnology.com/1xforth.htm

Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.

A modern ebook manager and reader with sync and backup capacities for Windows, macOS, Linux and Web - koodo-reader/koodo-reader

Эту статью я пишу во многом для нескольких друзей, которые решили приобщиться к этому тренду, и здесь будет обзор моего личного self hosted - про всякие разные штуки, которые показались полезны лично мне, и плотно заняли своё место на моём домашнем сервере.

Open source 2FA authenticator, with end-to-end encrypted backups

У скобочной записи есть преимущество: каждое выражение имеет начало и конец. Не обязательно писать на Лиспе, но нужно знать эту его сторону. Чтобы не выглядеть глупо, не хихикать и не прыскать в кулачок, когда случится увидеть Лисп.

perfect programming language.

Best programming language of all time

A single-user “wiki” engine powering the ThoughtStorms wiki.

Прекрасная статья о выборе человечества - покинуть планету с её проблемами или остаться и решать их? Обратиться к корням - природе, ручному труду или отвергнуть прошлое и адаптироваться к жестокому космосу?
Как сказал Курт Воннегут: "What makes you think you’re going anywhere?"
Подобные Дайсонам, в моей душе борются отец и сын, правда скорее поменявшись ролями. Тянуться к недостижимому космосу, к неизведанным и от того прекрасным технологиям с их бесконечными проблемами? Или обратить внимание на верную спутницу человека - прекрасную Землю и, возможно, обрести покой в отказе от амбиций?