Мониторинг не нужен просто так, сам для себя. Должен быть кто-то, кто получит алерт, обработает его и пойдёт положит ещё мышек и проводов. Можно и в слепую раз в неделю взять тележку с добром, и пройтись по всем точкам раздачи кампуса, пополнить запасы. Все равно надо в переговорках проверить маркеры и карандаши, в принтерные принести бумагу.
ФСБ обращается, швейцарская компания ей отвечает что ничего не знает и сообщать не будет. Всё, история на этом заканчивается. ФСБ, конечно, может подать иск в швейцарский суд, но нужны более серьезные доказательства чем просто письмо с айпи-адреса.
Все же, сделать File.LoadToString несравнимо проще, чем правильно собрать потоки. Потом ещё окажется, что нужен случайный доступ к записям и придётся ещё что-то изобретать. Конечно, когда речь идёт о миллиардах записей, это все имеет смысл. Но бывает что там файлец-то в пару килобайт, а вы человека шлангом отмудохали. Неудобно как-то.
С хорошим ТЗ любая работа легче делается. У нас или разработчики обнаружат что поле логина на макетах нигде не подписано, и нужно срочно дозаказывать переводы. Или переводчики прочитают описание, но нихрена не поймут и переведут как смогут.
Вы свои ТЗ тестируете как-то?
Процессы отдельного управления действительно сильно не оптимизировать, потому что большой поток входящих от смежных управлений. Но есть стойкое ощущение, что вообще вся эта бюрократическая деятельность производится в основном ради бюрократии. На системном уровне 90% процессов можно (да и нужно) просто исключить.
Когда вы используете какой-то язык программирования, вы неизбежно приносите в проект код этого языка и библиотек. А его тоже кто-то написал, и будьте уверены, о багах и уязвимостях они побеспокоились.
Возможно там есть аппаратная защита от записи на загрузочный носитель, возможно и нет. Все же, наличие такой защиты вызывает серьезные неудобства в обслуживании и само может быть причиной сбоев.
В аэробусах давно делают fly-by-wire. У пилота только джойстик, и без участия бортового компьютера управление в принципе невозможно. Понятно, что там и резервирование и защиты на всех уровнях и вообще, но гипотетически БК можно перепрограммировать так, чтобы произошло что-то плохое и пилоты тут будут бессильны.
Развлекательная система в этом контексте как раз и может быть использована для атаки на БК, ну, если бы у них были каналы связи друг с другом, конечно.
Если специалист может запустить скрипт immediate_deconstruct в бортовом компьютере, то собственно ему ничего не мешает запустить там скрипт типа while(true) if(now() < 2020-11-11) sleep() else immediate_deconstruct. И спокойно долететь до конца маршрута. Сесть в другой самолёт и там это повторить, и так раз 50.
Чтобы приподнять градус паранои, можно себе представить что это происходит прямо сейчас, или уже произошло и эти скрипты просто ждут своего часа.
Тут речь про другое немного. Представьте, что есть две системы А и Б. И у злоумышленника есть доступ только к системе А, но эти системы могут взаимодействовать между собой. Так вот если они «написаны на одном языке», то у них и уязвимости похожие. То есть, получилось взломать А — считай что и Б уже тоже под контролем. Если же системы собраны из разных костылей, то вместо одного взлома придется делать уже два. Вероятности что в обоих одновременно будут непропатченные уязвимости умножаются (вместо условного 0.001 будет уже всего 0.000001), и получается что раскладывать яйца по разным корзинкам несколько надежней.
Для привязки наблюдений надо знать положение Земли относительно не только Солнца, но и окружающих звёзд. И раз уж уже научились продолжительность года измерять с точностью до долей секунды, то лишние сутки определенно потребуют изменений.
С другой стороны, есть вероятность что после такого события астрономию признают лженаукой и коррективы в расчётах уже не потребуются, всех астрономов, например, сожгут на кострах.
А почему нельзя просто забить на такое удлинение года? Ну будет зима по чуть-чуть уползать, через сто лет будет не июль самым жарким, а октябрь — никто и не поймёт что не так. В Австралии вот живут же как-то. Проблемы, наверное будут у астрономов только, но они там пусть уж сами разбираются между собой.
«Вася» выяснял и выяснял требования до мельчайших деталей и строго бездумно им следовал
Это скорее про soft skills, когда джун всех уже достал, но профита от него все равно как от джуна.
Мой опыт показывает, что если исполнитель здорово облажается с приоритетами, весом параметра в целевой функции, например ему скажут что прод критичен для бизнеса, а он там тестить начнёт потому что «а что такого-то?» то могут и уволить. Хотя такое случается редко, все же люди чаще склонны слушать что им говорят.
Если же он неверно предположит значение параметра целевой функции, например скажет что сделает за неделю, а провозится месяц — то обычно за это не наказывают вообще, просто не дают более ответственных задач.
Да, но все равно не понятно, как в дискретном пространстве решений может быть несколько глобальных минимумов целевой функции. Не всегда известно, как этого минимума достичь, где он находится, и даже что это за функция. Но минимум ∃!.
Если нам важен какой-то параметр, его вес будет больше чем у тех, которые не важны. Например, у параметра «научная новизна» при разработке сайта-визитки вес будет скорее отрицательный. При подготовке доклада на конференцию наоборот, больше многих остальных.
С параметром «стабильность в проде» ситуация противоположная, для доклада это не важно, и его вес равен нолю, а для визитки это критично.
Но определять, надо ли, и до каких пределов жертвовать параметром А в пользу параметра Б — это именно ответственность тех, кого мы тут называем «бизнес».
Иногда эти приоритеты долго не меняются и очевидны, тогда Коля может сэкономить пару минут на расспросах, но можно и спросить, никого никогда за это не увольняли. А вот истории, когда Вася сам попытался угадать что важно а что нет, но не спросил и в результате промахнулся — обычно заканчиваются очень печально.
Что важно для бизнеса, а что нет как раз и определяет эти веса параметров. Как вы собрались выяснять, что важно для бизнеса не спрашивая при этом, что ему важно?
Мониторинг не нужен просто так, сам для себя. Должен быть кто-то, кто получит алерт, обработает его и пойдёт положит ещё мышек и проводов. Можно и в слепую раз в неделю взять тележку с добром, и пройтись по всем точкам раздачи кампуса, пополнить запасы. Все равно надо в переговорках проверить маркеры и карандаши, в принтерные принести бумагу.
— Где вы берёте хорошие ТЗ?
— Ну это в интересах менеджера, хз, как-то вот справляются.
Правильно я вас понял?
Я на разных языках программирую, большую часть приходится писать на английском :) потому и про ТЗ спрашиваю
С хорошим ТЗ любая работа легче делается. У нас или разработчики обнаружат что поле логина на макетах нигде не подписано, и нужно срочно дозаказывать переводы. Или переводчики прочитают описание, но нихрена не поймут и переведут как смогут.
Вы свои ТЗ тестируете как-то?
Предлагаете для тех, кто кнопку «аппрув» в ревью нажимает собеседовать отдельно, и уже их гонять по алгоритмам и Биг-О?
Процессы отдельного управления действительно сильно не оптимизировать, потому что большой поток входящих от смежных управлений. Но есть стойкое ощущение, что вообще вся эта бюрократическая деятельность производится в основном ради бюрократии. На системном уровне 90% процессов можно (да и нужно) просто исключить.
Когда вы используете какой-то язык программирования, вы неизбежно приносите в проект код этого языка и библиотек. А его тоже кто-то написал, и будьте уверены, о багах и уязвимостях они побеспокоились.
Возможно там есть аппаратная защита от записи на загрузочный носитель, возможно и нет. Все же, наличие такой защиты вызывает серьезные неудобства в обслуживании и само может быть причиной сбоев.
В аэробусах давно делают fly-by-wire. У пилота только джойстик, и без участия бортового компьютера управление в принципе невозможно. Понятно, что там и резервирование и защиты на всех уровнях и вообще, но гипотетически БК можно перепрограммировать так, чтобы произошло что-то плохое и пилоты тут будут бессильны.
Развлекательная система в этом контексте как раз и может быть использована для атаки на БК, ну, если бы у них были каналы связи друг с другом, конечно.
Чтобы приподнять градус паранои, можно себе представить что это происходит прямо сейчас, или уже произошло и эти скрипты просто ждут своего часа.
С другой стороны, есть вероятность что после такого события астрономию признают лженаукой и коррективы в расчётах уже не потребуются, всех астрономов, например, сожгут на кострах.
Мой опыт показывает, что если исполнитель здорово облажается с приоритетами, весом параметра в целевой функции, например ему скажут что прод критичен для бизнеса, а он там тестить начнёт потому что «а что такого-то?» то могут и уволить. Хотя такое случается редко, все же люди чаще склонны слушать что им говорят.
Если же он неверно предположит значение параметра целевой функции, например скажет что сделает за неделю, а провозится месяц — то обычно за это не наказывают вообще, просто не дают более ответственных задач.
С параметром «стабильность в проде» ситуация противоположная, для доклада это не важно, и его вес равен нолю, а для визитки это критично.
Но определять, надо ли, и до каких пределов жертвовать параметром А в пользу параметра Б — это именно ответственность тех, кого мы тут называем «бизнес».
Иногда эти приоритеты долго не меняются и очевидны, тогда Коля может сэкономить пару минут на расспросах, но можно и спросить, никого никогда за это не увольняли. А вот истории, когда Вася сам попытался угадать что важно а что нет, но не спросил и в результате промахнулся — обычно заканчиваются очень печально.
Что важно для бизнеса, а что нет как раз и определяет эти веса параметров. Как вы собрались выяснять, что важно для бизнеса не спрашивая при этом, что ему важно?