Используя пароль, в аккаунте компании постят некую условную дичь, у компании определённый убыток.
Это скорее ущерб деловой репутации, неправомерный доступ и т.д. но никак не относится ни к NDA, ни к коммерческой тайне. И юридически правильно это называется не убыток, а упущенная выгода или недополученная прибыль.
Автор хоть и пишет на ИТ ресурсе, но кажется сам не понимает, что аутентификация пользователя не имеет никакого отношения к NDA. Тем более по описанному в статье примере.
Если SMM передал свой пароль, и на сайте опубликовали левый материал, то за это будет отвечать именно SMM, так как по формальным критериям это сделал именно он сам. Либо ему придется доказывать, что его взломали, пытали и прочее.
А если с помощью этого логина-пароля заходят 10 человек или с помощью логина SMM можно войти в корпоративную сеть для чтения коммерческой информации, то тут проблема не в пароле, а либо к ИТ отделу, либо это неправомерный доступ к компьютерной информации, но опять же NDA тут не причем.
Мда... Я же вам даже специально процитировал, что такое логин и пароль.
А вы в курсе, что при нормально настроенной политике безопасности в компании, пароль пользователя не знает даже системный администратор (это такой самый главный человек по компьютерам), да и пользователь может поменять пароль в любой момент? Другими словами, даже если бы использование логина и пароля для аутентификации пользователей требовался режим коммерческой тайны, то расписываться было бы не за что?
Коммерческая тайна — это информация, которую компания не разглашает, чтобы увеличить доходы, избежать неоправданных расходов, сохранить или улучшить своё положение на рынке либо получить любую другую коммерческую выгоду.
Логин и пароль - это способ аутентификации пользователя в компьютерной системе или на сайте.
Наталья, Вы точно уверены, что логин и пароль попадают под категорию "коммерческой тайны" и для его использования нужно расписываться в журнале ознакомления с коммерческой тайной компании?
А вы уверены, что дело было именно так, как вам рассказал ваш знакомый? Ведь время постановки задачи на тестирование фиксируется в трекерах.
Тогда как вполне могло случиться так, что тестировщик согласился поработать сверурочно из-за релиза, но на работу забил (сказал, что тесты прогнал, а хотя реально нет), из-за этого выкатили в сырое в прод. И вот в этом случае решение менеджера будет вполне оправдано, а вам (знакомой, которая не в проекте) можно рассказать все, что угодно.
Просто последнее время старый термин "проект" (работы, планы, мероприятия и т.д.) чаще интерпретируется как "создание продукт" (устройство, работа или услуга). Соответственно и в инструментах, которые требуются для управления работами в ограничениях (например, диаграмма ганта), уже нет острой необходимости.
Ведь даже у вас в подписи стоит не только "Project manager", но и "Scrum master", т.е. тот, кто нацелен именно на продуктовую разработку.
Кажется видел тут на Хабре статью, в которой переопределяли менеджер памяти, чтобы достичь близкого к 100% процента покрытия тестами, но там реализация идеи была проще и красивей.
Перед тестом (или во время запуска) формировался счетчик вызовов malloc, по достижении которого функция возвращала ошибку. И при каждом вызове счетчик последовательно увеличивался от 1 до максимального. И все это работает без правки кода и непонятных наведенных ошибок.
Но там для подобных извращений была необходимость, т.к. процент покрытия тестами был определен контрактом и являлся одним из критериев приемки проекта, т.е. процент покрытия тестами был оформлен как одно из бизнес-требований.
Вы же сами написали "продуктовой", т.е целью является готовый и рабочий продукт, а не "написание тестов с имитацией ошибок, и чем они разнообразнее, тем лучше".
программа ломается на любое отклонение от идеальных условий - как раз то, что вы называете "индусский код".
Вы попутали теплое с мягким и если вам сильно хочется фаззинг, то возьмите какой нибудь готовый инструмент.
Повторю еще раз: Умные указатели не панацея и в рамках С++. ...
Умные указатели, это только инструмент, который позволяет упростить написание кода и исключить множество типовых ошибок. Но им, как и любым другим инструментом тоже нужно уметь пользоваться и помнить, что он подходит для решения не каждой задачи.
Соглашусь с утверждением, что юнит-тестирование слабо влияет на качество архитектуры программы. Но является фундаментом для программы с любым качеством архитектуры.
Кажется, вы не поняли мою мысль. Я пытался вам сказать, что лучше сосредоточиться на проверке качества выполнения целевой функции приложения, т.е. на работе бизнес логики, а генерация и обработка надуманных ошибок при ручном управлении памятью, это из области индусского кода. т.е. текста много, но пользы от этого мало, т.к. вы перераспределяется усилия команды (ограниченные ресурсы) на имитацию надуманных ошибок, обработка которых может быть сделана за счет правильной архитектуры приложения.
Более того, использование умных указателей (которых нет в Си) - также совсем не панацея от всего и подлежит тестированию.
С этим соглашусь, но тут есть другой архитектурный нюанс. Если С++ использовать нельзя или нежелательно (например в прошивках для микроконтроллеров), то нужно смотреть на конкретную задачу. Можно либо отказать от динамического выделения памяти (только статические буферы), либо делать С-ишный враппер над C++ библиотекой.
Плюсанул, так как когда-то давно тоже заморачивался подобными извращениями, чтобы повысить процент покрытия тестами.
Но потом стало очевидно, что голый "процент покрытия", это вспомогательный параметр оценки качества и подобные финты с эмуляцией ошибок выделения памяти помогают закрывать договора (в которых "процент покрытия" указан ключевым показателем), но слабо влияют на реальное качество кода.
Гораздо лучшая стратегия, реализовать архитектуру приложения без необходимости ручного управления памятью (shared_ptr, unique_ptr), а освободившиеся ресурсы перенаправить на тестирование логики, которая в свою очередь должна покрываться тестами на 100% без исключения.
большая часть опен сорса большими компаниями и пилится
Эта исключительно только та часть, которая используется у них в собственном бизнесе. И мне неизвестно ни одной компании, которая бы оплачивала разработки, которые ей потенциально не интересны. А вот финансирование свободных проектов как раз и позволяет развивать не только то, что интересно акулам бизнеса, но и в других направлениях.
"Опенсурс" может не иметь (и в подавляющем случае не имеет) своей торговой марки, как и торговая марка чаще всего не относится к ПО, т.к. это разные сущности. И хотя с помощью торговой марки можно защитить какой нибудь свободный проект, но это элементарно обходится обычным форком под другим именем.
При чем тут ГК? Вы хоть понимаете разницу между "пользователь ПО" и "владелец прав на экземпляр ПО"?
Когда пользователь скачивает сводный софт с сайта, условно, Ubuntu, то вместе с дистрибутивом он присоединяется к лицензионному договору и получает права и обязанности на данный экземпляр ПО под соответствующими лицензиями (GPLv2 и прочими) .
В вашем же случае "конечный пользователь-физлицо" является только пользователем в силу выполнения своих должностных обязанностей, но не является законным владельцем экземпляра ПО, не является участником данного договора присоединения и не может никак распоряжаться рабочим экземпляром ПО.
Это как МСВС. Она не нарушает GPL в силу того, что её нет в свободном доступе и поэтому нет пользователей, законных владельцев прав на экземпляр ПО, которые могли бы потребовать исходники для исполнения требований GPL. А реальные "конечные пользователи-физлицо", условно, военнослужащий, не имеет прав на экземпляр используемого ПО, чтобы потребовать исполнение договора присоединения под названием GPL.
А с чего вы взяли, что "конечный пользователь" в описанной мной схеме является физическое лицо? Данная схема разработана для тех случаев, когда покупателем выступает юридическое лицо, которое, например, заказывает доработку GPL продукта под свои нужды.
В этом случае, этап реального тестирования перед закрытием сделки неизбежен, и именно этот этап и будет являться временнЫм лагом, между созданием и передачей кода и получением права у заказчика на его дальнейшую публикацию.
Даже Столлман на "раглише" смог понять идею, но предупредил, что это будет иметь смысл только в том случае, если работа будет действительно выполняется, т.е. если это НЕ будет притворной сделкой.
Но вам похоже что либо объяснять бесполезно, вы же сразу заранее во всем уверены.
Это вы передергиваете, сразу навешивая ярлык притворной сделки. То, что вы процитировали, это я пересказал слова Столлмана из нашего обсуждения данных способов коммерциализации GPL.
Я привел два реальных способа, как не нарушая GPL создавать создавать коммерческую ценность для свободных проектов, помимо стандартной "продажи поддержки".
А то, что обмануть можно кого угодно, хоть с договором, так и без него, это не секрет, и провернуть это можно хоть с предложенными способами, так и без них. Причем, без них, это делать даже гораздо проще.
Это скорее ущерб деловой репутации, неправомерный доступ и т.д. но никак не относится ни к NDA, ни к коммерческой тайне. И юридически правильно это называется не
убыток, а упущенная выгода или недополученная прибыль.Автор хоть и пишет на ИТ ресурсе, но кажется сам не понимает, что аутентификация пользователя не имеет никакого отношения к NDA. Тем более по описанному в статье примере.
Если SMM передал свой пароль, и на сайте опубликовали левый материал, то за это будет отвечать именно SMM, так как по формальным критериям это сделал именно он сам. Либо ему придется доказывать, что его взломали, пытали и прочее.
А если с помощью этого логина-пароля заходят 10 человек или с помощью логина SMM можно войти в корпоративную сеть для чтения коммерческой информации, то тут проблема не в пароле, а либо к ИТ отделу, либо это неправомерный доступ к компьютерной информации, но опять же NDA тут не причем.
Мда... Я же вам даже специально процитировал, что такое логин и пароль.
А вы в курсе, что при нормально настроенной политике безопасности в компании, пароль пользователя не знает даже системный администратор (это такой самый главный человек по компьютерам), да и пользователь может поменять пароль в любой момент? Другими словами, даже если бы использование логина и пароля для аутентификации пользователей требовался режим коммерческой тайны, то расписываться было бы не за что?
Наталья, Вы точно уверены, что логин и пароль попадают под категорию "коммерческой тайны" и для его использования нужно расписываться в журнале ознакомления с коммерческой тайной компании?
А вы уверены, что дело было именно так, как вам рассказал ваш знакомый? Ведь время постановки задачи на тестирование фиксируется в трекерах.
Тогда как вполне могло случиться так, что тестировщик согласился поработать сверурочно из-за релиза, но на работу забил (сказал, что тесты прогнал, а хотя реально нет), из-за этого выкатили в сырое в прод. И вот в этом случае решение менеджера будет вполне оправдано, а вам (знакомой, которая не в проекте) можно рассказать все, что угодно.
Просто последнее время старый термин "проект" (работы, планы, мероприятия и т.д.) чаще интерпретируется как "создание продукт" (устройство, работа или услуга). Соответственно и в инструментах, которые требуются для управления работами в ограничениях (например, диаграмма ганта), уже нет острой необходимости.
Ведь даже у вас в подписи стоит не только "Project manager", но и "Scrum master", т.е. тот, кто нацелен именно на продуктовую разработку.
Без проблем!
Кажется видел тут на Хабре статью, в которой переопределяли менеджер памяти, чтобы достичь близкого к 100% процента покрытия тестами, но там реализация идеи была проще и красивей.
Перед тестом (или во время запуска) формировался счетчик вызовов malloc, по достижении которого функция возвращала ошибку. И при каждом вызове счетчик последовательно увеличивался от 1 до максимального. И все это работает без правки кода и непонятных наведенных ошибок.
Но там для подобных извращений была необходимость, т.к. процент покрытия тестами был определен контрактом и являлся одним из критериев приемки проекта, т.е. процент покрытия тестами был оформлен как одно из бизнес-требований.
Вы же сами написали "продуктовой", т.е целью является готовый и рабочий продукт, а не "написание тестов с имитацией ошибок, и чем они разнообразнее, тем лучше".
Вы попутали теплое с мягким и если вам сильно хочется фаззинг, то возьмите какой нибудь готовый инструмент.
Умные указатели, это только инструмент, который позволяет упростить написание кода и исключить множество типовых ошибок. Но им, как и любым другим инструментом тоже нужно уметь пользоваться и помнить, что он подходит для решения не каждой задачи.
Кажется, вы не поняли мою мысль. Я пытался вам сказать, что лучше сосредоточиться на проверке качества выполнения целевой функции приложения, т.е. на работе бизнес логики, а генерация и обработка надуманных ошибок при ручном управлении памятью, это из области индусского кода. т.е. текста много, но пользы от этого мало, т.к. вы перераспределяется усилия команды (ограниченные ресурсы) на имитацию надуманных ошибок, обработка которых может быть сделана за счет правильной архитектуры приложения.
С этим соглашусь, но тут есть другой архитектурный нюанс. Если С++ использовать нельзя или нежелательно (например в прошивках для микроконтроллеров), то нужно смотреть на конкретную задачу. Можно либо отказать от динамического выделения памяти (только статические буферы), либо делать С-ишный враппер над C++ библиотекой.
И да, все нужно тестировать:-)
Что значит "начнет"?
Плюсанул, так как когда-то давно тоже заморачивался подобными извращениями, чтобы повысить процент покрытия тестами.
Но потом стало очевидно, что голый "процент покрытия", это вспомогательный параметр оценки качества и подобные финты с эмуляцией ошибок выделения памяти помогают закрывать договора (в которых "процент покрытия" указан ключевым показателем), но слабо влияют на реальное качество кода.
Гораздо лучшая стратегия, реализовать архитектуру приложения без необходимости ручного управления памятью (shared_ptr, unique_ptr), а освободившиеся ресурсы перенаправить на тестирование логики, которая в свою очередь должна покрываться тестами на 100% без исключения.
Ага
Эта исключительно только та часть, которая используется у них в собственном бизнесе. И мне неизвестно ни одной компании, которая бы оплачивала разработки, которые ей потенциально не интересны. А вот финансирование свободных проектов как раз и позволяет развивать не только то, что интересно акулам бизнеса, но и в других направлениях.
"Опенсурс" может не иметь (и в подавляющем случае не имеет) своей торговой марки, как и торговая марка чаще всего не относится к ПО, т.к. это разные сущности.
И хотя с помощью торговой марки можно защитить какой нибудь свободный проект, но это элементарно обходится обычным форком под другим именем.
При чем тут ГК? Вы хоть понимаете разницу между "пользователь ПО" и "владелец прав на экземпляр ПО"?
Когда пользователь скачивает сводный софт с сайта, условно, Ubuntu, то вместе с дистрибутивом он присоединяется к лицензионному договору и получает права и обязанности на данный экземпляр ПО под соответствующими лицензиями (GPLv2 и прочими) .
В вашем же случае "конечный пользователь-физлицо" является только пользователем в силу выполнения своих должностных обязанностей, но не является законным владельцем экземпляра ПО, не является участником данного договора присоединения и не может никак распоряжаться рабочим экземпляром ПО.
Это как МСВС. Она не нарушает GPL в силу того, что её нет в свободном доступе и поэтому нет пользователей, законных владельцев прав на экземпляр ПО, которые могли бы потребовать исходники для исполнения требований GPL. А реальные "конечные пользователи-физлицо", условно, военнослужащий, не имеет прав на экземпляр используемого ПО, чтобы потребовать исполнение договора присоединения под названием GPL.
А с чего вы взяли, что "конечный пользователь" в описанной мной схеме является физическое лицо? Данная схема разработана для тех случаев, когда покупателем выступает юридическое лицо, которое, например, заказывает доработку GPL продукта под свои нужды.
В этом случае, этап реального тестирования перед закрытием сделки неизбежен, и именно этот этап и будет являться временнЫм лагом, между созданием и передачей кода и получением права у заказчика на его дальнейшую публикацию.
Даже Столлман на "раглише" смог понять идею, но предупредил, что это будет иметь смысл только в том случае, если работа будет действительно выполняется, т.е. если это НЕ будет притворной сделкой.
Но вам похоже что либо объяснять бесполезно, вы же сразу заранее во всем уверены.
Свободное, это не даром!
Это вы передергиваете, сразу навешивая ярлык притворной сделки.
То, что вы процитировали, это я пересказал слова Столлмана из нашего обсуждения данных способов коммерциализации GPL.
Я привел два реальных способа, как не нарушая GPL создавать создавать коммерческую ценность для свободных проектов, помимо стандартной "продажи поддержки".
А то, что обмануть можно кого угодно, хоть с договором, так и без него, это не секрет, и провернуть это можно хоть с предложенными способами, так и без них. Причем, без них, это делать даже гораздо проще.