Переслал эту статью бывшей коллеге, чтобы услышать профессиональное мнение со стороны HR/PR и вот этого всего. И что вы думаете? Она не ответила. BA-DUM-TSS!
Если в конторе такой огромный поток кандидатов, то возможно стоит как-то (ну хотя бы чуть-чуть) регламентировать работу с гигантским количеством отказников. Например, сделать FAQ и добавить его в подпись для HR, типа "дорогой кандидат, мы очень ценим ваше желание работать с нами, но если вы не получаете ответ от наших специалистов, то это значит то-то и нужно делать (или не делать) то-то (например обратиться через год или навсегда забыть имэйл компании)". Вроде выглядит несложно.
Егор где-то сам говорил, что специально использует более резкие формулировки, чтобы привлечь внимание, заставить людей задуматься, переосмыслить что-то возможно. Why not?
Да, согласен, про лидирующие запятые это отдельная тема. Я там в конце статьи специально отметил, что способов для осей может быть много, это только пример.
А я правильно понимаю, что swagger-generator для spring до сих пор поддерживает в генерируемых контроллерах только springfox и не умеет springdoc?
Вот такой PR навшел github.com/OpenAPITools/openapi-generator/pull/6306
Итого, все что описано в статье, давно всем известно
Данная статья задумывалась как обновленная и более развернутая расшифровка одной из частей моего доклада с одноименным названием. Если здесь все понятно, то это хорошо.
и везде применяется
Идея не только в том, что везде используется SQL-код, а что относиться к нему стоит как к настоящему коду.
А что мы делаем с кодом — храним его в git'е, настраиваем всякие пайплайны чтобы им управлять, делаем ревью и вот это все. При чем это относится и к коду приложений и инфраструктурному коду.
В database as code тоже идея состоит в том, что весь SQL-код проходит через репозиторий (не только миграции). Написали запрос, закомитили, сделали merge request и он пошел по пайплайну.
А именно:
— запустились какие-то линтеры
— сделали ревью
— автотесты (почему бы и нет — github.com/dimitri/regresql)
— обновились доки и диаграммы в них
— в IDE/Manager добавилась новая закладка, где смотреть его результаты в более удобном виде, делать выгрузки всякие
— при необходимости начали собираться метрики на базе результатов запроса
— появился новый дашборд в Графане/Кибане на основании этих метрик
— и пр.
Спасибо, почитаю. У меня еще в wait-листе «Дефрагментация мозга», там вроде тоже что-то похожее.
На самом деле статья (и сама идея) не про маппинг, а про отношение, отношение к SQL-коду как к Коду.
Переведите, пожалуйста, что понимаете под «database as code» — из статьи это не получается определить.
Это мое небольшое хобби. Идея простая — если есть «infrastructure as code», «configuration as code» и пр., то где «database as code»? Причем в случае с БД даже не надо выдумывать никаких yml-ов, ведь уже есть настоящий код — это SQL.
Если интересно, то у меня есть еще одна статья на Хабре на эту тему, и небольшой доклад.
Готов ответить на любые вопросы (если они будут).
Переслал эту статью бывшей коллеге, чтобы услышать профессиональное мнение со стороны HR/PR и вот этого всего. И что вы думаете? Она не ответила. BA-DUM-TSS!
Спасибо за очередной великолепный Postgresso
PS Максим Грамин здесь, если будут вопросы/пожелания/предложения/угрозы, то милости прошу, в личку или на почту
Если в конторе такой огромный поток кандидатов, то возможно стоит как-то (ну хотя бы чуть-чуть) регламентировать работу с гигантским количеством отказников. Например, сделать FAQ и добавить его в подпись для HR, типа "дорогой кандидат, мы очень ценим ваше желание работать с нами, но если вы не получаете ответ от наших специалистов, то это значит то-то и нужно делать (или не делать) то-то (например обратиться через год или навсегда забыть имэйл компании)". Вроде выглядит несложно.
Если ещё актуально - гляньте плиз на мою поделку https://github.com/mgramin/malewicz Там можно любой API намутить, могу помочь если что
С хорошей IDE (а-ля datagrip) это не проблема
Да можно и не слушать в принципе )
Да наверное, особенно учитывая что чего-то такого готового большого и проверенного нету (только dbt может быть, но это про другое)
Егор где-то сам говорил, что специально использует более резкие формулировки, чтобы привлечь внимание, заставить людей задуматься, переосмыслить что-то возможно. Why not?
Есть ещё шаблонизация
Вот например в dbt это решается моделями (грубо говоря это sql-запрос), которые можно шаблонизировать и переиспользовать
Похоже генетическая память, многие так привыкли. По той же причине по которой секции светофора делают до сих пор круглыми
Да, согласен, про лидирующие запятые это отдельная тема. Я там в конце статьи специально отметил, что способов для осей может быть много, это только пример.
Мутационные тесты ещё есть
Вот такой PR навшел github.com/OpenAPITools/openapi-generator/pull/6306
Данная статья задумывалась как обновленная и более развернутая расшифровка одной из частей моего доклада с одноименным названием. Если здесь все понятно, то это хорошо.
Идея не только в том, что везде используется SQL-код, а что относиться к нему стоит как к настоящему коду.
А что мы делаем с кодом — храним его в git'е, настраиваем всякие пайплайны чтобы им управлять, делаем ревью и вот это все. При чем это относится и к коду приложений и инфраструктурному коду.
В database as code тоже идея состоит в том, что весь SQL-код проходит через репозиторий (не только миграции). Написали запрос, закомитили, сделали merge request и он пошел по пайплайну.
А именно:
— запустились какие-то линтеры
— сделали ревью
— автотесты (почему бы и нет — github.com/dimitri/regresql)
— обновились доки и диаграммы в них
— в IDE/Manager добавилась новая закладка, где смотреть его результаты в более удобном виде, делать выгрузки всякие
— при необходимости начали собираться метрики на базе результатов запроса
— появился новый дашборд в Графане/Кибане на основании этих метрик
— и пр.
На самом деле статья (и сама идея) не про маппинг, а про отношение, отношение к SQL-коду как к Коду.
Это мое небольшое хобби. Идея простая — если есть «infrastructure as code», «configuration as code» и пр., то где «database as code»? Причем в случае с БД даже не надо выдумывать никаких yml-ов, ведь уже есть настоящий код — это SQL.
Если интересно, то у меня есть еще одна статья на Хабре на эту тему, и небольшой доклад.
Готов ответить на любые вопросы (если они будут).
Да, и это одна из главных идей поста (по крайней мере я так планировал).
Т.е. фразу «мы не виделись сто лет» могут употреблять только долгожители? Я уже молчу про «со скоростью пули», «задушить в объятьях» и пр.
Приношу «тысячу извинений», что не оправдал Ваших надежд.
Вообще не думал, что такой безобидный речевой оборот вызовет столько полемики.
С какой целью интересуетесь моим образованием?