Ребят я провожу опрос на тему карьерного и профессионального роста. Пройдите пожалуйста небольшую анкету, если вы думаете качаться или уже качаетесь. Это сильно повлияет на канал и активности, которые будут проводиться. А они будут, тут в закромах я работаю над запуском клуба, но пока это секрет (хехе). Кликать сюда -> https://forms.gle/x3anpqUnwLGRy4336

Если кто-то из вас готов со мной на часовое интервью (касдев), то отметьте там внутри галочку. Я планирую поговорить с 10 людьми, кому интересен рост и прямо на созвоне проконсультирую, дав по мере возможности рекомендации для вашей ситуации.

Буквально на днях мы провели опрос о карьере и уже прилетело больше 200 ответов. Я закинул их в chatgpt чтобы собрать какие-то общие выводы. Они мне показались интересными, поэтому я решил поделиться с вами.

Возраст участников и опыт:
• Участники имеют широкий возрастной диапазон: от 18 до 45+ лет. Это свидетельствует о том, что в сфере IT присутствуют как молодые специалисты, только начинающие свою карьеру, так и опытные профессионалы.
• Большинство людей уже работают в IT, с началом карьеры от 2000-х до 2020-х годов, что указывает на участие как новичков, так и тех, кто работает в индустрии уже более 20 лет.

Грейд и текущие роли:
• Преобладают участники уровня middle и senior, что говорит о высоком уровне экспертизы. Однако, есть и джуниоры, и даже стажеры, что подчеркивает разнообразие опыта.
• Ряд участников занимают позиции лидов (team lead, tech lead), а также руководящие роли, что свидетельствует о высоком уровне ответственности и лидерства.

Стек технологий:
• Наиболее часто встречающиеся технологии: JavaScript (включая React, Vue), Python, Go и PHP.
• Многие специалисты работают с бекендом и фуллстеком, что отражает текущие тенденции в IT, где важна гибкость и умение работать на разных уровнях стеков.

Навыки и развитие:
• Значительная часть респондентов указывает на необходимость прокачки Hard Skills (жесткие навыки), что говорит о приоритете технических компетенций для карьерного роста.
• Soft Skills также упоминаются, особенно среди тех, кто уже занимает лидирующие позиции или хочет развиваться в менеджменте.

Карьерные планы:
• Многие специалисты стремятся к повышению грейда, особенно те, кто уже находится на позиции Middle или Senior.
• Около трети участников опроса хотят расти в своей текущей компании.
• Некоторые рассматривают возможность перехода в более крупные компании или компании мечты, такие как FAANG (Facebook, Apple, Amazon, Netflix, Google), или крупные международные компании.
• Некоторые рассматривают собственный бизнес или стартап в качестве долгосрочной цели.

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

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

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

p.s. У вас совпадает?

На канале появился новый выпуск: “SOLID принципы в 2024: Полный разбор и прожарка”, который мы записали вместе с S0ER. Этот выпуск особенный, потому что здесь мы разбираем принципы играя в адвоката дьявола. Я объясняю почему они не нужны, а Женя наоборот https://www.youtube.com/watch?v=qHh_B97OjEY

Рубрика: текстовый собес. Я задаю пять вопросов, вы отвечаете в комментариях :) Поехали =>

1. Достаточно ли валидации в ORM при реализации проверки на уникальность, например, email при регистрации? Раскройте
2. Какие последствия возможны при отправке email прямо в контроллере? Как можно решить эти проблемы?
3. Как бы вы реализовали смену email на сайте, так чтобы соблюсти баланс между сложностью и безопасностью?
4. Можно ли доверять email, который мы получаем по oauth от соц сетей и мержить аккаунты автоматически? Приведите примеры
5. Как ограничить отправку email пользователю, который добавил письмо нашего проекта в спам? И почему это стоит делать (или не стоит)?

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

Новый выпуск подкаста уже доступен для прослушивания. https://www.youtube.com/watch?v=1XAbFkMaWxw Здесь мы вместе с Валентином Удальцовым, автором канала Пых, обсуждаем PHP. Поговорим про весь путь его развития — от старых подходов до новых тенденций, PHP-комьюнити и контрибьютах в версии PHP.

Написал пост про управление паролями и доступами в компании. Полезно тем, у кого нет выделенных безопасников. Больше как инструкция для своих, но может быть полезно и другим: https://vc.ru/life/1568530

Давно была идея запустить ботов для проектов Хекслета, но не доходили руки. А тут мы двинулись в сторону создания закрытых сообществ и сопровождения процесса обучения в телеге. Поэтому как-то само пришло.

Сначала я долго искал сервис, который умеет не только стандартные вещи типа цепочек, триггеров и разнообразных диалогов, но и управление закрытыми сообществами с подпиской на них. В итоге нашел не очень известных ребят, но с обалденной функциональностью: winwinbot.ru. Мне понадобилось где-то пару дней плотно потыкать ботов, чтобы примерно понять принципы организации диалогов и организацию реакции на разные действия. Дальше уже пошло легко.

Суммарно у нас будет под десяток ботов, про которые я еще расскажу, например, через такой бот мы хотим сделать онбординг сотрудников Хекслета. На текущий момент из них запущены три: Хекслет.Карьера - это наш новый продукт, который мы пока обкатываем на студентах, а потом откроем наружу. Хекслет.Наставники - через этого бота управляем наставниками и закрытой группой для них в телеге (переехали из матермоста). По плану в этом боте будет много всякого, включая курсы обучения наставничеству (можно делать прямо в боте). И бот, который я настраивал последние дни и сегодня запустил https://t.me/HexletLearningBot (@HexletLearningBot).

Сейчас этот бот знакомит с проектами Хекслета и дает удобный доступ (меню) к ним (группы, каналы, сообщества, курсы и т.п.). В будущем он будет сопровождать прямо по обучению на Хекслете. Собственно потыкайте) Как вам?

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

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

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

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

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

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

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

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

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

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

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

Как управлять текстами в проектах и при чем тут 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. А как вы работаете с текстами в своих проектах?

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

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

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

Семантический 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 в основном приходят люди из совсем других областей типа бьюти. Они часто классные спецы, но в нашем деле важно иметь связь с разработкой, таких людей мало.