Нажаль ми зібрали лише 3500/77 000грн на оплату клініки для постраждалих тварин.

Оплачувати лікарню немає чим, а рахунок має бути закритий сьогодні, або послуги лікаря нам відключать(

Якщо можете докиньте скільки не шкода

https://send.monobank.ua/jar/9tbJNeWg6U

💰 Чим більше учасників, тим «геніальніший» випадковий переможець

Припустимо, мільйон людей мають однакові здібності та використовують однакову стратегію.

Максимальний випадковий результат серед N учасників приблизно дорівнює:
L = sqrt(2 ln N)σ
L(1m) = sqrt(2 ln 1m)σ = 5.26σ
де σ — це стандартне відхилення

Тобто серед мільйона однаково здібних людей майже неминуче зʼявиться хтось із результатом більш ніж на п’ять стандартних відхилень вище середнього - просто через випадковість.

Після цього він може написати книжку:
"Я став багатим, бо прокидався о п’ятій ранку"

Але сотні тисяч людей, які також прокидалися о пʼятій і не стали багатими, книжок не напишуть.

PS: Правда ж математики це чудово?)
Доречі ця ж формула юзається в аналізі сигналів для фільтрації шумів

Почему в персонализации резюме нет никакого смысла.

Уверен вы долго слушали людей которые говорили противоположное, но на моей стороне математика))

Итак возьмем за условия:

1) Вероятность что резюме увидят - одинаковая для обеих случаев так как канал одинаковый

2) Вероятность заинтересовать рекрутера, если он увидел резюме. Для обычного резюме давай поставим 3%, вероятность для подготовленного резюме Х - эту вероятность мы будем трекать что бы понять при каком значении она дает результат лучше рассылки

3) Время потраченое на работу:
отправить резюме - 30сек
персонализированое резюме - возьмем разбивку 5мин, 15мин, 30мин (тестируем паралельно с вероятностью Х)

4) Цена нашего часа работы - 25$

На графиках результат 4х Стратегий. Как видим даже при затрате всего 5 мин на резюме, его эффективность должна вырасти с базовых 3% до 33%, что в реальной жизни почти нереально. Но это можно взять за базис - все что требует больше 5мин времени 100% бесполезно.

Как видими вариант просто масс рассылок - самый выигрышный. А если его еще и автоматизировать дабы не тратить 30сек то и подавно.

Что еще может улучшить - качество исходного базового резюме. Ведь даже если вы его подымите с 3% до 5% эффективности - это увеличит результативность в 1.66 раза.

ДИСКЛЕЙМЕР: Все это верно при условии если вам все-равно где работать

на

В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency для GET, PUT и LIST без заявленного ухудшения performance и без глобальной координации. И вот инженерно это намного интереснее самого названия алгоритма. ([Amazon Web Services, Inc.][1])

Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:

W + R > N
2 + 2 > 3

Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.

На масштабе S3 проблема становится жестче. Нельзя просто посадить миллиарды ключей на один consensus group - leader превратится в bottleneck. Значит, coordination domain надо дробить, маршрутизацию делать локальной, а metadata и версии объектов обновлять так, чтобы независимые ключи практически не мешали друг другу.

Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:

1 000 000 / 10 000 = 100 ключей на group.

Теперь consensus остается локальным, а throughput масштабируется горизонтально.

В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])

Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.

[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"

#заметкиархитектора #история

Головне не в житті не вийти на себе)

#жартипроандрія

Після 2014 року я вперше по справжньому побачив, як в Україні працює технологічна допомога армії.

Я тоді займався машинним навчанням. До мене прийшли військові з ідеєю автоматичної турелі. Камера знаходить людину, система визначає свій це чи чужий, сама наводиться і відкриває вогонь. Без маячків, без електронної ідентифікації, тільки по зображенню.

Я пояснив, що це матиме величезну похибку. Камуфляж, погане освітлення, трофейна форма, закрите обличчя, нестача нормальних даних. Сказав, що помилка легко перевищить 25 відсотків.

Мені відповіли: нормально, нас влаштовує.

Тобто система може вбивати своїх, і це для когось прийнятна статистика. Я подивився на них і сказав, що в такому лайні участі не братиму.

Наприкінці 2022 і на початку 2023 року ми вже працювали над системами візуальної навігації, розпізнавання і автоматичного наведення. Технологія була. Люди були. Можна було робити реальні речі для армії.

А потім почалася не інженерія, а українська система.