Хм, насчет пункта 1 – есть абсолютно животрепещущий вопрос.
То есть, всё же гугл-карты позволяют сделать бескомпромиссный режим слежения за телефоном и его прозвон/блокировку в случае утери? Мне казалось, что основной проблемой любого стороннего приложения в мобильной ОС всегда будет отсутствие привилегий высокого уровня: игнорирование настроек сбережения электроэнергии (невыключабельность, одним словом), подавление настроек звукового профиля (функция нахождения по звуку), возможность блокировки и стирания контента пользователя.
Если я заблуждаюсь, и сторонние программы это позволяют решить путем обыкновенной установки и настройки, без дополнительных танцев с бубном, я бы с удовольствием ознакомился с такой информацией. Давно уже задумываюсь над тем, как бы решить эту проблему на своем Huawei P30.
Первый уже внедрил на одном проекте, а над вторым как раз подумываю. Какие у вас впечатления по этим полифиллам, если пользовались?
Мне обе фичи очень нравятся: диалоги — своей семантичностью и поддержкой нескольких плюшек (form method=dialog, showModal(), ::backdrop), а :focus-visible — возможностью сделать ненавязчивый focus ring, включающийся только при работе с клавиатуры.
Читал и узнавал себя. Сам питаю слабость к основательным рефакторам тогда, когда можно без них в принципе обойтись, и никто особо о них и не просил.
Единственное, в чем не соглашусь, так это в бесплодности таких мероприятий. Да, оказалось ненужно, но! Мне кажется, что в сухом итоге у автора добавилось боевого опыта работы с трудным запутанным кодом, и это тот скилл, который не приходит бесплатно, только в результате многократных и регулярных оттачиваний оного.
И в скоростной рефакторинг можно тоже выкидывать очки опыта, как в отдельную ветку своего дерева навыков. Главное, чтобы не всегда этот навык применялся вхолостую, а был когда-никогда нужен и востребован.
Хотелось бы понять, почему робот-гепард не может воспроизводить движения своего прообраза — то ли технически не получается, то ли разработчики принципиально не хотят, то ли текущий способ передвижения и так хорош...
В целом, с посылом статьи я согласен, и мне кажется уже изначально некорректно требовать 100% покрытия кода именно от юнит-тестов, ведь не каждая строка имеет одинаковую ценность и смысл.
Так, например, нередко приходится написать пространное полотно конфигурации (подписаться, отписаться на события, проинициализировать ряд вещей, передать им ссылки друг на друга), но все это само по себе не имеет никакого смысла и ценности в отрыве от той большой общей задачи, для которой вообще этот код был написан.
То есть, технически-то можно протестировать строчку за строчкой, но такие тесты будут практически бесполезны, так как подобная (решаемая конфигурационным кодом) задача попросту неосязаема для близоруких проверок юнит-тестов, и поддается рассмотрению лишь взору интеграционных и end-to-end тестов.
Но, даже если мы напишем более релевантные тесты для таких случаев, задействуя альтернативные инструменты, то может возникнуть другой вопрос — как совместить по разным инструментам задачу подсчета покрытия кода (и зачем)? Насчет первого — тут я даже не уверен, делает ли так кто либо… суммируют ли E2E+Integration+Unit coverage? Думаю, что да, но реже, чем стоило бы.
Зачем суммировать? Ну, положим, если все же мы будем суммировать покрытие, и у нас будут оставаться в коде места, которые ни разу не выполнились в ходе прогона самых разнообразных тестов, то тогда мы сможем идентифицировать все места в существующей кодовой базе, которые имеют неясное предназначение, потенциально являясь источником недоразумений и/или багов.
И, наконец, если это на поверку оказывается нужной логикой, и этот код имеет право на существования, то тут мы подходим к заключительному, не самому приятному вопросу. Почему нам не подошли существующие инструменты для тестирования такого кода?
А это реальная ведь ситуация. За примерами далеко ходить не надо, если взять фронт-энд разработку — как насчет затерянного одинокого экзотического обработчика события, срабатывающего только для мобильного браузера Windows Phone 7? Можно понять человека, отказавшегося покрывать это тестами и проверившего обработчик пару раз вручную на живом телефоне.
Я думаю, что если бы написать такой экзотический тест было бы не дольше 20-30 минут и 10-20 строчек кода, то грешно было бы не написать. Но если же это грозит такими радужными перспективами как писать разные костыли, прикручивать друг к другу проекты номинально несовместимые или малоподдерживаемые, то ради чего?
В любом случае, мы здесь выиграем в том, что выявим недостатки в существующих инструментах тестирования и потенциально сможем добиться их улучшения (если это того стоит, ха-ха, ибо пример с WP7, пожалуй, слишком «суров»). А если мы не захотим или не сможем этого сделать, то как минимум у нас в проекте засчет интегрального такого покрытия будет всегда актуальная обновляемая карта «белых пятен на карте», перепись эдаких тихих омутов с чертями, что позволит держать их популяцию под хоть каким-то, но контролем.
Я был достаточно высокого мнения об этом разработчике, чтобы сказать без обиняков
I had enough trust with the developer to bluntly say,
Может, лучше было бы перевести как-то вроде «У меня были достаточно доверительные отношения с этим разработчиком, чтобы сказать без обиняков», потому что, честно говоря, «высокое мнение» сбило с толку при чтении.
По теме последнего абзаца вашего комментария. Речь идет не только о переборе паролей на живом сайте, но больше о профилактике от раскалывания украденной базы паролей в сжатые сроки — насколько я понимаю, имея на руках хэши, соли и словарь часто используемых паролей, можно в сжатые сроки подобрать около 5-10% паролей минимум. То есть подобная валидация — это последняя линия защиты, когда база уже угнана, но владельцы сайта еще не знают об этом и не успели сбросить всем пользователям пароли и разослать публичное письмо об утечке. Не секрет, что с крупными сервисами это периодически происходит, так что эта линия защиты имхо имеет право на жизнь.
В принципе, я с этим утверждением согласен, но никто не мешает авторам автономного решения на JS подключить как бы невзначай аналитический сервис (хоть бы и Google Analytics), и отправить чего лишнего. Впрочем, можно поставить браузерное расширение, блокирующее сбор аналитики, но и тут нельзя быть уверенным на 100% в его прозрачности.
Я тут было подумал, что обрубить сбор информации можно гораздо проще и произачнее — отключиться от сети (авиарежим, WiFi, и т. п.), и выполнить проверку оффлайн, но ведь и тут засада — если сайт использует localStorage, Service Workers или некую другую комбинацию техник, то собранную информацию можно придержать до первого удобного случая и отправить позже.
По идее, добавление предосторожности в виде Incognito Mode поставит шах и мат в этой комбинации, так как не удастся накопить информацию в оффлайн-режиме, но и тут надо быть осторожным и не забыть закрыть все вкладки посещенного сайта-проверялки до того как вы включите интернет.
Я это все веду к тому, что «простому пользователю» для обеспечения безопасной проверки пароля в рамках некого веб-сервиса (причем безотносительно метода его доставки — автономное JS-приложение или почти чистое серверное) придется овладеть очень непростыми познаниями в предметной области или довериться экспертам, что тоже имеет свою цену и риски.
P. S. Кстати, можно было бы добавить в статью прямые ссылки на текстовые базы паролей 100,000 и 1,000,000, «для максимального эффекта».
Сколько времени у вас длится компиляция с TypeScript в JavaScript, раз уж речь идет о 250,000 строках кода? По личному опыту наблюдений на слабеньких машинках (например, Macbook Pro 13 2012 года) средний эдакий проект размером с 1000-1500 файлов компилируется около 20-30 секунд, а на мощных десктопах (как то Core i7-6700) от 8 до 15 секунд.
В принципе, эти цифры не такие и страшные, но не ропщут ли ваши разработчики, что раньше ждать ничего было не надо (если писать на ES5, скажем чисто для примера), а теперь на каждое изменение нужно сколько-то еще и ждать?
Конечно же, TypeScript со своей стороны предлагает пару-тройку вариантов ускорения сборки, но интересно, какие методики вы у себя в проекте используете дабы не ждать подолгу завершения компиляции?
В целом, подсчеты по другим ЯП у них уже есть (их можно увидеть в JSON API), но публичный доступ к ним организация пока не предоставляет. Сдается мне, что адекватность и точность выдачи там порядком ниже, чем для JS, и они хотят позаниматься тюнингом и дополнительной проверкой других ТОП-рейтингов, прежде чем их выкладывать в общий доступ.
Хм, насчет пункта 1 – есть абсолютно животрепещущий вопрос.
То есть, всё же гугл-карты позволяют сделать бескомпромиссный режим слежения за телефоном и его прозвон/блокировку в случае утери? Мне казалось, что основной проблемой любого стороннего приложения в мобильной ОС всегда будет отсутствие привилегий высокого уровня: игнорирование настроек сбережения электроэнергии (невыключабельность, одним словом), подавление настроек звукового профиля (функция нахождения по звуку), возможность блокировки и стирания контента пользователя.
Если я заблуждаюсь, и сторонние программы это позволяют решить путем обыкновенной установки и настройки, без дополнительных танцев с бубном, я бы с удовольствием ознакомился с такой информацией. Давно уже задумываюсь над тем, как бы решить эту проблему на своем Huawei P30.
Да, пользуюсь. Давеча было два юзкейса:
Первый уже внедрил на одном проекте, а над вторым как раз подумываю. Какие у вас впечатления по этим полифиллам, если пользовались?
Мне обе фичи очень нравятся: диалоги — своей семантичностью и поддержкой нескольких плюшек (form method=dialog, showModal(), ::backdrop), а :focus-visible — возможностью сделать ненавязчивый focus ring, включающийся только при работе с клавиатуры.
Читал и узнавал себя. Сам питаю слабость к основательным рефакторам тогда, когда можно без них в принципе обойтись, и никто особо о них и не просил.
Единственное, в чем не соглашусь, так это в бесплодности таких мероприятий. Да, оказалось ненужно, но! Мне кажется, что в сухом итоге у автора добавилось боевого опыта работы с трудным запутанным кодом, и это тот скилл, который не приходит бесплатно, только в результате многократных и регулярных оттачиваний оного.
И в скоростной рефакторинг можно тоже выкидывать очки опыта, как в отдельную ветку своего дерева навыков. Главное, чтобы не всегда этот навык применялся вхолостую, а был когда-никогда нужен и востребован.
Хотелось бы понять, почему робот-гепард не может воспроизводить движения своего прообраза — то ли технически не получается, то ли разработчики принципиально не хотят, то ли текущий способ передвижения и так хорош...
Так, например, нередко приходится написать пространное полотно конфигурации (подписаться, отписаться на события, проинициализировать ряд вещей, передать им ссылки друг на друга), но все это само по себе не имеет никакого смысла и ценности в отрыве от той большой общей задачи, для которой вообще этот код был написан.
То есть, технически-то можно протестировать строчку за строчкой, но такие тесты будут практически бесполезны, так как подобная (решаемая конфигурационным кодом) задача попросту неосязаема для близоруких проверок юнит-тестов, и поддается рассмотрению лишь взору интеграционных и end-to-end тестов.
Но, даже если мы напишем более релевантные тесты для таких случаев, задействуя альтернативные инструменты, то может возникнуть другой вопрос — как совместить по разным инструментам задачу подсчета покрытия кода (и зачем)? Насчет первого — тут я даже не уверен, делает ли так кто либо… суммируют ли E2E+Integration+Unit coverage? Думаю, что да, но реже, чем стоило бы.
Зачем суммировать? Ну, положим, если все же мы будем суммировать покрытие, и у нас будут оставаться в коде места, которые ни разу не выполнились в ходе прогона самых разнообразных тестов, то тогда мы сможем идентифицировать все места в существующей кодовой базе, которые имеют неясное предназначение, потенциально являясь источником недоразумений и/или багов.
И, наконец, если это на поверку оказывается нужной логикой, и этот код имеет право на существования, то тут мы подходим к заключительному, не самому приятному вопросу. Почему нам не подошли существующие инструменты для тестирования такого кода?
А это реальная ведь ситуация. За примерами далеко ходить не надо, если взять фронт-энд разработку — как насчет затерянного одинокого экзотического обработчика события, срабатывающего только для мобильного браузера Windows Phone 7? Можно понять человека, отказавшегося покрывать это тестами и проверившего обработчик пару раз вручную на живом телефоне.
Я думаю, что если бы написать такой экзотический тест было бы не дольше 20-30 минут и 10-20 строчек кода, то грешно было бы не написать. Но если же это грозит такими радужными перспективами как писать разные костыли, прикручивать друг к другу проекты номинально несовместимые или малоподдерживаемые, то ради чего?
В любом случае, мы здесь выиграем в том, что выявим недостатки в существующих инструментах тестирования и потенциально сможем добиться их улучшения (если это того стоит, ха-ха, ибо пример с WP7, пожалуй, слишком «суров»). А если мы не захотим или не сможем этого сделать, то как минимум у нас в проекте засчет интегрального такого покрытия будет всегда актуальная обновляемая карта «белых пятен на карте», перепись эдаких тихих омутов с чертями, что позволит держать их популяцию под хоть каким-то, но контролем.
Может, лучше было бы перевести как-то вроде «У меня были достаточно доверительные отношения с этим разработчиком, чтобы сказать без обиняков», потому что, честно говоря, «высокое мнение» сбило с толку при чтении.
Я тут было подумал, что обрубить сбор информации можно гораздо проще и произачнее — отключиться от сети (авиарежим, WiFi, и т. п.), и выполнить проверку оффлайн, но ведь и тут засада — если сайт использует localStorage, Service Workers или некую другую комбинацию техник, то собранную информацию можно придержать до первого удобного случая и отправить позже.
По идее, добавление предосторожности в виде Incognito Mode поставит шах и мат в этой комбинации, так как не удастся накопить информацию в оффлайн-режиме, но и тут надо быть осторожным и не забыть закрыть все вкладки посещенного сайта-проверялки до того как вы включите интернет.
Я это все веду к тому, что «простому пользователю» для обеспечения безопасной проверки пароля в рамках некого веб-сервиса (причем безотносительно метода его доставки — автономное JS-приложение или почти чистое серверное) придется овладеть очень непростыми познаниями в предметной области или довериться экспертам, что тоже имеет свою цену и риски.
P. S. Кстати, можно было бы добавить в статью прямые ссылки на текстовые базы паролей 100,000 и 1,000,000, «для максимального эффекта».
В принципе, эти цифры не такие и страшные, но не ропщут ли ваши разработчики, что раньше ждать ничего было не надо (если писать на ES5, скажем чисто для примера), а теперь на каждое изменение нужно сколько-то еще и ждать?
Конечно же, TypeScript со своей стороны предлагает пару-тройку вариантов ускорения сборки, но интересно, какие методики вы у себя в проекте используете дабы не ждать подолгу завершения компиляции?