#жиза

Как похорошела Москва бюрократия при Собянине Мишустине!

В январе 2023 я приобрел нидерландское гражданство и, согласно миграционному законодательству, должен отказаться от русского паспорта.

С Россией меня преимущественно связывают личные отношения, так что я со спокойной душой приступил к выполнению своих обязательств. Запускать процедуру выхода из гражданства в России мне не хотелось, а значит нужно прогуляться до консульства в Гааге 3 раза, чтобы:
1. Выписаться из отчего дома
2. Забрать справку, что я выписался из отчего дома
3. Подать заявление на выход из гражданства

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

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

Здесь надо сделать одну ремарку о бюрократии. В Нидерландах я практически любое действие я совершаю онлайн, авторизуясь с помощью ЭЦП, а визиты в офис миграционной службы нужны только чтобы сдать биометрию или забрать бумаги. С Россией же у меня была стойка ассоциация “собери 10 бумажек из 12 разных мест, приходи в определенный день недели”. Впрочем, с русской бюрократией я дел практически не имел, как переехал.

Так вот, в чем казус: почти все бумаги для выхода из гражданства РФ, кроме справки о выписке, я могу сделать онлайн и в электронной форме с ЭЦП! А вот чтобы уведомить миграционную службу Нидерландов о том, что я вышел из гражданства, мне нужно отправить бумажное письмо с переведенной справкой от консульства! Более того, чтобы запросить отсрочку (!!!) дедлайна, я тоже должен отправить бумажное письмо!

Чья бюрократическая машина теперь эффективнее - вопрос открытый.

#пятничное #люди

Открыл блог про то, "как создавать высокопроизводительные инженерные команды".

"Шаг 1: Наймите топовых инженеров"

Закрыл блог.

#машины_разное

Обещанный пост про блокировки!

Если совсем просто, то механизм блокировок (lock) реализуется с помощью обычной хеш-таблицы/словаря/чего-бы-то-ни-было. Ключом к этому словарю обычно является сам объект блокировки, а значение - некий идентификатор/токен замочка.

Объектом блокировки в данном контексте может быть что угодно. Довольно древний, по современным меркам, storage engine MySQL под названием MyISAM блокирует целые таблицы, а более новый InnoDB - строки. Продвинутый механизм блокировок в PostgreSQL, который задействует snapshot isolation - блокировка назначается на строку, но в определенный момент времени! Записи, в том числе обновления и удаления данных, в таблицах Postgres, работают в режиме append only, заправляя это все крепеньким vacuum’ом, ну или как там это называется, знатоки пусть меня поправят.

Локальная система блокировок существует в памяти СУБД.
1. Подключился к СУБД
2. Запрашиваешь “замочек” на строку Х в таблице У (acquire lock)
3. Получаешь некий токен “замочка” - механизм тебя “запоминает”
4. Производишь запись, “освобождаешь” замок (release lock)

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

Но если вы работаете в смузихлебном стартапе, то скорее всего вы живете в условиях распределенных систем, а значит у вас распределенные хранилища, а возможно и распределенные системы блокировок!

И если вам сейчас показалось, что я несу откровенную чушь - то зря. В SRE книге Гугла в 4-ой главе рассказывается про распределенную систему блокировок Chubby. Другим примером распределенного замочка может быть ситуация, когда вы хотите заблокировать некую сущность в пределах нескольких независимых систем. Распределенный замок может быть реализован и в рамках самой системы, например Redlock в Redis. Мы к этому еще вернемся, но тут важно уточнить, что Redlock это фича для потребителя, а не внутренний механизм для работы с запросами.

Как любая распределенная система создает неприятный головняк, так и распределенные блокировки тоже. Представьте себе следующее: процесс взял замок, начал обрабатывать транзакцию, а потом умер. Мы можем решить это с помощью срока жизни (TTL) замка, но что если процесс не умер, но задержался на срок дольше TTL?

Решается это еще интереснее, и вот тут я хочу поделиться наинтереснейшей статьей от автора того самого Кабанчика. Там вам и про блокировки, и почему Redlock говно. Не потому что Redlock, а потому что в распределенных системах все говно, если хорошенько докопаться.

#машины_разное #машины_aws

История о том, как Amazon Prime, стриминговый сервис, мигрировал часть своего кода с AWS Lambda на монолиты в виртуальных машинах, вызвала пусть и дебильную, но предсказуемую реакцию.

Почему дебильную? Потому что любой, кто работал с AWS, знает, что рантайм Lambda поминутно дороже ЕС2, а serverless сильно дороже на больших мощностях. Serverless стек подходит для маленьких контор с минимальной нагрузкой (считай, не больше 100 запросов в секунду) и инженерным штатом из 3-5 человек, компетенции которых хватает на то, чтобы быстро написать код и запустить.

Все, что тяжелее, решается усилиями очень дорогих SRE/DevOps/PlatformEng, зарплаты которых дешевле расходов на инфраструктуру. Но сейчас не об этом.

Некоторое время назад я писал о том, что системные администраторы вернулись. В защиту монолита теперь высказывается доктор Фогельс, утверждая очевидную истину: прагматичность в принимаемых решениях.

Выходит, колесо Сансары таки сделало огромный оборот. Такими темпами еще и к частным ЦОДам на собственном оборудовании вернемся и будем правы.

#машины_разное

Насчет смены стратегий, архитектуры и направления, читай "начали за serverless, закончили за монолит", есть важный нюанс под названием "контекст". Можно было бы пройтись по Amazon Prime, но эту историю только ленивый не мусолил. Давайте из моего опыта.

🟢Ситуация 1: CRUD хранилище
Спроектировали систему-хранилище. Модель данных простая до безобразия:

{
UserId: UUID,
ItemId: UUID,
SchemaName: str,
Payload: binary
}

Поле Payload представляет собой закодированный в Apache Avro набор данных, схема которого описана в отдельном реестре. Пользователь может декодировать на стороне сервера - тогда сервер вернет JSON, или на стороне клиента - тогда сервер вернет base64 строку, а там уже пусть клиент сам схему разбирает.

Целесообразность: эффективно хранить данные, максимальная гибкость клиенту. Сервис, предполагается, будет иметь строгую структуру данных и выполнять функции CRUD.

🟡Ситуация 2: CRUD хранилище с внешними интеграциями.

Проходит некоторое время, и появляется потребность помимо записи в базу делать вызовы туда-сюда, дополнять поле Payload новыми данными и класть в базу. Чем городить костыли на текущем сервисе, принимается решение сделать Отдельный Слой Абстракции™, который будет эти вызовы делать.

Целесообразность: иметь отдельный “интеграционный” слой, не выходить за рамки текущего сервиса.

🟠Ситуация 3: CRUD хранилище с внешними интеграциями, динамическими полями и строгой типизацией десериализованных данных.

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

Целесообразность: иметь отдельный уровень абстракции, который берет на себя сложность десерализации и расчета динамических полей.

🔴Ситуация 4: А какого хрена мы ходим через 3 сервиса, чтобы вернуть одну сущность?! Почему у нас 80 мс на проксирование запросов?! Давайте переделывать в угоду эффективности.

Между Ситуацией 1 и Ситуацией 4 прошло без малого 6 лет. Если бы вы, как и я, устроились в контору недавно, вы бы, как и я, решили, что систему проектировали и проектировали наркоманы и смузихлебы.

Тут надо сделать ремарку и вновь упомянуть моего приятеля Серегу П., словами которого я руководствуюсь: "Мне очень экономит время задавание вопроса самому себе, когда я вижу какую-то дичь: "При каких условиях я сделал бы вот эту ебалу?"

Ситуации с 1 по 3 я описал, опираясь на дизайн документы, предшествовавшие каждому слою. В каждом, повторюсь, каждом дизайне все было логично, потому что контекст был именно такой. Предполагали ли инженеры-архитекторы тогда, во что вырастет система сегодня? Сомневаюсь. Представляют ли они сейчас? Вполне себе да. Для опыта не существует алгоритма компрессии.

#жиза

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

Раньше мне казалось, что письмо требует обязательного аттрибута "муза", но этот миф был быстро развеян. К моему удивлению, письмо это самая настоящая работа, и относиться к письму надо как к работе.

Первое подтверждение этому я это увидел в книге Карлоса Руиза Сафона "Игра Ангела", где главный герой, неудачливый писатель, поймавший большой куш и приобретя патрона, говорит своей ассистентке: "Утром садишься и не встаешь, пока не напишешь."

Несколько лет спустя, я читаю похожие правила от Стивена Кинга в его автобиографическом мануале о писательстве On writing. В самом труде много полезных советов и упражнений, очевидных и внезапных, но правило то же - не ждешь музу, просто садишься и пишешь. Будешь писать редко - стухнешь и просрешь идею.

К техническому тексту такой совет слабо применим, но я немало интересных тем для канала бездарно просрал, потому что поленился и не написал. Надо исправляться. :)

#машины_aws

К слову о интересных темах - смахнем пыль со старого срача о системах управления облаками, т.е. Infrastructure-as-Code. Так получилось, что я снова изучаю возможности CloudFormation и нарвался на нововведение под названием Language Extensions.

Language Extensions это Template Macros, разработанные AWS. Сами макросы представляют собой блоки шаблона, которые “трансформируются” на лету, делая шаблон динамическим и позволяя с ним химичить, как душе угодно.

Например, AWS SAM это самый, что ни на есть, макрос-сахарок, который абстрагирует под собой неудобства описания serverless ресурсов.

На момент этой записи Language Extensions умеет конвертировать YAML ключи-значения в JSON-строки, включает поддержку Intrinsic Functions в - наконец-то - Update/DeletionPolicy, и с какой-то целью добавляет новую функцию Fn::Length.

Что привлекло мое внимание, так это обсуждение новых фишек этой разработки, а именно вот эта ветка. Да, вам не показалось, мои дорогие ненавистники многострочных шаблонов. В CFN собираются внедрить циклы. Возможно, затем и придумали Fn::Length.

При чем здесь срач, скажете вы? При том, что львиная доля холиваров CloudFormation vs Terraform vs CDK vs Pulumi нередко сводились к тому, что последние 3 инструмента могут использовать цикличность для описания ресурса один раз, а создания многажды, а мой любимый целофан - нет. Поэтому, создавая VPC с 6 подсетями, 3 публичными и 3 приватными, вы 6 раз описывали подсеть, 6 раз описывали ассоциацию таблицу маршрузитации с подсетью, и неизвестно сколько еще дубликаций вам пришлось бы сделать позднее. Шаблон становился огромным набором копированного дублированного кода, который не хочется ни читать, ни тем более обслуживать.

Наконец-то за эту проблему взялись сами владельцы сервиса. Это создает надежду, что сервис живет и не станет полумертвым backend’ом для CDK. А может и станет, кто ж его знает.

#люди

Я привык разделять карьерный трек инженера на "до" и "после", где "после" наступает после обретения так называемой "сеньорской мудрости". Дальше рост идет только в вертикальном направлении (лидерские и управленческие качества), либо горизонтальном (охват областей и технологий). И то чаще всего идет вертикальный рост.

Пресловутая “мудрость” появляется, как ни странно, вместе с “сеньорской заебанностью”, когда молодой энергичный заряд постепенно ослабевает, и инженер становится… медленнее. Меньше отправляет pull request’ов в день по сравнению с коллегами, меньше производит дизайн документов, тише ведет себя на встречах и так далее. Это вовсе не значит, что инженер потерял в производительности! Скорее инженер понимает, что здоровье у него одно, опыта у него о-го-го, а 25-летних людей по скорости переплюнуть просто невозможно.

Но причинять пользу предприятию надо, и инженер начинает работать эффективно. Находит дешевые и быстрые имплементации или вообще избегает их - ведь лучше всего работает тот код, который не написали! Делегирует задачи, опираясь на сильные стороны своих коллег (про это расскажу отдельно), доверяет им принятие решений в определенных областях и этапах; выбивает у своего руководителя человеческие ресурсы, чтобы не тянуть проект в одиночку; и начинает все чаще задавать нелюбимый всеми вопрос “А зачем?”. Инженер уже не следит за бесконечным потоком новых фронтенд фремворков и очередных витков эволюции в индустрии, потому что он уже опоздал их изучать, да и они все равно каждую неделю новые.

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

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

#анонсы

4-ого июля буду выступать на HighLoad в Сербии, рассказывая о том, как можно сделать Redis строго-консистентным в кластерном режиме.

Буду рад встретиться очно с коллегами, кто окажется там же в те же дни. 🙂

#люди

Питер Друкер, известный экономист и автор множества произведений в области управления, в своем труде The Effective Executive дает следующий карьерный совет: “Build on strengths, not weaknesses.”

На первый взгляд такая рекомендация кажется чем-то странным, да и конфликтует с идеей T-shape, но это далеко не так. Тот же T-shape подразумевает наличие основного навыка, в которую специалист постоянно инвестирует. Помимо этого навыка у специалиста есть общее понимание смежных областей - достаточное, чтобы сделать простейшую оценку или поддержать диалог.

Что же касается самого совета, то он полезен не дебютантам индустрии, но опытным кадрам, которые спустя Х лет решили сменить свой карьерный курс. Рекомендую не выбрасывать за борт накопленный багаж знаний и опыта.

К моменту моего трудоустройства в Убер, я поставил себе задачу перестать опираться на AWS, потому что чувствовал, что некий порог уже достигнут. В какой-то мере это удалось - теперь я занимаюсь бекендом, но сказать, что теперь бекенд стал моим основным навыком будет как минимум наивно. Мозгом я все еще сисадмин инфраструктурщик, который проектирует системы из расчета, где и как могут отстрелить компоненты или как тяжело их обслуживать. Опыт работы с AWS дал мне этот и много других поднавыков, которые и стали столпом моей экспертизы: анализ откупов и выбор наименее худшего сценария; умение договариваться; коммуникативные навыки и навыки презентаций; техническое письмо, и так далее. На этих качествах я и строю свою карьеру дальше, потому что в них я силен и могу конкурировать.

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

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

#машины_разное

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

Один из законов Лемана гласит, что ПО либо эволюционирует, либо становится несопровождаемым и бесполезным. Это может привести к тому, что экономия человеческих ресурсов от новой красивой системы нивелируется при условии, что старая система все еще существует, но в нее уже не инвестируют.

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

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

​​#жиза

В Амстердаме стоит Королевский музей, габаритами и наполнением словно Пушкинский в Москве. Внутри он разделен на несколько эпох нидерландской культуры и искусства, от деревянных церковных статуэток святых до легендарного автопортрета, тогда еще “двуухого”, Ван Гога и знаменитого “Ночного дозора” Рембрандта, вокруг которого построили стеклянный саркофаг.

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

Моя любимая картина там - "Испуганный лебедь" Яна Асселина, про работу которого я узнал из нидерландского мистического триллера “Арес”. Лебедь олицетворяет Яна де Витта, защищающего тогда еще Голландию от “сущего зла”, которое изобразили в виде собаки сутулой.

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

Была мысль, что автор тогда испытывал те же трудности, что и художники, которые рисовали зверей по рассказам и на слух, из-за чего вы часто можете посмеяться над максимально всратыми львами, тиграми и птицами, но я не рискну взять ее как основную гипотезу.

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

#машины_aws

Для CloudFormation был разработан линтер cfn-lint, который на базе разных правил проверял шаблон на вшивость. Одной из моих любимых фишек этого линтера была возможность написать свое правило на том же языке, что и сам линтер, т.е. на Python.

А раз для написания правила используется верхнеуровневый язык программирования, то положить в это правило можно буквально все что угодно. Автор помнит времена, когда он злоупотреблял Boto3, чтобы в рамках правила делать вызовы на AWS API и делать более точечные проверки, например, если hardcoded ARN ссылается на существующий ресурс.

У таких свистоплясок есть очевидный недостаток. Например, если линт проходит в рамках CI, то у сборочного агента должен быть доступ в AWS, не говоря уже о том, что мы нагружаем линтер функциональностью, для которой он никогда не предназначался.

И вот я в очередном туре по кишкам CFN, изучая расширения, нашел расширение Hooks. Hooks проверяют разные типы ресурсов на соответствие определенным правилам, но в этот раз правила проверяются на стороне самого CloudFormation. Может показаться, что это бесполезное дело, ресурс дешевле проверить до развертывания, а не во время развертывания.

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

Но для этого нужно побороть сначала свою лень и написать много правил на все случаи жизни. 🙂

#пятничное

Уморительно, оказывается есть игра, где участнику надо угадать, кто по ту сторону чата - человек или машина.

https://www.humanornot.ai/

Один сеанс игры занимает всего 2 минуты, долго переписываться не получиться. Для себя нашел выигрышную стратегию, задавать вопросы о политике.

Не чтобы позлить лишний раз, а потому что о политоте у каждого человека мнение есть. 🙂

#машины_aws

А если без шуток, то c us-east-1 часто творится какая-то хрень, потому что это старейший и крупнейший регион, причем не только у AWS, но и в целом в Северной Виргинии очень много ЦОД. Автор помнит мемы, когда какой-то реднек хотел "сломать интернет" взорвав серверные интернет провайдеров в этом штате.

С USE1 ситуация усложняется еще тем, что раньше этот регион ставился по умолчанию всем, кто заходил в облако впервые. Молодым же стартаперам невдомек были особенности регионального развертывания, да и запустить свежий продукт поскорее хотелось больше, чем думать о том, где именно его запускать. Чего уж добавлять, что AWS тестирует новые сервисы в Вирджинии и Ирландии (eu-west-1).

В итоге USE1 перегрузился, AWS сделал регионом по умолчанию Орегон (us-west-2), но дело это не сильно спасло, ибо вчерашние стартапы уже стали единорогами.

Собственно хозяйке на заметку: держитесь от USE1 подальше. А про мульти-региональные приложения вы и без меня знаете.

#машины_разное #люди

Попался на глаза прикольный блог про “10 законов в технологиях от Амира”. Кто такой этот Амир, не так уж и важно, в чем он сам и признается, ибо это его наблюдения за карьеру.

Хочу подчеркнуть 3 основных закона, которые мне аукнулись.

“A technology that was built for good will eventually be also used for bad.”

Я бы сократил это до “A technology will eventually be also used for bad.”, причем так можно говорить не только про новые блестяшки, как (де-)генеративный ИИ, но и про внутренние системы, которыми неизбежно будут злоупотреблять или использовать не по назначению. Соответственно, я, как разработчик-владелец, должен не допустить такого поведения.

“The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years.”

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

“A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers.”, и за ним же: “Left alone, a product team will optimize to the closest and easiest goal.”

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

Прекрасно понимаю коллег, которые в индустрии ради того, чтобы приносить пользу, занимаясь любимым делом и постоянно развиваясь. Неприятная реальность такова, что такие мотивы должны соответствовать миссии коммерческой организации, которая в 9 из 10 случаев звучит: “Зарабатывать деньги.”

#машины_aws

Разработчикам CloudFormation Extensions, да и в целом команде CFN - мое почтение, такого удобства как человек, который хочет писать бизнес-логику и только, я с сервисами AWS не испытывал примерно никогда.

Собственно, в чем цимес. Разработчики CFN придумали расширения, в которые входят Modules (по аналогии с Terraform), Hooks (валидация изменений, но теперь на лету) и Resource Types - та самая мякотка, которая позволяет выкинуть в окно и сжечь Custom Resource со всеми его Lambda’ми.

От разработчикам расширения требуется строгое следование спецификации. Оно и понятно, ведь ресурс управляется бекендом CFN, а значит входящий тип должен спокойно перевариваться. В помощь разработчику дается cloudformation-cli с набором плагинов, в который оборачивается логика жизненного цикла ресурса.

Чтобы сгенерировать стартовый скелет, нужно просто напечатать cfn init и пройти интерактивный опрос. Обертка подготовит структуру проекта, сгенерирует модель, хендлеры, скелеты тестов, и даже набросает схему.

Посмотрев на результат работы init-скрипта, я поймал сильный вайб от SAM. Предположив, что мне нужно будет руками поправить сначала схему, потом переписать приблизительно все. Однако, открыв models.py, я увидел подозрительную строчку: # DO NOT modify this file by hand, changes will be overwritten

Пройдясь бегло по мануалу, я обнаружил волшебную команду cfn generate, которая на основе схемы генерирует весь шаблонный код, с (де-)сериализацией, валидаторами и прочим. От меня нужно только CRUDL нашлепать, да в сгенерированные тесты какие-то данные сложить.

Весь остальной опыт +- такой же как у SAM CLI, но вот генерация и регенерация кода - мое увожение, я был приятно удивлен.

#пятничное #воскресное

"Он понял из этого отрывочного бормотания, что Сомс - отвергнутый, нелюбимый муж - восстановил свои права на жену путем величайшего, наивысшего акта собственности."

Какой интересный способ выбрал Джон Голсуорси чтобы в "Саге о Форсайтах" описать обыкновенное домашнее насилие!

#машины_разное

Усилия по ускорения Python продолжаются! Теперь Гвидо при поддержке инженеров из Меты намерен выкинуть из него GIL.

Нелюбовь к GIL сама по себе не новость. Из-за него для эффективной параллелизации приходится использовать multiprocessing, что неэффективно по памяти, хотя multithreading vs multiprocessing - отдельная дискуссия в сообществе.

Толчком к движению PEP-a вперед стало желание фейсбушников помочь, выделив на этот проект 3 человеко-года.