Просто нужно уметь возможность на момент миграции отключать "длинные транзакции" (например те же отчеты или другие миграции на этой же таблице). Если есть возможность или необходимость - можно оценивать, какие вообще транзакции идут сейчас по данной таблице и откладывать миграцию DDL на момент "все тихо", но это уже сложное решение. Или принудительно делать rollback для всех транзакций, а потом уже делать ALTER TABLE
Но ALTER TABLE my_table ADD COLUMN"требует блокировки ACCESS EXCLUSIVE. В большинстве случаев это может быть не заметным, но если идет выполнение длинной транзакции, то данное требование приведет к весьма заметной недоступности таблицы.Поэтому указанный подход нужно использовать очень аккуратно и не стоит использовать в ответах на собеседовании.
А толку-то, если нормально сделано, то там у каждого пароля своя соль и используется нормальный алгоритм типа bcrypt или более поздний, который сложен и для GPU и даже для квантовых компьютеров. Ну а если базу делали какие-то новички, то там ничего не поможет (
Как это "одна и та же роль"? Это вообще из разных реальностей термины.
Кстати, а где в scrum guide запрет на внесение изменений в спринт? В последних редакциях такого запрета нет, есть только "не вносятся изменения, которые могут поставить под угрозу Sprint Goal" и явно сказано "Поэтому SprintBacklog обновляется на протяжении всего Sprint по мере появления новых знаний".
А обучение Скраму в ОТУСе по какой, вообще, редакции осуществляется?
А сколько очередей (топиков) одновременно удалось поднять на pulsar и на каком железе? У кафки проблемы начинаются где-то с 100K, а как на пульсаре по вашему опыту?
А чем API Gateway помогает для улучшения наглядности? И так в любом логе или трейсинге видно, кто и кого вызывает. API Gateway для внутренних сервисов скорее усложняет отладку. Гораздо лучше API Gateway использовать для изоляции внешних запросов (для чего он обычно и делается).
Какие-то слабые «эффективные менеджеры», не смогли объяснить инвестору и координатору, что вы саботировали все их идеи и по этой причине произошла такая задержка. И вас не смогли уволить (а для грамотного эффективного менеджера, отжимающего на себя финансовые потоки — это вообще самое важное действие).
Такое ощущение, что эти менеджеры реально хотели сделать проект лучше, но это уже не «эффективные», а просто непрофессиональные.
Интерфейс делать сложно. А вот использовать Dart-овую общую прослойку для state managment/api managment для Web и Mobile — вполне реально, мы так делаем. Есть и плюсы и минусы, конечно.
По Коуберну — нужно менять методологию при каждом переходе из клетки в клетку и тут я с ним полностью согласен: начало проекта втроем и развитие проекта в команде из 20 человек — очень разные вещи, требующие сильно разных подходов и методологий.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
3. Про «конструктор».
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
2. Про «взрослые» и «аджайл» методологии. Вообще, и те и другие пришли сверху, отнюдь не из «девелоперской» среды. Просто они отвечают разным наборам страхов (тяжелые — потеря управляемости и выхода за границы бюджета, легкие — увеличения time-to-market и «сделать не то»).
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
Буду отвечать по пунктам, а то слишком сложно уже ориентироваться в большом тексте.
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
Хм, возможно я просто не в курсе. А есть какие-то научные работы по менеджменту? Соответствующие критериям Поппера? Или что вы имеете в виду под «теоретическими достижениями в управлении»? Лучшее, что я видел — это была не слишком корректная статистика, хотя приходится опираться на нее, конечно.
Спасибо за ответ.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
Вот собственно про движение от 722 и близких к нему к текущему Лего я и говорю. Когда вместо единообразия универсальных деталей появились гораздо более узко специализированные конструкторы с мелкими, но специфическими деталями. Когда появилось много узких линеек.
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )
Просто нужно уметь возможность на момент миграции отключать "длинные транзакции" (например те же отчеты или другие миграции на этой же таблице).
Если есть возможность или необходимость - можно оценивать, какие вообще транзакции идут сейчас по данной таблице и откладывать миграцию DDL на момент "все тихо", но это уже сложное решение.
Или принудительно делать rollback для всех транзакций, а потом уже делать ALTER TABLE
Но
ALTER TABLE my_table ADD COLUMN"требует блокировки ACCESS EXCLUSIVE. В большинстве случаев это может быть не заметным, но если идет выполнение длинной транзакции, то данное требование приведет к весьма заметной недоступности таблицы.Поэтому указанный подход нужно использовать очень аккуратно и не стоит использовать в ответах на собеседовании.И все клавиатуры из списка вредны для запястья, ни одной эргономичной.
И все без тачпада, так что придется руки часто переносить.
А толку-то, если нормально сделано, то там у каждого пароля своя соль и используется нормальный алгоритм типа bcrypt или более поздний, который сложен и для GPU и даже для квантовых компьютеров.
Ну а если базу делали какие-то новички, то там ничего не поможет (
Каким способом при переводе "purpose/why" превратилось в "некоторую компенсацию"?
Как это "одна и та же роль"? Это вообще из разных реальностей термины.
Кстати, а где в scrum guide запрет на внесение изменений в спринт? В последних редакциях такого запрета нет, есть только "не вносятся изменения, которые могут поставить под угрозу Sprint Goal" и явно сказано "Поэтому SprintBacklog обновляется на протяжении всего Sprint по мере появления новых знаний".
А обучение Скраму в ОТУСе по какой, вообще, редакции осуществляется?
А сколько очередей (топиков) одновременно удалось поднять на pulsar и на каком железе?
У кафки проблемы начинаются где-то с 100K, а как на пульсаре по вашему опыту?
Такое ощущение, что эти менеджеры реально хотели сделать проект лучше, но это уже не «эффективные», а просто непрофессиональные.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )