👶🏾Первый язык программирования 👶🏾

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

(продолжение в комментариях)

😐 Bun и даже тут напортачил 😐

#js #nodejs #bun

🥧 Вышел Bun 1.0 🥧

Ну вышел и вышел

#js #nodejs #typescript #bun

💩 Какой язык программирования выбрать 💩

Что выбираю я: – Full-stack web приложение с кучей бизнес-логики? TypeScript
– Нужен более быстрый IO или терминальная утилита? Go
– Нужен тонкий memory management? Zig
– Сделать какую-то аналитику? Python (хотя я и на TypeScript нашел способ)
– Мобильное приложение? Cordova (она до сих пор отлично работает), на крайняк React Native
– Десктоп? Electron / Tauri
– Микроконтроллеры? JS на Mongoose OS + C
– GameDev? – Godot + GoScript / C / Zig

Почему не: – Ruby / Python – без типизации, медленные, неудобные IO
– C# – по факту старший брат TypeScript, но слишком жирный
– Java – старый, жирный, некрасивый (описал мое будущее)
– Kotlin / Scala – если бы нравилась Java, но не хотел писать на Java
– Haskell / Elixir / F# – функциональное программирование классное, но у меня не было кейса, когда оно мне было нужно, а в остальном, слишком маленький рынок разрабов
– Rust – ненавижу borrow checker
– C – нравится, но много чего привычного не хватает
– С++ – это пиздец
– Swift / Objective C – лучше C++

Есть ли у моего стэка минусы? Только они и есть

Стоит ли ориентироваться на мой список при выборе своего стэка? Нет

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

🔤 Авто-масштабирующаяся БД - Реляции + ХХХ = Ляпота 🔤

"Авто-масштабирующаяся БД" – автошар-дируемая база формата master-master (CockroachDB, YDB, ScyllaDB, Clickhouse, PlanetScale, etc.), что позволяет писать много данных быстро и с условно неограниченной параллельностью

"- Реляции" потому что в 90% таких БД не будет CONSTAINT, благодаря которым БД при изменении / уничтожении данных чистить / менять связанные с ними данные. Чаще всего, поддержание реляций в распределенных базах - задача, за которую авторы БД не могут дать требуемых каждому отдельному проекту гарантий и времени исполнения.

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

И для начала, ложка дегтя: я неоднократно слышал и только со временем поверил в то, что реляции (особено CASCADE DELETE) – палка о двух концах. Это слабо контролируется, весь каскад тяжело увидеть в БД, некоторые случайные удаления могут вызвать необратимые последствия. Статейки 1, 2. Иногда лучше оставить данные на месте "до лучших времен", ведь часто при запросе пользователю или не увидит уже несвязанные с ними данные (из-за отсутствия реляции) или эти данные относятся к "фактам прошлого", которые вообще не стоит удалять.

Ок, а если надо удалить, или убрать FORIEGN KEY, или проставить deletedAt?

. Простой вариант – крон, который чистит записи "сироты" (orphaned rows)

. Надежный, но кропотливый – ручками, в каждом отдельном месте понимать что и как нужно удалить / поменять (на сложных проектах иногда приходится к такому прибегать вместо реляций)

. Кривоватый, но рабочий вариант – ORM или свой плагин, который на уровне кода применяет каскадом действия при изменении / удалении сущности. Крайне опасная и часто малопредсказуемая история (хотя, я видел подобный успешный опыт)

. Более продвинуто – закидывать событие об удалении сущности в Queue, читать отдельным сервисов и принимать нужные решения. Придется иметь и настраивать MQ, а еще и не забывать писать все эти ивенты.

. А вот самый заебись вариант это Change Data Capture (CDC) – механизм базы, который позволяет подписаться на события об изменении данных, которые она будет присылать вам на лету.

И вот именно встроенный CDC является тем самым ингридиентом ХХХ, который добавляет этим базам удобства и надежности решения вопроса с реляциями.

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

Мощной вам прокачки 😎

P.S.

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

#postgresql #db #highload #ydb

⏲ 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