Многих IT-руководителей ценят за их инженерный опыт: зачастую до менеджерской позиции они занимались разработкой и были техлидами в командах. Но, к сожалению, с течением времени любой специалист, не программирующий ежедневно, будет терять уровень экспертизы. Предлагаю ряд способов, которые помогут уменьшить деградацию технических навыков и позволят на практике осваивать новые тренды в IT-отрасли.
Привет, меня зовут Андрей Осягин, я Product Owner в Домклике и отвечаю за продукт «Кабинет участника сделки». Он нужен для подготовки к ипотечной сделке с момента первичного одобрения заявки и до самой выдачи кредита. MAU Домклик сейчас превышает 16 млн пользователей.
Я расскажу вам, как мы реализовали проект «Истории»: опишу вдохновение, разочарования, запуск и метрики, и отвечу на вопрос — должны ли истории умереть. Эта информация может пригодится тем, кто планирует запускать такой или похожий проект в своём продукте, или думает о том, как решить похожие задачи.
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Как вы помните из предыдущих частей (1, 2, 3), у нас уже есть функциональность для работы с планировщиком в бэкенде. Теперь нашей задачей будет создать удобный и интуитивно понятный пользовательский интерфейс, чтобы пользователи могли легко взаимодействовать с задачами.
Приветствую всех читателей, меня зовут Вадим, я — бэкенд-разработчик в компании Домклик. В этой статье я хотел бы поделиться своим интересным опытом мажорного повышения зависимостей в проекте, который свыше пяти лет находится в проде под ежедневной нагрузкой более 2000 RPS. Мне пришлось обновить наш основной фреймворк сразу на несколько мажорных версий. Приглашаю прочесть как именно и зачем я это делал!
Привет, меня зовут Денис, я руковожу направлением разработки в Домклике. Дополнительно несу ношу лидера frontend-направления в нашей компании. Не так давно я отрефакторил систему собеседований для frontend-разработчиков, попутно тестируя технические вопросы на внешних и внутренних респондентах. И пришёл к выводу, что множество мной опрошенных разработчиков, вне зависимости от уровня, не знают или просто не обращают внимание на базовые правила при работе с картинками. В результате на просторах интернета зачастую можно найти изображения размером 200 на 200 пикселей и весом в несколько мегабайтов со смещением макета, столь раздражающим пользователей. Если вам интересно, как практически без вложений улучшить пользовательский опыт, то прошу под кат.
Древняя мудрость гласит: «Театр начинается с вешалки, а путь к должности дизайн‑директора — с первого шага». Но что ещё нужно сделать? Как превратить свою мечту в реальность и не сбиться с пути? С вами Артём Литвин, дизайн-лид в Домклик. Сегодня я расскажу вам, как мы помогаем развиваться и расти в должности нашим дизайнерам.
Я собрал эту статью в виде экспериментальной театральной постановки в трёх актах. В течение первого акта мы познакомимся с героями — сотрудниками продуктовой компании: и узнаем их проблемы и потребности. Во втором акте мы создадим систему роста для продуктовых дизайнеров. Ну а в третьем акте займёмся её внедрением.
Итак, давайте начинать!
Jobs to Be Done дает хорошую базу, но в полной мере не покрывает детали для проектирования интерфейсов. Расскажу, как я адаптировал подход для разработки цифровых продуктов, используя Desired Outcomes. С ними становится понятнее, что делать в продукте, они дают ответ на вопрос "чтобы что", и генерация идей перестает быть изнуряющим процессом.
Привет! Я Маргарита Романова, дизайнер в Домклике. Расскажу о принципах разработки внутренних CRM и о том, почему их дизайн отличается от B2C и даже B2B. Статья для тех, кто тоже делает внутренние CRM или планирует скоро этим заняться.
Всем привет. Меня зовут Игорь, я Tech Lead команды DevOps-инженеров и активно развиваю направления мониторинга в компании. В продолжение статьи своего коллеги по цеху @EvgenNet хочу познакомить вас с шаблоном для Zabbix и дашбордом в Grafana для визуализации активности пользователей OpenVPN. Возьмите вкусняшек, чайку и присаживайтесь поудобнее.
Всем привет! В предыдущей части цикла статей мы поговорили о том, зачем вообще нужно функциональное программирование, а также обсудили понятие классов типов и разобрали базовые из них: Eq (эквивалентность) и Ord (сравнимость).
Сейчас я хочу пролить свет на два наводящих жуть на неподготовленного читателя слова: моноиды и полугруппы. Это математические понятия родом из общей алгебры. На самом деле всё не так уж и страшно. Если совсем упрощать, то оба термина относятся к объединению элементов множества. Я помогу разобраться с их формальными определениями, а также на практических примерах покажу, как и зачем их использовать.
Приветствую! Меня зовут Евгений, я DevOps в команде развития инфраструктуры. Мои прошлые статьи были посвящены протоколу BGP, но в этот раз я приготовил нечто поинтереснее. В прошлом году мне захотелось расширить своё портфолио навыков в сторону автоматизации задач. Не последнюю роль в этом желании сыграла книга «Автоматизация программируемых сетей», выпущенная известным в IT-кругах издательским домом O'Reilly. В ней примеры скриптов написаны на Python. Позже я в учебном центре прошёл курс повышения квалификации по программе «Python для сетевых инженеров. Автоматизация сетевых задач», а затем продолжил самостоятельно постигать это искусство. Недавно подвернулась интересная задача, о решении которой при помощи Python я вам сегодня и расскажу. Усаживаетесь поудобнее, мы отправляемся.
Всем привет! Меня зовут Анастасия Щедрина, я технический лидер по фронтенду проекта размещения объявлений в компании Домклик. Сегодня я расскажу вам немного о том, как устроены правила в ESLint, и покажу на примере, как можно разработать собственные.
Статья будет полезна тем, кто уже задумался о создании своих правил, а также тем, кто использует линтер, но не знает, как он устроен и как подключённые правила обрабатывают наш код.
Меня зовут Станислав Тюленев, я главный инженер по разработке в одной из продуктовых команд Домклик. В статье я расскажу о том, как, будучи новичком в команде, не бояться говорить о своих проблемах или идеях, и при чëм тут «технический совет».
По мере того, как ваше приложение растёт и развивается, растут и затраты времени на его тестирование и сборку, достигая нескольких минут при пересборке в dev-режиме и, возможно, десятков минут при «холодной» production-сборке. Что, конечно, совершенно неприемлемо. И если поначалу увеличение временных затрат может казаться незначительным, то впоследствии это непременно ведёт к ухудшению процесса разработки и может негативно повлиять на скорость выкатки важных релизов или хотфиксов. Таким образом, в какой-то момент вопрос оптимизации и ускорения сборки приложения может стать критически важным для разработчика.
Меня зовут Иван Кесель, я CPO в Домклик, лидер нескольких команд. Давайте поговорим про disrupt. Во-первых, разберёмся, что это за англицизм. Во-вторых, на примере из практики Домклика я покажу, как мы запускаем disrupt-решения. И в-третьих, дам вам десять подробных практических советов, которые нам помогают.
Заявление звучит довольно громко и, я бы даже сказал, провокационно. Но в последние годы я всё больше и больше считаю, что это утверждение действительно верно, и хочу подробно объяснить, почему.
В ходе исследования непонятного бага с битой кодировкой в именах загружаемых файлов мы столкнулись с непредвиденным поведением популярной библиотеки aiohttp. Решая эту проблему, мы получили полезный опыт, которым хочу с вами поделиться.
Создаётся впечатление, что программные инженеры получают свои звания произвольным образом. С самого начала, как вы начинаете работать, вы мечтаете о звании сеньора. Многие, особенно не стремящиеся руководить или основать стартап, считают это вершиной успеха. Но как получают это звание? Если что-то нельзя измерить, отследить или объективно оценить, значит, мы это просто придумываем. Соглашусь, что это немного эфемерно, но всё же не произвольно. Я в этой отрасли 11 лет, поработал с инженерами всех уровней, и скажу вам вот что: ваш уровень специалиста — это разница между вашими знаниями и опытом.
Что такое монада? Душнила ответит: “Это моноид в категории эндофункторов”, и будет абсолютно прав. Вопросов появляется ещё больше: “Что такое моноид?”, “Что такое категория?”, “Что такое эндофунктор?”. В эту же секунду человека сковывает первородный ужас, сошедший со страниц рассказов Г. Ф. Лавкрафта, инстинкт самосохранения кричит: “Беги!” Интересный собеседник, обладающий эмпатией, приобнимет и скажет: “Бро, это же просто контейнер для какого-то значения, способный соединяться в цепочки таких же контейнеров. Ты же пишешь фронтенд? Или бэк на ноде? В холодильнике пиво, угощайся, а я тебе расскажу про библиотеку fp-ts и разные клёвые штуки из функционального программирования.
Для js-а существуют тонны библиотек, поддерживающих функциональный стиль программирования. Lodash, Ramda, Sanctuary — это то что сразу приходит в голову. В эпоху Typescript писать без типобезопасности уже моветон. Ни Lodash, ни Ramda типобезопасность не обещают, Sanctuary проверяет типы в рантайме, что требует дополнительных накладных расходов. Fp-ts изначально написан на typescript и помимо фич функционального программирования предлагает изящную проверку типов. Эта интересная библиотека реализует множество концепций из статически типизированных функциональных языков семейства ML, таких так Haskell, Ocaml и Scala. В fp-ts всё прекрасно, кроме документации и практических примеров использования. Моя задача как раз подсветить эти тёмные углы, а также показать несколько практических примеров.
В статье я не буду обсуждать базовые концепции ФП, такие как чистые функции, лямбды, композиция и прочее. Про это написано много статей и ютуб завален тоннами видеороликов от индиан гаев. Здесь я постараюсь простыми словами на практических примерах объяснить классы типов, какие они бывают и как их использовать в fp-ts.
Во многих компаниях задумываются о внедрении больших больших языковых моделей для векторизации и в качестве классификатора. Однако здесь есть несколько моментов, которые обычно отпугивают. Во-первых, непрогнозируемость улучшения результатов по сравнению с уже имеющимися решениями. Во-вторых, сложности по внедрению этих моделей в промышленную среду. Мы постарались раскрыть весь путь от идеи до ввода в эксплуатацию, описали проблемы, с которыми столкнулись, и их решение.