Что такое CodeBasics

Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:

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

Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).

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

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

Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)

В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.

Альтернативные площадки: ВК Видео | Подкаст

https://youtu.be/BsNgohFW6rM

Про менеджеры версий

Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: nvm, gvm, rvm, rbenv и так далее. Десятки их. В общем задолбаешься если постоянно надо между языками переключаться. Поэтому кто-то догадался написать универсальный менеджер.

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

Начать можно отсюда: https://asdf-vm.com/guide/getting-started.html

// Вариант установки для brew

// Ставим asdf и зависимости
brew install asdf

// Ставим плагин для ноды
asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
// И его зависимости
brew install gpg gawk

// Устанавливаем последнюю версию nodejs и делаем ее доступной глобально
asdf global nodejs latest

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

p.s. А какой менеджер версий используете вы?

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

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

https://www.youtube.com/watch?v=bKyxOaP-mDg

Альтернативные площадки ВК Видео | Аудио

Идеальное решение

Поделюсь техникой, которой я пользуюсь при решении разных технических и не только задач. Она помогает лучше проектировать и фокусироваться на смыслах, там где легко свернуть не туда из-за существующих ограничений. Что здесь имеется ввиду?

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

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

* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно

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

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

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

Кто-то скажет, Кирилл погоди, это же из ТРИЗ и будет прав. Там это называется Идеальный Конечный Результат (ИКР).

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

У меня пропал сон

Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?

В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают стабильность и масштабируемость в самых требовательных системах.

Альтернативные ссылки ВК Видео | Аудио

https://www.youtube.com/watch?v=lpmZJ2xnsaE

Собеседования: Истории и раздражающие практики

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

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

Написал мощную статью на хабр про то как на самом деле надо собеседовать разработчиков. Вложил туда так сказать весь опыт с 2009 года, когда я начал впервые собеседовать и с тех пор провел более 1000 собесов! https://habr.com/ru/articles/879902/ не забудьте поделиться с друзьями ;)

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

Альтернативные площадки ВК Видео | Аудио
https://www.youtube.com/watch?v=Lbq_NwIKUrI

slim => inertiajs + react + vite в code-basics

Саммари по переезду с серверной шаблонизации на slim в code-basics на инерацию с реактом. Если кто пропустил напомню, концепция инерации в том, что она соединяет бек и фронт в классическом стиле для бекенд фреймворков. В экшенах контроллера передаются данные во вьюху, а вместо обычной серверной вьюхи, используется какой-либо фронтенд фреймворк, в моем случае реакт. Инерция концептуально работает как nest.js, но в качестве бека может выступать любой бекенд фреймворк для которого есть адаптер. Ключевые моменты:

* Используется серверный роутинг
* На фронтенде нет стора. Данные идут в пропсы
* По причине описанной выше, нет никакого API

Для меня это уже второе приложение в таком стиле. Сначала была приемка документов для колледжа, в разработке которой я участвовал три месяца. Теперь вот code-basics. В отдаленной перспективе, я планирую переводить на эту схему сам Хекслет.

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

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

Либа для ресурсов (DTO), как и полагается в современном мире, умеет генерировать типы для TS, что очень помогает не дублировать и не описывать все ручками.

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

Рельса предоставляет много удобных механизмов для серверных шаблонов, например офигенные формы, которые умеют работать с моделями. Это автоматизирует кучу вещей, от правильной обработки ошибок, интеграцию с i18n и многое другое. В новой схеме все это пришлось заводить руками. Инерция поставляется с хуками для обработки форм, но им далеко до рельсовых интеграций, поэтому пришлось напилить файл с формами. Для хранения строк я взял i18next, но сделал хитро. Я не стал дублировать и переносить переводы из бека, а заюзал либу, которая автоматом собирает все в json для фронта. Поэтому сами тексты описываются как обычно, но “магически” оказываются на фронтенде.

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

А что по внешнему виду? Тут многие знают что я предпочитаю бутстрап, но честно говоря, у меня была попытка найти что-то такое же высокоуровневое. В итоге из более менее подходящего оказался только https://primereact.org/, который можно подстраивать под свои стили. Сейчас в проекте часть компонентов взята из react-bootstrap, часть из primereact, например автокомплит или грид в админке.

Ну и нельзя не сказать про ssr. Так бы он и нафиг не сдался, но для проекта критично SEO, поэтому пришлось заводить. Плюс один процесс в продакшене + настройка + пришлось разбираться с кучей либ, которые не работают в беке.

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

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

В сегодняшнем подкасте мы поговорили с Владимиром Ивановым, Senior Engineering менеджером в Bolt, о системном дизайне и его роли в создании крупных сервисов. В выпуске много живых кейсов и инсайтов из реальных проектов
https://youtu.be/5A7ncMHfB1g

ВК Видео | Подкаст
https://youtu.be/5A7ncMHfB1g

Выход из крысиных бегов

А что вас останавливает от старта своего бизнеса? Недостаток идей? Страхи? Что-то еще? Поделитесь плс в комментариях. Пора уже и про стартапы начинать движуху 🙂

Готов ли я рисковать?

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

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

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

Кто-то в комментариях написал, что закрываются 9 из 10 бизнесов. Ха, все еще интереснее. Конкретно каждый предприниматель вам скажет что он 10 лет пытался и закрыл 10 бизнесов перед тем как у него что-то получилось. Другой вопрос, что в историях успеха про это не особо упоминают. Еще писали что “деньги буду получать только через год”. Вот тоже не факт, что через год у вас будут какие-то деньги. Гарантий никаких вообще. Нормально я мотивировать умею да? 🙂

Ну и я на всякий спросил у ChatGPT: “степень риска на которую готов пойти человек в своей жизни в разных аспектах определяется его воспитанием или это врожденная штука?”. Он неплохо расписал, можете сами попробовать. Вывод там такой: “Склонность к риску – это не что-то одно, а сочетание генетики и воспитания. Но важный момент: человек может сознательно менять свою стратегию риска, обучаясь анализировать риски и управлять ими.”

Пока достаточно) Вот примерный план публикаций:

* Предпринимательское мышление (жилка).
* Чем вообще можно заниматься если у меня нет денег и я не секу в маркетинге.
* Как оценить идею и размер рынка.
* С чего надо начать: продукт, маркетинг, продажи. Какой такой customer development?
* AAARRR. CJM и Воронки
* Лидопад и сломанные процессы. Почему владелец бизнеса обречен.
* Как работает маркетинг. Обзор всех направлений. Сквозная аналитика.

Что скажете? Не будете отписываться? 🙂

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

p.s. В твиттере прошлый пост то же бахнул сильно, там более 100 комментов: https://x.com/mokevnin/status/1891542982349758856

Предпринимательское мышление

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

> Полное отсутствие предпринимательской жилки. Абсолютное.

Человек как будто поставил себе диагноз: “у меня плоскостопие”. Короче, предпринимательское мышление это навык. Его можно сформулирвоать так: умение видеть возможности там, где другие видят проблемы. Лучше всего показать это на сравнении:

События

Событие: Отключили twitter
Восприятие1: Лишают сервисов, помогите!
Восприятие2: О, а что если сделать локальный аналог

Событие: Ввели санкции на импорт ПО (происходит везде!)
Восприятие 1: Мы отстали от мира, работать невозможно
Восприятие 2: Отличный момент для создания аналогов и выхода на рынок с локальными решениями

Событие: Развивается ИИ, который умеет писать код
Восприятие1: Я не буду никому нужен, моя профессия умрет
Восприятие2: Сделаю проект, который умеет создавать приложения по тз

Событие: В стране резко выросли процентные ставки
Восприятие 1: Бизнесу конец, кредиты неподъемные
Восприятие 2: Люди будут искать альтернативы кредитам → создаю платформу для взаимного кредитования или рассрочек

Событие: Вводят строгие законы по защите персональных данных
Восприятие 1: Компании будут тратить миллионы на соблюдение новых требований
Восприятие 2: Делаю сервис, который автоматически проверяет соответствие и помогает бизнесу минимизировать риски

Наблюдения

Другой вариант, это кейсы связанные с использованием каких-то сервисов. Возьмем для примера известный в рф cloudpayments. Ребята делают классный сервис, вроде все хорошо, но если вы хотите крутую аналитику для подписки, то вам придется выгружать данные из этого сервиса и где то все это лепить. Но если посмотреть на мировую практику, то вокруг платежных провайдеров существуют спец сервисы, которые автоматом все выгружают и показывают в суперудобном виде. И эти сервисы вполне себе актуальны и зарабатывают: https://baremetrics.com/

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

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

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

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

p.s. В следующем посте поговорим уже конкретные примеры в it которые нас окружают. Чем можно заняться и как это увидеть.

В этом выпуске мы пообщались с Алексеем Фёдоровым — сооснователем JUG Ru Group и организатором одних из крупнейших IT-конференций в России. Он поделился тем, как создаются профессиональные мероприятия с нуля, какие сложности поджидают организаторов, и почему, несмотря на все трудности, офлайн-события остаются востребованными.

Альтернативные платформы: ВК Видео | Аудио

https://youtu.be/tX3sOLDpBpU?si=8g5su3QUESnqGmVF

Инженерные решения: Хранение курсов на Хекслете

Когда мы делали Хекслет (а потом и code-basics), то перед нами стояла вроде бы типовая задачка создать CRUD курсов, которые, кстати, почти все текстовые. Но не все так просто. Так как авторы курсов могут быть внешними людьми, то сразу встает вопрос организации доступов. На этом этапе возникает пачка новых вопросов:

• А если человек что-то сотрет, что не надо стирать?
• А если он просто все удалит?
• А если один курс будет править сразу несколько человек?

Короче стало понятно, что нужно внедрять систему прав и версионирование. Мы как-то покрутили это добро и поняли, что заниматься такими вопросами ну совсем не хочется. Это круто с точки зрения программирования, но совсем не нужно с точки зрения бизнеса. Можно ли как-то по другому решить этот вопрос? Гит подумали мы и посмотрели на гитхаб. Ну и плюсом система прав. Все что остается сделать это написать небольшой круд с загрузкой курса. Так мы и сделали, заодно реализовали CD, когда коммит в main приводит к автоматической загрузке и выкладке курса на платформу.

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

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

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

Менеджерские навыки у тимлидов

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

• Коммуникация в зависимости от вида отношений
• Process design (как system design, но про процессы)
• У нас нет тимлидов! (про бирюзовые компании)

Кстати Женя был как-то в подкасте Хекслета, но узнал я об этом только недавно :) В общем если вы управляете людьми, то найдете для себя там немало полезного