All streams
Search
Write a publication
Pull to refresh
93
0

Пользователь

Send message

Представляю, как Гомер смотрит на небо и думает: «Ну и какого оно цвета? Нет, небо не обязано иметь цвет!» - думает Гомер.

Есть мнение, что не было подходящего слова, и ключевым измерением для описания цвета была "ось" светлый-тёмный. Отсюда и οἶνοψ πόντος, wine-dark sea.

Считаю, тут уместна будет такая картинка по поводу использования синего художниками:

Also, интересное мнение (паночка ссылочка помёрла): В 1858 году британский литератор Уильям Гладстон заметил, что в «Илиаде» Гомера нет ни одного упоминания о синем цвете. Версия о том, что Гомер был слепым, давно отвергнута учеными: по страницам «Илиады» разбросаны красочные и детальные описания оружия, лиц, животных, деталей одежды и так далее. Однако многие вещи «окрашены» в непривычные для нас цвета. Так, гомеровский мед – зеленый, а море и овцы – фиолетовые.

.

Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема

Это верно, конечно.

Но ведь если следовать low coupling, и всяким буквочкам типа S, I и D - зачем "всему" влезать в мозги?

Интересно 👍 Не совсем понятно, как в случае с conventions.md сочетаются требования «не дублировать информацию из него» и «отразить все главные принципы разработки из документа @vision.md». Ведь без дублирования не обойтись: если изменится vision.md, придётся править и conventions.md. Может, тогда в vision.md оставить только принципы? Что там есть ещё, кроме принципов?

А потом замечаем: ошибка была в самом первом коммите. В feat: Add initial user authentication.
Что делать?
Не знаю, как у вас, у меня такое регулярно.

Коммитить fix в ветку new-feature а потом pull request + squash.

Вот тут так делали регулярно.

О, а тут ещё начальник прибегает с криком: "hotfix срочно!"

Ну в новую ветку переключаешься да и всё. Возможно, я чего-то не понял...

Давайте чуть более конкретно. Возьмём принципы.

  1. Контекст

  2. Цель

  3. Декомпозиция

  4. Примеры

  5. Роли

  6. Уточнение

  7. Ясность исходников

Пожалуй что без 4 и 5 можно обойтись, но остальное - в той или иной степени неплохо использовать. Что думаете?

Дальнейшее развитие модальности можливости: оценка Anthropic может не превысить 100 миллиардов долларов.

мы используем YDB как хранилище данных сообщений в чатах.

Понятно, т.е. "несколько десятков серверов" не заняты работой по долгосрочному хранению данных ;)

Благодарю за ответы🤝, было интересно.

Статистический парадокс дней рождения говорит как раз о неравномерности нагрузки.

Парадокс дней рождения возникает как раз из-за того, что испытаний мало а слотов много и кажется, что пересечений по слотам быть не должно.

Тут же имеется парадокс другого характера - испытаний много, слотов мало и, казалось бы, должен работать ЗБЧ и распределение должно быть ранвомерным.

Интересно было бы взглянуть на более конкретную модельку. Когда и в каком виде появляется неравномерность, в числах.

Если что, первое случается крайне редко

Спасибо за интересную ссылку 👍. Там, кстати, упоминается: «Мы регулярно проводим для команды учения с имитацией падения одного дата‑центра и, как правило, продолжаем совершенствовать систему эксплуатации по итогам таких учений.» Видимо, эти учения совсем не зря — у нас недавно в двух дата‑центрах Hetzner возникли серьёзные проблемы: ⚠️ Outage Load balancer: There are network problems at the LB host nodes in FSN1 and HEL1. Status: Investigating

Собственно, в основном меня интересует вопрос HA по отношению к данным. Понятно, что воркер можно "перетащить", а вот как с данными обстоит дело если из строя выходит один ДЦ, как это отрабатывается на "учениях с имитацией падения одного дата‑центра"?

«…тут нам мешает “тяжёлый” хвост у распределения веса чатов.»

Можно ли здесь подробнее показать модель с цифрами? Например, если имеются миллионы пользователей и десятки тысяч RPS на сервер, то как именно этот «тяжёлый хвост» приводит к ситуации, где на один сервер может внезапно приходить не 10 000, а, допустим 50 000 RPS (или сколько нужно чтобы потребовалась ребалансировка?

Да, точно, это было в статье. Проглядел.

Понятно. Не подскажете, как в web-версии присоединить git-репозиторий? Ну т.е. вот я создал новый каталог, а дальше что с ним делать? Какие-то credentials должны вводится...?

По поводу

Local Storage: Files are stored locally in Markdown, editable in any text editor.

Верно ли это для browser-based version (File System API/OPFS) ? Или что-то типа IndexedDB используется?

Неплохо. Отлично, даже можно сказать.

Но вот по поводу отличий. Вы пишете

Looking for an alternative to GitBook, Mintlify, or typical Static Site Generators (SSGs)?

В такой постановке вопросы - хорошо бы посмотреть более внятный список key differentiators. Ну или сравнительную табличку - у кого что есть, а чего, наоборот, нет.

Ваша уникальность, с первого поверхностного взгляда (vs GitBook):

  • Local Storage

  • Multilingual Support?

По-поводу Multilingual Support не уверен. В GitBook есть, но наши Content Creators не очень довольны.

Интересно, спасибо. Уже в XIX веке знали толк в highload’е (турбин).

Есть несколько вопросов, если позволите.

Fanout обрабатывает очень высокую нагрузку — несколько десятков серверов совместно обслуживают более 300 тысяч RPS.

  • Сколько серверов отведено под воркеры?

  • Сервер серверу рознь: можно уточнить конфигурацию железа, в частности, количество ядер CPU?

  • Как обеспечивается HA при outage уровня датацентра?

Далее. Судя по RPS, можно предположить, что количество активных пользователей не менее миллиона. При таком объёме пользователей возникает вопрос: откуда берётся выраженный дисбаланс, требующий регулярной ребалансировки партиций? Казалось бы, статистически должно обеспечиваться более-менее равномерное распределение нагрузки.

Какие-то проблемы на бэке определённо есть...

Dependency Hell in Microservices:

Зоопарк блоков для построения архитектуры:

1
23 ...

Information

Rating
5,356-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Software Architect
Lead