Хекслет.Клуб официально открыт! Значит рассказываю. У меня давно была идея, объединять не только тех кто хочет вкатываться в it, но и тех кто уже работает и кому важен профессиональный рост, карьерный рост, возможность увеличить свой нетворк, если нужно переехать и устроиться куда-то зарубеж.

Как устроен клуб (к чему мы идем)

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

- Собеседования: Опыт прохождения участниками мидловых и синьорских собеседований с вопросами и требованиями
- Компании: Отзывы и рассказ о внутренней кухне работы компаний, в которых работают участники
- Менторы: Отчеты менторов и о менторах, с описанием планов развития

В разговорных чатах обсуждается все от алгоритмов и курсов до построения личного бренда.

Сам клуб управляется через бота https://t.me/HexletClubBot Через него дается доступ к чату, в этом же боте собраны полезные ссылки и база знаний клуба.

Ну что, поехали) Жду всех там

Хекслет.Клуб - общаемся, растем технически и в карьере, строим личный бренд

Во многих фреймворках создание нового ресурса - это одна команда. А вот удаление - ручной, многосоставный, рутинный ад. Вы создаёте файлы: модель, миграцию, контроллер, тесты. Потом передумываете, а файлы уже лежат в git. Что дальше?

Если повезет через git clean, но обычно руками:

* удалить файлы модели, миграции, контроллера, вьюх,
* откатить миграцию,
* удалить строчки в routes,
* проверить, ничего ли не осталось.

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

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

В Rails есть команда, которая удаляет всё одним движением. То есть на каждый генератор, есть “удалятел”, который подчищает все то, что было добавлено генератором.

Генерация


bin/rails generate model User name:string
invoke active_record
create db/migrate/20250424120000_create_users.rb
create app/models/user.rb
invoke test_unit
create test/models/user_test.rb
create test/fixtures/users.yml


Удаление


bin/rails destroy model User
remove db/migrate/20250424120000_create_users.rb
remove app/models/user.rb
remove test/models/user_test.rb
remove test/fixtures/users.yml


Крутяк да? А как вы удаляете то, что вам нагенерилось?

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

Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

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

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

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

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

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

Выпуск про тимлидов уже доступен для просмотра. Вы узнаете, как устроена настоящая командная динамика, что делать, если «всё рушится», и почему работа тимлида — это не про власть, а про ответственность. Не пропустите — разговор откровенный, местами жёсткий, но крайне полезный для всех, кто хочет расти в IT.

https://www.youtube.com/watch?v=_qJ_rU8-S90

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

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

Ух, последнее время навалило и я плотно занялся разработкой платформы Хекслета спустя несколько лет, после того, как я перестал писать туда код. На днях мы делаем большой релиз с выкаткой ИИ-ассиснта вроде того, что я сделал в code-basics.com. Хочу поделиться несколькими историями, которые в процессе возникли и как ИИ немного поменял мой подход к работе.

Удаление Docker Compose

Возможно вы скажете что я сошел с ума, но упрощая одно, Docker Compose делает сложным многое другое. Работа редактора, постоянное переключение внутри/снаружи (опять же история команд), сложности с сервисами (например интеграционные тесты), сложности с рестартом (когда это происходит по внутренним причинам а не снаружи). Все это сопровождает работу в Compose каждый день, а сетап окружения, по факту, делается один раз, в самом начале. Поэтому лучше один раз потратить чуть больше времени, зато потом не париться. Тем более сейчас все не так уж сложно: mise, overmind, caddy + базы и другие штуки прямо в докере, вместе работают как надо. Даже обвязка в виде команд занимает меньше строк чем docker-compose конфигурации:


# Procfile.dev
webserver: make services-webserver-run
vite: make services-frontend-run
app: make services-app-run
jobs: make services-jobs-run


В общем сначала я сделал это на code-basics.com, теперь мы это делаем и на репе Хекслета

Замена старья на Chatgpt

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

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

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

Такая же история у меня была с интеграцией @sdk/ai от vercel. Я потратил целый день пытаясь его завести, мне даже пришлось полностью перелопатить его кишки в итоге я не смог его нормально завести для своих задач (смог, но с большим количеством подпорок). В конце я просто плюнул и сгенерил себе react hook, который делает все нужное (коммуникация с сервером, отправка прием данных). Посмотрите какая красота: https://github.com/hexlet-basics/hexlet-basics/blob/main/app/javascript/hooks/useAssistantStream.ts

Я не уверен что решился бы сам его писать. Не потому что не могу, а потому что не хочу тратить на это время. А щас это перестало быть проблемой.

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

В этом выпуске мы поговорили с Петром Зайцевым из Percona, который раскрыл историю и эволюцию популярных баз данных: MySQL, Postgres, MariaDB и других решений. Обсудили, как MySQL оказалась в руках Oracle и к чему это привело, как возникли форки вроде MariaDB и почему в итоге всё чаще стали выбирать Postgres. Пётр также рассказал, почему баз данных становится всё больше, как бизнес-модель и «идеология» вендоров влияют на то, что мы видим под капотом, и почему он продолжает верить в open source-подход.

youtube.com/watch?v=TgT7fjyzZzY

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

В этом выпуске мы поговорили с Петром Зайцевым из Percona, который раскрыл историю и эволюцию популярных баз данных: MySQL, Postgres, MariaDB и других решений. Обсудили, как MySQL оказалась в руках Oracle и к чему это привело, как возникли форки вроде MariaDB и почему в итоге всё чаще стали выбирать Postgres. Пётр также рассказал, почему баз данных становится всё больше, как бизнес-модель и «идеология» вендоров влияют на то, что мы видим под капотом, и почему он продолжает верить в open source-подход.

youtube.com/watch?v=TgT7fjyzZzY

Как программист, я больше всего люблю:

- Удалять код, а не добавлять его
- Уменьшать количество используемых систем
- Заменять кастомные решения, на стандартные
- Использовать готовые решения, вместо написания своих
- Принимать административные решения, а не технические

Смотрите что я вам принес. Отлично поболтали с Мурычем про js и программирование в целом. Деды бухтят https://www.youtube.com/watch?v=wv_qgOI60ao

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

Принцип на все времена: Command-Query Separation

CQS очень простой принцип программирования, применение которого встречается на каждом шагу. Обычно его формулируют так: “задавая вопрос, не изменяй ответ”. Представьте что у вас есть функция, которая проверяет валидность объекта user.isValid(). По смыслу эта функция проверяет данные по каким-то правилам и возвращает true/false.

Может ли она что-то менять? Большинство скажет что это не логично и будет право. Она не должна ничего менять. На практике же, это происходит тут и там. В тех же Rails, вы легко встретите внутри модели колбек before_validation, в котором можно сделать любое изменение, которое сработает на вызов valid?. И этим часто пользуются, я был свидетелем, как в коде удалялись связи у пользователя. Но тоже самое встречается налево и направо у программистов во всех языках.

Однажды, когда я собесил человека на наставника в Хекслет, мы как-то по пути выяснили, что у них там в коде во время запроса каких-то опций, они удалялись из списка опций, мы обсудили этот момент, я чуть-чуть рассказал про CQS и разработчик мне ответил, что после разговора пойдет переписывать код :)

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

Кстати да, это правило распространяется на все вокруг. Именно поэтому в HTTP существует GET, который можно кешировать так как он сам не меняет данные (но данные могут поменяться по другим причинам), а POST всегда меняет, поэтому кеширование к нему не применяется.

Буквально недавно мы разговаривали с Тагиром и он поделился тем как в Java работает форматирование дат. Оказалось, что в Java есть объект SimpleDateFormat, и он непотокобезопасен. Почему? Потому что метод, который вроде бы просто форматирует дату в строку, на самом деле меняет внутреннее состояние объекта. И если два потока одновременно вызовут .format(…), то они могут получить некорректный результат. Это классический пример нарушения CQS: метод, выглядящий как query (просто возвращает значение), внезапно ведёт себя как command — вносит изменения.

В результате приходится либо каждый раз создавать новый SimpleDateFormat, либо оборачивать его в ThreadLocal, либо использовать DateTimeFormatter из более нового API, который как раз спроектирован с учётом CQS — он ничего не мутирует.

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

Но это что касается вопросов. А что насчет команд? Тут уже не так очевидно, почему если мы выполняем действие (`setSomething()`, doSomething(), то данные лучше не возвращать?

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

Во-вторых, это помогает отделить побочные эффекты от чистых вычислений. Когда метод возвращает что-то, возникает иллюзия, что это «безопасно» — можно просто вызвать и использовать результат. Но за кулисами может происходить что угодно: удаление из базы, отправка письма, пересчёт кэша. Такое поведение тяжело тестировать и отлаживать.

Это не значит, что действия никогда ничего не возвращают. Иногда они могут вернуть, например, true или false, чтобы явно показать успех или неудачу. Более того, в некоторых ситуациях невозможно соблюдать CQS, например, при открытии файла на запись (создается файловый дескриптор).

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


p.s. Признавайтесь, писали такой код?

Чот я завалился на первом вопросе у ai помощника для подготовки к собесу. Похоже с фронтендом придется завязать

В подкасте вместе с Ириной Назаровой (CEO «Злых марсиан») мы разобрали, почему модель Open Core стала одним из доступных способов для разработчиков запустить собственный бизнес без чрезмерных инвестиций в маркетинг и продажи.

Выпуск будет полезен всем, кто хочет построить свой бизнес, оставаясь в технической зоне комфорта.

https://youtu.be/OY62kYMdM4M

Альтернативные платформы: ВК Видео | Аудио
https://youtu.be/OY62kYMdM4M

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

Отдельно написал загрузчика курсов в асситенты. Писать было одно удовольствие, зацените код https://github.com/hexlet-basics/hexlet-basics-assistant

Что по пути узнал и чему научился:

⁃ В openai внутри есть RAG, соответственно считай готовая база куда надо просто вгрузить данные, дальше все работает само.
⁃ Работу со стримами для подготовки файлов мне полностью сделал chatgpt, так как либы в js не умеют в последовательную запись (либо устарели)
⁃ Количеством параллельно обрабатываемых файлов с уроками можно рулить через пакет p-queue, очень простая и полезная либа

Вот так работает:


➜ hexlet-basics-assistant git:(main) make assistant-load L=css
bin/dev.js load css
Repository: https://github.com//hexlet-basics/exercises-css
Clone to: /var/folders/mk/qlh1ntvj27581bntpj_gx9qh0000gn/T/hexlet-basics/exercises-css
Cloning repository...
Repository cloned
Directory for prepared files: /var/folders/mk/qlh1ntvj27581bntpj_gx9qh0000gn/T
css-10-basics-10-introduction.txt
css-10-basics-20-connection.txt
css-10-basics-35-basics-style.txt
css-10-basics-30-style.txt


На самом code-basics подрубил либу ruby-openai и соединил ее со стримингом через ActionCable. Шок в том, что этот код мне полностью написал chatgpt и он оказался рабочим с первого раза. Как фронт так и бек. Правда сначала я попробовал работать через ActionController::LIve, но уперся в то что он рвал коннекты и был не надежен. С ActionCable я до этого не работал, но готовая реализация получилась за час.

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

По пути выяснилось две проблемы:

⁃ На фронт надо передавать дельты без обработки, а то теряются \n и потом на выводе сломанный маркдаун
⁃ ActionCable асинхронный поэтому чанки путаются, пришлось дополнительно внедрять нумерацию и выпрямления порядка

Вот тут можно посмотреть исходник: https://github.com/hexlet-basics/hexlet-basics/blob/8d83e74d398b47571997b4d04eef1b010cedbf55/app/javascript/components/Chat.tsx

Ну и затестите как оно работает: https://code-basics.com/ru/languages/javascript/lessons/logic-combine-expressions

p.s. там в процессе еще немного секьюрити в порядок привести надо, я этим занимаюсь :)

📢 Телетекст, посвященный обработке ошибок в Go
Когда: 27 марта 14:00 мск
Где: в сообществе в телеграме
⠀
ПРИНЯТЬ УЧАСТИЕ
⠀
Почему в Go нет исключений в классическом понимании? Как правильно обрабатывать ошибки? Эти и другие вопросы обсудим с Валентином Чащиным, руководителем отдела серверной разработки Go в ecom.tech (ex. Samokat.tech).
⠀
🎁 Спикер будет публиковать доклад в текстовом формате. Вы сможете читать его в своем темпе, оставлять комментарии и задавать вопросы. Автор самого интересного вопроса получит в подарок дни доступа к платформе.
⠀
Обязательно зарегистрируйтесь в боте, чтобы принять участие и получить возможность забрать подарок.

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

Выпуск будет полезен тем, кто только начинает путь в интерфейсной разработке, и тем, кто хочет переосмыслить свой стек и открыть для себя новые грани CSS.

https://youtu.be/mmmmllrf3ws

Альтернативные площадки: ВК Видео | Аудио
https://youtu.be/mmmmllrf3ws

Подумалось, что забытый всеми HATEOAS, без которого любой REST это недоREST с точки зрения идей создателя, может наконец-то стать востребованным из-за AI агентов, которые сами рыскают в поиске информации по интернету. Навеяно выходом протокола https://www.anthropic.com/news/model-context-protocol

Крах Vibe Coding: как ИИ-помощник едва не уничтожил стартап. Лео Мартинес, 30-летний предприниматель без формального опыта в программировании, сидел в своей квартире в Майами с панорамным видом на город. В его руках была не клавиатура с кодом, а ноутбук с открытым редактором Cursor — ИИ-инструментом, который помогал ему писать код. Так родился VibeFlow — SaaS-платформа, позволяющая создавать сайты, просто описывая их словами. Этот метод, который получил название "vibe coding", завоевал популярность, а Лео делился успехами в соцсетях, набирая тысячи лайков и репостов.

Но 17 марта 2025 года его мечта едва не рухнула.

Утром Лео, наслаждаясь кофе, заметил поток тревожных уведомлений: ошибки API, превышенные лимиты, пользователи получали премиум-доступ бесплатно. В панике он написал в X (бывший Twitter):
"Ребята, меня взломали. Кажется, меня наказывают за ‘vibe coding’."

Ответы не заставили себя ждать. Один из пользователей предположил SQL-инъекцию:
"Если у тебя в базе появились случайные данные, это может быть SQL-инъекция. Любой может войти под логином ' OR 1+1=2 --."

Лео похолодел. Он почти ничего не знал о SQL-инъекциях, но понимал, что безопасность данных пользователей оказалась под угрозой.

Без сна и отдыха он пытался исправить ситуацию, следуя подсказкам Cursor и советам комментаторов. Он сбросил API-ключи, вынес их в переменные окружения, добавил аутентификацию. Затем закрыл доступ к API для неавторизованных пользователей и ужесточил CORS-настройки.

Но интернет был безжалостен. На Reddit его высмеивали:
"Безопасность? Просто доверяй вайбу."

Лео сдержал злость и написал:
"Я должен был просто молчать. Спасибо тем, кто действительно помогает. Сделаю выводы."

Спустя несколько дней Лео нанял эксперта по безопасности, усилил защиту сервиса и принял важное решение — не делиться деталями разработки публично.

Vibe coding дал ему возможность создать продукт без знаний программирования, но он же и стал причиной его проблем. Теперь каждый сгенерированный Cursor фрагмент кода казался ему потенциальной уязвимостью.

Лео понял: ИИ может ускорить разработку, но без знаний основ безопасности это путь к катастрофе. Его опыт стал предупреждением для всех, кто слишком доверяет технологиям — код, созданный без понимания, может разрушить бизнес так же быстро, как и построить его.

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

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

https://x.com/leojr94_/status/1901560276488511759

Пару месяцев назад я рассказывал про то что мы начали активно снимать для ютуба Хекслета. Спустя какое-то количество попыток у нас начало получаться выдавать интересные ролики и одним из них я хочу поделиться: “Почему компании не берут джунов без опыта работы, и что с этим делать?” Это видео длинной почти полтора часа, для ребят, которые хотят понять, что же такое коммерческий опыт. Чо как вам?

p.s. И не забудьте скинуть видос знакомым, кто только учится
https://www.youtube.com/watch?v=Iq0vqta4uq8&lc=UgxFdDrWJqI8xI2ypKF4AaABAg

В подкасте мы поговорили с Александром Валялкиным, сооснователем и core-разработчиком VictoriaMetrics — одного из самых популярных инструментов для мониторинга, конкурирующего с Prometheus.
Разобрали, как программисту стать предпринимателем, обсудили, как создать продукт, который нужен рынку, и где искать первых клиентов.

Выпуск — гайд для тех, кто хочет выйти за рамки программирования и построить прибыльный бизнес на своих идеях.

https://youtu.be/8xkCykuJwKs

Альтернативные площадки ВК Видео | Аудио
https://youtu.be/8xkCykuJwKs

Ребят, мы тут снова активно ринулись в производство контента для новичков и продолжающих. Языки, девопс, аналитика, тестирование, интелект и даже 1c. Есть много небольших тем, типа fastapi, асинхронность в питоне, kafka. Если вы хорошо разбираетесь в своей теме и умеете объяснять сложные вещи простыми словами, будем рады сотрудничеству.

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

Если вам интересно — откликайтесь или передайте тем, кому это может подойти 💜

Вакансии тут: https://hh.ru/employer/4307094?hhtmFrom=vacancy Лайк, шер, алишер

Как устроен маркетинг. Воронки

Давайте с главного. Что такое маркетинг?

Правильное сообщение (креатив), правильному человеку (сегмент), в правильное время.

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

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

Но такая прямая воронка работает только на очень теплую аудиторию, то есть ту, которая уже была готова купить ваш продукт и вы вовремя попались под руку. Работать только с такой аудиторией можно, но она сильно ограничена в объеме. Любой проект нацеленный на рост упирается в то, что надо идти дальше. Соответственно расширяются сегменты и вдруг все показатели резко падают, так как мы имеем дело с более холодной аудиторией, которая может и интересуется вашим продуктом, но не находится в состоянии “ищу чтобы купить”. Тогда нужно прорабатывать более сложные воронки, которые не факт что ведут к продаже прямо сейчас, они могут “прогревать” в течении какого-то времени, перед тем как продать. Сюда относятся: телеграм-боты, вебинары, бесплатные пробники, подготовительные курсы и тому подобное, тут много от ниши зависит. Но почти всегда воронка заканчивается оставлением заявки, формой оплаты или звонком, который делает сам клиент. Иначе это не воронка, а хрень какая-то.

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

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

Но даже если вы сделали воронку, то с какого перепуга на нее попадут люди? И вот тут мы приходим к привлечению клиентов. Об этом в одном из следующих постов. Я думаю про маркетинг еще 2-3 поста и потом перерыв :)

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

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

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

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


mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊

$ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1

Created a new certificate valid for the following names 📜
- "example.com"
- "*.example.com"
- "example.test"
- "localhost"
- "127.0.0.1"
- "::1"

The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem"


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

Другой вариант это туннелирование с помощью ngrok.io, и аналогов. Хороший вариант, заодно позволяет дать доступ к проекту снаружи для взаимодействия с другими системами и тестирования. Большая часть таких утилит работает только если у вас есть интренет, хотя там подсказали https://www.localcan.com/ который умеет и локальный сетап (выглядит кстати круто). Мы кстати, конкретно для хекслета решили просто вести разработку в облаках, я даже на конфе выступал с таким докладом: https://www.youtube.com/watch?v=WVjz0HcAWOs

Дальше была куча разного рода устаревших штук (которые не обновляются) + те кто по старинке в рукопашную. Видимо когда-то научились и так продолжают.

Ну и последний вариант, которым я пользуюсь уже лет пять, это использование веб-сервера Caddy для локальной разработки. Этот вариант, кстати, возможно самый популярный судя по ответам. Тут все максимально просто, вот пример конфигурации code-basics.com, где за сертификат отвечает ровно одна строчка.


https://code-basics.test {
# Enable gzip and other compression
encode gzip zstd

reverse_proxy /vite-dev/* http://127.0.0.1:3036
reverse_proxy http://127.0.0.1:3100

# Automatic HTTPS
tls internal
}


Класс, да? Ничего не надо генерировать. Все делается само. Единственный недостаток, это то, что сетификат не доверенный. Придется в браузере жмякать “все равно зайти” (сафари по дефолту не дает так сделать).

p.s. Кстати, вы знаете почему использовать .local для локальной разработки нельзя? Правильно .test


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

В этом выпуске мы поговорили с Тагиром Валеевым — Java-чемпионом, разработчиком IDE и статических анализаторов для Java, а также автором книги «100 ошибок Java». Он рассказал о развитии Java, ключевых изменениях в языке и OpenJDK, а также о том, как эти нововведения влияют на разработчиков.
Не пропустите инсайты и практические советы для тех, кто хочет глубже разобраться в языке!

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

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

Шаринг типов между сервером и клиентом

Вчера в одном чатике задали вопрос на эту тему:> Вот смотрите, предположим, есть backend на питоне, есть UI на Angular. Оба используют контрактные (согласованные) структуры - бэк отдавая, фронт получая. Как мне подружить эти схемы, что б можно было вести только в одном месте ?

Тут у нас какие варианты, давайте по рассуждаем.

Первый идеальный. У нас на беке и фронте TS, поэтому проблемы как таковой и нет. Честно говоря, мне настолько понравилось последнее время делать проекты в этом стиле, что я бы в будущем так все проекты и делал. Особенно учитывая наличие великолепной drizzle orm в node.js (просто вау)

Второй энтерпрайзный. Описываем отдельную спеку в https://typespec.io/ затем из нее генерим не только типы, но и sdk для работы. Но такой подход тяжелее и больше используется для взаимодействия сервисов друг с другом, чем для клиент-серверного взаимодействия где это может быть оверкилом. Ну и на беке все равно будет связка “свои модели” - “сгенерированные dto” - “маппинги”, то есть рутины все равно достаточно.

Третий практичный. В этом варианте мы генерируем TS типы из наших моделей или dto (что правильнее). Как правило для бекенд фреймворков есть готовые либы https://github.com/skryukov/typelizer Если нет, то можно попросить chatgpt написать конвертер. Этот вариант не без изъянов, так как типы не мапятся один в один, то иногда в беке надо явно прописывать фронтендовые типы как строки. В https://code-basics.com выбран именно этот вариант.

Четвертый апишный. Генераторы на уровне описания самого апи в беке. То есть пишем апишку, добавляем мету и из нее генерим спеку, дальше из этой спеки можно уже типы для фронта https://drf-yasg.readthedocs.io/en/stable/. Возможно наиболее популярный путь, но такое точно не сработает с подходом аля inertia.js.

Четвертый рукпошка. Просто описываем типы независимо от бека и страдаем. Как ни странно, этот вариант не на последнем месте по популярности.

p.s. А как делаете вы и нравится ли вам такой подход?

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

Коллеги попросили разместить объяву. Если у вас есть те, кто хочет вкатиться в разработку, то грант это офигенный шанс получить обучение бесплатно:

В прошлом году мы в Хекслете запустили конкурс грантов: трое человек получили возможность бесплатно учиться 10 месяцев с наставником.
Все трое уже работают. Они учились в общих группах, без особых условий, опыта в IT у них раньше не было.
В этом году решили повторить. Участвовать может любой новый пользователь Хекслета. Можно быть новичком или уже работать в IT, но, например, хотеть сменить направление.
Те, кто не выиграют грант, в обиде не останутся. Мы заморочились и подготовили десятки подарков от партнеров (спасибо им!): билеты на профессиональные конференции, подписки, сертификаты.
Подать заявку можно до 7 марта. Если вам актуально или знаете, кому может быть полезно, перешлите ссылку https://special.hexlet.io/grant

Начинаем свое дело. Примеры

Наконец-то добрались до мяса, а чем собственно можно заняться, так чтобы это не потребовало вложений или они были минимальны? Но перед началом напомню, что мой фокус это технологии, поэтому и про стартапы мы будем говорить именно в этом ключе. Если вы хотите организовать свою молочную ферму, то тут этого не будет :) Так же мы не будем говорить про свои курсы/консалтинг/агентский бизнес. Это все реально сделать без денег и вывозить на своем личном бренде (который надо таки строить), но это немного другое направление, со своими заморочками.

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

Что можно запустить без вложений?

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

== Инструменты для разработчиков

Сюда входят какие-то дополнения в разные экосистемы, которые можно продавать, потому что никто так хорошо не делает. Например в rails есть система обработки асинхронных jobs (sidekiq), создатель которой зарабатывает на про версии. Другие чуваки продают систему миграций для Java. Короче максимально технические проекты, глубоко встроенные в экосистемы языков и фреймворков.

== Продукты на базе существующих платформ

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

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

== Продукты по модели Open Core

Последние годы стала набирать массовые обороты модель open core. Это довольно старая схема, когда базовый продукт дается не только бесплатно, но еще и в открытом виде. Код обычно лежит на гитхабе и сам продукт можно развернуть у себя. При этом, есть платная улучшенная версия или платная поддержка/внедрение. В чем тут фишка? Такие продукты заменяют вам немало маркетинговых усилий. Дело в том, что многие компании (особенно за последние годы) начали задумываться на тему безопасности данных, блокировок и отключений. Рассчитывать на чистые облака нельзя, в любой момент все может накрыться медным тазом. Поэтому лучше завязываться на продукт, который в любой момент можно из saas вариант можно перевезти к себе в инфраструктуру. Примеры:

- Нужно передавать события, а zapier капец дорогой? Бери n8n
- Нужна возможность быстро херачить админки на реакте? react-admin. Нужно больше фич? Покупай энтерпрайз версию.
- Нужен крутой фреймворк на ноде? Бери nestjs и доплачивай за энтерпрайз если ты большой
- Нужен мониторинг ошибок? Sentry бесплатен, но плати за энтерпрайз
- Ну и просто списком: gitlab, Metabase, PostHog

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

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

p.s. Большой пост на реддите где разработчики делятся тем как они зарабатывают деньги на таких проектах

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

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

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

На канале "разрабы" вышел подкаст со мной, где я рассказываю про то как я нанимаю разработчиков и не только. Смотрим, радуемся, образовываемся :)
https://youtube.com/watch?v=jVjutIlBLLQ

Чтобы начать стартап, мне нужны деньги

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

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

Вы читали мою статью Как основать школу программирования в 2012 году и чуть не потерять всё из-за бума в Edtech ? Я именно тот человек, который вместе с Рахимом (олды, кто помнит?) получил инвестиции в районе 40 000$ от небольших фондов (в нас тогда вложился украинский и финские фонды примерно пополам), которые мы успешно просрали в течение года, занимаясь всякой херней в стиле “щас напишем крутую платформу, на которой авторы сделают классные курсы”. Весь наш маркетинг свелся к постингу в соцсетях, немного лайвов на ютуб и не регулярному блогу на хабре. За год мы ни с одним автором не смогли довести курс до конца, а то что было сделано, мягко говоря не решало никаких задач, в тот момент мы даже не пытались делать готовые продукты, которые решают хоть какую-то проблему, это были просто наброски на разные темы.

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

Дальше может пойти слезливая история, как я постоянно отрицал маркетинговые приемы, включал режим “кто я такой чтобы конкурировать с яндексом”, не пытался разобраться в управлении бизнесом и многое другое. Момент когда на Хекслете мы хотя бы начали лежать в правильную сторону, начался в 2019 году, спустя СЕМЬ ЛЕТ черт побери. И только сейчас я могу сказать, что начал немного понимать как вообще работают бизнесы и, самое главное, у меня произошла перестройка в мозгу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

События

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

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

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

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

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

Наблюдения

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

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

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

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

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

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

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

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

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

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

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

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

События

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

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

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

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

Событие: Вводят налог на самозанятых и фрилансеров
Восприятие 1: Государство душит малый бизнес
Восприятие 2: Все будут искать легкие способы учета и уплаты налогов → делаю удобный сервис для автоматизации

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

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

Наблюдения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: 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