Да, плакалЪ, когда увидел…
(просто довелось столкнуться с забавным багом: софт не мог подсоединиться к серверу из-за того, что сертификат был вшит, и антивирус с его MiTM мешал соединению)
Спасибо, хорошая статья, и напоминание про подобные грабли (на примере наивного подхода) не лишнее.
Сам такой подход люблю, особенно для сглаживающих цифровых фильтров (когда разрядов мало), но не знал названия.
Однако же попробуйте метод (для float) на последовательности из миллиона единиц, потом миллион двоек…
Ну или более реальный случай — миллион чисел, плавно растущих от 1 до 2.
Обычно надо не метод переименовывать, а подробней описать аргументы и результат (ну, как обычно описаны функции у ms/apple/..., и в doxygen/… удобно делать)
Да не обращайте внимания, это так, шутливое ворчание. Даже я догадался, что речь про веб — хотя в ленте на m.habrahabr.ru ничто на это не указывает (но именно потому что в любой другой области автор указал бы, о каком API идёт речь, а в вашей области разработчики зачастую забывают, что существует остальной мир).
Предлагаю ввести термин "default API" по аналогии с "default city". Чтобы сразу было ясно: если в заголовке упомянуто API — это исключительно для веб-приложений, всяким шудрам, пишущим не для веба, можно не заглядывать.
Честно говоря, кроме квеста с nullability (ценного безотносительно перехода) выглядит, как просто следование за модой.
Ну, во всяком случае из вашего описания другие причины перехода не видны.
В идеале хотелось бы увидеть от них не просто ответ "мы выпилили заразу", но и наличие Content-Security-Policy хедера в ответе сервера, чтобы левых iframe и скриптов в принципе не могло быть.
троллейбус.jpg
Взять нейронную сеть и начать с её помощью решать задачу, для которой она заведомо не очень хороша? Ну… Может, как учебная задачка и сойдёт, но я бы не стал.
Потроха — это, конечно, хорошо, но в реальной практике нужны более конкретные знания. Например, с ходу вспомните разницу в поведении между dispatch_async на главном потоке и performSelectorOnMainThread (под MacOS)? А она существенна, и заменив второе на первое — легко словить баг.
(если не вспомнили: серьёзное отличие — GCD работает только в главном цикле обработки сообщений, поэтому, если вызвать runModalForWindow:- до закрытия окна блоки не отработают)
Лучше не моторчик, а подкручивание от сжимания пальцами. Чтобы поддерживать вращение сколь угодно долго.
Хотя проще взять йо-йо или диаболо (выучить десяток трюков с диаболо — легко, а внимания привлекает — куда там спинеру) — там подкручивание реализовано «из коробки».
Ну, если из коробки нет — понятно, что можно настроить, по крайней мере, в достаточной степени (r/w доступ к папке, куда бэкапимся, r/o к снэпшотам.
Насчёт rsync — я про бэкап рабочей машины на nas в стиле http://www.mikerubel.org/computers/rsync_snapshots/ (на zfs получится лучше, конечно)
Не гонять же по сети все данные?
Спасибо.
Чтоб не искать (если помните) — на каком уровне nas4free "из коробки" обеспечивает функционал вида "снэпшоты неприкосновенны"? Запуск rsync server под chroot?
Спасибо. Объяснить, что будет с тестировщиком, предложившим подобное? Правильно, он пойдёт воспроизводить баг заново, пока не напишет нормальный тикет.
Итого, ему всё равно придётся делать короткие тесты — т.е. выполнять вдвое больше работы.
Написание подобной цепочки оправдано в одном случае: прога отлажена до упора, новый функционал в неё не вносится — а значит, вероятность поломки минимальна (и можно не делать коротких тестов, пока всё не сломается).
Ну и более-менее приемлем вариант "написать длинный тест и проверять результат на каждом шаге". Он позволяет малой кровью изолировать баг (у кого тестирование организовано на виртуалке — может быть, можно отдать программистам систему в состоянии "сейчас сломается"). Но тут опять же неприятный момент — когда система дорабатывается и её поведение меняется.
Меня, как программиста, подобные сложносочинённые тесты напрягают. Я мечтаю, чтобы тестировщики как можно точнее локализовали ошибку, а тут будешь только знать, что в системе из 50 звеньев что-то пошло не так — и ищи, где...
А если речь не о системе для организации (где ценность и объём данных оправдывают достаточно дорогую систему защиты), а о домашнем применении — можете что-то посоветовать?
Мои мысли бродят в направлении линуксовой машинки + rsnapshot + (возможно) zfs. С запуском бэкапа со стороны этой машинки — чтобы рабочая машина вообще не имела к диску с бэкапами доступа на запись. Ну или ещё какими хитростями — лишь бы не давать доступа на запись к старым снепшотам.
Хотя предпочёл бы готовый NAS, умеющий всё нужное...
Когда я свою покупал (тоже конструктор) — у меня дома было три паяльника…
Да, плакалЪ, когда увидел…
(просто довелось столкнуться с забавным багом: софт не мог подсоединиться к серверу из-за того, что сертификат был вшит, и антивирус с его MiTM мешал соединению)
Э… Я вижу просто явную передачу this в качестве аргумента функции (вместо обычной неявной), и всё. Что изменилось, кроме увеличения размера кода?
Спасибо, хорошая статья, и напоминание про подобные грабли (на примере наивного подхода) не лишнее.
Сам такой подход люблю, особенно для сглаживающих цифровых фильтров (когда разрядов мало), но не знал названия.
Однако же попробуйте метод (для float) на последовательности из миллиона единиц, потом миллион двоек…
Ну или более реальный случай — миллион чисел, плавно растущих от 1 до 2.
Обычно надо не метод переименовывать, а подробней описать аргументы и результат (ну, как обычно описаны функции у ms/apple/..., и в doxygen/… удобно делать)
Да не обращайте внимания, это так, шутливое ворчание. Даже я догадался, что речь про веб — хотя в ленте на m.habrahabr.ru ничто на это не указывает (но именно потому что в любой другой области автор указал бы, о каком API идёт речь, а в вашей области разработчики зачастую забывают, что существует остальной мир).
Предлагаю ввести термин "default API" по аналогии с "default city". Чтобы сразу было ясно: если в заголовке упомянуто API — это исключительно для веб-приложений, всяким шудрам, пишущим не для веба, можно не заглядывать.
Да. Надо было отсортировать максимумом, а потом взять первый элемент.
Э… Кагбэ сравнивать smt-многопоточность имело смысл не с временнОй, а с многоядерностью. Тогда все её проблемы — как на ладони.
Честно говоря, кроме квеста с nullability (ценного безотносительно перехода) выглядит, как просто следование за модой.
Ну, во всяком случае из вашего описания другие причины перехода не видны.
В идеале хотелось бы увидеть от них не просто ответ "мы выпилили заразу", но и наличие Content-Security-Policy хедера в ответе сервера, чтобы левых iframe и скриптов в принципе не могло быть.
троллейбус.jpg
Взять нейронную сеть и начать с её помощью решать задачу, для которой она заведомо не очень хороша? Ну… Может, как учебная задачка и сойдёт, но я бы не стал.
Потроха — это, конечно, хорошо, но в реальной практике нужны более конкретные знания. Например, с ходу вспомните разницу в поведении между dispatch_async на главном потоке и performSelectorOnMainThread (под MacOS)? А она существенна, и заменив второе на первое — легко словить баг.
(если не вспомнили: серьёзное отличие — GCD работает только в главном цикле обработки сообщений, поэтому, если вызвать runModalForWindow:- до закрытия окна блоки не отработают)
Хотя проще взять йо-йо или диаболо (выучить десяток трюков с диаболо — легко, а внимания привлекает — куда там спинеру) — там подкручивание реализовано «из коробки».
Ну, если из коробки нет — понятно, что можно настроить, по крайней мере, в достаточной степени (r/w доступ к папке, куда бэкапимся, r/o к снэпшотам.
Насчёт rsync — я про бэкап рабочей машины на nas в стиле http://www.mikerubel.org/computers/rsync_snapshots/ (на zfs получится лучше, конечно)
Не гонять же по сети все данные?
Спасибо.
Чтоб не искать (если помните) — на каком уровне nas4free "из коробки" обеспечивает функционал вида "снэпшоты неприкосновенны"? Запуск rsync server под chroot?
Спасибо. Объяснить, что будет с тестировщиком, предложившим подобное? Правильно, он пойдёт воспроизводить баг заново, пока не напишет нормальный тикет.
Итого, ему всё равно придётся делать короткие тесты — т.е. выполнять вдвое больше работы.
Написание подобной цепочки оправдано в одном случае: прога отлажена до упора, новый функционал в неё не вносится — а значит, вероятность поломки минимальна (и можно не делать коротких тестов, пока всё не сломается).
Ну и более-менее приемлем вариант "написать длинный тест и проверять результат на каждом шаге". Он позволяет малой кровью изолировать баг (у кого тестирование организовано на виртуалке — может быть, можно отдать программистам систему в состоянии "сейчас сломается"). Но тут опять же неприятный момент — когда система дорабатывается и её поведение меняется.
Увы, презумпция невиновности касается только уголовных дел.
Меня, как программиста, подобные сложносочинённые тесты напрягают. Я мечтаю, чтобы тестировщики как можно точнее локализовали ошибку, а тут будешь только знать, что в системе из 50 звеньев что-то пошло не так — и ищи, где...
А если речь не о системе для организации (где ценность и объём данных оправдывают достаточно дорогую систему защиты), а о домашнем применении — можете что-то посоветовать?
Мои мысли бродят в направлении линуксовой машинки + rsnapshot + (возможно) zfs. С запуском бэкапа со стороны этой машинки — чтобы рабочая машина вообще не имела к диску с бэкапами доступа на запись. Ну или ещё какими хитростями — лишь бы не давать доступа на запись к старым снепшотам.
Хотя предпочёл бы готовый NAS, умеющий всё нужное...