⏲ Go defer на JS ⏲

В Go есть очень крутой оператор defer, он позволяет отложить выполнение какой-либо операции на конец функции (неважно это return или выброс ошибки на текущем или ниже уровнях)

Например, закрыть доступ к базе при выходе из функции где мы его открыли будет выглядеть примерно так:

- - - -
db := pg.connect()
defer db.destroy()

// Куча всякой логики и если будет return или выброс ошибки db.destroy() отработает
// ...
- - - -

Всегда сетовал, что в JS, не было такого оператора, но я наконец-то нашел ему хоть какую-то алтернативу и это try ... finally ...

Вроде, очевидно, но я почему-то никогда об этом не думал, поэтому пример выше будет таким:

- - - -
const db = pg.connect()
try {
// Куча всякой логики и если будет return или выброс ошибки db.destroy() отработает
// ...
} finally {
db.destroy()
}
- - - -

Не так элегантно, но дает возможность на 100% выполнить операцию при любом выходе из функции

Сделал gist с тестами

📟 Product market fit технических стартапов 📱
Классический стартап - наличие технической инновации дает бонус, но не является главным двигателем бизнеса: Uber, Facebook, Telegram

Технический стартап - основан на преимуществе, появившемуся благодаря конкретной технологии: OpenAI, Boston Dynamics, Protocol Labs

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

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

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

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

Все компании с которому мы общались устраивало то, что прототипы только в стадии разработки

А по дороге мы ещё выиграли тендер на поставку таких коробок для институтов и тех. колледжей для изучения студентами автоматизации растениеводства и экспериментов

Я в итоге не дожил до первых больших результатов, потому что подобного рода разработка физически требует около 2-3-х лет экспериментов, на что у меня не было сил, но наш главный инженер до сих пор в этой тематике и в другой команде пилит устройства по данному направлению (https://t.me/hydroponylab)

Это я все к чему веду: никогда не стесняйтесь и не ищите оправдания почему вы не пошли к покупателям / инвесторам

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

🧌 Всем нужны СТО 🧌 В одном популярном продуктовом канале выложили опрос по поиску кофаундеров и интересно то, что 80% всех заявок – это поиск СТО.

Я предполагаю, что чаще всего под "СТО" люди подразумевают "Супер Технически подкованного, но аюсолютно бесплатного разрабОтчика", которому предложат какую-то радужную перспективу в будущем, а сейчас надо будет годик другой впахать за 5-рых без оплаты.

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

Сейчас же критериев отбора у меня намнооого больше, среди них по порядку важности:

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

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

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

– Уже найденный Product/Market Fit – на собственном опыте знаю, что чтобы убедиться в нужности продукта (и даже начать зарабатывать) СТО и разработка вообще не нужны. Если команда без разработки не смогла найти заинтересованных клиентов / инвесторов, то есть все шансы, что они считают что именно "написанный код" будет их продающим аспектом (дисклемер, это практически никогда не так и перед вами люди, не понимающие устроство стартапов и бизнеса в целом)

– Собственные инвестиции. И я не про полное собственное обеспечение, а ну просто какие-то деньги, 50-100к $ если все фаундеры вкинуться. Эти деньги супер сильно облегчат как вопросы разработки, так и вопросы маркетинга и продаж, этих денег хватит, чтобы обогнать и сразу выйти из категории "пет-проектов" (то есть 90% рынка), двигаться в 10 раз быстрее и трате меньшего кол-ва сил. Я на 10к$ в месяц могу даже целую команду собрать и за 2-3 месяца напилить весь продукт. Короче, деньги как бы то ни было нужны.

Вот если все 5 фактора есть, тогда я бы мог рассмотреть идею выступить даже как бесплатный СТО и даже привнести немного денюжки в проект.

Но опять же, это потому что я – техно-буржуй, который разлегся на лаврах опыта и требует себе хорошей жизни, лет 4-5 назад я бы с гораздо меньшим кол-вом амбиций вписался и был бы доволен опыту.

Есть здесь кто-то кто тоже поделиться своими мыслями на "бытие СТО в стартапах"?

🌧 "А как тебе drizzle?" 🌧

Отличный вопрос в комментариях к предыдущему посту

Я даже думал сделать о Drizzle ORM преписку к прошлому посту: "это вторая библиотека, которую мы бы попробовали, если бы не kysely"

Смущает несколько вещей:

– Drizzle дальше от SQL, чем kysely: у Drizzle чтобы получить реляции можно использовать "with: { ... }", которого не существует в SQL, значит будет как-то по-своему интерпертироваться, а в kysely только SQL возможности (например, join или json_agg), причем очень качественно описанные – Для kysely достаточно иметь типизацию (type, interface) таблиц базы, что супер легко сделать даже своими инструментами интроспекции (у нас свой скрипт был, мы потом его поменяли на официальный, но скоро вернемся обратно на свой), а также очень легко расширять (импортируете в соседний файл, кастомизируем типы, используете кастомныеы типы), а в drizzle придется использовать их интроспекцию (она ломалась на наших базах из-за недоработанности по некоторым типам) + я пока вообще не понимаю как можно расширять его интроспекцию

– ИМХО у kysely более продвинутая документация

Но с учетом, что kysely сработал, у меня нет никакого повода и преимущества даже смотреть на drizzle, потому что kysely гораздо лучше справляется с моей главной потребностью – иметь максимальную типобезопасность и гибкость в написании нестандартных SQL запросов (пример в следующем посте покажу)

😍 Мы нашли шикарную альтернативу TypeORM, Prisma и Knex 😍

Вот вроде, 2023 год, вроде, Node JS один из самых хайповых и быстрорастущий стэков, но блять до сих пор нет понятного ответа на: "Какую хорошую ORM / Query Builder выбрать?"

До недавнего времени я сказал бы: "Все гавно, выбери Go (шутка)"

TypeORM забагованный, непредсказуемый, неоптимизированный и неудобный (создание класса и дальнейшее присвоение значения параметрам через .... зачем вообще тогда было использовать TypeScript...)

Prisma неплоха, но синтасис настолько далеко от SQL , что я бы назвал его "PrismaQL", непредсказуемость тоже присутствует, Rust байндинг, который требуется для запуска и интерпретации "PrismaQL" в SQL тоже жрет ресурсы и недоступен в некоторых средах (например, serverless) и своя собственная схема за рамки которой ты никак не выйдешь, если тебе понадобится какая-нибудь особенная фича PostgreSQL

Knex еще более менее (им я и пользовался) по какой-то причине практически нет ответов на StackOverflow и самое главное – у него очень плохая поддержка TypeScript (когда .leftJoin возвращает T[] вместо T[] | null это для меня красный флаг)

В итоге, после долгих поисков и сомнений ответ наконец-то нашелся!!!

🎉 Kysely 🎉 Это проооосто потрясающий Query Builder:

– Типизация невероятно сильная: .with, subquery, json_agg, parametric condition, CASE WHEN – все это и очень много другого абсолютно автоматически и правильно типизировано

– Очень понятный и похожий на SQL синтаксис (синтаксис выражений и предикатов лучший из мною увиденных)

– Ему достаточно интроспекции типов из БД, чтобы начать работать (мы используем kysely-codegen), поэтому очень просто интегрировать в любой уже существующий проект (мы используем его в новых фичах и при рефакторинге переписываем старые, а все легаси по-прежнему на TypeORM / Knex)

– Супер легко расширять колонки интроспекции своими кастомными типами (например, брендированными типами)

– Можно самому полнолстью настроить пуллы (мы для внедрения в проект с TypeORM просто переиспользуем пулл из самого TypeORM)

Короче, если вы хотите крутой Query Builder я теперь на 100% могу посоветовать вам Kysely

P.S.

Я болел последние пару месяц, но вот наконец-то выздоравливаю, поэтому постепенно начну больше писать постов, а писать есть о чем – мы недавно запустили крупный High Load проект и постепенно переносим на него нагрузку с легаси системы

Так что ждите и мощной вам прокачки 💪

#nodejs #ts #orm #postgresql #top #hot

😐 Fastgen – no-code backend, который мы заслужили Я когда-то писал про нодовое программирование – это когда вы визуальными блоками собираете бизнес-логику приложения.

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

Ребята из Fastgen подметили это и собрали для нас готовое решение – Authentication + Validation + PostgreSQL + готовые блоки для API и Cron-а.

Мне это напоминает Supabase / Hasura, но с накрученным графическим билдером логики.

Ребята не так давно начали и у них есть только cloud версия, что хорошо (потому что можно быстро стартануть и сразу иметь сервер + БД из коробки) и плохо (потому что это 100% вендор-лок)

Если тема разовьется, буду ждать когда появятся Open-source альтернативы (скорее всего, сделанные на n8n.io ), тогда я попробовал бы для какого-нибудь быстрого проекта.

🛣 Пути назад нет или жизнь без Rollback Недавно начал пробовать работать с новенькой, но очень амбициозной ORM drizzle.

И наткнулся на тред с обсуждением, что drizzle генерирует только up миграцию. Люди начали сетовать, что у них нет down миграции, а значит они не могут роллбэкнуться.

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

То есть, даже если вы хотите сделать rollback, это должна быть отдельная up миграция.

И знаете, я с ним согласен.

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

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

Это проще, чем реализация rollback, безопаснее и при этом крайне эффективно.

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

Всем мощной прокачки 🦾

🎉 Функционально Ориентированное Программирование (ФОП) официально релизнулось! И мне нужна ваша помощь https://fop.davidshekunts.ru

После 2-х лет написания моя книга про ФОП достигла v1.0 🎉

Это еще далеко не конец, у меня намечены еще несколько разделов (про Cohesion vs Coupling, Error Handling, etc.), также записать пару видеоинструкций и начать выступать конференциях рассказывая про ФОП.

Релиз v1.0 ознаменовался тем, что @cyberJohnny бесплатно выложил посты о моей книге в кучу его пабликов, за что спасибо тебе большое, @cyberJohnny!

Если интересно, вот ссылки на паблики: 1, 2, 3, 4, 5 Нужна ваша помощь! Во-первых, огромная помощь – это комментарии и критика написанного в книге. Я правда верю в то, что написал и уже много лет это использую. НО только благодаря обсуждению мыслей из книги я могу делать их как-либо улучшать. Поэтому любые вопросы и мысли приветствуются!

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

P.S.

Еще я сделал рекламу блога и это принесло +53 подписчика в качалку, велком, друзья 😍

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

Самый крутой показатель в этом опроснике – 36% хотели бы возвращать, но выбрасывают.

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

Еще, в комментариях к посту мы с @highloadzone (спасибо тебе большое за дискуссию) устроили массивное обсуждение на тему ошибок и трейсов, советую почитать.

Там я пришел к следующей мысли:

Реальные "ошибки" – это те, которым мы разрешаем положить наше приложение, и их надо выкидывать.

А все остальные "ошибки" надо рассматривать скорее как "неуспех" / "неудачу", и их надо возвращать.

Если следовать такому пути, вы получите лучшее из двух миров:

. Опасные ошибки будут перехватываться где-то на самом верху стэка и иметь право даже положить приложение;

. А вот "неудача", которую просто синтасически удобно выразить в форме структуры Error, всегда возвращается из функций, потому что нам эту неудачу придется 1 и более раз каким-то образом обработать.

Я понял, что тема крайне большая, поэтому посвящу ее отдельный раздел в книге ФОП, где расскажу про принципы, заложенные Робом Пайком в дизайн Go, error handling функциональных языков, проблемы hidden control flow и Railway Oriented Programming.

Комментарии + Markdown = 🖤 Одна из самых важных задач в кодинге – делать его понятным для других разработчиков и будущего себя. И для этого существуют 3 основных трюка:

1. Пишите более простые конструкции. If / else, вместо тернарников, for loop вместо filter + map + reduce (именно, когда вам приходится использовать все 3 в комбинации), заранее вычислять предикаты, присваивать их в union type и делать switch, вместо множества вложенный if / else.

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

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

1. Comment Driven Development – я очень часто сначала пишу комментарии в функции о том, что она должна сделать, а потом только пишу код. Это позволяет заранее увидить и порешать логические коллизии.

2. Используйте Markdown. Пример без Markdown:

// First comment
const foo = await bar()

if (foo) {
// Second comment
await helloWorld()
}

// Third comment
const ping = await ping()

А теперь скажите: First comment и Third comment связаны или нет? То есть, это следующий этап кода или часть предыдущего?

Ответ тут можно только гадать.

А вот если использовать Markdown:

// # First comment
const foo = await bar()

if (foo) {
// ## Second comment
await helloWorld()
}

// # Third comment
const ping = await ping()

Как вы видите, я обозначаю через Markdown "главы" кода, как если бы это был обычный текст. Благодаря этому можно четко понимать, что Third comment – это новая глава (следующий этап).

Вот таким легким движением руки, ваши комментарии приобретают гораздо больше контекста и понятности для других разрабов

А какие вы используете трюки для написания комментариев?