Можно ли называть синьорами разработчиков с большим опытом, которые

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


Что вы об этом думаете? Палец ввер можем, палец вниз не можем

На следующей неделе уезжаю в небольшой отпуск, у нас тут день благодарения, редкий случай когда есть возможность вырваться, так как нет школы у детей. Писать врядли получится, но чтобы вам не было скучно, рекомендую почитать мою серию постов "совершенный код", в которых рассказываются неустаревающие вещи про разнообразные технические решения, которые стоит выбирать или на что стоит ориентироваться при их выборе: https://ru.hexlet.io/u/mokevnin/blog_posts Всем чмоки

Как мы нанимаем

Некоторое время назад мы начали собеседовать мидлового rails-программиста в Хекслет и когда я об этом написал, то люди начали спрашивать, а как мы собственно собеседуем. Рассказываю 🙂

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

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

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

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

Для части вакансий в этот процесс встраивается тестовое задание. Где-то оно идет до общения с руководителем направления (но после разговора с рекрутером), где-то после.

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

В целом, когда все это выстроено, то весь процесс занимает в районе недели (без тестового). Кстати весь этот процесс делается в талантиксе.

p.s. А как построено у вас? Вам нравится ваш процесс найма?

На той неделе в штатах бомбанула такая история https://twitter.com/GergelyOrosz/status/1729268790033306105 про фейковых докладчиков девушек на конфе. Я не любитель обсуждать такие штуки, но меня кое что зацепило. На эту историю среагировал дядя боб (роберт мартин), который в рунете считается полубогом и дальше понеслось. Прочитайте этот тред в твиттере, чтобы просто быть в курсе происходящего и составить свое мнение.

Как мы собеседуем программистов
В основном мы нанимаем разработчиков на rails которые либо уже фулстек либо с потенциалом на фулстек. Но есть важная особенность. Я никогда не был сторонником брать людей, которые работали именно на том стеке, который мне нужен. Установка была всегда нанимать хороших ребят с любых смежных стеков. Например на нашу позицию отлично подходят те кто работали с бекенд фреймворками типа laravel, django, spring boot и другими, но не микрофреймворками. Наши самые успешные кейсы и ребята как раз были такими свитчерами. Эта особенность сильно влияет на само собеседование. Оно делится на три основные части.

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

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

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

p.s. Домашнее задание: напишите в комментарии как бы вы решили эту задачу в вашем стеке

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

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

⁃ Веб программирование (django и вот это все)
⁃ Аналитика
⁃ Администрирование
⁃ Какой-то скриптинг, здесь все остальное

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

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

p.s. А что у вас было во время обучения в школе и универе?

Вакансии пост. Если вы или ваши друзья разрабатывают на rails/spring boot/asp.net/django/laravel/symfony/любой другой бек фреймворк, в течении года-двух, то мы бы с удовольствием поговорили https://hh.ru/vacancy/88545320 вакансия немного заточена под rails, но на практике мы ищем не только рельсовика (чаще мы даже переучиваем).

Задачи которые мы решаем в ближайшие месяцы:

- выпиливаем страйп и переходим на клаудпейментс для зарубежных карт
- перерабатываем механику проверки проектов наставниками и менторами (довольно большая штука)
- вводим наставников для b2b, у них там своя атмосфера и нужны возможности похожие на групповое обучение хекслета
- готовим хекслет к запуску в латинской америке (тут все включая переводы, события, интеграция систем)
- интегрируем chatgpt в процесс обучения, чтобы он подсказывал по коду и по урокам
- еще 150 тикетов в беклоге, до которых не добрались :)

Чему у нас можно научиться:

- У нас офигенный код и культура разработки. Линтеры, тесты все как полагается. Прагматично, без "покрытие 90%", без юнитов на каждый чих и так далее. Все само собирается на ci, деплоится всеми по тегу в куб. В докер тоже само сворачивается. Весь набор тестов пробегает минут за 5. В продакшен катим по 5 раз в день

- По проекту это сотни тысяч строк кода, около 300 моделей, десяток подпроектов, десятки серверов, много автоматизаций вокруг (сборка и запуск практик), тысячи репозиториев, образов, много сторонних сервисов. Все это обслуживается командой из 3 фултайм кор девелоперов

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

- Все разработчики хекслета в процессе учатся и могут во фронт (реакт) в ops (ansible, куб, докер, терраформ, облака, мониторинг, алертинг)

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

- У нас фронт внедрен как виджеты, это значит что нет всяких сложных схем аля отдельный фронт отдельное апи и надо все дружить. У нас классический рендеринг на беке с шаблонизатором haml/slim. Мы юзаем бутстрап без кастома и всегда легко под него подстариваемся. Экономим кучу времени и не отвлекаемся на верстку (кроме всяких маркетинговых штук, но для этого есть свои люди). Каждый человек делает задачу от начала и до конца и ни от кого не зависит почти всегда. От идеи до выкатил проходит очень мало времени.

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

- Меня отстранили от разработки и больше в код не пускают :D

Что значит фраза программиста: “задача готова” ?
В зависимости от компании, готовность задачи может определяться как:

⁃ Подготовил пулреквест
⁃ Передал тестировщикам
⁃ Влил в основную ветку
⁃ Выкатил на продакшен

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

Первое я начал интересоваться процессами, познакомился с канбаном, дао тойоты, теорией ограничений и так далее. Тогда стало понятно, что задача которую сделали, но не отгрузили (выкатили в прод), это проблема, так как пока задача висит, ситуация может поменяться и код придется допиливать. Программист в это время уже занят другим и возвращаться обратно ему будет сложно, плюс потраченное время на вспомнить контекст. Остальные же просто не учитывают сделанные изменения в своей работе и при слиянии мы можем получить серьезные конфликты.

Второе, у меня появился собственный бизнес и я увидел что любая задача, которая “сделана”, но ей никто не пользуется, на самом деле является пустой тратой денег. Не важно что она лежит в ветке, важно что это не приносит никакой пользы бизнесу. Особенно это бьет по задачам, которые в итоге зависают на выходные или, что еще хуже, на праздники. Представьте что мы сделали важное изменение перед новогодними, но не задеплоили. Получается что 10 дней потеряны у нас ни аналитики, ни эффекта.

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

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

p.s. А что значит “задача готова” в вашем проекте и хорошо ли это работает?

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

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

Из недавнего опыта. Я искал для проектов Хекслета фронтенд систему, которая позволяет генерировать интерфейсы из готовых элементов в коде, чтобы не тратить время на ручное их написание там, где нам это не нужно. Например нам такое нужно во всех проектах, где делается бекенд, а фронтенд предоставляем мы сами. После изучения вопроса стало понятно что есть два основных решения: https://refine.dev/ и https://marmelab.com/react-admin/ Если посмотреть их документацию, то видно что первое решение более гибкое и например позволяет менять внешний вид так как работает с разными css-фреймворками. Но если посмотреть на код, эта гибкость дается дорого, количество кода, которое надо писать в refine, значительно больше чем в react-admin, где из коробки material который не поменяешь, но зато весь css скрыт на 100%. В итоге я выбрал react-admin, а реализация того что нам нужно составила около 100 строк кода (несколько крудов, аутентификация, связь с бекендом).

Все тоже самое проявляется и на более низком уровне:

⁃ Отсутствие внедрения зависимостей VS внедрение зависимостей (усложняет систему очень сильно)
⁃ Работа с конфигами из файлов VS универсальная штука загрузки конфигов
⁃ Модель с фиксированными полями VS модель с динамическим набором полей
⁃ Active Records VS Data Mapper
⁃ Работа с одной базой данных VS Поддержка любых баз данных (особенно если NoSQL смешивается с SQL)

Все это не значит что гибкость не нужна, но нужно правильно оценивать эту гибкость. Часто она дается настолько дорого, что лучше все же не обобщать. Хорошим примером может служить Java и Spring Boot где все сильно обобщено, есть множество интерфейсов на все случаи жизни, которые все реализуют. Огромная куча абстракций, которую не так то просто выучить. Зато все можно подменить и в теории это работает. С другой стороны находятся фреймворки динамических языков типа Django, Ruby On Rails, Laravel, где шли другим путем, давали готовые решения, которые не такие гибкие, но зато очень простые, легкие в изучении и использовании.

p.s. Какая концепция вам ближе? Spring Boot или Django/Rails/Laravel?

Как нас шантажирует человек, пересмотревший пацанов
> это слито с вашего дырявого сайта...Во шухер будет...удачи чушпаны!!!)))

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

Как обычно все происходит в случае, если человек нашел серьезную дыру в безопасности на сайте? У многих компаний есть вполне стандартная процедура, которую знают те кто находят такие ошибки. Человек, который нашел баг, пишет о том что у вас мол такой баг и показывает доказательства его присутствия. Обычно, человек уточняет есть ли у компании баг-баунти программа и если есть то сначала договаривается о сумме выплат, затем рассказывает про баг и получает деньги. Компания после этого чинить баг и в идеале меняет внутренние процессы так чтобы подобные баги не воспроизводились.

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

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

Мы принимаем разные меры (но я не расскажу какие потому что он скорее всего меня читает lol), чтобы разрулить эту ситуацию правильно. Но при этом хочется сказать несколько важных вещей. 2fa штука важная, будем внедрять. Надо во все курсы встраивать урок про безопасность паролей)

Как мы реализовали подписку на Хекслете

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

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

Концепция была в следующем, что с точки зрения платформы, должно быть не важно каким образом у человека появился доступ. Это может быть купон, страйп, доступ для друга, подарок, оплата через компанию и еще тысяча разных способов. Внутри платформы все это сводится к единому признаку “имеет доступ?”. Для этого мы придумали систему с днями доступа. Специальная таблица, в которую заносится любой доступ в виде дней. Например купил подписку на месяц (снялись деньги), получил 30 дней доступа (в зависимости от месяца). Дали купон на 10 дней, после активации туда заносится эта информация. С другой стороны, каждый день запускается скрипт, который списывает эти дни по одному. Фактически у нас получился аналог книги доходов/расходов в бухгалтерии.

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

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

Как-то раз я общался с Андреем Ребровым, который является СТО компании scentbird.com мы обсуждали с ним биллинг. Оказалось что они реализовали такую же схему, только у них были не дни, а недели или месяцы, сейчас уже не помню.

p.s. В ваших проектах есть подписки? Как они реализованы?

Почему плохой код? Потому что мы стартап

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

Если мы говорим про создание типовых веб-проектов, то у нас все достаточно просто. Современные фреймворки и их экосистема, позволяют без особых затрат и сложностей реализовывать проекты достаточно приличных размеров. Что для этого нужно? Модели, контроллеры и вьюхи/фронтенд, по большому счету все. Какой-то серьезной архитектуры тут еще нет, все сводится к тому что надо тратить немного времени на продумывании сущностей и их связей, это главная задача. А дальше как-то мы все это обрабатываем в контроллерах, выводим во вьюхах или отдаем по api. То насколько код здесь чистый не принципиально, а принципиальны две вещи:

⁃ Сущности и их связи. Фактически тут мы говорим о перекладывании модели предметной области на код. Здесь нужно немного думать вперед.
⁃ Структура API. Важно не облажаться с форматом, чтобы потом не пришлось переделывать. Менять публичное апи это еще та попаболь.
⁃ Идеально еще интеграционное тестирование, которое полезно даже в стартапах, так как не сильно зависит от внутренностей (об этом были свои посты)

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

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

⁃ Сразу включаем микросервисы. Хаха, мое любимое. Будет отдельный пост
⁃ Забиваем на возможности фреймворков и пилим все сами. Вплоть до игнорирования ORM
⁃ Плохое знание экосистемы. Как ни странно даже среди вроде бы синьоров такое встречается. Пилят то, что уже напилено в виде библиотек. А иногда это “у нас не должно быть зависимостей” и дальше пилим все сами
⁃ Непонимание концепции автоматов и моделирования процессов на их базе. Бывает такое что интуитивно делают правильно, но часто делают не правильно
⁃ Использование необкатанных и не популярных инструментов, где еще как не в стартапе воткнуть светл?
⁃ Какие-то установки типа: 100% покрытие, на любой чих юнит-тест, вся логика в моделях, юзаем graphql, вводим три слоя абстракций, используем ddd, без паттернов жизнь не жизнь, внедряем event source и так далее.

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

p.s. По каким причинам в ваших проектах плохой код?)

Ни единой идеи как так получилось

Через полчаса стартую новогодний стрим, где покажу все что скрыто. Новости Хекслета, как прошел год, что будет в следующем. Немного про канал, немного про программирование, отвечу на вопросы и вот это все https://www.youtube.com/watch?v=RgZ-YsDuibc

Итоги 2023 года
В этом году встречаемся последний раз, поэтому можно немного подвести итогов. За шесть месяцев я нафигачил 68 постов (ничо си) и вас, мои дорогие, стало 3500 человек. Учитывая что все это происходит в свободное время без каких-то вложений, то результат достаточно хороший, но пока еще никто не пришел с предложением продавать рекламу. Делать я этого не буду, но все равно обидно :D

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

В конечном итоге, моя цель не в том чтобы просто выговориться, а в том, чтобы вы открывали для себя что-то новое, что влияло бы на ваше представление о программировании и внедрялось в ваши проекты. Я знаю что это иногда происходит, даже когда под постами разгорается много споров)

Всем спасибо за доверие! С наступающим! Я не планирую уходить на выходные, буду писать и дальше. Уже есть план на два десятка статей. Накидывайте своих тем, я буду их добавлять в список.

p.s. Если у вас есть свой канал на любой площадке, сбросьте ссылку на него в комментах с описанием. Давайте посмотрим кто у нас тут собрался)

Если бы я делал веб-проект с нуля

Меня регулярно спрашивают, на каких технологиях я бы делал проект если бы пришлось делать его с нуля. И у меня есть ответ на это. Он не универсальный, есть совершенно разные проекты, но так как нельзя охватить сразу все, я опишу некий средний проект, в котором есть веб-морда с большим количеством логики, скорее это какое-то SaaS-решение.

Базовым стеком я бы назвал:

Ruby On Rails, React, React Native

Дальше по приоритетам:

⁃ Система будет очень сложной с большим количеством программистов сразу? Spring Boot
⁃ Нужно много бекендовой тяжелой обработки? Go или Java
⁃ Нет экспертизы в руби? Берем Laravel или Django
⁃ Нужны нативные мобильные приложения? Тут все понятно: Swift и Kotlin
⁃ Нужен реалтайм на фронте (а значит асинхронный бекенд)? Node.js, Go
⁃ Нужно e2e тестирование? Playwright

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

p.s. На чем бы вы сделали проект с нуля?

Хранение деревьев в базе: Материализованный путь

Обычно, для хранения деревьев в базе в таблицу добавляется поле parent_id. Это дубовое решение, которое работает хорошо в небольшом количестве ситуаций. Кому-то даже может хватить, но есть запросы, на которых такая схема не работает. Например если нам понадобится извлечь ветку этого дерева. В таком случае понадобится рекурсивно выполнять запрос с parent_id где для каждого нового запроса parent_id становится id записи из предыдущего запроса. Кто-то пытается решать эту задачу прямо в коде, создавая очень не эффективное решение, кто-то с помощью возможностей базы данных, что сильно привязывает к ней, плюс, страдает интеграция с ORM.

Однако, есть решение лучше. Кое-кто слышал про nested set и это действительно решение, но очень громоздкое, тяжелое в реализации и понимании. Поэтому тут мы его даже не будем рассматривать, так как есть по настоящему элегантное решение, которое называется materialized path.

Идея в Materialized path заключается в том, что каждый узел (каждая запись в базе) хранит полный путь до корня. То есть вместо parent_id, мы добавляем path, который выглядит, например, так: 1/2/5/8/99/3. / - часто используется как разделитель, но можно выбрать и другой. 1 - в примере это корень под который попадает текущая запись, 3 это прямой родитель. Все что между это промежуточные родительские записи.

Этим подходом мы сразу решили проблему выборку всей нужной ветки. Все что нам надо будет сделать это в коде разделить 1/2/5/8/99/3 на идентификаторы, и сделать один in запрос IN (1, 2, 5, 8, 99, 3)

При такой структуре, для выборки всех потомков понадобится такой запрос:

SELECT * FROM <name> WHERE path LIKE '1/2/%';

Для выборки детей:

SELECT * FROM <name> WHERE path LIKE '1/2';

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

habr.com/en/articles/46659/

Как мы экономим на фронтенде используя виджеты

Хекслет фронтенда реализован в виде виджетов. Что это значит? Изначально сам проект представляет собой классический MVC (model2), в котором View это обычные серверные шаблоны, в нашем случае на haml.

.table-responsive
  %table.table.table-striped
    %thead
      %tr
        %th= sort_link(@search, :id)
        %th= sort_link(@search, :email)
    %tbody
      - @users.each do |user|
        %tr
          %td= user.id
          %td= user.email

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

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

- append_javascript_packs 'community'
- append_stylesheet_packs 'community'

Эти файлы готовит webpack на базе entrypoints. Каждый entrypoint это свой виджет. Внутри уже идет подключение реакта, стилей и всего что там нужно (с точки зрения перфоманса вебпак выделяет общие чанки, которые подключаются один раз для всех).

import app from '../community/index.jsx';

import './community.scss';

const communityBoxId = 'community-box';

app.init(communityBoxId, /* параметры */);

В итоге у нас несколько десятков подобных виджетов, которые подключаются в разных местах, для решения локальных задач. Из общего кода у этих виджетов только библиотеки. Все остальное свое. Размер виджетов от десятков строк кода до 5 тысяч.

Такой подход позволяет оставаться в рамках классической серверной шаблонизации и при этом по необходимости внедрят интерактивные элементы на нужных страницах или на сквозь (как нотификации).

Заблуждения программистов относительно времени

Кто работал со временем в коде, тот в цирке не смеется. Вот вам подборка заблуждений насчет времени, которые гуляют среди программистов:

1. В месяцах бывает 28, 29, 30 или 31 день.
2. В одно и то же время используется только одна календарная система.
3. Переход на летнее время происходит в одно и то же время каждый год.
4. Переход на летнее время происходит в одно и то же время в каждом часовом поясе.
5. Переход на летнее время всегда корректируется на час.
6. В одном и том же месяце везде одинаковое количество дней!
7. Время Unix - это количество секунд, прошедших с 1 января 1970 года.
8. День перед субботой всегда пятница.
9. Если создать два объекта даты рядом друг с другом, они будут представлять одно и то же время. (фантастический генератор Heisenbug)
10. Недели начинаются в понедельник.
11. Дни начинаются утром.
12. Выходные состоят из субботы и воскресенья.
13. В каждой минуте 60 секунд.
14. GMT и UTC - это один и тот же часовой пояс.
15. Время всегда идет вперед.
16. 24:12:34 - недействительное время.
17. Часовые пояса всегда отличаются на целый час
18. Двузначные годы должны быть где-то в диапазоне 1900-2099
19. Существует только 24 часовых пояса
20. Часовые пояса всегда на целые часы удалены от UTC
21. В году 365 или 366 дней.
22. Високосные годы случаются каждые 4 года.

p.s. оригинал поста https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time Там 79 пунктов

Синхронные VS Асинхронные дейли

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

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

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

• Асинхронный дейли напрягает намного меньше 🙂
• Не нужен процессник, который ведет дейли и следит за тем как он проходит. Достаточно руководителя, который может поправить формат дейли, если кто-то пишет не в том формате, который требуется.
• Больше никаких завязок друг на друга, начал работать - заполнил дейли. Никто никого не ждет, никто не пропускает (если не отсутствует), никто не тратит время на то что ему не интересно.
• Асинхронный дейли в слаке внезапно оказался удобен тогда, когда нужно что-то уточнить или поправить человека. Любой человек в команде может зайти в тред к посту и что-то уточнить и синхронизировать свою работу. Плюс это видят остальные, что делает процесс прозрачным.
• Асинхронный текстовый дейли сохраняется, можно примерно понимать что происходит у человека или происходило не только в конкретный день но и в динамике.

В итоге перешли и остались довольны. Пример того как это работает можно посмотреть тут https://geekbot.com/

p.s. Какой дейли у вас в компании? Это эффективно иль нет?