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

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

Выпуск про отличие бигтеха от небольших компаний и стартапов опубликован и доступен в видео и аудио версиях на всех платформах (ссылки описании к ролику) 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