Кейс поучительный, но финальные абзацы про старые системы и пр. вне контекса просто сотрясание воздуха. Как общее правило да, не надо погонять мертвую лошадь, но конкретные случаи все особенные. Многие системы не полгода создаются, а десятилетиями.
Но какой ценой была достигнута цель спринта? Ростом нагрузки на сеть. Увеличением времени обработки запросов клиентов. Таймаутами. Решение было неоптимальным. У команды образовался техдолг.
Довольно-таки дискутируемый вопрос, даже вне контекста.
Есть ли деньги на разработку оптимального решения?
Каковы критерии оптимальности решения?
Много ли таких клиентов, которым надо отправлять пачку платежек?
Как вы в этом тысячелетии умудрились разработать клиент-банк, который отправляет платежки поштучно?
Отвечу и на вопросы.
Есть ли в вашей компании процесс управления техдолгом в целом и техдолгом аналитики в частности? - нет, технического долга собирается довольно мало, а делать что-то красивое вместо некрасивого обычно настолько затратно, что контролируется это верхним руководством, а не внутри команды к.-л. проекта
Как он организован? - всё в рамках управления проектом, если есть насущная нужда осовременить или доработать нечто - то это включается в план работы.
Какими инструментами пользуетесь? - JIRA
По большому счету, техдолг от бэклога в моем случае недалеко ушел.
Да нормально, скрининг проходят только особи, которые только что оторвали попу от табуретки, на которой кодили на том же фреймворке то же самое и у которых тимлидом был клон вашего тимлида.
Масса случаев - на сухариках и огурцах, вероятно, а не на мясе и пресловутой гречке. То есть проблемы в голове. С ними как бороться? Вот я отлично знаю, что даже на базовый уровень калорий кашу с мясом устану в себя запихивать. Но голова хочет того и сего - а не надо.
Вот этот комментарий не вызывает никакого несогласия, но в собственно статье делается (излишний?) упор на микрофлору. Может быть, правда в отсутствии стресса и в дефиците калорий, а уже потом в витаминах, пребиотиках и прочем?
Полностью согласен, не покупать же бюджетный ноут для конференций с установкой на него всего вот этого вот.
С другой стороны, вуз, который не может изобрести систему адекватного контроля знаний дистанционно, расписывается в собственной некомпетентности. Достаточно устно краткого опроса по итогам большого онлайн-теста. Это на поверхности лежит, а если крепко подумать?
It depends. Подозреваю, что большинство сеньоров не хотят руками водить. Anyway, квалифицированному специалисту гораздо легче сменить место работы, чем руководителю. И терять квалификацию не все захотят.
Мидл-менеджер сам пробьется, брать его не надо :)))
Чеклист приличный. Теперь еще написать инструкции по восстановлению работы на случай пожара в ДЦ, прилета инопланетян, заражения админского компьютера вирусом и т.д. и т.п.
А то получите нерабочий сервер, вышеописанный талмуд и блымающего глазами "нового человека". Другое дело - четкий доклад о ходе устранения инцидента...
Тендерная открытая документация это просто жесть жестяная, если читающий ее хоть немного в теме [тендера, само собой]. Не перестаю удивляться ее доступности.
в себя в ядро и специализированные аппаратно-программные комплексы для хирургии
Я понял, что я ничего не понял, ни тебе про ключевые фичи, ни про преимущества, а эту чудо-фразу вообще можно понимать как "разработан робохирург" - не знаю, пугаться или нет. Чем концептуально это отличается от зума? Что на иллюстрации?! При чем здесь ВКО? :)
если генератор основывается на выводе двоичного представления числа π с какой-то неизвестной точки, он не является криптографически устойчивым – при определении текущего бита числа π аналитик может вычислить и все предшествующие биты
Девиз статьи - "если трудностей нет - надо их создать" (и героически преодолевать с потерей большого количества серого вещества).
Для бухгалтерской отчетности нужно вычислять идентификатор следующего потенциального заказа. Вы храните это значение в отдельной таблице и после каждого заказа вычисляете его с помощью формулы last_order_id + 1. По мере роста нагрузки вам приходится слишком часто блокировать как таблицу заказов, так и таблицу, хранящую следующий идентификатор, пока он вычисляется.Де
Перед записью нового заказа получаете (мгновенно) новый сиквенс. По-хорошему заказы (зачем-то автор путает бухгалтерию, в которой нет вообще проблем обработать документы по факту их создания, и управление торговлей) надо писать в одном потоке. Фактически, будет единственный пользователь (ядро системы, обрабатывающее сложенные в асинхронную очередь новые заказы, а точнее, черновики), у которого особых проблем не будет ни с сиквенсом, ни с блокировками. Попытка нескольких пользователей заказать один и тот же товар - это скорее из области бизнес-логики (а также управления складскими остатками). Кто первый успел нажать Ок, тому и досталось, хотя видели остатки все одни и те же. Лояльный разработчик еще и подкрасит заканчивающийся товар. Эффективно работающая OLTP - это INSERT и больше (в идеале) ничего, проблемы с блокировками - это действительно проблемы плохой архитектуры.
MyISAM вообще не про финансовый учет, хотя для интернет-торговли можно и его использовать (ответственности не так уж много), но особого смысла нет. InnoDB в руки и вперед.
Скорее не так, сразу видишь почему оно не взлетит. Почему может взлететь, видишь тоже, но...
Кейс поучительный, но финальные абзацы про старые системы и пр. вне контекса просто сотрясание воздуха. Как общее правило да, не надо погонять мертвую лошадь, но конкретные случаи все особенные. Многие системы не полгода создаются, а десятилетиями.
Довольно-таки дискутируемый вопрос, даже вне контекста.
Есть ли деньги на разработку оптимального решения?
Каковы критерии оптимальности решения?
Много ли таких клиентов, которым надо отправлять пачку платежек?
Как вы в этом тысячелетии умудрились разработать клиент-банк, который отправляет платежки поштучно?
Отвечу и на вопросы.
Есть ли в вашей компании процесс управления техдолгом в целом и техдолгом аналитики в частности? - нет, технического долга собирается довольно мало, а делать что-то красивое вместо некрасивого обычно настолько затратно, что контролируется это верхним руководством, а не внутри команды к.-л. проекта
Как он организован? - всё в рамках управления проектом, если есть насущная нужда осовременить или доработать нечто - то это включается в план работы.
Какими инструментами пользуетесь? - JIRA
По большому счету, техдолг от бэклога в моем случае недалеко ушел.
Да нормально, скрининг проходят только особи, которые только что оторвали попу от табуретки, на которой кодили на том же фреймворке то же самое и у которых тимлидом был клон вашего тимлида.
Масса случаев - на сухариках и огурцах, вероятно, а не на мясе и пресловутой гречке. То есть проблемы в голове. С ними как бороться? Вот я отлично знаю, что даже на базовый уровень калорий кашу с мясом устану в себя запихивать. Но голова хочет того и сего - а не надо.
Вот этот комментарий не вызывает никакого несогласия, но в собственно статье делается (излишний?) упор на микрофлору. Может быть, правда в отсутствии стресса и в дефиците калорий, а уже потом в витаминах, пребиотиках и прочем?
Откинуть можно копыта, а предрассудки токмо отбросить :)))
Господа, это днище уже. Надо как-то стратифицировать публикации, ну там 12+, 25-...
Полностью согласен, не покупать же бюджетный ноут для конференций с установкой на него всего вот этого вот.
С другой стороны, вуз, который не может изобрести систему адекватного контроля знаний дистанционно, расписывается в собственной некомпетентности. Достаточно устно краткого опроса по итогам большого онлайн-теста. Это на поверхности лежит, а если крепко подумать?
Пора менять прокторинг на гэмблинг.
It depends. Подозреваю, что большинство сеньоров не хотят руками водить. Anyway, квалифицированному специалисту гораздо легче сменить место работы, чем руководителю. И терять квалификацию не все захотят.
Мидл-менеджер сам пробьется, брать его не надо :)))
Пешком до Москвы дошел бы и университет основал.
Корочка - ценз и какая-никакая гарантия культурного уровня. Знания... ну да, ну да...
Чеклист приличный. Теперь еще написать инструкции по восстановлению работы на случай пожара в ДЦ, прилета инопланетян, заражения админского компьютера вирусом и т.д. и т.п.
А то получите нерабочий сервер, вышеописанный талмуд и блымающего глазами "нового человека". Другое дело - четкий доклад о ходе устранения инцидента...
Тендерная открытая документация это просто жесть жестяная, если читающий ее хоть немного в теме [тендера, само собой]. Не перестаю удивляться ее доступности.
Я понял, что я ничего не понял, ни тебе про ключевые фичи, ни про преимущества, а эту чудо-фразу вообще можно понимать как "разработан робохирург" - не знаю, пугаться или нет. Чем концептуально это отличается от зума? Что на иллюстрации?! При чем здесь ВКО? :)
Вашу статью трудно читать ;) Местами предложения длинноваты. В жизни каждого автора должен быть кто-то, кто на это обратит внимание :)
Куда-куда их погрузят?!
Почему не связано. "ИТ и реальный мир", вполне себе интересный раздельчик получится.
Каким же образом?
Девиз статьи - "если трудностей нет - надо их создать" (и героически преодолевать с потерей большого количества серого вещества).
Перед записью нового заказа получаете (мгновенно) новый сиквенс. По-хорошему заказы (зачем-то автор путает бухгалтерию, в которой нет вообще проблем обработать документы по факту их создания, и управление торговлей) надо писать в одном потоке. Фактически, будет единственный пользователь (ядро системы, обрабатывающее сложенные в асинхронную очередь новые заказы, а точнее, черновики), у которого особых проблем не будет ни с сиквенсом, ни с блокировками. Попытка нескольких пользователей заказать один и тот же товар - это скорее из области бизнес-логики (а также управления складскими остатками). Кто первый успел нажать Ок, тому и досталось, хотя видели остатки все одни и те же. Лояльный разработчик еще и подкрасит заканчивающийся товар. Эффективно работающая OLTP - это INSERT и больше (в идеале) ничего, проблемы с блокировками - это действительно проблемы плохой архитектуры.
MyISAM вообще не про финансовый учет, хотя для интернет-торговли можно и его использовать (ответственности не так уж много), но особого смысла нет. InnoDB в руки и вперед.