Организованное программирование | Кирилл Мокевнин

Последние месяцы канала

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

Помимо просто праздников (в штатах щас самое праздничное время) и поездок с детьми, я начал активно работать над перерождением Ютуба, в первую очередь, на Хекслете. Мы планируем по полной программе начать записывать и выкладывать не просто разговоры, но и нормальные контентные выпуски. Для этого я нашел классного продюсера, который, кстати помогает мне выпускать подкаст “организованное программирование” (вы заметили что это повлияло на звук и монтаж?). А последние недели мы занимаемся тем что подбираем темы, пишем сценарии, собираем домашнюю студию. У меня дома сейчас куча всякого оборудования, которое наконец-то собрано и готово к работе. Уже были пробные записи, но пока всплывает еще много проблем, начиная от кривого меня, которому надо уметь правильно выражать эмоции и ставить паузы (я планирую брать уроки по этой теме), до хренового света и камеры. Вот над всем этим мы и работаем.

Помимо ютуба, я последние месяцы взялся за пересборку smm на Хекслете. Просмотрел почти 500 кандидатов (ручками без автофильтров!) и кажется нашел человека, который затащит. Он выходит 9 декабря, но пока его нет, в каналах Хекслета тишина, потому что меня, все же, не хватило сразу на столько активностей. Но планы у нас грандиозные, на фоне мы проводим разные исследования и интересную журналистскую работу, результаты которой я буду делиться и там и тут.

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

Ну и недавно канал перевалил за 8000 подписчиков с чем я себя и поздравляю. План был 10 000 до конца года, но уже вряд ли получится. С другой стороны, планирую в следующем году запустить немного рекламного трафика, посмотрим как отработает и почем мне обойдется подписчик.

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

Давайте попробуем в комментах устроить секцию вопросов/ответов. Хочется поболтать)

Ссылки: Телеграм | Youtube | VK

Новый выпуск уже доступе для просмотра, в этот раз разбираем Clojure. В этом выпуске мы погружаемся в мир функционального программирования вместе с Николаем Рыжиковым — одним из ведущих специалистов по Clojure в России. Николай делится своим уникальным опытом использования Clojure как в разработке коммерческих проектов, так и в создании open-source инструментов.

Мы обсуждаем, чем Clojure отличается от других языков, почему его философия минимализма и неизменяемости так важна для современной разработки, и какие задачи лучше всего решать с его помощью. Николай рассказывает о том, как этот язык помогает ему создавать лаконичный, надежный и масштабируемый код, который легко поддерживать. https://www.youtube.com/watch?v=7eJ3yUgbzSA

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

2007 - php
2008 - plsql, oracle
2009 -python, ruby
2011 - javascript, coffescript
2014 - erlang
2017 - elixir, clojure, clojurescript
2022 - java
2023 - typescript

Ссылки: Телеграм | Youtube | VK

Minimal Modeling - новый подход для проектирования баз данных

В этом выпуске я поговорил о проектировании баз данных с Алексеем Махоткиным (он был техническим директором того самого Undev). У Леши богатейший опыт в работе с БД, который вылился в разработку своей собственной методики моделирования баз данных, которая называется Minimal Modeling. Скоро выходит книга посвященная этому подходу, а здесь мы разбираем принципы лежащие в его основе.

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

https://www.youtube.com/watch?v=vYYZy1EulUk

3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте мы обсуждаем все от технических деталей организации своего подкаста до влияния на индустрию. https://www.youtube.com/watch?v=Lwgmz7qVXEM

Видели скриншоты красных флагов найма в яндексе?

Краткая история, кто то слил в сеть часть внутренних доков и дальше, понеслась. Яндекс, как последнее время водится, обвинили во всех смертных грехах. Поделюсь своими наблюдениями и понаблюдаю на вашу реакцию, интересно кто что думает об этом :)

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

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

- Отсеивающие критерии (курсы, стажировки, джуновый опыт) Инвертированный вариант “не берем без опыта”, аналогично могли бы написать что ищут мидлов и выше.
- Сбербанк (ведущие позиции, 1-2 года опыта) Человек либо там работал и знает о чем говорит, либо слышал про это либо обжигался при найме. Возможно это стандартная тема при накрутке (накрутчики часто используют один паттерн) поэтому прописали отдельно.
- не it-образование при небольшом опыте (3-4) опять же просто опыт конкретного человека, он сделал для себя такой вывод. А мы можем сделать вывод (с высокой степенью вероятности), что у человека вероятно 10+ лет опыта и сильный вуз за спиной, поэтому про 3-4 года он пишет как “небольшой”
- Задачи (одна верстка, 1c, битрикс, wordpress) - почему такие вещи вообще выносят в подобные списки? Просто подобных ребят довольно много и опыт собесов показывает что среди них мало релевантных, поэтому проще исключить их из подбора, кандидатов все равно много, а время у спецов на собесы немного и оно дорогое.
- Попрыгунчики (до года везде) - если у человек в таком формате больше 3 мест, я и сам смотрю с подозрением, потому что на определенных позициях, вкатываться только полгода, а то и год. Все это время компания тратит ресурсы, вовлекая и обучая человека. Коммуникация опять же. Бывает что это зависит не от человека, например стартапы все время заканчиваются? Бывает конечно. Стоит ли ради единиц таких рисковать? Зависит от компании и нанимающих ребят, но яндекс явно не та компания, которая будет этим заморачиваться, как, впрочем и многие другие крупняки, у которых на входе очередь.
- Если хочет меньше 200к - и хотя я тут немного удивился, все же подобный критерий всплывает у меня в голове, когда я беру специалиста, например, из маркетинга, и эти специалисты указывают прямо неадекватно низкую планку по зп, например в три-четыре раза меньше чем по рынку, типа 30 тысяч на smm специалиста. Тут просто наверняка либо студент без опыта, либо человек не планирует фултайм и не скажет об этом до собеса, а на собесе начнет продавать услуги (дада в маркетинге так происходит), так как хочет проектную работу, набрать таких десяток и сидеть не гудеть
- От 40 и старше Чего греха таить, когда мне было 25, я думал 40 это все, списывать только. Скоро мне 40 и мнение за годы конечно поменялось. Но я все равно понимаю почему они так пишут, люди в этом возрасте слишком себе на уме, что может стать проблемой и в своей практике я с этой корреляцией сталкивался. При этом конкретно этот критерий несмотря на определенную корреляцию по каким-то параметрам просто не приемлем в современном мире в открытом виде. Эджизм убрать невозможно потому что это не люди глупые,  а потому что мы так устроены (у всех есть лимиты на подбор партнера по возрасту например). Поэтому такие вещи если и делаются, то про себя и на основе косвенных факторов (и да это происходит в штатах тоже налево и направо)

И да, чем больше компания, тем больше всякого такого внутри бывает, потому что там работают люди со всеми мнениями, какие только встречаются. Для меня это просто локальные флуктуации, не более

А что вы думаете по этому поводу?

Ссылки: Телеграм | Youtube | VK

Выпуск про отличие бигтеха от небольших компаний и стартапов опубликован и доступен в видео и аудио версиях на всех платформах (ссылки описании к ролику) https://youtu.be/Lo4F8NMmkN0?si=8FJpN-Ymx1jj6P5S

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

Вакансии пост. Редко такое публикую, но попробуем. Нам в Хекслет нужен smm-менеджер (или как говорят контент-менеджер, smm-маркетолог), с опытом ведения каналов технической направленности и желанием в эту сторону развиваться. Если вы такой или у вас есть знакомые подходящие под вакансию, порекомендуйте позязя https://hh.ru/vacancy/108869389 (откликаться лучше там же)

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

Семантический I18n

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

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

Но в какой-то момент, даже эта система тяжелеет. Когда в проекте тысячи ключей, то снова появляется дублирование и неиспользуемые ключи (легче всего их убрать если у вас gettext). А еще появляется ощущение постоянной грязи, места, в котором все навалено. Можно ли от этого избавиться?

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

Первый вариант это неймспейсы (https://www.i18next.com/principles/namespaces). Мы можем разделить все ключи на разные большие блоки, которые обычно хранятся в разных файлах. Делать это можно по фичам или по слоям. Например переводы для писем в одном месте, а переводы для фронтенда в другом. Сюда же добавляем вложенность. Например если у нас есть меню, то мы можем расположить переводы внутри ключа “top-menu”. Ниже пример с хлебными крошками:


{
"breadcrumbs": {
"home.index": "Главная",
"admin": {
"home.index": "Админка",
"colleges": {
"index": "Колледжи",
"create": "Новый",
"edit": "`name`"
},
"users.index": "Пользователи",
"users.create": "Новый",
"users.edit": "`name`",
"colleges_team_members.index": "Сотрудники колледжей",
"colleges_team_members.create": "Новый сотрудник",
"colleges_team_members.edit": "`name`"
}
}
}


Дальше всех в этом отношении продвинулись Rails. I18n там встроен во все слои сразу причем с учетом семантики. Все что я сейчас напишу ниже, можно подсмотреть тут: https://github.com/hexlet-basics/hexlet-basics/tree/main/config/locales

Возьмем модели. Для каждой модели и её атрибутов создаются ключи, отражающие иерархию переводов.


ru:
activerecord:
models:
user: "Пользователь"
attributes:
base:
name: “Название”
user:
name: "Имя"
email: "Электронная почта"


Когда мы вызываем атрибуты модели в формах или представлениях, Rails автоматически подставляет переводы, если они заданы в config/locales. Например, в форме для модели User, если мы вызовем , Rails отобразит перевод для user.name как "Имя", если он указан. Если он не указан, Rails попробует взять общее название по ключу base, затем попробует отработать fallback (https://www.i18next.com/principles/fallback) и в самом конце, попробует подставить имя ключа преобразованное в текст (первая буква заглавная).

Сообщения об ошибках также поддерживают i18n. Если у нас есть валидации, например, для обязательного заполнения атрибута name, мы можем указать сообщение об ошибке. Модель:


class User < ApplicationRecord
validates :name, presence: true
validates :email, presence: true, uniqueness: true
end


Переводы:


ru:
activerecord:
errors:
models:
user:
attributes:
name:
blank: "Имя не может быть пустым"


Тоже самое касается любого другого слоя. Единственное место где ключи создаются как попало это шаблоны, в которых нет никаких правил заранее, кроме одного. Rails позволяет использовать формат ключа с точкой в начале .keyname, который означает относительный путь. В таком случае слева автоматически подставляется путь до шаблона. Пример: https://github.com/hexlet-basics/hexlet-basics/blob/main/app/views/web/account/profiles/edit.html.slim#L24

Ссылки: Телеграм | Youtube | VK

Прямо сейчас у нас прямой эфир php-линча, где мы будем разбирать проблемы Laravel. Заходите https://youtu.be/KpSfWe7XS3A

Сняли офигенный видос про REST API. Даже если вы думаете что все понимаете, обязательно посмотрите, узнаете про typespec, typebox и много другого интересного: https://www.youtube.com/watch?v=W9sYAdiLnt8

Как управлять текстами в проектах и при чем тут i18n

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

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

* 100% дублирование всех названий. Если у нас есть какое-то поле “Имя”, то оно будет повторено в каждом месте. В крупных проектах это может превращаться в десятки, а то и сотни повторений только для одного названия. А таких не уникальных текстов на сайтах большинство.
* Ручная интерполяция. В тех ситуациях, когда текст содержит динамические части, придется все это закодить руками и тут мы приходим к следующей проблеме
* Учет числа (плюрализация). Часто бывает, что надо писать слово в зависимости от количество элементов: 1 сообщение, 2 сообщения и так далее. Если хардкодить тексты, то эта задача становится проблемой и, часто, говнокодом.

Как минимум, часть проблем может уйти, если вместо текстов вставленных прямо по месту использования, создать словари, например, в json или yaml и дальше использовать их, но даже это решение не справляется с плюрализацией и интерполяцией. Лучше предпочесть специализированное решение и оно есть. Причем, в большинстве бекенд фреймворков оно уже встроено в сам фреймворк (laravel, django, rails и т.п.) это I18n.

I18n работает примерно так, мы описываем файлы с ключами (включая вложенные) и значения (тексты, возможно с интерполяцией)


{
  "key_one": "item",
  "key_other": "items",
  "keyWithCount_one": "`count` item",
  "keyWithCount_other": "`count` items"
}


А затем используем в нужном месте программы


i18next.t('key', {count: 0}); // -> "items"
i18next.t('key', {count: 1}); // -> "item"
i18next.t('key', {count: 5}); // -> "items"
i18next.t('key', {count: 100}); // -> "items"
i18next.t('keyWithCount', {count: 0}); // -> "0 items"
i18next.t('keyWithCount', {count: 1}); // -> "1 item"
i18next.t('keyWithCount', {count: 5}); // -> "5 items"
i18next.t('keyWithCount', {count: 100}); // -> "100 items"


Кто-то скажет, погодите, а при чем тут I18n? А вот так. I18n это, на базовом уровне, не инструмент перевода, а инструмент управления текстами. Даже если у вас один язык и другие не планируются, i18n нужно использовать для управления строками. Таким образом полностью решается вопрос дублирования, решается вопрос плюрализация (это базовая фича всех i18n), а еще там есть форматирование:


i18next.t('intlNumber', { val: 1000 });
// --> Some 1,000


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

И еще. Во многих бекенд фреймворках свой формат и свои тексты. Фронтенд может создавать свои, а может переиспользовать тексты с бекенда, хотя бы частично. Для этого ко многим фреймворкам понаписаны утилиты, которые позволяют взять бекенд тексты и перекинуть их во фронтенд. Например https://github.com/fnando/i18n-js

Ссылки: Телеграм | Youtube | VK

p.s. А как вы работаете с текстами в своих проектах?

Новый выпуск с core-разработчиком Python (автором async/await) Юрием Селивановым, в котором, мы говорим о разработке на Python: будет много про Open Source, контрибьют в Python, инструменты и технологии. Рассмотрим, где сейчас активно применяется Python в веб-разработке, Data Science и Machine Learning, а также сравним его с другими языками, такими как Go, Erlang и Rust. http://youtube.com/watch?v=kVCTHuWwCR0

Зачем компании делают скидки?

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

* Компания запускает большой розыгрыш с призами. Кажется, что они хотят поблагодарить клиентов. На самом деле, они пытаются привлечь новую аудиторию и увеличить свою базу подписчиков.
* Компания заявляет о своей заботе о природе, выпуская эко-упаковку. Кажется, что они действительно заботятся об экологии. На самом деле, они пытаются улучшить свой имидж, чтобы получить выгоду от растущего спроса на эко-продукты.
* Компания устраивает массовую распродажу. Кажется, что они хотят поблагодарить покупателей и предложить выгодные условия. На самом деле, у них переизбыток товара, и они просто освобождают склады перед новым сезоном.
* Компания объявляет бесплатную доставку на все заказы. Кажется, что они хотят сделать покупки удобнее для своих клиентов. На самом деле, они делают это, чтобы увеличить средний чек и компенсировать падение продаж.
* Компания организует благотворительную кампанию, перечисляя часть средств с продаж на нужды благотворительности. Кажется, что они искренне хотят помочь нуждающимся. На самом деле, это часть их PR-стратегии, чтобы улучшить репутацию и повысить доверие к бренду.
* Компания заявляет, что продукция производится локально. Кажется, что они поддерживают местное производство и заботятся о развитии региона. На самом деле, только финальная сборка происходит локально, а все основные компоненты закупаются за границей, чтобы снизить издержки.
* Компания делает акцент на "природные ингредиенты" в своём продукте. Кажется, что они заботятся о здоровье своих клиентов. На самом деле, количество этих натуральных ингредиентов минимально, но использование таких слов позволяет повысить цену продукта.
* Компания заявляет, что переходит на углеродно-нейтральное производство. Кажется, что они заботятся о снижении воздействия на климат. На самом деле, они покупают углеродные кредиты, а производство остаётся практически таким же, как и раньше.
* Компания организует крупное пожертвование на благотворительность. Кажется, что они хотят помочь нуждающимся. На самом деле, пожертвование — это часть их PR-кампании, а также способ получить налоговые льготы и привлечь внимание к своему бренду.

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

Продолжаю серию постов про организацию процессов в компании. В этот раз написал про принципы организации структуры корп доков и баз знаний. Советы универсальные. Забирайте: https://vc.ru/office/1592491-kak-organizovat-strukturu-hraneniya-korporativnyh-dokumenty-tak-chtoby-ne-stradat

Хабр жив! В этом выпуске мы вместе с Алексеем [Boomburum] Шевелёвым, одним из первых рейтинговых авторов, а теперь руководителем отдела по работе с пользователями Хабра, погружаемся в историю самого культового в ру-сегменте ИТ-портала и обсуждаем проблемы контента, авторов, карму, минусы в комментариях и многое другое. https://www.youtube.com/watch?v=_lvcEUi1MtE

Хочу рассказать небольшую, но важную штуку, связанную с поиском работы. Найм в любой области обладает сезонностью. Общая схема такая: В конце января начинается набор, который доходит до пика в марте-апреле, затем резкое снижение (майские) и плато летом. Затем к сентябрю снова начинается рост найма, который доходит до пика в октябре. В ноябре начинается спад, который доходит до самой низкой точке в декабре, когда никто не нанимает, так как праздники и никто не хочет платить новым людям за 10 праздничных дней, когда они еще ничего не сделали. Дальше цикл повторяется.

Ссылки: Телеграм | Youtube | VK