Самое крутое, что это сын депутата госдумы. Это ведь даже не какие-то махинации с ценными бумагами или гос. контрактом. Это чистой воды криминал, без всяких принципов. Наркотики из дипмиссии недавно всплывали. Что дальше, торговля оружием и людьми?
Судя по описанию, в процессе настройки нужно довольно много кликать мышкой. Значит ли это, что кликать нужно три раза, для каждого окружения и следить, чтобы в процессе работы все три как-то друг другу соответствовали?
По поводу отладки — нетривиальные функции часто работают с БД, S3 и прочим. Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке?
В теории выглядит очень привлекательно. Но мне до сих пор не ясно как такой способ построения системы дружит с
* отладкой
* тестированием
* контролем версий
* dev/stage/production окружением
Нет смысла бороться против системы по ее правилам, вы не выиграете никогда. Нужно требовать другие правила. Несколько сотен тысяч человек на улицах Москвы в течение 3-4 недель будут намного эффективнее любых жалоб. РКН знает что делает и готов к жалобам. Если только Жаров не полный идиот, то позиция согласована на самом верху и ему плевать на любое количество жалоб. Не зря же вертикаль власти строили все это время.
Но глава РКН уже ответил на ваш запрос, он считает, что блокируется только Телеграм. Либо он не в курсе что они делают, и тогда они все там идиоты и их надо заменить. Или же они все понимают. В любом случае, говорить с ними не о чем. Можно только требовать либо замены текущих людей на более компетентных, либо расформирования РКН вообще.
Если же сайты действительно выиграют суды, то РКН с радостью оплатит судебные издержки из ваших налогов.
Тем временем заблокировано уже 19 миллионов адресов. Но Жаров считает, что все это Телеграм, а добропорядочные сайты не пострадали. РКН обозначил свою позицию, вы действительно думаете, что с ними возможен диалог?
У нас в приложении все строки одной длины. Вы ерундой заниматься будете или чинить?
С радостью — я взял код функции, понял как он работает, внес правки чтобы он работал как вам надо. Если вам не нравится как работает новый код воображаемой функции, то расскажите как он теперь поломан и я буду «чинить» его дальше :)
Вы, что на полном серьезе размышляете про хеш функцию сигнатуры string -> bool? Вы ничего не путаете или у вас в проекте такие есть?
Ну а я не понимаю почему вы говорите, что у вас тесты ломкие.
Я привел достаточно аргументов выше. Если у вас есть комментарии к одном из них, то милости прошу озвучить их тут.
Я использую моки чтобы заменить внешние сервисы, которые я не контролирую, типа SaaS сервиса отправки почты, все остальное прекрасно стартует и используется прямо в тесте.
А никто не обещал хорошего легаси, а вам надо починить исходя из концепции «тестируем вход и выход».
Зачем мне ее чинить? Я заменю такую хеш функцию на 'return x.Length % 2 == 0;' и выкину все моки сделанные для ее тестов. А еще уволю разработчика, который додумался сделать *хеш функцию* сигнатуры string -> bool.
Если вы мне объясните как — я подумаю соглашаться ли с вами. Но раз Вы от ответа уходите — видимо концепция не очень.
Если не согласны с моей позицией и вам интересно продолжить дискуссию, то приводите контраргументы. Я не вижу как история с ILargeRangeSorter вообще связана с тем, о чем я говорю. Моя позиция очень простая, аргументы изложены выше.
Весь посыл моих сообщений состоит в нескольких простых идеях
— Unit тесты пошли из Smalltalk, а там они скорее похожи на то, что сейчас называется интеграционными тестами.
— Я противопоставляю подробность тестов их хрупкости. Чем более подробен тест, тем сильнее он завязан не реализацию и тем сложнее рефакторинг.
Как вывод, я предлагаю
— забыть о разговорах unit vs integration
— по возможности воспринимать всю программу как черный ящик и тестировать вход и выход, не влезать во внутренности этой самой программы.
Вы с чем из вышеперечисленного несогласны?
Предложенная вами хеш-функция отображает строки на bool. Это очень плохая хеш функция, вне зависимости от ее реализации.
«Идеальный» (юнит-)тест не должен проверять все возможные состояния, и, тем более, позволить восстановить алгоритм.
Собственно я с этого и начал, надо проверять вход и выход самого большого куска кода, в идеале всей программы. Более маленькие компоненты проверять только если это оправдано. В этом ключе споры unit vs integration вообще смысл теряют.
Про qsort — если я тестирую класс Sorter и в тестах мокаю сервис ISmallRangeSorter, то это говорит кое-что о том, как реализована сортировка.
Тесты не задают неявную модель системы, они явно проверяют соответствует ли модель, реализованная в коде, модели заданной в тестах.
В коде у нас не модель, в коде у нас сама система и есть. Код, в свою очередь, может моделировать что-то, но в данном контексте это не важно. В тестах есть знание о коде и чем подробнее тесты тем больше знания «просачивается» в тесты и тем сильнее они связаны.
Основная мысль была в том, что в Smalltalk, откуда все это идет, юнит тесты очень похожи на то, что мы называем интеграционным, в силу особенностей среды. А то, что мы делаем с моками это, в большинстве случаев, очень вредные действия.
По сути ваш ответ заключается в обсуждении необходимой степени подробности тестов, это я и прокомментирую.
Высокоуровневые тесты действительно не скажут вам, что будет если отвалится сеть. Можно в систему даже внести специальные «ручки», чтобы такие ошибки генерировать. Или же стабы/моки использовать в таких сценариях. Я предпочитаю «ручки», потому что с ними проще работать.
Утверждение (готов доказать как теорему) — чем тщательнее мы проверяем наш код тестом, тем больше информации о нашем коде перетекает в тест и тем сильнее он связан с нашим кодом. Чем сильнее эта связь, тем сильнее нужно менять тест при изменении нашего кода. «Идеальный» тест, проверяющий все возможные состояния, позволит нам точно восстановить алгоритм. Менее «идеальный» тест позволит восстановить только часть.
Пример — алгоритм сортировки qsort. Если мы проверяем, что алгоритм переключается на bubble sort при малом размере сортируемого диапазона, то такой тест нужно будет «убить» если мы переключимся на merge sort. При этом вход и выход останутся неизменными, клиенту этого кода будет, чаще всего, все равно.
Жуткая спекуляция — возможно этот эффект можно связать с эффектом ухудшения качества статистической модели при превышении определенного порога сложности, который специфичен для задачи. Это в статистике часто бывает и в ML в виде переобучения — когда модель точно повторяет данные, но слишком хрупкая, чтобы эффективно обобщать реальность.
Я это все к чему — тесты задают неявную модель системы. Если эта модель слишком подробная, она становится хрупкой и требует постоянной подгонки под изменяющуюся систему. Мы это видим, как необходимость переделывать много тестов при изменениях системы.
К сожалению умные книжки не дают рекомендаций по нахождению оптимальной «подробности» или «тщательности» тестов для заданной системы. Отсюда и все разговоры о unit vs integration vs functional vs regression vs any-other-type-of-tests. Нам, по сути, нужна теория, которая бы позволила определить степень подробности тестов для заданной системы и требований качества. Пока такой теории нет я плюю на разницу между unit/не unit, игнорирую авторитетов и пытаюсь найти оптимум «тщательности» путем последовательных приближений. Ошибку приближения оцениваю по степени попаболи от тестов при рефакторинге системы.
По моему все обсуждения тестов игнорирую самое важное. XP и TDD после него было предложено и опробовано в проекте на SmallTalk. Я совсем немного писал на этом языке и самое важное, что сразу бросается в глаза — не вы запускаете программу из IDE, а IDE интегрировано в программу. Вы можете затем IDE в релизе «вырезать» Как результат исчезает понятие «компиляция», вы просто меняете методы в работающей программе. В такой среде все внешние зависимости как правило тоже доступны. Проблема сложных сетапов исчезает, моки почти не нужны, а там где нужны Smalltalk позволяет все легко заменить. В такой среде вы действительно можете эффективно писать тесты и они действительно будут очень похожи на примеры кода. Причем ваши тесты будут ближе к тому, что называется сейчас интеграционным. Работать все будет быстро, тесты ведь запускаются в уже работающей IDE-программе.
ИМХО тестировать нужно только то, что может вызвать клиент вашей программы. По возможности избегая моков и тестирования всяких внутренних штук. Бизнес может и меняется очень быстро, но поля формы логина и логика его обработки довольно стабильна. То же касается и других требований, никто из бухгалтерии тракторный завод не делает, изменения более-менее плавные. А значит и формат входа и выхода более менее стабилен. Плюс нам платят как раз за то, чтобы при правильном вводе был правильный вывод, это и надо проверять на 100%. Остальное опционально.
Я этого подхода придерживаюсь уже 5 лет и с тех пор полюбил тесты. До этого, в течение пяти лет пытался научиться писать правильные юнит тесты, по заветам из книжек. Результат
гора моков — время, файлы, бд, сеть, ui, библиотеки, работающие со всем перечисленным. Тесты ведь должны быть независимыми и работать быстро. Что делать в line of business системах, которые, по сути, прослойки между юзером и БД, особо не уточняется.
Куча тестов на каждый модуль-класс.
Почти 0 багов ловится тестами, покрытие 80%.
Тесты массово валятся при малейшем рефакторинге (из за моков).
Поддержка тестов стоит больше поддержки программы.
А если работать с реальной системой, а не горой моков, то тестов становится в разы меньше и они работают — ловят баги и кушать особо не просят.
Если нет наблюдателей, то комиссия может бюллетени даже не считать. Они просто пишут, что им хочется в протокол и отсылают его в ТИК. Сами бюллетени упаковываются в мешки и никто на них больше никогда не смотрит и не пересчитывает. Так что да, просто нарисовали, поставили синей шариковой ручкой нужное количество голосов в нужной графе протокола.
Думаю, что нужную явку им прямо не говорят. Но на протяжении нескольких месяцев до выборов неоднократно озвучивают, что ожидается такое-то количество народу (такой-то процент за кандидата), если будет меньше, то влетит от начальства и премию не дадут. В распоряжении комиссии всегда есть неиспользованные бюллетени, их вбрасывать даже не нужно. Можно просто после закрытия участка проголосовать самостоятельно на лишних бюллетенях или же «нарисовать» нужные числа. Вбрасывать приходится когда на участке принципиальный наблюдатель сидит.
Подтверждаю каждое слово, особенно достают требовательные и бедные клиенты. Их можно понять, но контраст работы с нашими и американцами просто потрясает. В 10 меньше проблем в 10 раз больше денег. Все это, конечно же, не от того что наши «хуже», но от бедности и изолированности от остального мира.
В комментария советуют сменить страну, но в этом смысла большого нет. Жизнь и бизнес разные вещи, а в России можно жить достаточно комфортно. Систему менять нужно, но это не для хабра обсуждение.
Спасибо за статью. Есть ли где-то готовый набор практик и приемов, которые позволяют исключить или уменьшить вероятность получить XSS уязвимость? Это настолько уже обширная тема, что знать все методы XSS атак прикладному программисту просто невозможно. Нужны best practices, которые позволят избежать уязвимостей не вдаваясь в детали их реализации.
PS: К сожалению, судя по количеству комментариев, сообщество не очень интересуется этой темой :(
В Xamarin.Forms 2.5.0 получились такие показатели для страницы Hello World:
XAML без компиляции 441 мс
XAML с компиляцией 188 мс
Код на C# 182 мс.
182 мс это 5 кадров в секунду и это hello world. Если так для каждой незакешированной ячейки, то Xamarin.Forms есть куда еще расти (мягко говоря). Мне кажется вы могли замерить время jit (на android), либо время подгрузки каких-либо библиотек.
Я как-то мерял скорость маршалинга из C# в ObjC и назад и получалось, что разницы практически нет. Затраты на p/Invoke теряются на фоне типичных операций типа выставления текста (label.Text) и составляют доли %. То есть сам Xamarin оказывает незначительное влияние и точно не медленее ObjC/Swift. Forms другое дело, про них я ничего не знаю, всегда работал только с Native.
По поводу отладки — нетривиальные функции часто работают с БД, S3 и прочим. Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке?
* отладкой
* тестированием
* контролем версий
* dev/stage/production окружением
Если же сайты действительно выиграют суды, то РКН с радостью оплатит судебные издержки из ваших налогов.
Родителей, братьев и сестер тоже вывезете и организуете вид на жительство или тут оставите?
С радостью — я взял код функции, понял как он работает, внес правки чтобы он работал как вам надо. Если вам не нравится как работает новый код воображаемой функции, то расскажите как он теперь поломан и я буду «чинить» его дальше :)
Вы, что на полном серьезе размышляете про хеш функцию сигнатуры string -> bool? Вы ничего не путаете или у вас в проекте такие есть?
Я привел достаточно аргументов выше. Если у вас есть комментарии к одном из них, то милости прошу озвучить их тут.
Зачем мне ее чинить? Я заменю такую хеш функцию на 'return x.Length % 2 == 0;' и выкину все моки сделанные для ее тестов. А еще уволю разработчика, который додумался сделать *хеш функцию* сигнатуры string -> bool.
Если не согласны с моей позицией и вам интересно продолжить дискуссию, то приводите контраргументы. Я не вижу как история с ILargeRangeSorter вообще связана с тем, о чем я говорю. Моя позиция очень простая, аргументы изложены выше.
— Unit тесты пошли из Smalltalk, а там они скорее похожи на то, что сейчас называется интеграционными тестами.
— Я противопоставляю подробность тестов их хрупкости. Чем более подробен тест, тем сильнее он завязан не реализацию и тем сложнее рефакторинг.
Как вывод, я предлагаю
— забыть о разговорах unit vs integration
— по возможности воспринимать всю программу как черный ящик и тестировать вход и выход, не влезать во внутренности этой самой программы.
Вы с чем из вышеперечисленного несогласны?
Предложенная вами хеш-функция отображает строки на bool. Это очень плохая хеш функция, вне зависимости от ее реализации.
Собственно я с этого и начал, надо проверять вход и выход самого большого куска кода, в идеале всей программы. Более маленькие компоненты проверять только если это оправдано. В этом ключе споры unit vs integration вообще смысл теряют.
Про qsort — если я тестирую класс Sorter и в тестах мокаю сервис ISmallRangeSorter, то это говорит кое-что о том, как реализована сортировка.
В коде у нас не модель, в коде у нас сама система и есть. Код, в свою очередь, может моделировать что-то, но в данном контексте это не важно. В тестах есть знание о коде и чем подробнее тесты тем больше знания «просачивается» в тесты и тем сильнее они связаны.
По сути ваш ответ заключается в обсуждении необходимой степени подробности тестов, это я и прокомментирую.
Высокоуровневые тесты действительно не скажут вам, что будет если отвалится сеть. Можно в систему даже внести специальные «ручки», чтобы такие ошибки генерировать. Или же стабы/моки использовать в таких сценариях. Я предпочитаю «ручки», потому что с ними проще работать.
Утверждение (готов доказать как теорему) — чем тщательнее мы проверяем наш код тестом, тем больше информации о нашем коде перетекает в тест и тем сильнее он связан с нашим кодом. Чем сильнее эта связь, тем сильнее нужно менять тест при изменении нашего кода. «Идеальный» тест, проверяющий все возможные состояния, позволит нам точно восстановить алгоритм. Менее «идеальный» тест позволит восстановить только часть.
Пример — алгоритм сортировки qsort. Если мы проверяем, что алгоритм переключается на bubble sort при малом размере сортируемого диапазона, то такой тест нужно будет «убить» если мы переключимся на merge sort. При этом вход и выход останутся неизменными, клиенту этого кода будет, чаще всего, все равно.
Жуткая спекуляция — возможно этот эффект можно связать с эффектом ухудшения качества статистической модели при превышении определенного порога сложности, который специфичен для задачи. Это в статистике часто бывает и в ML в виде переобучения — когда модель точно повторяет данные, но слишком хрупкая, чтобы эффективно обобщать реальность.
Я это все к чему — тесты задают неявную модель системы. Если эта модель слишком подробная, она становится хрупкой и требует постоянной подгонки под изменяющуюся систему. Мы это видим, как необходимость переделывать много тестов при изменениях системы.
К сожалению умные книжки не дают рекомендаций по нахождению оптимальной «подробности» или «тщательности» тестов для заданной системы. Отсюда и все разговоры о unit vs integration vs functional vs regression vs any-other-type-of-tests. Нам, по сути, нужна теория, которая бы позволила определить степень подробности тестов для заданной системы и требований качества. Пока такой теории нет я плюю на разницу между unit/не unit, игнорирую авторитетов и пытаюсь найти оптимум «тщательности» путем последовательных приближений. Ошибку приближения оцениваю по степени попаболи от тестов при рефакторинге системы.
По моему все обсуждения тестов игнорирую самое важное. XP и TDD после него было предложено и опробовано в проекте на SmallTalk. Я совсем немного писал на этом языке и самое важное, что сразу бросается в глаза — не вы запускаете программу из IDE, а IDE интегрировано в программу. Вы можете затем IDE в релизе «вырезать» Как результат исчезает понятие «компиляция», вы просто меняете методы в работающей программе. В такой среде все внешние зависимости как правило тоже доступны. Проблема сложных сетапов исчезает, моки почти не нужны, а там где нужны Smalltalk позволяет все легко заменить. В такой среде вы действительно можете эффективно писать тесты и они действительно будут очень похожи на примеры кода. Причем ваши тесты будут ближе к тому, что называется сейчас интеграционным. Работать все будет быстро, тесты ведь запускаются в уже работающей IDE-программе.
ИМХО тестировать нужно только то, что может вызвать клиент вашей программы. По возможности избегая моков и тестирования всяких внутренних штук. Бизнес может и меняется очень быстро, но поля формы логина и логика его обработки довольно стабильна. То же касается и других требований, никто из бухгалтерии тракторный завод не делает, изменения более-менее плавные. А значит и формат входа и выхода более менее стабилен. Плюс нам платят как раз за то, чтобы при правильном вводе был правильный вывод, это и надо проверять на 100%. Остальное опционально.
Я этого подхода придерживаюсь уже 5 лет и с тех пор полюбил тесты. До этого, в течение пяти лет пытался научиться писать правильные юнит тесты, по заветам из книжек. Результат
А если работать с реальной системой, а не горой моков, то тестов становится в разы меньше и они работают — ловят баги и кушать особо не просят.
Думаю, что нужную явку им прямо не говорят. Но на протяжении нескольких месяцев до выборов неоднократно озвучивают, что ожидается такое-то количество народу (такой-то процент за кандидата), если будет меньше, то влетит от начальства и премию не дадут. В распоряжении комиссии всегда есть неиспользованные бюллетени, их вбрасывать даже не нужно. Можно просто после закрытия участка проголосовать самостоятельно на лишних бюллетенях или же «нарисовать» нужные числа. Вбрасывать приходится когда на участке принципиальный наблюдатель сидит.
В комментария советуют сменить страну, но в этом смысла большого нет. Жизнь и бизнес разные вещи, а в России можно жить достаточно комфортно. Систему менять нужно, но это не для хабра обсуждение.
PS: К сожалению, судя по количеству комментариев, сообщество не очень интересуется этой темой :(
182 мс это 5 кадров в секунду и это hello world. Если так для каждой незакешированной ячейки, то Xamarin.Forms есть куда еще расти (мягко говоря). Мне кажется вы могли замерить время jit (на android), либо время подгрузки каких-либо библиотек.
Я как-то мерял скорость маршалинга из C# в ObjC и назад и получалось, что разницы практически нет. Затраты на p/Invoke теряются на фоне типичных операций типа выставления текста (label.Text) и составляют доли %. То есть сам Xamarin оказывает незначительное влияние и точно не медленее ObjC/Swift. Forms другое дело, про них я ничего не знаю, всегда работал только с Native.