Как можно проконтролировать, что после рефакторинга базы и/или запросов у вас ничего не сломается?
"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.
Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов SQL запросов на основе parsers.dev!
Как он работает и кому нужен?
Надеюсь, что те, кто пишет запросы руками, хранит каждый запрос в отдельном файле. Если нет, рекомендую срочно начать это делать!
Итак, запросы у вас разложены по файлам, описание схемы тоже разложено по файлам с миграциями.
Актуальный код запушен в гит, изменения пока на локальной машине.
Запускаем скрипт с указанием расположения папок со схемой и запросами и получаем на выходе информацию о том, что изменилось с последнего пуша!
Отслеживаются:
- типы полей в результатах каждого запроса
- возможность каждого поля в ответе принимать значение NULL
- расхождения в источниках данных
- класс количества строк результата (NONE, ONE, ONE_OR_NONE, MANY, MANY_OR_NONE)
В описании пакета есть несколько примеров с гифками, поэтому предлагаю незамедлительно ознакомиться и попробовать! https://github.com/parsers-dev/sql-type-tracker
А пока пример на утверждение про тесты.
Давайте предположим, что у вас было как-то поле, у которого было ограничение NOT NULL. В процессе запиливания новой фичи стало понятно, что это ограничение нужно убрать.
Вы написали тесты для проверки поведения новой фичи с учетом этого самого возможного NULL.
А теперь несколько вопросов:
- как много запросов используют это поле для передачи его в приложение?
- как много запросов опираются на это поле при фильтрации и в джойнах?
- сломаются ли старые тесты без данного ограничения?
Правильные ответы - ХЗ, ХЗ и еще раз ХЗ.
Кажется, что самый важный из этих вопросов - последний. И ответ на него зависит от того как у вас устроены интеграционные тесты. Но в абсолютном большинстве случаев тесты ничего не покажут.
А чем нам это может грозить?
- в приложение попадут NULL в те места, где проверки на NULL нет
- джойны вместо 1 записи могут теперь выдавать 0 или наоборот много записей
В старых тестах все отлично - там мы эту ситуацию не ожидаем. По уму необходимо взять все существующие тесты и дописать на каждый кейс, который затрагивается этим NULL'ом, дополнительные тесты.
А какие кейсы затрагиваются этим NULL'ом?
И тут оказывается, что важными были все три вопроса...
И ответы появятся только на проде и только когда по новой фиче польются данные. В ночь с пятницы на субботу :)
В этом месте становится понятно, что нужно увеличивать бюджет на тестирование, найм и закладывать побольше времени...
Кстати, я надеюсь, что вы проверяете класс количества строк результата в приложении? :)
Давайте еще уточним, что этот NULL появился из-за нормализации данных, например. И там, где у нас данные тянулись из 1 таблицы, теперь они тянутся из двух. Нам нужно переписать Все запросы, где такое происходит.
Ок, не вопрос. Грепаем по имени таблицы все запросы и идем править.
И случайно в процессе копипасты, у нас в результат запроса попадает не то поле, которое нужно, а поле с таким же именем из другой таблицы. Тут id, там id... И типы одинаковые. И NULL'ов нет. Но данные теперь скомпрометированы!
Вот бы круто, если бы такое изменение можно было найти автоматом...
Ну вы поняли? https://github.com/parsers-dev/sql-type-tracker :)
Лайк, шер, пулл-реквест :)
PS: на higload2019 я делал доклад на эту тему.
PPS: смотреть необязательно :)
"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.
Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов SQL запросов на основе parsers.dev!
Как он работает и кому нужен?
Надеюсь, что те, кто пишет запросы руками, хранит каждый запрос в отдельном файле. Если нет, рекомендую срочно начать это делать!
Итак, запросы у вас разложены по файлам, описание схемы тоже разложено по файлам с миграциями.
Актуальный код запушен в гит, изменения пока на локальной машине.
Запускаем скрипт с указанием расположения папок со схемой и запросами и получаем на выходе информацию о том, что изменилось с последнего пуша!
Отслеживаются:
- типы полей в результатах каждого запроса
- возможность каждого поля в ответе принимать значение NULL
- расхождения в источниках данных
- класс количества строк результата (NONE, ONE, ONE_OR_NONE, MANY, MANY_OR_NONE)
В описании пакета есть несколько примеров с гифками, поэтому предлагаю незамедлительно ознакомиться и попробовать! https://github.com/parsers-dev/sql-type-tracker
А пока пример на утверждение про тесты.
Давайте предположим, что у вас было как-то поле, у которого было ограничение NOT NULL. В процессе запиливания новой фичи стало понятно, что это ограничение нужно убрать.
Вы написали тесты для проверки поведения новой фичи с учетом этого самого возможного NULL.
А теперь несколько вопросов:
- как много запросов используют это поле для передачи его в приложение?
- как много запросов опираются на это поле при фильтрации и в джойнах?
- сломаются ли старые тесты без данного ограничения?
Правильные ответы - ХЗ, ХЗ и еще раз ХЗ.
Кажется, что самый важный из этих вопросов - последний. И ответ на него зависит от того как у вас устроены интеграционные тесты. Но в абсолютном большинстве случаев тесты ничего не покажут.
А чем нам это может грозить?
- в приложение попадут NULL в те места, где проверки на NULL нет
- джойны вместо 1 записи могут теперь выдавать 0 или наоборот много записей
В старых тестах все отлично - там мы эту ситуацию не ожидаем. По уму необходимо взять все существующие тесты и дописать на каждый кейс, который затрагивается этим NULL'ом, дополнительные тесты.
А какие кейсы затрагиваются этим NULL'ом?
И тут оказывается, что важными были все три вопроса...
И ответы появятся только на проде и только когда по новой фиче польются данные. В ночь с пятницы на субботу :)
В этом месте становится понятно, что нужно увеличивать бюджет на тестирование, найм и закладывать побольше времени...
Кстати, я надеюсь, что вы проверяете класс количества строк результата в приложении? :)
Давайте еще уточним, что этот NULL появился из-за нормализации данных, например. И там, где у нас данные тянулись из 1 таблицы, теперь они тянутся из двух. Нам нужно переписать Все запросы, где такое происходит.
Ок, не вопрос. Грепаем по имени таблицы все запросы и идем править.
И случайно в процессе копипасты, у нас в результат запроса попадает не то поле, которое нужно, а поле с таким же именем из другой таблицы. Тут id, там id... И типы одинаковые. И NULL'ов нет. Но данные теперь скомпрометированы!
Вот бы круто, если бы такое изменение можно было найти автоматом...
Ну вы поняли? https://github.com/parsers-dev/sql-type-tracker :)
Лайк, шер, пулл-реквест :)
PS: на higload2019 я делал доклад на эту тему.
PPS: смотреть необязательно :)
Ну, во-первых, это красиво...
Постоянно на глаза попадаются какие-то странные и крутые штуки - вещи, арт, архитектура, природа.
Решил запилить отдельный канал, куда буду скидывать такое:
@wellfirstofallitsbeautiful
Как говорится, нужно культурно расти, иначе....
Если что-то интересное будет попадаться, присылайте :)
Постоянно на глаза попадаются какие-то странные и крутые штуки - вещи, арт, архитектура, природа.
Решил запилить отдельный канал, куда буду скидывать такое:
@wellfirstofallitsbeautiful
Как говорится, нужно культурно расти, иначе....
Если что-то интересное будет попадаться, присылайте :)
Все уже забыли, что я не только про базы, но и так, про потерянные полимеры тоже... :)
Forwarded from Kedr to Earth | Земля, я Кедр (✅ Yuri Ammosov)
Оказывается, когда Adobe недавно окончательно и глобально отключил Flash... в Китае на целый день перестала работать железная дорога в Даляне. У них все управление через Flash делалось - расписание, формирование составов, путевые операции... Айтишники решили проблему, поставив пиратку Flash.
https://verietyinfo.com/taiwaneng/after-disabling-adobe-flash-trains-in-dalian-china-could-hardly-open-technews-%E7%A7%91%E6%8A%80-%E6%96%B0-%E6%8A%A5/
https://verietyinfo.com/taiwaneng/after-disabling-adobe-flash-trains-in-dalian-china-could-hardly-open-technews-%E7%A7%91%E6%8A%80-%E6%96%B0-%E6%8A%A5/
SQL эксплорер для S3.
Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля:
https://twitter.com/phil_eaton/status/1353372050023456768
Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля:
https://twitter.com/phil_eaton/status/1353372050023456768
GitHub
GitHub - eatonphil/gosql: An early PostgreSQL implementation in Go
An early PostgreSQL implementation in Go. Contribute to eatonphil/gosql development by creating an account on GitHub.
"Опыт приходит сразу после того, как был нужен" - золотые слова :)
Облака: Выбирайте наши managed продукты! Мы возьмем с вас в вагон денег, но за это вам будет доступна вся наша экспертиза!
Также облака: Расставляйте условия в WHERE в оптимальном порядке сами, мы за вас еще тут думать должны?!
Bigquery assumes that the user has provided the best order of expressions in the WHERE clause, and does not attempt to reorder expressions. Expressions in your WHERE clauses should be ordered with the most selective expression first.
https://wklytech.medium.com/bigquery-sql-optimization-c7a7db170c56
Также облака: Расставляйте условия в WHERE в оптимальном порядке сами, мы за вас еще тут думать должны?!
Bigquery assumes that the user has provided the best order of expressions in the WHERE clause, and does not attempt to reorder expressions. Expressions in your WHERE clauses should be ordered with the most selective expression first.
https://wklytech.medium.com/bigquery-sql-optimization-c7a7db170c56
There will be no singularity
SQL эксплорер для S3. Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля: https://twitter.com/phil_eaton/status/1353372050023456768
все уже украдено до нас (с):
https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html
https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html
Amazon
SELECT Command - Amazon Simple Storage Service
Overview of the SELECT SQL command supported by Amazon S3 Select.
There will be no singularity
все уже украдено до нас (с): https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html
и еще:
https://aws.amazon.com/athena/
Simply point to your data in Amazon S3, define the schema, and start querying using standard SQL
https://aws.amazon.com/athena/
Simply point to your data in Amazon S3, define the schema, and start querying using standard SQL
Amazon
Interactive SQL - Amazon Athena - AWS
Amazon Athena is a serverless, interactive analytics service that provides a simplified and flexible way to analyze petabytes of data where it lives.
Решил я тут с flow перебраться на typenoscript.
"Хватит извращений и закопали стюардессу" (c) анекдот
Пару дней поковырялся. Тулинг, конечно, огонь. Все быстро, работает, подсказки подсказывают.
Но он же, блин, не строгий. Ну совсем. Flow в этом плане до сих пор его уделывает, несмотря на то, что flow делает по большому счету 2 человека из фейсбука.
Пока наблюдения такие:
- нет exact типов. Их попросили 4 года назад!!! flow / typenoscript
- не понимает фильтрацию null'ов. flow / tуpenoscript
- flow умеет матчить файлы с json с типами, указанными в приложении, ts нет:
3.5 года назад был вот такой видос со сравнением typenoscript vs flow. Такое ощущение, что ms недалеко продвинулись c того времени...
Меня люто бомбит, что никто из них не ругается на
Короче, буду держать вас в курсе :)
"хватит извращений и закопали стюардессу"
--- сейчас вы находитесь здесь ---
"хватит извращений и откопали стюардессу"
PS: еще про тулинг. Поставил tabnine. Он даже помогает. Подозреваю, что еще немножко обучится и будет совсем хорошо.
PPS: есть еще такая тулза от отечественного производителя. Я как-то пробовал, у меня не завелось. Надо будет еще разок...
"Хватит извращений и закопали стюардессу" (c) анекдот
Пару дней поковырялся. Тулинг, конечно, огонь. Все быстро, работает, подсказки подсказывают.
Но он же, блин, не строгий. Ну совсем. Flow в этом плане до сих пор его уделывает, несмотря на то, что flow делает по большому счету 2 человека из фейсбука.
Пока наблюдения такие:
- нет exact типов. Их попросили 4 года назад!!! flow / typenoscript
- не понимает фильтрацию null'ов. flow / tуpenoscript
- flow умеет матчить файлы с json с типами, указанными в приложении, ts нет:
const a:ConfigType = require('./config.json')
И это я только начал :)3.5 года назад был вот такой видос со сравнением typenoscript vs flow. Такое ощущение, что ms недалеко продвинулись c того времени...
Меня люто бомбит, что никто из них не ругается на
[{}].includes('wtf?!')
Сколько времени было убито на дебаг...Короче, буду держать вас в курсе :)
"хватит извращений и закопали стюардессу"
--- сейчас вы находитесь здесь ---
"хватит извращений и откопали стюардессу"
PS: еще про тулинг. Поставил tabnine. Он даже помогает. Подозреваю, что еще немножко обучится и будет совсем хорошо.
PPS: есть еще такая тулза от отечественного производителя. Я как-то пробовал, у меня не завелось. Надо будет еще разок...
На последний пост flow vs typenoscript приехала пояснительная бригада и в каментах накидала хаков. Делюсь:
1) хак на exact типы
2) фильтрация на null
3) json не типизируется через require, но типизируется через import
4)
Продолжаю наблюдение...
1) хак на exact типы
2) фильтрация на null
3) json не типизируется через require, но типизируется через import
4)
[{}].includes('wtf?!') действительно не работает, но если будет не пустой объект, а что-то понятное, то все будет ок (во flow, кстати, не будет)Продолжаю наблюдение...
There will be no singularity
На последний пост flow vs typenoscript приехала пояснительная бригада и в каментах накидала хаков. Делюсь: 1) хак на exact типы 2) фильтрация на null 3) json не типизируется через require, но типизируется через import 4) [{}].includes('wtf?!') действительно…
Я, оказывается, уже как-то бомбил про includes :)
Там еще есть пара моментов. Например, дефолтные значения функций
https://news.1rj.ru/str/nosingularity/261
Там еще есть пара моментов. Например, дефолтные значения функций
https://news.1rj.ru/str/nosingularity/261
Telegram
Сингулярности не будет (18+)
открытое письмо, блин :)
@jitbit написал как он решал боль с тринарным оператором:
https://news.1rj.ru/str/devfounder/18
У меня есть пара комментариев, которые явно не тянули на отдельную статью, но теперь можно :)
Тут, безусловно, опыт накладывает отпечаток,…
@jitbit написал как он решал боль с тринарным оператором:
https://news.1rj.ru/str/devfounder/18
У меня есть пара комментариев, которые явно не тянули на отдельную статью, но теперь можно :)
Тут, безусловно, опыт накладывает отпечаток,…
Forwarded from Jem
Гляньте по ссылке в твите исходники WebKit
Cтолько захардкоженных доменов и хаков для них вы ещё не видели
https://twitter.com/jordwalke/status/1355681285717385217
Cтолько захардкоженных доменов и хаков для них вы ещё не видели
https://twitter.com/jordwalke/status/1355681285717385217
Twitter
jordwalke
Getting iOS Safari to not scroll to focused inputs is tricky, but it's possible for the determined. All you have to do is: 1. Get MBA. 2. Become CEO of Zillow. 3. Run Zillow into the ground and transfer zillow.com domain name to your website.
Автор замечательного канала @devfounder напомнил мне сейчас про товарищей из seekwell.io
У них, оказывается, есть плагин для хрома, который дает возможность выполнять SQL-запросы к Google Sheets и другим урлам. Денег за это, кажется, не просят, но выглядит жутковато :)
Пользуясь случаем напомню про мою подборочку коллекцию экзотических применений SQL (1-6: https://news.1rj.ru/str/nosingularity/595, 7: https://news.1rj.ru/str/nosingularity/651) (этот же список на гитхабе)
У них, оказывается, есть плагин для хрома, который дает возможность выполнять SQL-запросы к Google Sheets и другим урлам. Денег за это, кажется, не просят, но выглядит жутковато :)
Пользуясь случаем напомню про мою подборочку коллекцию экзотических применений SQL (1-6: https://news.1rj.ru/str/nosingularity/595, 7: https://news.1rj.ru/str/nosingularity/651) (этот же список на гитхабе)