Мартышка вылепил себе из карьеры чёрт знает что. Мне кажется, что отдельные HR-ы смотрят на это и думают, что чел просто какие-то рандомные технологии из интернета накопипастил:

• Кучу лет продакшена десктопного гуя с БД под винду;
• Пару лет фронтенда на Vue;
• Бэк на C/C++ Linux.
• Кучу всякий мелкой фигни на C и питоне.

Мне подсказывают, что нынче время ATS, твоё CV не пройдёт, но мне очень не хочется скатываться в обман и работу в команде, набранной ATS и через собеседования «нейросетка оценивает ответы нейросетки».

Есть куча вакансий IoT/embedded, но там требуется личное присутствие. Возможно, я в итоге вернусь обратно в Польшу по этому поводу. Есть удалёнка на всякие HFT и Cloud Linux, но там «у вас меньше 10 лет опыта разработки ядра Linux, вы нам не подходите».

Моя светлая мечта — это найти свой продукт и свою команду, чтобы отвечать результатом, а не на тупые вопросы HR-ов. Но, к сожалению, из-за утизма получается у меня это из рук вон плохо — главным образом в плане «найти заказчика, которого заинтересовали бы мои услуги» или «найти пользователей, которые были бы заинтересованы в моем софте».

Последний год сидел ковырял нейросетки, но опять занимаюсь какой-то бестолковой херней вроде «каким образом Batch Normalization влияет на обучаемость CNN» — в итоге пришел к выводу, по которому уже какое-то время назад написали статью:
https://arxiv.org/abs/1811.12231
«Ну и зачем я этой херней занимаюсь?» — спросил я у себя? На что-то фуднаментальное вне исследовательских групп я вряд ли буду претендовать. Нормальные люди либо из Ollama с FAISS лепят говёные боты поддержки/базы знаний, либо оптимизации на TensorRT, Triton, ONNX разворачивают. А я вот, сижу ковыряю баги из трекера llama.cpp от нефиг делать.

Сначала думал писать в раздел работы, но какая ж тут работа? Тут скорее «помогите вернуться в реальный мир». Но, да, я ищу работу... главным образом C/C++, в идеале линукс, рекомендации смены подхода и «взяться за ум» приветствуются.

Внимание, вопрос очень неоднозначный, потому не стоит сразу отвечать что придёт в голову. Я уже чёрт знает сколько времени пытаюсь найти на него более-менее чёткий ответ.

Пока что у меня варианты ответов находятся где-то между «не нужно почти никогда», «нужно для ленивых фулстэкеров, которые даже embedded будут писать на JS», и «готовые решения определяют задачи».

В каноничной форме решаемая задача выглядит как некий вебсает, часть которого полностью статична; часть статична, но пользователь взаимодействует с ним сверх возможностей HTML, например, бесконечный скроллинг со статичным отдельным описанием товара; часть вебсайта полностью диинамична, то есть, корзина покупателя или админка или мессенжер.

Большинство имеющихся решений исходит из полной динамики в сторону статики, то есть, изначально сайт представляет собой пустую страницу, на которой всё генерирует JS в браузере, но при неободимости часть генерации мы переносим на сервер и даже делаем её однократной. Особой технической причины делать именно так нет — причина скорее социальная, поскольку фулстэкера на JS найти тупо проще, и далее решение формирует проблемы.

У меня осталось большое числое знакомых линуксоидов и просто родственников по другую сторону баррикад. Мало того, что на Россию наложены санкции, так вдобавок изнутри тоже затягиваются гайки выискаванием иноагентов под каждым кустом и тотальным запретом обезличенных платежных систем для переводов более 50 рублей в месяц. Единственным надежным вариантом остаются криптовалюты, но биткоин на хлеб не намажешь, а правовой статус у криптовалют остается спорный.

В моем случае речь идет про довольно смешные деньги, порядка нескольких тысяч рублей, которых хватит разве что для того, чтобы не приходилось воровать в магазине еду и торговать телом — ни про какое отмывание и спонсирование терроризма речи не идет. Сам я не скрываюсь, достаточно внимательные местные обитатели знают и мое имя, и где я живу (жил).

Вариант ехать в Грузию/Армению рабочий, но очень геморный (и меня не выпустят). Кто как решает проблему/может помочь? Если не готовы озвучить публично — можете написать на мойник@gmail.com.

https://www.youtube.com/watch?v=mm4B5nBtuFQ&t=395s

Я сначала не мог понять, что это за фигня вокруг Эльбруса, но сейчас логические цепочки выстроились: некие коррумпированные круги под соусом «отечественный импортонезависимый процессор» распилили астрономическое число денег, получив чудовищно дорогостоящий процессор, который может производиться только в Тайвани. Когда люди наконец узнали стоимость сего чуда, то логично сказали «пошли вы на с таким импортозамещением». На что им ответили: «ах так? А вот мы обяжем все гос конторы ставить только Эльбрусы». Результат — из-за резкого роста стоимости всей авиакосмической продукции произошло резкое сокращение производства БПЛА и ракет. Причем, производить в России эти процессоры тупо негде.

Вот я и удивляюсь: почему в каждом треде про Эльбрус не говорится, что это совершенно бесперспективный проект с нулевым выхлопом с целью тупого попила?

Ну типа да, есть кучу смартфонов с возможностью поставить LineageOS+Aurora, но проблема в том, что 99% смартфонов на рынке делаются под 75-77 мм ширину, руки соответствующего размера в комплекте не идут, а теми, что есть у меня, держать 75 мм девайс чудовищно неудобно. Меня забавляют тяновны, которые вообще держат девайс на кончиках пальчиков, как блюдечко. Еще пошла мода на безрамочные устройства, чтобы ты не дай бог не вздумал держать их пальцами за край.

Даже если брать не адроидсовместимые девайсы, вроде соснофона и либрема, там тоже 75 мм, а раскладушку Пиру уже 7 лет пилят-пилят, пилят-пилят, а до сих пор Preorder.

Меня поражает современная мода на устройства, автономности которых хватает лишь на то, чтобы успеть проехать на автобусе от одной розетки к другой. Особенно меня удивляют ноутбуки, которые почему-то идут по пути уменьшения массы ниже 2 кг, а не повышения автономности. Да, я понимаю, что генеральная идея заключается в том, чтобы привязать всех к зондам, что ты должен быть подключен к сети, а там, где есть сеть, есть и розетка для подзарядки. Но я абсолютно уверен, что куче людей автономности стандартных устройств не фатает. Поясните мне, кто и как толкает движет индустрию по пути снижения автономности. Какие-то идиоты же покупают ультратонкие ноуты? Я уверен, что некоторые даже тут сидят — поясните, что вами движет?

inb4: таскай с собой дизель-генератор повербанк.

Поставил через flatpak 1.4.1, запускаю через:

flatpak run org.gajim.Gajim -c /home/user/.var/app/org.gajim.Gajim/profile

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

Как вариант — посоветуйте jabber клиент или посоветуйте свалить на телеграм. Но телеграм тоже такое-себе.

Как мы все знаем, private объявления де-факто являются частью интерфейса класса, их изменение приводит к перекомпиляции зависящего кода. Кто как обходит проблему? Из того, что я перепробовал:

 — непрозрачные ссылки на forward-объявления структур и функции для работы с ними;
 — публичная структура, которая агрегируется в класс-реализацию;
 — абстрактный класс, он же «интерфейс», от которого наследуется реализация.

Но у всех них есть свои недостатки. Есть ли какие-то иные приемы, которые я упустил?

Например, не могу нигде найти:
https://www.destroyallsoftware.com/talks/useing-youre-types-good
Чел просто взял и удалил его со своего сайта. Видео было публично, но на ютьюбе оно не выложено, и по итогу остались только рассказы в реддите про «ах, какой хороший был слон».

N месяцев назад мне ставили в упрек то, что якобы аналоги сервисов AWS есть у кучи других провайдеров. Ну есть же да? Сколько альтернативных реализаций S3, да? Как бы не так. Который месяц ковыря S3, я прихожу к однозначному выводу: интерфейсы AWS определены через реализацию, то есть, нет никаких общих абстрактных протоколов, разработанных для конкретных задач. Вместо этого протекает деталь реализации здесь, протекает костыль тут, здесь устаревший параметр, которым уже давно никто не пользуется, а здесь новый параметры, которым ЕЩЁ никто не пользуется, и по итогу портирование минимально сложной системы на базе S3 с одной площадки на другую требует целой команды макак с напильниками.

Раньше я не решался высказать эту мысль, потому что у меня небыло железных пруфов, но сейчас они есть, по крайней мере по отношению к S3. Даже достаточно продвинутые реализации S3 API в Yandex.Cloud или Ceph имеют огромное число несовместимостей с AWS.

Как бы это не могло звучать странно, тем не менее, эту картину я вижу далеко не первый раз. Это не тупая ошибка, а точный расчет — так развивали свои решения как минимум Oracle, SAP, Microsoft, а именно — холили и лелеяли каждый маленький костыль, для поддержки которого приходилось выделять отдельного программиста, ровно для одной цели — чтобы никто не мог реверс-инженернуть твою софтину и написать альтернативу, таким образом уведя клиентов. IBM сделало независимый от реализации стандарт PC? Intel сказал огромное спасибо и монопольно основался в нише.

К тому же, с маркетинговой точки зрения чем больше пунктов с фичанеймами в брошюрках — тем лучше смотрится продукт. Почесать левой рукой левое ухо — замечательная фича. Клиент приходит с запросом «мне нужно почесать левое ухо правой рукой» — «извините, поддержка такой фичи у нас не планируется».

И только не нужно мне говорить, что вот же есть где-то Джон и Фрэнком, которым позарез нужен ваш костыль 1997 года выпуска, без которого они не могут жить. Могут. Разработчик мог сэкономить на поддержке этого костыля, потеряв лояльность пары клиентов — это допустимая жертва. Однако, фактор vendor-lock-а за счет бесконечной поверхности интерфейса В УСЛОВИЯХ ИЗБЫТКА ФИНАНСИРОВАНИЯ слишком привлекателен. Я хочу подчеркнуть фактор избытка финансирования, потому что при недостатке финансирования клиенты Джон с Фрэнком будут мгновенно посланы, руководство ни одной минуты не будет размышлять про какую-то совместимость, доверие клиентов, и прочие пустые слова, лишь поддержка будет отвечать дежурное «мы работатаем над этим, оставайтесь пожалуйста на связи». Всё, о чем будет думать руководство — это как сократить издержки. чтобы выйти на прибыль.

Мне удивляет только тот факт, что подобные соображения никто не пишет на каждом заборе. Ведь это просто священные заповеди коммерческой разработки, но даже я до недавних пор не рисковал оглашать их публично. Страшно то, что эти заповеди «с молоком матери» впитали многие разработчики, и следуют им, даже не понимая, что эти заповеди существуют. «Я должен поддерживать совместимость ради совместимости. Моя совместимость должна быть совместимой. Даже если я обосрался в минорном релизе, который скачало 10 человек — я буду эту ошибку тащить следующие 10 лет разработки, потому что могу».

Кстати, если вдруг у кого-то есть блоги-книжки-статьи, аналогичные этому сообщению — буду благодарен за ссылку. Заранее хочу иключить из списка благодарности заполеннные водой книжки манагеров, ничего не соображающих в коммерческой разработке — это большая часть массы макулатуры мне совершенно не интересна.

Которые вынуждены этой сранью пользоваться под линем. Так сказать «новое дно пробито». Я уже молчу про проблемы плана «не работает видео», «не работает звук». Мне удалось побороть проблему автостарта через «rm ~/.config/autostart/teams.desktop» в ~/.profile (этот кусок дерьма отказывается работать, если не пропишется в автостарте).

Но есть вещь более страшная. Это пустое окошечко с крестиком закрытия, которое захватывает фокус ввода, делая все иксы фактически неюзабельными. Я сижу на Xfce, включил в настройках «focus stealing prevention», но это не помогает. В интернетах говоря, что помогает режим «фокус следует за мышкой» — но этот режим не устраивает меня сам по себе.

Достала меня реклама на ютьюбе... потому я принес ее на LOR. Ведь правы ребята в рекламе, это и есть то самое единственное, чего в Jira нет и никогда не будет — гибкости. Как бы хорошо она не была настроена, как бы удобна эта настройка здесь и сейчас не была для конкретного человека — уже завтра возникнет потребность настроить ее по другому.

К сожалению, сам я этот ClickUp в бою пока не тыкал. Из того, что я видел, это похоже на Тот Же Сорт Говна Reloaded, то есть, без старого наследия, но с «новым наследием».

А может быть у кого-то есть мысли по поводу того, как вырваться из этого порочного круга©? Я слыхивал, что в том же Google™ пользуются чем ни попадя для прожект менеджмента — так может в этом и есть счастье? Ну то есть не иметь конкретного инструмента.

Сколько я пользуюсь компами с виндой и линем, столько испытываю эти проблемы. Некая десктопная софтина жрет оперативу. потом еще немного жрет, и еще немного, и потом внезапно система висит, бешенно читая SSD накопитель. OOM не срабатывает, потому что память в медленном сценарии не исчерпана. Хуже всего то, что при отсутствии свопа данный сценарий наступает очень резко, лавиннобразно, система работает как ни в чем ни бывало, а потом за несколько секунд замирает.

Прописал vm.vfs_cache_pressure = 20 в /etc/sysctl.conf — ничего не поменялось. Systemd до недавних пор в этом плане тоже была поломатое, вроде в бунте 21.10 пофиксили, но у меня деб 11: https://github.com/systemd/systemd/issues/10581

rm /opt/db/ *

В очередной раз читая статьи успешнилы, у меня внезапно появился ответ на этот вопрос. Как когда-то заметил ixrws, есть два мира: реальный сектор, который производит товары и оказывает услуги, и спекулятивный сектор, который делает вид, что что-то делает, но на самом деле ничего не делает, а лишь встраивается в потоки денег/валют (в том числе ценных бумаг и байтиков в БД) с целью выуживания прибыли из этих потоков. Именно последние формируют такие замечательные аномалии, как отрицательная цена на нефть, которая в реальном секторе не имеет никакого смысла, если это нефть не загрязнена плутонием.

В чем фундаментальная особенность крайних проявлений двух миров? Мир реального сектора тут надолго, он долго завоевывает репутацию и дорожит ею, у него есть средства производства, у него есть костяк квалифицированного штата и доверенные партнеры. Потому разработка ПО для реального сектора часто отличается умеренным финансированием, долгими сроками реализации, ориентацией на долгосрочную перспективу. Пример чисто айтишного реального сектора — это гугл, который на долгосрочную перспективу развивает опенсорсную инфраструктуру. Питон и линукс по большему счету поднялся именно за счет гугла: cgroups именно в гугле разработали, а ведь на нем держатся все линуксовые контейнеры; TensorFlow, опять же, разработка гугла.

В противовес этому, спекулятивный сектор стартапов, на 95% состоящий из заведомо провальных проектов, абсолютно точно разорится, рано или поздно, поскольку сам по себе не генерирует прибыли. Даже успешные стартапы в итоге сводятся к «продать гуглу/фейсбуку и уехать в закат». Примерно для таких проектов Дональд Норман сформулировал свой закон: «The day the product team is announced, it is behind schedule and over its budget». Смысл как раз в том, что стартап уже разорился в тот момент, как только получил инвесторов.

Следствие такого экономического подхода — решение/продукт нужны ПРЯМО СЕЙЧАС. В идеале реализацию нашего клона AWS нужно завершить к обеду, а к ужину мы уже раскатаем его по всему земному шарику и начнем продавать. Потому что есть ненулевая вероятность, что эту неделю стартап уже не переживет.

Следствие следствия — стартапу некогда адаптировать сотрудников к проекту, в идеале сотрудник должен прийти в проект уже со своим готовым решением и просто минимально адаптировать его под требования или интегрировать с другими готовыми решениями. Ты рукожоп, но ты можешь показать результат прямо сейчас — потому ты лучше человека, способного на листке бумаги перевернуть дерево, как это нужно гуглу. Потому что у гугла есть время адаптировать нового сотрудника и есть уверенность в том, что сотрудник не убежит через месяц-другой, а стартап ничего этого не может себе позволить. Яркий пример — это Booking, который разрабатывал свой сайт на перле, но по причине недостатка перловиков брал с рынка просто талантливых кодеров из смежных сфер.

Конечно, есть еще такой важный фактор, как «сеньор-консультант-архитектор с опытом по конкретной технологии принесет с собой в команду много опыта, научит других кодеров, после чего его можно выгнать и остаться с хорошей командой» — но это все-таки уже не столько программист, сколько консультант-тренер, а псто я как бы пишу про программистов-исполнителей.

Мне всё это в диковинку. потому что я большую часть карьеры работал с продуктовиками, и для меня особенности стартапной экономики кажутся безумными. А кто-то привык работать в сплошных финансово-медико-бигдатово-микросервисовых стартапах, и потому видит совершенно естественным подход «я изучил вышедший пять минут назад фреймворк и уже имею пять лет экспертизы в нём, которые и продаю очередному стартапу». Отсюда эксперты по Cassandra, которые ничего не понимают в принципах проектирования распределенных БД — они продают кассандру, потому что стартапу нужна кассандра прямо сейчас, потому что инвестор заплатил именно за кассандру, ему не нужно грамотное проектирование БД, потому что инвестор все равно ничего не понимает в БД, а стартап гарантировано разорится и разница заключается лишь в том, насколько быстро это произойдет.

PS: кто-то может удивиться, почему экономика 100% разоряющихся стартапов работает. Есть два фактора: казино помноженное на тупость, то есть, МММ; и эмиссия, которая изначально подразумевалась просто для притягивания инициативных людей со всего шарика в штаты, просто чтобы эти люди остались в штатах, а не начали внезапно создавать перспективные проекты в других регионах.

https://habr.com/en/company/mvideo/blog/599689/

Эпичный по своему масштабу трешак. Анон из тринидад и тобаго пишет опенсорсную либу для логирования, эту либу безвозмездно включают в свои сервисы крупнейшие игроки рынка, спустя годы выясняется, что либа для логирования дырява насквозь, потому что анону из тринидад и тобаго просто пофигу на AWS, ведь он не получил от амазона ни копейки. Причем, точно так же амазону и клаудфлере пофигу на качество используемого кода — они мне напоминают школьника, который поставил на компьютер кучу крякнутых игрух с торрентов, а потом удивился, что его пароли куда-то утекли.

Просто к слову о том, почему я не хочу быть опенсорсным разрабом-мейнтейнером. Ты пишешь код, а потом внезапно еще и оказываешься должен кому-то. Как там говорилось «за привелегию писать код нужно брать деньги».

Уже обсуждалось тут: Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

UPD: https://habr.com/en/news/t/599865/ — Автор faker.js и colors.js намеренно сломал свои пакеты

Еще один аноним из зимбабве недоволен, что корпорации используют его библиотеки, и потому, воспользовавшись привелегией лицензии MIT про отказ от ответственности, автор взял и намеренно испортил код библиотеки — дошло до блокировки его аккаунта GitHub-ом!

Разработчик внёс деструктивные изменения в NPM-пакеты colors и faker, применяемые в 20 тысячах проектах

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

Недавно Амазон объявил о переходе с модели eventual consistency на strong consistency, то есть read-after-write consistency.
А также есть статья в блоге некоего высокопоставленного манагера из Амазона:
https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html — Diving Deep on S3 Consistency

Первое, что думается в ответ на эти новости: а как же теорема CAP? Подсказки для этого ответа ищутся в гугле:

https://news.ycombinator.com/item?id=25271791

So they claim performance and availability will remain same while claiming strong consistency. I was confused at first but then “same” availability isn’t 100% availability. So it indeed CP.

In this paper about Spanner, we learn that it’s possible to build a CA system (one which prioritises Consistency and Availability) and also build a network so good that the risk of Partitions to be Tolerant of is negligible enough to effectively ignore.

Короче говоря, CAP никуда не делось, вечного двигателя, сверхсветовой передачи информации, или телепорта в амазоне не изобрели. Амазон пошел по логичному пути: пока нет ни единого разрыва сети, БД дает consistency+availability гарантии, когда сеть рвется — запросы на запись перестают выполняться, имеющиеся данные замораживаюся в том систоянии, в котором они были до разрыва.

Теперь по самой реализации. Инфа в гугле крайне скудная, пока что лучшее, что удалось найти:
https://www.reddit.com/r/aws/comments/k4yknz/s3_strong_consistency/gecdohv/

If I had to guess, s3 synchronously writes to a cluster of storage nodes before returning success, and then asynchronously replicates it to other nodes for stronger durability and availability. There used to be a risk of reading from a node that didn't receive a file's change yet, which could give you an outdated file. Now they added logic so the lookup router is aware of how far an update is propagated and can avoid routing reads to stale replicas.

Судя по всему, ключевым архитектором сего чуда был некто Нихил Шах:
https://www.linkedin.com/in/nikhiljshah/

DATA ITEM AND WITNESS SERVICE PARTITIONING IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P73159-US01

TRANSACTION MANAGEMENT FOR MONOTONIC WRITE CONSISTENCY IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P74530-US01

Первое, что находится в гугле по запросам «strong consistency witness» и «monotonic writes witness» — это статьи:

http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf - Voting with Witnesses: A Consistency Scheme for Replicated Files
https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

Первая статья делает акцент на quorum-based консенсусе — это весьма медленная штука и я сомневаюсь, что амазон смог бы отрапортовать про бесплатный апгрейд согласованности данных, если бы оная для простого чтения требовала еще одной круговой задержки по всему кластеру. Из этой же оперы идет статья с модификацией Apache ZooKeeper:

https://www.usenix.org/system/files/fast20-ganesan.pdf - Strong and Efficient Consistency with Consistency-Aware Durability

Здесь авторы просто отложили операции записи, за счет чего уменьшили время ответа по запросам записи до уровня асинхронной репликации (и потеряли гарантии сохранности при исчезновении питания, но кого это волнует в 2022?). Монотонность чтений без необходимости опроса всего кластера «гарантировали» списком активных узлов, которые получили актуальные изменения и знают об этом. Можно спорить по поводу того, вовремя ли отвалившиеся узлы поймут, что у них уже нет актуальных данных, и потому сериализуемы ли чтения по кластеру, но ведь чтения несериализуемы даже в оригинальном ZooKeeper по абсолютно той же причине (узел может продолжать думать, что он лидер, хотя в кластере выбран новый лидер) — так что вроде как ухудшения нету.

Вот я сидел-сидел, думал-думал, и подумал «а зачем здесь полный консенсус?». Соответственно, взор мой возвращается снова на

https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

где авторы используют свидетелей просто как избыточное eventual consistency хранилище. Вам ничего это не напоминает? Мне напоминает устройство S3 до введения строгой согласованности.

Лично я склоняюсь к тому, что Амазон под капотом S3 оставил тот же самый eventual consistency, работающий на типичной для той же Amazon DynamoDB модели «sloppy consensus», например, когда у вас 10 узлов в сети и для подтверждения записи достаточно подтверждения от 3 узлов (а не шести, как это было бы в строгом консенсусе). Данные со временем будут раскопированы асинхронно на остальные узлы. Естественно, sloppy consensus никак не защищает от split brain, когда у вас две части кластера теряют связь и начинают независимо изменять файлы (в обоих частях есть по три узла для успешного подтверждения), и потому не знают про изменения в другой части кластера. Очевидно, при восстановлении связи нужно как-то конфликтные изменения разруливать. Amazon DynamoDB и Riak уже давно используют решение «в лоб» — оставлять запись с самым последним timestamp. Ту же политику декларирует S3:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#Consistenc...

Amazon S3 does not support object locking for concurrent writers. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins.

Совпадение? Не думаю. По итогу воображается что-то такое:

https://habrastorage.org/webt/ve/c9/ua/vec9uatqx1zht2814ljj-ipvipm.png

То есть, по сути то же самое DynamoDB плюс подобие процессорного кэша. Успешный ответ на операцию PUT возвращается только после успешного сохранения на достаточное число персистентных хранилищ и после оповещения кэшей. Операция оповещения кэша требует передачи данных по сети, но лишь самого минимума, и кэш может мгновенно ответить на этот запрос, так что синхронность не является проблемой.

Как можно заметить, я нарисовал четыре стрелки от кэша к хранилищу — это минимальное количество связей, которое нужно для гарантированного получения данных, залитых на 2 из 5 хранилищ. В принципе, используя информацию из оповещения кэш может стучаться только в два первых хранилища, в которые данные будут размещены раньше всего. Конечно, может оказаться так, что данные уже нужны, а они даже в первые хранилища не залиты — это достаточно редкая ситуация, которую можно разрулить через запрос «отдай мне данные версии XXX, если они у тебя уже есть».

Здесь возникает множество подводных камней при потери связи между узлами. Например, кэш может так и не дождаться ответа на «отдай мне данные версии XXX». Но проблема может быть еще серьезнее: что если кэш вообще не получил уведомления и до сих пор считает, будто данные остались в своей старой версии? Вот это и есть вся фишка CAP и недосказанности со стороны Амазона — а ничего не делать, тупо выдавать старую версию файла, хотя уже давно есть новая. Скрестим пальчики и будем надеяться, что ситуация февраля 2017 года больше никогда не повторится.

Сопсоставил я факты, и поразился одной вещи, которую отправлю вам в виде твитта.

На рынке труда сложилась абсурдная ситуация, когда зарплаты питонистов вышли почти на уровень крестовиков. Питоносеньоры стоят $5500-7000. WTF, если учесть, что изначально смысл питона заключался в том, чтобы посадить на нем кодить макаку за еду? Неужели я был прав год назад, когда писал, что кодинг на питоне не проще, чем кодинг на C++? Или же это очередной рынкоабсурд плана:

-- На чём будем делать новый проект?
-- На питоне. На нем проще писать и больше кодеров...
Спустя год...
-- Почему до сих пор ничего не работает и где нам найти норм индуса-питониста дешевле чем за $5000?

Одноядерный Celeron 2 ГГц образца эдак 2010 года, аш целых 4 Гб оперативы — для своего времени это был достойный экземпляр с солидным временем автономной работы. В свое время на ноуте писался код, игралась дота и CS, смотрелся ютьюб и твитч. В 2022 году я попытался посмотреть трансляцию, зайти в фейсбук — мамачки, даже ссаный фейсбук довольно неспешно перекатывается в браузере. Как там разрабы реакта говорили... «fast enough»? Они только не добавили, что «fast enough for 4 cores and 16 Gb RAM». Вся эта реактная параша просто не работает. В принципе, я это знал, но я просто не подозревал, насколько всё плохо, НАСКОЛЬКО ВСЁ ПЛОХО. И самое страшное то, что совсем недавно я примерно это же и писал, только не на реакте, а не Vue. Пошёл ставить свечку и молиться. С новым годом. Мы все умрём.

Я внезапно осознал, что толком не могу сформулировать, какие фичи питона стоит использовать, а какие — нет (как в последнем треде по крестам). Ситуация усложняется тем, что нынче каждая вторая собака считает себя гуру питона и готова учить других, но только единицы умеют по-настоящему хорошо пользоваться языком. Я могу открыть очередную сессию экспертов LOR следующими правилами:

• Не используй monkey patching (изменения классов и функций в процессе работы приложения) без крайней необходимости;
• Не используй классы, если это не навязывает библиотека и тебе не нужно переопределить операторы, предпочитай duck typing. Следствие — статическая типизация в питоне не работает;
• Лямбды — говно, и функциональная парадигма в питоне близка к неюзабельности из-за трудности передачи блока кода аргументом. Язык изначально ориентирован именно на импертивный код аля «башпортянка», потому предпочитай list comprehension/generator expression вместо filter-map;
• Предпочитай пересоздавать простые значения с нужным типом, а не передавать их как есть или по ссылке. При изменении значения ячейки используй новые значения, а не изменяй старые обьекты. Под капотом CPython уже создает-высвобождает объекты на каждый чих. Создать строку из строки в питоне стоит примерно ничего, но если внезапно вместо строки подвернется непонятный тип или None, то код рискует свалиться со стэком в неожиданном месте.

PS: мои прошлые работы по теме, которые дают советы «как не делать», но не дают советов «что же делать»:

Объектная модель питона
https://habr.com/ru/post/481782/ - О проблемах транслятора Python и переосмысление языка

Перемещено leave из talks