​От нескольких человек слышал рекомендацию, что мне стоит заопенсорсить мой анализатор (holistic.dev) и зарабатывать на саппорте для enterprise.

У меня на этот счет несколько другое мнение. Мне кажется, что схема с OSS не сработает с инструментами для улучшения качества ПО.

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

- Saas-версию? Этот класс ПО не требует какого-то специального обслуживания (бэкапы, настройка), поэтому даже предпочтительнее иметь on-premise версию, чем SaaS.

- Сделать лицензию, чтоб ее не могли использовать облачные провайдеры в managed версиях бесплатно, как mongodb? 100 индусов за полгода перепишет все на java и в этой лицензии не будет никакого смысла.

- Другое? Напишите в чат, пожалуйста, если есть идеи.

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

Если в области статического анализа для c/ c++/ c#/ java идет месилово, да и то коммерческие продукты как-то ухитряются существовать, то в области sql-анализа тишь да гладь.
Собираю тут полезные ссылки в этой области, ознакомьтесь, если интересно:
https://github.com/antonrevyako/useful-links/blob/master/opensource-sql-tools.md

И там все печально.

Я постоянно просматриваю много проектов, связанных с SQL. По понятной причине меня интересуют части, связанные с парсингом различных SQL - диалектов.
Абсолютно все проекты построены на кривых костылях. Они даже не пытаются сделать что-то приличное.
Все делают вид, что работают со всеми основными базами pg/mysql/mssql/oracle. Достичь они это пытаются, сделав парсер некого обобщенного SQL - диалекта,
который работает везде. Если попытаться использовать какой-то специфичный синтаксис - все рушится.

Например, свежий OSS-убийца DataGrip - beekeeper studio:
https://github.com/beekeeper-studio/beekeeper-studio

Без выбора базы автодополнение SELECT * FROM выглядит как список всех известных токенов (ALTER, AND, AS...), а при SELECT * FROM public. автодополнение не появляется.
И есть подозрение, что лучше тут ничего не будет, т.к. ноги растут из пакета https://github.com/maxcnunes/sql-query-identifier, который не обновлялся уже 3 года.

Или вот, vitess.io - a database clustering system for horizontal scaling of MySQL. Тулза на go, все по уму.
Они заморочились и сделали свой AST парсер, который собирается из самописной грамматики. Можно попробовать собрать:
https://github.com/vitessio/vitess/tree/master/go/vt/sqlparser

И что? Грамматика описана криво даже для версии 5.7
Например, в ней важен порядок DEFAULT и NOT NULL в CREATE TABLE, а в оригинальной MySQL - нет.
Новый синтаксис 8.0 не поддерживается совсем.
В прошедшем декабре CNCF объявила vitess достаточно зрелым для использования в production.

Вот такая ситуация с этими вашими OSS.

А что там у коммерческих продуктов?

Про drawsql.app (mysql/pg/mssql) и моего единственного конкурента я уже бугуртил тут
https://news.1rj.ru/str/nosingularity/424

Так, что у нас там дальше... dbdiagram.io (mysql/pg/ror)
Не понимает половины ALTER, совсем не понимает CREATE FUNCTION, CREATE EXTENSION и тд.

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

Почему все более или менее прилично у DateGrip? Они разрабатывают свой универсальный парсер грамматики:
https://github.com/JetBrains/Grammar-Kit
Специфичную для разных баз грамматику они пишут руками.

Справедливости ради, holistic.dev не начался бы, если бы не было OSS AST-парсера для postgresql.
Но на данный момент в этом парсере реализована поддержка специфичного синтаксиса postgresql только до 10 версии.

Поэтому нам пришлось самостоятельно выковыривать парсер из postgresql 13. В ближайшем большом релизе мы его выкатим.
Похожим образом приходится действовать с mysql и clickhouse.

Найти подходящий AST парсер - это процентов 5 всей работы.

Вы бы стали опенсорсить остальные 95%?

Как пелось в одной старой песне: «hit me baby one more time» (disclaimer: никак не связанно с текущей новостной повесткой :))

Еще одно мнение про долину:

https://telegra.ph/CHto-eshche-ne-rasskazali-pro-nedostatki-Kremnievoj-Doliny-05-11

... Если не менять работу/обстановку/жизнь, то от понимания, что так может пройти вся оставшаяся жизнь, рано или поздно начинаешь задаваться вопросами "а что я сделал в жизни" и от осознания реальности становится не по себе. Не знаю, с чем это связано – возможно с тем, что у русских "особенная душа"...

А в любой другой точке мира будет как-то иначе?
Сильно сомневаюсь, что свойство задаваться подобными вопросами зависит от национального признака.
По моим ощущениям виновны тут две вещи - пирамида Маслоу + кризис среднего возраста.

Когда у тебя океан под боком, отдельный дом (пусть и в ипотеку), Илон в кибертраке стоит рядом с твоей теслой в пробке, то как мне кажется, думы в духе «что ты сделал для хипхопа в свои годы» обдумывать намного легче, чем в столичном метро по дороге на работу из арендной студии в пригороде в 30 минутах от метро.

Справедливости ради, ни в одной из ситуаций я не находился, поэтому сегодня играю за диванного аналитика.

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

​Удивительным образом вселенная подбрасывает релевантный контент. И нет, алгоритмы гугла и фб тут не виноваты. И даже феномен Баадера — Майнхоф тут ни при чем.

В догонку к предыдущему посту, на Шмит16 пост об осознании места гречки, себя, гречки в себе и всего вместе в нашем неспокойном мире:
https://news.1rj.ru/str/Shmit16/527

Некоторым это может напомнить старый анекдот «больной, я как посмотрю, у вас времени свободного дохрена...»

Но я искренне завидую людям, которые могут заниматься рефлексией на таком уровне...

xzibit.jpg

Меж тем зарождается новый поджанр в абстрактной живописи — Martin Calvino рисует абстрактные картины, навеянные изображениями, сгенерированными нейросетями.

обидно конечно, pg day russia в Питере не будет, но на что тут можно было надеяться?..


https://twitter.com/pgdayrussia/status/1260234609700241409

Нормально сегодня повалило....
https://news.1rj.ru/str/durov/116

А, пошло дело на лад...
https://news.1rj.ru/str/addmeto/3128

Канал @sqlquestions разыскивает человека, хорошо понимающего SQL и способного придумывать или находить вопросы для нашего канала.

Для тех, кто хочет получить работу в качестве тестового задания:
1. Создайте свой телеграмм канал
2. Добавьте туда 7 вопросов по sql, которые вы считаете будут интересны нашим подписчикам.

3. Пришлите ссылку на ваш канал на @algoritmsrules

По оплате: 30рублей за пост.

https://news.1rj.ru/str/dbbooks/397


Ура, если что, с голоду не помру!

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

У японцев, кстати, есть слово, которое означает выражение "книги, которые купили, но не читают" ― 積ん読 (tsundoku)
И еще 積ん読主義 (tsundokushugi) ― страсть к накоплению книг

Я недавно купил на распродаже theartofpostgresql.com и даже начал читать! )))
Еще присматриваюсь к databass.dev, но до black friday все равно руки не дойдут, и пока не понятно насколько оно мне пригодится.

ps: отвалившаяся после редактирования картинка:


https://ichef-bbci-co-uk.cdn.ampproject.org/i/s/ichef.bbci.co.uk/news/695/cpsprodpb/E80B/production/_102730495_steamdoku.png

Хорошая история:
https://habr.com/ru/company/digital-ecosystems/blog/501536/

напомнила про Норвегию в yaml:
https://news.1rj.ru/str/nosingularity/273

​Не секрет, что я не очень люблю mogodb и троллю их при любой возможности (так же как и рубистов):
https://news.1rj.ru/str/nosingularity/194

Семь лет назад вышла статья, о которой я писал тут
https://news.1rj.ru/str/nosingularity/35

и спустя два года вышла еще одна
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
где первый коммент "As a Stripe customer, I sure hope you’re not using Mongo to keep track of my transactions."
Быгыгы :)

В очередной раз напомню, что stripe с оценкой $36 ярдов написан на руби и монге.

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

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

Ну что, мои маленькие любители json'ов, держите:
https://twitter.com/jepsen_io/status/1261276984681754625

MongoDB 4.2.6's transactions aren't full ACID, or even snapshot isolated. We found read skew, cyclic information flow, and internal inconsistencies, including transactions which could read their own writes from the future. Ooooh, spooooky!
Also transactions are allowed to lose data & read uncommitted, possibly impossible states by default, because why would you *not* want that behavior from something called a transaction. This was already documented, but I found it surprising!

Подробнее тут:
http://jepsen.io/analyses/mongodb-4.2.6

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

https://vas3k.ru/blog/blockchain/

Но сегодня нашлась лучше:

​Давно ничего не писал, фигачу :)

Недавно вышла статья васктрика про no-code (https://vas3k.ru/blog/nocode/), выпуск подлодки про no-code (https://soundcloud.com/podlodka/podlodka-162-indi-igry) ну и так, "музыкой навеяло" :)

Автоматизация рутины это отлично! Особенно, когда ничего не надо делать :)

Поставить этот подход на службу меня я пытался еще тогда, когда появился IFTTT, т.е. лет 7 назад.
Не зашло. Все что можно там можно было сделать мне делать было не нужно...

Потом был iOS Shortcuts. Пытался настроить включение low battery mode обратно, когда он выключается и выключать wifi и bluetooth после выхода из дома и включение при возвращении. Первое выкидывало предупреждение и включало, пока не подтвердишь, второе злостно тормозило и зачем-то требовало постоянно включенного bluetooth :)
Плюнул нафг.

Когда затеял ремонт, подумал про умный дом. Так вертел и сяк - ничего не придумал.
Даже какую-то хреновину на kickstarter проинвестировал, которая скрипты для умного дома позволяет на js писать. Кинули :)

Максимум - свет в некоторых помещениях от датчиков движения работает. И можно влажность с читотой воздуха в приложении посмотреть.
Ерунда, короче :)

Как-то наткнулся на glideapps.com - конструктор вебапов, где источником данных выступает Google Sheet.
Супер тул для всяких popup событий типа вечеринок, конференций, у которых каждое первое приложение адский ад. Там много всяких шаблонов, может вам пригодится что-нибудь.


На днях в несколько кликов подключил платежную форму от paddle. Я всю свою жизнь, сцк, пилил это добро руками!


Сегодня узнал на retool.com
Гениальная вещь для всяких внутренних админок.
Если вам, конечно, не стремно давать каким - то левым чувакам доступ к вашей базе через интернет.

Вангую, что их как-нибудь вынесут со всеми клиентами и будет мета-утечка.

Но если об этом не думать - огонь штука!
Пыщ-пыщ и админка готова.


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

Или вот - нужна мне внутренняя админка для себя? Нет, конечно, я все в data grip посмотреть могу. Но если понадобится кому-то быстро показать, то можно будет временно дать коннект к проду и показать все данные красиво.

Нифига себе, у них on-premise есть!
https://docs.retool.com/docs/setup-instructions

​Один твит, который изменил мою жизнь :)

Не, конечно, все не так, но времени съело прилично.
Началось все как "10 фильмов, которые вдохновляют вас кодить"

https://twitter.com/ravinwashere/status/1261266239688790016

Но в треде их намного больше :)
Правда, забыли valley of boom - мини-сериал про начало и крах доткомов.

Не очень понятно, почему хочется кодить после "The Founder" - история про чувака, который отжал макдоналдс у его основателей, но фильм сам по себе прикольный.
Или "The Pursuit of Happiness" - про мигрантов.

Особое место в этом списке, конечно, занимает
Indie Game: The Movie HD

Фильм будет близок всем, кто делает свои продукты небольшими командами.
И разговор не только про игры.

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

Braid разрабатывался два года.
FEZ пять лет!
Как же это знакомо, черт побери :)

Мы вместе с очень крутым художником @pvl_lagutin несколько лет делали indie-игры, и, конечно, мы мечтали о таких результатах, как у создателей braid или super meat boy.

Нашел старое интервью с Павлом, там есть и примеры его работ, зацените:
https://darkermagazine.ru/page/pavel-lagutin-tjanulo-k-strashnomu

Еще хочу порекомендовать блог одного инди-разработчика ant-karlov.ru
Он пишет не часто, но довольно интересно. Раньше он пилил на флеше, но потом переехал на unity.

Иногда хочется вернуться в геймдев, но... война - дело молодых :)

Сегодня хотел сказать пару слов про инновации.

Есть 2 противоположные точки зрения относительно создания чего-то нового. Точка зрения инноватора и точка зрения инвестора.

На стороне инноватора выступает Генри форд с цитатой: «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь».

На стороне инвесторов... все инвесторы :) Их позиция - "Если у вас нет конкурентов, значит вы делаете то, что никому не нужно".

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

Инноватор хочет... инноваций. Зачем делать то, что делают другие, даже если ты знаешь (думаешь, что знаешь) как сделать это же лучше? Го делать новые крутые штуки, которые никто не делал!

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

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

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

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

Вы когда-нибудь пробовали выбрать систему управления проектами? Jira, asana, youtrack, clubhouse, wrike, targetprocess и т.д. и т.п. Мы пробовали. На это было потрачено много ресурсов и в итоге плюнули и решили остановиться на issue в гитлабе. Продолжало у нас после этого болеть? Да. Но заставить нас вернуться к процессу выбора еще раз было практически невозможно. Процессы криво-косо настроили, на это тратилось какое-то количество ручного труда, но это считалось приемлемыми потерями.

Обычно в этот момент приходят истории про дисрапт. Твой продукт должен наносить драматически бОльшее количество пользы, чем та, которая наносится сейчас, чтобы клиент посмотрел в твою сторону.
Есть история про такой продукт fibery.io, который много лет делал один из создателей targetprocess и который должен был дисраптить тему. Я попытался попробовать. Очень интересно, но ничего не понятно...

Но с дисраптом все та же беда - проблема для клиента должна быть очевидной. Была у клиента проблема, которую решал Форд своими автомобилями? Судя по его цитате в начале поста, проблемы не было :) Ну да, лошади, пахнут, надо кормить, они болеют, но процесс налажен. Зачем менять это все на какие-то железки, которые пахнут, им надо заливать топливо, они ломаются и тд? Да и лошадки красивее :) Бегали бы побыстрее, а так норм. Дисраптом в современном понимании была бы телепортация...

Короче, если ты инноватор - кастдевить бестолку, будет только хуже :)

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

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

Можно привести много примеров из моих разговоров, но я постараюсь сделать выжимку.

Итак, встречайте!

10 кейсов, после которых вы расхотите тратить время на кастдев :)

Disclamer: за платными советами по кастдеву идите к Ивану Замесину. Ниже я выражаю свой дилетантский взгляд на эту тему, основанный на опыте кастдева и поиска пилотных внедрений инновационного иструмента статического анализа SQL-запросов holistic.dev

1/3

Пример #1: hand made
Если в компании разные люди пишут приложение и SQL-запросы, возникают проблемы синхронизации результатов их работы. Типы, версионирование и тд. Частично решается тестами, но бОльшая часть автоматизации не поддается. Решение - страдать, колоться и жрать кактус. Никто не любит заниматься этим вручную, но считается, что это необходимое зло и все с ним мирятся. "Это работа программиста, нам за это платят".
Размазали проблему между несколькими разработчиками. Это снизило их мотивацию и замедлило работу. Инструмент - недешевый ручной труд.

Пример #2: cheap staff
Если в компании не пишут чистых SQL-запросов, а используют разного рода ORM, то возникают проблемы с производительностью всего. Решение - купить железо помощнее.
Кажется, что получается сэкономить на разработчиках и сократить time to market, а растущие технический долг и затраты на инфраструктуру - "это неизбежно и так у всех".
Размазали проблему по всему проекту. Инструмент - забрасывание деньгами.

Пример #3: startup (vc will pay)
Совокупность двух предыдущих примеров. Я как-то рассказывал про стартап, где не использовали нормализацию базы (https://news.1rj.ru/str/nosingularity/410), потому что join'ы страшные и тормозят, но при этом в базе нет ни одного индекса. Инструмент - недешевый ручной труд + забрасывание деньгами.

Во всех этих случаях нет главного - осознания проблемы. Как говориться, признание проблемы - это 50% ее решения.
У всех есть налаженные процессы, потери на которых приняты как приемлемые.

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

Кастдевить таких клиентов бестолку. Может сложиться ощущение, что ты делаешь то, что никому не нужно.

Пример #4: look-alike
Есть какая-то осознанная проблема, которая кажется похожей на ту, которую может решить твой продукт.
"О, круто ты придумал! Твой инструмент же расскажет мне каких индексов не хватает?" Это не самая большая из проблем, связанных с базой. Потратив день, можно вручную идентифицировать и устранить 80% проблем, связанных с индексами. Мой инструмент полезен не этим.
"Твой анализатор не ругается на поля в запросе, которых нет. Это не правильно." Это правильно. Это анализатор для DBA. Он не рассчитан, на то, что в него будут прилететь запросы, которые не валидны в run-time. Клиент хочет от инструмента для DBA получить функционал инструмента для разработчиков.

Это не те проблемы, которые ты собирался решать.

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

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