у нас трубы отопления целиком пластиковые (или металлопластиковые я отличий не знаю). и стояки и подводы, меняло УК централизовано…
Означает ли это, что у нас звиздец, если да то куда звонить? кому писать?
— Какие доказательства надежности и безопасности беспилотного автомобиля должны вам привести разработчики, чтобы вы сегодня сели в такой автомобиль (без водителя) и поехали по дорогам общего пользования?
а совсем без руля? или опционального включения?
для опционального мне было бы достаточно видеороликов с показанным поведением автомобиля в различных аварийноопасных ситуациях.
а без опции только после 2-5 лет массовой эксплуатации кем то другим :D
Я не вижу ничего страшного успеть за время обучения ознакомиться сначала с ЛОГО/Черепашкой/Scratch, затем с Паскалем/Си, а затем и с Питоном/Lua/Swift/C#/Java на что преподавателя хватит.
И провести через систему обучения последовательно
алгоритмику — функциональное программирование — ООП, а дальше факультативно (если не углубленная программа) уже любые расширения: графика, многопоточность, клиент-сервер, СУБД и т.д.
Давайте, расскажите нам какие предметы «базовые»? и чем «базовая» органическая химия/физика/биология/ полезнее «базовой» информатики?
В школе как раз и должен даваться максимальный спектр известных наук. В достаточно ограниченном объеме и основы одного или двух ЯП нужны примерно также как знания о том из чего состоит молекула спирта.
Учить надо на таких языках, на которых грязно написать в разы сложнее чем на Питоне. Иначе как дать нормальное понимание хотя бы базовых структур типа числа, символа, строки? Как они в памяти хранятся, как обрабатываются?
Используем подход 3. только инструмент Dbmaintain http://www.dbmaintain.org/overview.html Он достаточно сильно похож на flywaydb, но оказался более удобным.
Сначала по «минусам» 3 подхода.
Нельзя выделить историю изменения одного объекта, alter’ы на один объект разбросаны по многим скриптам, многим файликам.
«нельзя» слишком сильное слово. Поиск возможен только по файлам в репозитории, или, если вы храните примененные скрипты в БД, то по таблице. Значит и получить историю изменении можно (файлы то пронумерованы и может быть даже разложены по версиям).
Отлично работает для поиска относительно недавних изменений (до года)
Более старые изменения уходят в Baseline, то есть придется попрыгать по коммитам в git чтобы откопать что-то действительно старое.
При параллельной работе двух программистов, они могут создать скрипты с одинаковыми номерами.
В базе — да. Однако это легко решается программным созданием скриптов из шаблона. Заодним программист сразу видит что ему надо указать кроме его любимого alter….
Раз уж подход скриптоцентрированный, то не хватает фич:
— Некоторые скрипты хотелось бы накатывать при их изменении. То есть добавил строчку в скрипт версионируемого справочника, и он исполнился, и строчка в таблице появилась. В таком виде можно хранить историю изменения данных (см подход 4).
Нет этого минуса. Flyway DB позволяет делать повторяющиеся миграции https://flywaydb.org/documentation/migration/repeatable
Dbmaintain тоже это умеет. «добавил строчку — чексумма файла изменилась — скрипт применился»
— Некоторые скрипты хотелось бы накатывать при каждом deploy’е – это, например, какая-нибудь очистка, занесение персистентных справочников, которые должны версионироваться (поэтому их нельзя заносить вручную в БД).
И снова нет. Согласен, что Flyway это не умеет =-) Однако Dbmaintain позволяет добавить как скрипты, выполняющиеся ДО основных изменений, так и скрипты выполняющиеся ПОСЛЕ основных изменений. Так что это не минус подхода. это минус конкретного инструмента.
В последовательности произвольных скриптов крайне сложно разбираться. Создание таблиц, их alter’ы, добавление строчек в справочники, миграции – разбросаны практически хаотично в одной последовательности.
Какой же это недостаток? Cкрипты идеально расположены в порядке выполнения, который всегда (почти ;) ) одинаков. Упавший скрипт сразу дает не только информацию по конкретной ошибке, но и всю картину текущего состояния базы. Какие скрипты уже применены, какие еще не применены. Это гораздо полезнее чем разложенные по папочкам скрипты, которые не пойми применились или нет.
Считаю безусловным плюсом инкрементального подхода.
Хотелось бы иметь алфавитную сортировку файликов, различные папочки. Словом, хочется в скриптах видеть структуру БД. Можно, конечно, что-то придумать – сделать кучу папочек, сделать огромный bat, запускающий инструмент на эти папочки в нужном порядке… Да, это начало следующего подхода, 4го.
Это можно и без 4… да и структура каталогов может отталкиваться не от схем в БД ) В тоже время чем проще итоговый архив обновления, тем лучше. Если обновление зашивается в артефакты новой версии, то там при любой начальной структуре надо будет выполнять действия по правильной упаковке, с учетом платформ и специфики ПО.
добавлю к минусам подхода 4
Минус 4. Конфликты в управляющих файлах
Так как последовательность исполнения скриптов важна, вводим управляющие файлы, содержащие последовательность наката скриптов,
Если предположить что у нас не 2 разработчика, а 10, то уже не избежать постоянных конфликтов при мерже данных управляющих файлов из личных веток в общий ствол.
В Канбане возможны очень те же «проблемы», собственно там будет происходить так нелюбимый всеми «простой ресурсов» из-за узких мест, которые хорошо выявляет наличие ограничения по WiP.
Аналитики могут завалить разработчиков и ждать пока те разгребут проанализированные задачи. Разработчики -> тестировщиков. Если есть жизнь после тестирования — то тестировщики следующих за ними (например «специалисты по развертыванию»)
Конечно хорошо бы все эти узкие места расширять. Но в моей практике не взлетело. В результате спринты остались лучше по прогнозируемости чем канбан.
Согласен. Их же не зря придумали и есть случаи, когда использование Defferable оправдано и полезно.
К тому же, при наступлении подобного вашему случая, достаточно указать set constraints all deferred; точно на время подобной вставки. Что будет явно означать, что ожидаются неконсистентные данные, которые можно коммитить только после полной загрузки.
Но. Статья претендует на набор граблей/хороших практик и «как надо, а как не надо делать», а в ней написаны достаточно спорные вещи. Отношение к Deferrable тому пример.
Или рекомендация использовать With. Что тоже совсем не полезно для запросов. Ниже об этом уже написали.
Или «Боль! Перед тем, как написать delete или update, напишите where»
гораздо полезнее писать SET AUTOCOMMIT OFF! Всегда!
Потому что только это позволит оценить последствия до их применения. Хотя бы по количеству удаленных записей.
Плохо учить падаванов спорным практикам. Их приходится потом мучительно переучивать.
В остальном пункты здравые, спасибо автору за статью. Я себе занес в список ссылок, который стоит показывать разработчикам :)
это совсем не похоже ни на технику безопасности ни на «хорошую практику»
применимо к приложению это создает исключения только на этапе коммита, вместо генерации исключения на этапе insert/update/delete, что точно плохо сказывается на диагностике неполадки.
К тому же, поддерживать согласованность всегда полезно для выстраивания логики кода. Гораздо сложнее выстрелить себе в ногу при длинных транзакциях
Так случилось, что я учился (1990-2001) в экспериментальном классе, где информатика была с первого класса (г. Мурманск 43шк). Сейчас конечно точно не вспомню последовательность обучения, но начинали точно с простых вещей, что такое клавиатура, мышка, кушали букавки babytype, рисовали в paint или какой то ранний его аналог.
Далее шли алгоритмы, черепашка. Потом Кумир, фразу «если то иначе все» я помню до сих пор :D. qbasic, pascal. Также точно помню давались базовые знания по офису, интернету.
Мне никогда не казалось это чем то сложным или не по возрасту.
Судя по посту эксперимент, к сожалению, не прошел в общую школьную программу.
Означает ли это, что у нас звиздец, если да то куда звонить? кому писать?
а совсем без руля? или опционального включения?
для опционального мне было бы достаточно видеороликов с показанным поведением автомобиля в различных аварийноопасных ситуациях.
а без опции только после 2-5 лет массовой эксплуатации кем то другим :D
И провести через систему обучения последовательно
алгоритмику — функциональное программирование — ООП, а дальше факультативно (если не углубленная программа) уже любые расширения: графика, многопоточность, клиент-сервер, СУБД и т.д.
В школе как раз и должен даваться максимальный спектр известных наук. В достаточно ограниченном объеме и основы одного или двух ЯП нужны примерно также как знания о том из чего состоит молекула спирта.
market.yandex.ru/product/1721935093?show-uid=112682443653709204316001&nid=54544&glfilter=5085104%3A12106116&glfilter=15083339%3A15083349&glfilter=15083355%3A15083360&context=search
никак не 72к
Сначала по «минусам» 3 подхода.
«нельзя» слишком сильное слово. Поиск возможен только по файлам в репозитории, или, если вы храните примененные скрипты в БД, то по таблице. Значит и получить историю изменении можно (файлы то пронумерованы и может быть даже разложены по версиям).
Отлично работает для поиска относительно недавних изменений (до года)
Более старые изменения уходят в Baseline, то есть придется попрыгать по коммитам в git чтобы откопать что-то действительно старое.
В базе — да. Однако это легко решается программным созданием скриптов из шаблона. Заодним программист сразу видит что ему надо указать кроме его любимого alter….
Нет этого минуса. Flyway DB позволяет делать повторяющиеся миграции https://flywaydb.org/documentation/migration/repeatable
Dbmaintain тоже это умеет. «добавил строчку — чексумма файла изменилась — скрипт применился»
И снова нет. Согласен, что Flyway это не умеет =-) Однако Dbmaintain позволяет добавить как скрипты, выполняющиеся ДО основных изменений, так и скрипты выполняющиеся ПОСЛЕ основных изменений. Так что это не минус подхода. это минус конкретного инструмента.
Какой же это недостаток? Cкрипты идеально расположены в порядке выполнения, который всегда (почти ;) ) одинаков. Упавший скрипт сразу дает не только информацию по конкретной ошибке, но и всю картину текущего состояния базы. Какие скрипты уже применены, какие еще не применены. Это гораздо полезнее чем разложенные по папочкам скрипты, которые не пойми применились или нет.
Считаю безусловным плюсом инкрементального подхода.
Это можно и без 4… да и структура каталогов может отталкиваться не от схем в БД ) В тоже время чем проще итоговый архив обновления, тем лучше. Если обновление зашивается в артефакты новой версии, то там при любой начальной структуре надо будет выполнять действия по правильной упаковке, с учетом платформ и специфики ПО.
добавлю к минусам подхода 4
Минус 4. Конфликты в управляющих файлах
Если предположить что у нас не 2 разработчика, а 10, то уже не избежать постоянных конфликтов при мерже данных управляющих файлов из личных веток в общий ствол.
Аналитики могут завалить разработчиков и ждать пока те разгребут проанализированные задачи. Разработчики -> тестировщиков. Если есть жизнь после тестирования — то тестировщики следующих за ними (например «специалисты по развертыванию»)
Конечно хорошо бы все эти узкие места расширять. Но в моей практике не взлетело. В результате спринты остались лучше по прогнозируемости чем канбан.
К тому же, при наступлении подобного вашему случая, достаточно указать set constraints all deferred; точно на время подобной вставки. Что будет явно означать, что ожидаются неконсистентные данные, которые можно коммитить только после полной загрузки.
Но. Статья претендует на набор граблей/хороших практик и «как надо, а как не надо делать», а в ней написаны достаточно спорные вещи. Отношение к Deferrable тому пример.
Или рекомендация использовать With. Что тоже совсем не полезно для запросов. Ниже об этом уже написали.
Или «Боль! Перед тем, как написать delete или update, напишите where»
гораздо полезнее писать SET AUTOCOMMIT OFF! Всегда!
Потому что только это позволит оценить последствия до их применения. Хотя бы по количеству удаленных записей.
Плохо учить падаванов спорным практикам. Их приходится потом мучительно переучивать.
В остальном пункты здравые, спасибо автору за статью. Я себе занес в список ссылок, который стоит показывать разработчикам :)
применимо к приложению это создает исключения только на этапе коммита, вместо генерации исключения на этапе insert/update/delete, что точно плохо сказывается на диагностике неполадки.
К тому же, поддерживать согласованность всегда полезно для выстраивания логики кода. Гораздо сложнее выстрелить себе в ногу при длинных транзакциях
deferrable initially deferred только затруднит поиск ошибки.
Далее шли алгоритмы, черепашка. Потом Кумир, фразу «если то иначе все» я помню до сих пор :D. qbasic, pascal. Также точно помню давались базовые знания по офису, интернету.
Мне никогда не казалось это чем то сложным или не по возрасту.
Судя по посту эксперимент, к сожалению, не прошел в общую школьную программу.