Тайм-бомбы в проектах = вечный заработок

[liamkin]

https://yro.slashdot.org/story/19/12/19 ... t-new-work

logic bombs Tinley surreptitiously planted into his projects caused them to malfunction after a certain preset amount of time. Because Siemens managers were unaware of the logic bombs and didn't know the cause of the malfunctions, they would call Tinley and ask him to fix the misbehaving projects
...
was sentenced to six months in prison and a fine of $7,500 in the scheme
...
А прокурор просил
faced as much as 10 years in prison and a $250,000 fine.
....

Что-то похожее видели? У нас парочка людей уволилась, и недолго после их ухода система ушла в даун. Некий сервис-аккаунт протух. Тайм-бомба? Тайм-бомба. Судить уродов!

[deev_a_v]

http://ponedelnik.info/society/1-y-khak ... na-svobode

[Serguei666]

https://yro.slashdot.org/story/19/12/19 ... t-new-work

logic bombs Tinley surreptitiously planted into his projects caused them to malfunction after a certain preset amount of time. Because Siemens managers were unaware of the logic bombs and didn't know the cause of the malfunctions, they would call Tinley and ask him to fix the misbehaving projects
...
was sentenced to six months in prison and a fine of $7,500 in the scheme
...
А прокурор просил
faced as much as 10 years in prison and a $250,000 fine.
....

Что-то похожее видели? У нас парочка людей уволилась, и недолго после их ухода система ушла в даун. Некий сервис-аккаунт протух. Тайм-бомба? Тайм-бомба. Судить уродов!

Чтобы осудить, нужно доказать преднамеренность
А в вашем случае просто забыли вовремя пароль сменить

[liamkin]

http://ponedelnik.info/society/1-y-khak ... na-svobode

да. Интересная статейка. Премии и дачи в ответ на фиксы на АвтоВАЗе.

[Мальчик-Одуванчик]

Дыра может быть и результатом обычного головотяпства.
В одной известной мне системе хранения данных был некий вторичный счетчик, используемый в контроле версий.
Он ограничивался 16 разрядами, а потом системе приходил кирдык. При нормальном использовании в нашей конторе его бы хватило лет на тридцать.
Но пришли эффективные менеджеры и решили заавтоматизировать всё и вся. Это еще совпало с покупкой сторонней компании, код которой тоже необходимо было внести в систему с сохранением истории. А вот там история насчитывала уже больше десятка лет активных изменений.
Первый раз её внесли нейдачно, а после второго раза счётчику оставалось не больше пары лет.

[Мальчик-Одуванчик]

Что-то похожее видели? У нас парочка людей уволилась, и недолго после их ухода система ушла в даун. Некий сервис-аккаунт протух. Тайм-бомба? Тайм-бомба. Судить уродов!

Самый простой случай если уволившийся человек занимался в том числе и обновлением сертификатов для разрабатываемого или поддерживаемого им приложения . Чаще всего эта процедура не формализована, не документирована и при уходе он мог просто забыть или не захотеть передавать эти знания. Вот и бомбануло.

[katit]

Вечный не зню, но я вставлял - только из соображений "а вдруг не заплатят"
Потом есс-но убирал сразу. Но один раз забыл

[Helmsman]

Дыра может быть и результатом обычного головотяпства.
В одной известной мне системе хранения данных был некий вторичный счетчик, используемый в контроле версий.
Он ограничивался 16 разрядами, а потом системе приходил кирдык. При нормальном использовании в нашей конторе его бы хватило лет на тридцать.
Но пришли эффективные менеджеры и решили заавтоматизировать всё и вся. Это еще совпало с покупкой сторонней компании, код которой тоже необходимо было внести в систему с сохранением истории. А вот там история насчитывала уже больше десятка лет активных изменений.
Первый раз её внесли нейдачно, а после второго раза счётчику оставалось не больше пары лет.

Бывает и "так задумано". Месяц назад занимался "проблемой 2020": у тестеров при переходе через 2020 слетали даты. Нашли древнюю функцию для добавления времени к дате. Оказалось, что она не может добавить больше 20 лет, ну а поскольку многие старые даты при конверсии заменили на 1/1/2000 получили то, что получили. Решение? Ведущие индусские умы отложили проблему на 10 лет, заменив ограничение в 20 лет на 30, хоть и советовали им убрать оное нафиг.

[vdfs]

Нашли древнюю функцию для добавления времени к дате

На чем же вы там пишете, что нет готовой функции добавления времени к дате?

[Helmsman]

Cobol/C/Pro*C. Функция на C. Когда-то 25 лет назад отцы-основатели написали свой набор функций для манипуляций с датами, которыми все пользуются. Там есть мелкие отклонения от стандарта, почему сделали именно так - не помню.

[ystar]

https://yro.slashdot.org/story/19/12/19 ... t-new-work

logic bombs Tinley surreptitiously planted into his projects caused them to malfunction after a certain preset amount of time. Because Siemens managers were unaware of the logic bombs and didn't know the cause of the malfunctions, they would call Tinley and ask him to fix the misbehaving projects
...
was sentenced to six months in prison and a fine of $7,500 in the scheme
...
А прокурор просил
faced as much as 10 years in prison and a $250,000 fine.
....

Что-то похожее видели? У нас парочка людей уволилась, и недолго после их ухода система ушла в даун. Некий сервис-аккаунт протух. Тайм-бомба? Тайм-бомба. Судить уродов!

а мне после увольнения прошлая работа перестала платить.

[Бубновый Валет]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

[voyager3]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

Клауд называется.

[ystar]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

[nyekimov]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

Разве база данных не должна изолироваться от логики и логика тестироваться без базы с dependency injection и мок данными? Или вы больше об integrational testing говорите?

Согласен, что тесты занимают много времени. Особенно в зависимости от платформ, например иос или андроид снэпшот тэстин для ui занимает кучу времени, так как каждый раз изолированно разворачивается и сворачивается симулятор.
Но тогда опять же можно разбивать тесты по приоритетам и назначению и на каждом пул риквесте гонять только что то важное. А вот общий ригрешн только по ночам.

Сейчас конечно зависит от компании, но у меня сложилось мнение, что специально нанимают автотестеров для поддержания тестов на легаси коде. В придачу к разработке всяких large tests.

[IvanGrozniy]

Вечный не зню, но я вставлял - только из соображений "а вдруг не заплатят"
Потом есс-но убирал сразу. Но один раз забыл

Я чуть со стула не упал... Как говорится "и эти люди запрещают нам ковыряться в носу!"

[IvanGrozniy]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

Разве база данных не должна изолироваться от логики и логика тестироваться без базы с dependency injection и мок данными? Или вы больше об integrational testing говорите?

Согласен, что тесты занимают много времени. Особенно в зависимости от платформ, например иос или андроид снэпшот тэстин для ui занимает кучу времени, так как каждый раз изолированно разворачивается и сворачивается симулятор.
Но тогда опять же можно разбивать тесты по приоритетам и назначению и на каждом пул риквесте гонять только что то важное. А вот общий ригрешн только по ночам.

Сейчас конечно зависит от компании, но у меня сложилось мнение, что специально нанимают автотестеров для поддержания тестов на легаси коде. В придачу к разработке всяких large tests.

Кто мешает тесты закомментировать? У нас начальство часто так делает, когда какую-нибудь свою залипуху в код суют, а мозгов для программирования не хватает

[nyekimov]

У нас в конторе программисты так тесты пишут, что они начинают валиться со временем)

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

Разве база данных не должна изолироваться от логики и логика тестироваться без базы с dependency injection и мок данными? Или вы больше об integrational testing говорите?

Согласен, что тесты занимают много времени. Особенно в зависимости от платформ, например иос или андроид снэпшот тэстин для ui занимает кучу времени, так как каждый раз изолированно разворачивается и сворачивается симулятор.
Но тогда опять же можно разбивать тесты по приоритетам и назначению и на каждом пул риквесте гонять только что то важное. А вот общий ригрешн только по ночам.

Сейчас конечно зависит от компании, но у меня сложилось мнение, что специально нанимают автотестеров для поддержания тестов на легаси коде. В придачу к разработке всяких large tests.

Кто мешает тесты закомментировать? У нас начальство часто так делает, когда какую-нибудь свою залипуху в код суют, а мозгов для программирования не хватает

Ага. Или написать вспомогательные мок классы и тестировать их ))

[Zachet]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

[nyekimov]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

[ystar]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

только проблема, что он ушел из гугл в тестлу, и кто его код будет саппортить?
хороший предревью сделан для того, чтобы остальным только логику критиковать было легче и поддерживать потом было просто. плюс чтобы ты не отнимал на дефолтные вещи время остальных.

если его проблема только код ревью заботила, то человек крутой, а ведь в гугле все технологии можно сказать "самописные"

в тесле хорошо бы тестировать перед тем как стекла бить.

[nyekimov]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

только проблема, что он ушел из гугл в тестлу, и кто его код будет саппортить?
хороший предревью сделан для того, чтобы остальным только логику критиковать было легче и поддерживать потом было просто. плюс чтобы ты не отнимал на дефолтные вещи время остальных.

если его проблема только код ревью заботила, то человек крутой, а ведь в гугле все технологии можно сказать "самописные"

в тесле хорошо бы тестировать перед тем как стекла бить.

Я за код ревью и более того, смотрел канал техлида опять же бывшего гуглера, и он там описывал процедуры код ревью принятые у него в команде и в принципе в общем, это именно так, как мы делаем с ребятами, кто имеет соответствующие навыки. Также в код ревью мы всегда пишем, что поменяй для future developer, и тем, кто не в курсе, поясняем, что этим левелопером может быть как сам он так и не обязательно.

Ну а тесла, в гугле как понимаю, многое уже на рельсы поставлено, компания все таки постарше теслы, а молодые наступают на одни и те же грабли.

[Palych]

А есть были ли прецеденты когда за такие бомбы (после предъявления их начальству) действительно получали деньги? Или хотя бы избегали увольнения достаточно долго.

[liamkin]

А есть были ли прецеденты когда за такие бомбы (после предъявления их начальству) действительно получали деньги? Или хотя бы избегали увольнения достаточно долго.

В-основном, это используется как йоб секьюрити. И причем все в курсе. "Наш незаменимый специалист!".