Организованное программирование | Кирилл Мокевнин
10K subscribers
53 photos
201 links
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Download Telegram
Семантический 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, если мы вызовем <%= f.label :name %>, 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
Вакансии пост. Редко такое публикую, но попробуем. Нам в Хекслет нужен smm-менеджер (или как говорят контент-менеджер, smm-маркетолог), с опытом ведения каналов технической направленности и желанием в эту сторону развиваться. Если вы такой или у вас есть знакомые подходящие под вакансию, порекомендуйте позязя https://hh.ru/vacancy/108869389 (откликаться лучше там же)

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

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

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

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

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

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

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

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

Ссылки: Телеграм | Youtube | VK
Организованное программирование | Кирилл Мокевнин pinned «Выпуск про отличие бигтеха от небольших компаний и стартапов опубликован и доступен в видео и аудио версиях на всех платформах (ссылки описании к ролику) https://youtu.be/Lo4F8NMmkN0?si=8FJpN-Ymx1jj6P5S В этом выпуске мы с Евгением Козловым обсуждаем, как…»
3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте мы обсуждаем все от технических деталей организации своего подкаста до влияния на индустрию. https://www.youtube.com/watch?v=Lwgmz7qVXEM
Заблуждения относительно работы пагинации

Нашел на просторах сети список, хочу поделиться с вами:

1. Количество элементов на странице фиксировано навсегда.
2. Количество элементов на странице фиксировано для одного пользователя.
3. Количество элементов на странице фиксировано для одного набора результатов.
4. Страницы просматриваются только в одном направлении.
5. Ни один элемент не будет добавлен в набор результатов во время его извлечения.
6. Ни один элемент не будет удалён из набора результатов во время его извлечения.
7. Порядок сортировки элементов остаётся стабильным.
8. За один раз будет извлечена только одна страница результатов.
9. Страницы будут извлекаться по порядку.
10. Страницы будут извлекаться своевременно.

Ссылки: Телеграм | Youtube | VK
Организованное программирование | Кирилл Мокевнин pinned «3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте…»
Minimal Modeling - новый подход для проектирования баз данных

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

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

https://www.youtube.com/watch?v=vYYZy1EulUk
Организованное программирование | Кирилл Мокевнин pinned «Minimal Modeling - новый подход для проектирования баз данных В этом выпуске я поговорил о проектировании баз данных с Алексеем Махоткиным (он был техническим директором того самого Undev). У Леши богатейший опыт в работе с БД, который вылился в разработку…»
Поделитесь вашим путем по языкам программирования в коммерческой разработке. Начну с себя:

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

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

Мы обсуждаем, чем Clojure отличается от других языков, почему его философия минимализма и неизменяемости так важна для современной разработки, и какие задачи лучше всего решать с его помощью. Николай рассказывает о том, как этот язык помогает ему создавать лаконичный, надежный и масштабируемый код, который легко поддерживать. https://www.youtube.com/watch?v=7eJ3yUgbzSA
Организованное программирование | Кирилл Мокевнин pinned «Новый выпуск уже доступе для просмотра, в этот раз разбираем Clojure. В этом выпуске мы погружаемся в мир функционального программирования вместе с Николаем Рыжиковым — одним из ведущих специалистов по Clojure в России. Николай делится своим уникальным опытом…»
Последние месяцы канала

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

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

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

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

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

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

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

Ссылки: Телеграм | Youtube | VK
В этом выпуске мы с Андреем Ситником. обсудили будущее фронтент разработки и большой сдвиг в сторону баз данных на клиенте с автоматической синхронизацией вместо классических апи вызовов. Или короче, поговорили о движках синхронизации. Андрей рассказал про движение Local First, которое предлагает ряд принципов создания веб-приложений, одновременно решающих задачи владения данными и совместной работой. Благодаря движкам синхронизации, Local First приложения получают возможность работать офлайн и хранить свои данные там где нужно, не завязываясь на конкретный, обычно облачный, провайдер. Это позволяет строить более быстрые, безопасные и защищенные в плане владения данными приложения. https://www.youtube.com/watch?v=-57r5AARRgY
Пошли первые ласточки по нашему видео продакшену, зацените: https://www.youtube.com/shorts/sLU4az5m_zg Как вам? Постить я сюда их не буду, потому что по плану мы будем делать 10-20 шорстов в месяц. Кстати, там на видео я как будто смотрю в камеру, на самом деле это обработка.
Профессиональное развитие. Нам это не задавали

Чья ответственность заниматься своим развитием? Компании или человека? Многие ответят “конечно человека” и будут правы. Да компания может этому способствовать, но может и не способствовать, однако это не может и не должно нас останавливать.

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

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

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

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

Ссылки: Телеграм | Youtube | VK
В этом выпуске мы поговорили с Андреем Апанасиком о современном геймдеве, его вызовах и трендах. Обсудили, почему разработчики всё чаще выбирают готовые игровые движки вроде Unreal Engine и Unity вместо создания собственных решений. Андрей поделился своим опытом разработки игр, рассказал о том, как меняются подходы к созданию геймплея и почему маркетинг стал ключевым элементом успеха в игровой индустрии.
https://youtu.be/ZBgRe8FOvx0