Так можно отловить только сравнительно частые недостатки. Недостаток, проявляющийся в среднем раз в миллион полётов или раз в тысячу лет найти не удастся.
Тоже перепутали. Твердотопливные ускорители (правда не помню, переиспользовали ли их после Челленджера) и корабль-орбитер многоразовые. Только внешний топливный бак орбитера (большой и оранжевый) сгорал.
А вот на уровне разработчиков техдолг очень мешает выполнять работу.
А кто сказал, что работа должна быть лёгкой? Это ваша РАБота. При её выполнении положено уставать...
так пусть ответственные занимаются?
... И им за это платят зарплату. А если им кажется, что мало, то есть хэха.ру и аналогичные сайты... А новые сотрудники, нанятые вашим CTO взамен вам будут через какое-то время писать на хабр, что предыдущие сотрудники оставили проблемы в коде, а руководство не признаёт наличие проблем. It's the circle of life.
(a) То есть руководство должно взять на себя ответственность на увеличение сроков всех работ, а оно на это не шло, так как для него проблема не казалась сложной и требующей пересмотрах сроков всех команд.
(b) принимаются решения только после того, когда будет уверенность в успехе
Противоречие.
Т.е. либо на самом деле не было уверенности в успехе, хотя вам со своей стороны кажется, что уверенность у руководства есть (в конце концов, это их работа - внушать уверенность в выбранном ими курсе). Либо прав я в том, что все прекрасно знают, что они могут что-то не знать, либо что может что-то случиться вне зоны их влияния.
Ошибаетесь. Такая ситуация уже не первый год.
А я и не утверждал, что такой переход моментальный. Судя по вашим словам, у вас уже есть разрыв. Если при этом нет текучки, то честь и хвала вашему CTO и вашему руководству. Задачи исполняются удовлетворительно, значит они свою работу делают хорошо. А с неудобством и техдолгом положено работать уже вам.
Не понял аналогии. Раскройте, пожалуйста, детальнее
Эм.. Что здесь понимать. Вы же сами говорите: "CTO боится увольнения, потому вторит директору". Как в песне поётся: "Все хорошо, прекрасная маркиза, Дела идут и жизнь легка. Ни одного печального сюрприза, За исключением пустяка!"
Во всех остальных случаях всё наоборот - принимаются решения только после того, когда будет уверенность в успехе
Вы противоречите своей же статье. Все не дети и прекрасно понимают, что могут произойти события вне зоны их влияния: склад сгореть, разрабы уйти в запой или в другую компанию, провалив сроки. Но можно подстелить соломки: склад застраховать или не покупать его, а арендовать с "нормальными" условиями аренды, неустойку по проекту зафиксировать в капитале компании (или аутсорсить разработку с нормальной неустойкой) и т.д.
CTO боится увольнения, потому вторит директору и принимает крайне спорные решения с точке зрения технического специалиста. И при этом руководство описано на картинке в статье, то есть уже в отрыве от действительности.
Ну, я так понимаю, ваша компания как раз в переходе от первого состояния (хорошая прослойка, взлетающее в космос руководство) ко второму (разрыв в прослойке, постоянные мелкие факапы) . Раз вы написали статью, то до текучки рукой подать, если только ваш CTO не объяснит своему начальству, что из одной шкурки 10 шапок делать можно, но не очень хорошо. :)
Кстати, забыл упомянуть, что часто причиной разрыва становится "всё хорошо, прекрасная маркиза" с точки разрыва пирамиды...
Тут очень просто: в руководители часто выбиваются решительные люди, а хороняки остаются внизу. Поэтому с одной стороны "вверху" часто принимаются решения без 100% уверенности в успехе (и все там прекрасно понимают, что "может не взлететь" и "подстилают соломки"). А с другой стороны, "внизу" боятся скопипастить один модуль в роли нового MVP без досконального понимания и рефакторинга.
Более того, когда в компании хорошая прослойка (CTO/CIO и т.д.) и минимум техдолга, то "верхи" идут в отрыв от действительности, т.к. неудачности их решений компенсируются "заделами" (хорошей архитектурой, обученными "как для себя" сотрудниками и т.д). А когда плохая, то начинается текучка, которая заканчивается либо эпическим провалом, либо становлением/приходом более приспособленной к изменившейся действительности команды. Иногда эта текучка занимает годы, что вовсе не так плохо, т.к. при текучке компания не теряет навыки воспроизводства (путем обучения) кадров...
А решать конкретному исполнителю. Запускать ли проект с криворукими технарями, оставаться работать ли под руководством "космонавтов"...
Сокет это, сильно упрощенно, - пара файлов-пайпов. Клиенты ничего не делят, после установления соединения каждый общается по своей индивидуальной паре пайпов с сервером. Ну а сервер, понятное делое, понимает, от кого пришел запрос и в какой пайп кинуть ответ/событие.
К ТС тема для освещения: что такого особенного в X11-меню: где зарыты грабли - в самом протоколе или в Xlib/тулкитах, что во время активации меню некоторые вещи недоступны?
Но у вас же прикладной сервис, или более сложная система?
Если прикладной, то достаточно открыть внешние сервисы на каждой точке, анонсировать IP сервисов через DNS зону с достаточно коротким времени жизни, мониторить корректность работы, в случае аномалий отключать проблемный интерфейс через DNS. Балансировать/реплицировать можно, тунеллируя между серверами через тот же IPv4 (либо через IPv6, смотря что вышибет в конкретном инциденте).
Хотя по вашей схеме вы по сути получили ещё виртуалку-арбитра для мониторингов/профилактики сплитбрейнов, и гибкость по размещению узлов в совсем не связанных точках. Но и с вышеописанной схемой с третьей виртуалкой можно было бы получить то же самое (к тому же, дополнительно еще CDN подключить, наверное, не помешает)
Если хотите, можете скооперироваться с хабраюзером @Mithgol , чьё предложение по улучшению fido уже даже было поддержано на высшем уровне. Но что-то не пошло.
Передергивания и необъяснённые противоречия почти в каждом тезисе. Констатация мирового неравенства, упоминание ЯО "для сдерживания варваров" и тут же предположение, что технологии и свободные (насколько свободные, кстати?) рынки это порешают. И тому подобные моменты.
Спасибо за ответ. Да, я понимаю что много лет утекло и у JCP зависимости посвежее. Интересно просто, где граница между нормальным использованием сертифицированного СЭП/СКЗИ и какими-то действиями, которые могут этот статус пошатнуть...
Интересно, а вот эти хитрые манипуляции не делают полученную систему не соответсвующей пункту 63-ФЗ:
ст. 5 4. Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам: ... 2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
Или достаточно одного маленького куска CryptoPro JCP в проекте и уже "используются" нужные СЭП?
О, наконец-то я это нашёл (упомянутое вами положение).
Собственно, мои догадки подтвердились - по сути это просто особые счета в особой системе ЦБ. Там даже есть списание цифровых рублей по заявлению на бумажном носителе. %)
Разумные рекомендации. Единственное при предложении звонка на 2 минуты имеет смысл уточнять что будете обсуждать и почему это важно, что это блочит.
А бордовый или розовый можно?
Так можно отловить только сравнительно частые недостатки. Недостаток, проявляющийся в среднем раз в миллион полётов или раз в тысячу лет найти не удастся.
А есть хоть один Exynos? КМК, жизнь есть только на Qualcomm.
ЕМНИП, bazel произошёл от проприетарной внутренней системы сборки, так что можно предположить, что это не реклама, а требование к системе сборки.
А это в у вас происходило включая рабочее время?
Тоже перепутали. Твердотопливные ускорители (правда не помню, переиспользовали ли их после Челленджера) и корабль-орбитер многоразовые. Только внешний топливный бак орбитера (большой и оранжевый) сгорал.
А кто сказал, что работа должна быть лёгкой? Это ваша РАБота. При её выполнении положено уставать...
... И им за это платят зарплату. А если им кажется, что мало, то есть хэха.ру и аналогичные сайты... А новые сотрудники, нанятые вашим CTO взамен вам будут через какое-то время писать на хабр, что предыдущие сотрудники оставили проблемы в коде, а руководство не признаёт наличие проблем. It's the circle of life.
(a) То есть руководство должно взять на себя ответственность на увеличение сроков всех работ, а оно на это не шло, так как для него проблема не казалась сложной и требующей пересмотрах сроков всех команд.
(b) принимаются решения только после того, когда будет уверенность в успехе
Противоречие.
Т.е. либо на самом деле не было уверенности в успехе, хотя вам со своей стороны кажется, что уверенность у руководства есть (в конце концов, это их работа - внушать уверенность в выбранном ими курсе). Либо прав я в том, что все прекрасно знают, что они могут что-то не знать, либо что может что-то случиться вне зоны их влияния.
А я и не утверждал, что такой переход моментальный. Судя по вашим словам, у вас уже есть разрыв. Если при этом нет текучки, то честь и хвала вашему CTO и вашему руководству. Задачи исполняются удовлетворительно, значит они свою работу делают хорошо. А с неудобством и техдолгом положено работать уже вам.
Эм.. Что здесь понимать. Вы же сами говорите: "CTO боится увольнения, потому вторит директору". Как в песне поётся: "Все хорошо, прекрасная маркиза, Дела идут и жизнь легка.
Ни одного печального сюрприза, За исключением пустяка!"
Вы противоречите своей же статье. Все не дети и прекрасно понимают, что могут произойти события вне зоны их влияния: склад сгореть, разрабы уйти в запой или в другую компанию, провалив сроки. Но можно подстелить соломки: склад застраховать или не покупать его, а арендовать с "нормальными" условиями аренды, неустойку по проекту зафиксировать в капитале компании (или аутсорсить разработку с нормальной неустойкой) и т.д.
Ну, я так понимаю, ваша компания как раз в переходе от первого состояния (хорошая прослойка, взлетающее в космос руководство) ко второму (разрыв в прослойке, постоянные мелкие факапы) . Раз вы написали статью, то до текучки рукой подать, если только ваш CTO не объяснит своему начальству, что из одной шкурки 10 шапок делать можно, но не очень хорошо. :)
Кстати, забыл упомянуть, что часто причиной разрыва становится "всё хорошо, прекрасная маркиза" с точки разрыва пирамиды...
Тут очень просто: в руководители часто выбиваются решительные люди, а хороняки остаются внизу. Поэтому с одной стороны "вверху" часто принимаются решения без 100% уверенности в успехе (и все там прекрасно понимают, что "может не взлететь" и "подстилают соломки"). А с другой стороны, "внизу" боятся скопипастить один модуль в роли нового MVP без досконального понимания и рефакторинга.
Более того, когда в компании хорошая прослойка (CTO/CIO и т.д.) и минимум техдолга, то "верхи" идут в отрыв от действительности, т.к. неудачности их решений компенсируются "заделами" (хорошей архитектурой, обученными "как для себя" сотрудниками и т.д). А когда плохая, то начинается текучка, которая заканчивается либо эпическим провалом, либо становлением/приходом более приспособленной к изменившейся действительности команды. Иногда эта текучка занимает годы, что вовсе не так плохо, т.к. при текучке компания не теряет навыки воспроизводства (путем обучения) кадров...
А решать конкретному исполнителю. Запускать ли проект с криворукими технарями, оставаться работать ли под руководством "космонавтов"...
Сокет это, сильно упрощенно, - пара файлов-пайпов. Клиенты ничего не делят, после установления соединения каждый общается по своей индивидуальной паре пайпов с сервером. Ну а сервер, понятное делое, понимает, от кого пришел запрос и в какой пайп кинуть ответ/событие.
К ТС тема для освещения: что такого особенного в X11-меню: где зарыты грабли - в самом протоколе или в Xlib/тулкитах, что во время активации меню некоторые вещи недоступны?
Но у вас же прикладной сервис, или более сложная система?
Если прикладной, то достаточно открыть внешние сервисы на каждой точке, анонсировать IP сервисов через DNS зону с достаточно коротким времени жизни, мониторить корректность работы, в случае аномалий отключать проблемный интерфейс через DNS. Балансировать/реплицировать можно, тунеллируя между серверами через тот же IPv4 (либо через IPv6, смотря что вышибет в конкретном инциденте).
Хотя по вашей схеме вы по сути получили ещё виртуалку-арбитра для мониторингов/профилактики сплитбрейнов, и гибкость по размещению узлов в совсем не связанных точках. Но и с вышеописанной схемой с третьей виртуалкой можно было бы получить то же самое (к тому же, дополнительно еще CDN подключить, наверное, не помешает)
Если хотите, можете скооперироваться с хабраюзером @Mithgol , чьё предложение по улучшению fido уже даже было поддержано на высшем уровне. Но что-то не пошло.
Хотя бы заблокировать возможность регистрации новых на 70-100 лет
Передергивания и необъяснённые противоречия почти в каждом тезисе. Констатация мирового неравенства, упоминание ЯО "для сдерживания варваров" и тут же предположение, что технологии и свободные (насколько свободные, кстати?) рынки это порешают. И тому подобные моменты.
Спасибо за ответ. Да, я понимаю что много лет утекло и у JCP зависимости посвежее. Интересно просто, где граница между нормальным использованием сертифицированного СЭП/СКЗИ и какими-то действиями, которые могут этот статус пошатнуть...
Интересно, а вот эти хитрые манипуляции не делают полученную систему не соответсвующей пункту 63-ФЗ:
ст. 5
4. Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
...
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
Или достаточно одного маленького куска CryptoPro JCP в проекте и уже "используются" нужные СЭП?
А откуда информация про основанность на "технологии блокчейн"? Ниже привели Положение ЦБ - там есть даже списание по заявлению на бумажном носителе.
О, наконец-то я это нашёл (упомянутое вами положение).
Собственно, мои догадки подтвердились - по сути это просто особые счета в особой системе ЦБ. Там даже есть списание цифровых рублей по заявлению на бумажном носителе. %)