По моему опыту и моего друга флагманы Samsung живут очень даже долго. Обновления ОС выходят, мощности хватает с запасом. Все кого знаю меняют их раз в 2-3-4 года без проблем, самый экстрим 5 лет.
А ещё я генерирую имена файлов с помощью SHA256 (борьба с дубликатами, плюс борьба с одноимёнными файлами с разным содержимым). Как это сделать c presigned request? Считать хеш файла на фронте? Ненадёжно, фронт может быть свободно модифицирован пользователем.
А ещё может захотеться всяких других валидаций типа ограничения mime типа файла, а может даже содержимого (в моём коде можно не только считать хеш, но и что-нибудь ещё, можно даже в реальном времени модифицировать данные загружаемого файла, например, сжимать gzip) и т. п. А ещё мы можем хотеть выполнить какие-то дополнительные действия после загрузки (например, внести запись о файле в БД). Причём хотим обеспечить некоторую транзакцинность (на случай неудачи в середине загрузки, закрытия вкладки браузера или потерю соединения пользователем сразу после загрузки и т. д.).
С download не совсем согласен. Например, мы можем хранить в S3-картинки и хотеть их отдавать прямо браузеру, который встречает тэги типа img, css-стили и т. д. И там мы не контролируем поведение "фронта" (по сути встроенных алгоритмов браузера).
Хотя в идеале надо грузить с ACL public и проксировать напрямую веб-сервером в S3 (либо настроить веб-сервер, чтобы добавлял нужные заголовки авторизации, срезал лишние заголовки и запрещал методы отличные от GET). Но всё равно приятно иметь download в бекэнде как минимум для локальной разработки, чтобы не было необходимости настраивать веб-сервер.
Крч многоступенчатый download неудобен в данном сценарии.
С upload в целом, действительно, может быть хорошая идея, но с другой стороны у нас течёт абстракция. Теперь фронт должен быть в курсе, что у нас S3-хранилище и как с ним работать. А так мы полностью абстрагируем хранилище. Можно грузить файлы хоть HTML формой без JS.
К тому же бекэнд на Rust должен иметь очень высокую производительность в пересылке бинарных потоков, вполне возможно на уровне всяких nginx. И зачем нам тогда усложнять систему.
Для sleep, думаю, его можно считать равным 20 мс, как в самом sleep и написано. Для bcrypt действительно можно было бы померить.
По идее важно учесть количество рабочих тредов в этом случае, потому что, очевидно, 1 bcrypt и 10 bcrypt в разных тредах будут выполняться разное время (даже если ядер CPU больше 10, есть, например, тепловой троттлинг, который общий на всех).
Я мерию накладные расходы фреймворков. При росте константной задержки (вызванной вычислениями или банальным sleep - этот код общий для всех трёх тестов) доля оверхеда в общих числах уменьшается. Разница между 7 и 12 мс (= 5 мс) может быть ощутима. Разница между 505 мс и 501 мс (= 4 мс) уже вряд ли будет кого-то волновать. Она не исчезает в абсолютных числах, но исчезает в относительных.
В чем проблема таргетинга рекламы по этим данным? Людям разного происхождения действительно интересны в среднем разные рестораны, например. Разные кухни.
А оскорбительная реклама и так запрещена. По национальности или нет.
Всегда использую типы без TZ, не отдаю преобразование часовых поясов на откуп сессии БД. Преобразую уже на беке или даже на фронте, если нужно только отобразить.
Потому что есть три разных времени:
Часовой пояс сервера (может быть вообще любым в зависимости от фантазии сисадмина и физической локации сервера).
Часовой пояс бизнес-логики. Ну то самое "посчитать количество рабочих дней". Очень легко при развитии системы оказывается, что их на самом деле несколько. Например, у фирмы появляется несколько филиалов в разных часовых поясах или в систему добавляют несколько независимых фирм в разных часовых поясах. И надо выбирать часовой пояс в зависимости от разных условий.
Часовой пояс пользователя. Нередко известен только фронту. Иногда нужно учитывать, иногда не нужно.
Короче, проще всего на часовой пояс сервера не полагаться, а принять, что все даты в UTC, а потом уже их переводить явно в нужный часовой пояс из ТЗ. Ну слишком уж легко отстрелить себе ногу. Ты глядишь на запрос и не знаешь, что он вернёт, не зная настроек сервера.
Суд обязал Гонсалеса выплатить Tesla в качестве компенсации $493 тыс., а также постановил конфисковать незаконно полученные $232 тыс. и перевести эти средства в казну штата.
Не логичнее ли эти 232 тысяч было направить Тесле? Мне что-то подсказывает, что сидя в тюрьме заработать 493 тысячи очень сложно. Так что Тесла увидит свои деньги очень нескоро или никогда.
Неправильно. Нарушается контракт HashSet. Элемент после изменения хеша будет лежать на неправильной позиции. И это полностью ломает хеш-таблицу как структуру. Например, вы изменили элемент. А потом вставили элемент равный новому значению. Теперь у вас в хештаблице два одинаковых элемента, но один из них просто не на своём месте (и поэтому метод вставки его не заметил). Затем вы вставляете в хештаблицу ещё элементы, в ней кончается место и случается перехеширование. Что произойдёт в этот момент? Может быть сработает какой-нибудь assert и у вас случится исключение в месте вообще не связанном с исходной ошибкой. Может быть один элемент тихо потеряется. Может быть у вас теперь поиск начнет выдавать другой элемент, не тот что прежде. И держу пари это никак не регламентировано стандартом. Самое настоящее undefined behavior.
У вас после модификации ключа хештаблица превращается в бомбу, которая может взорваться (бросить недокументированное исключение, произвольно изменить видимое количество элементов) при вызове теоретическилюбого метода после изменения значения (даже если вы не пытаетесь обратиться к самому бракованному элементу). Их поведение больше не соответствует документации.
Сохранить наиболее значимые события? Их и не забудешь. Человек пишущий "дорогой дневник, сегодня я сделал Маше предложение руки и сердца" будет без всякого дневника помнить о том, что его сделал и что чувствовал в тот момент не то что часами, целыми днями и неделями после события. Времени на запись хватит. А то том сказала ему продавщица в магазине "здравствуйте" или "добрый день" и о чем он забудет за секунду, в дневники и не будет внесена информация, максимум "сходил в магазин".
Отпустить мысль, на которой зациклился или дать ей более чёткую форму. Здесь просто альтернатива записи ещё хуже - ещё больше времени и сил потратишь, а результат будет ещё хуже.
Исследование. Тогда запись и есть основная работа. "8:30, подсолнух ещё не повернулся к солнцу". Но если человек так хочет записывать каждую секунду своей жизни, то с этим к психологу. Так как похоже на желание избежать эту самую жизнь или какая-то форма деперсонализации.
Начальник поехал в командировку на поезде или полетел на самолёте и сайт резко ушёл в офлайн. Зашёл в какой-нибудь подвальный склад - аналогично.
Чтобы держать что-то серьёзнее "Привет, Хабр", смартфон придётся оставить дома в районе хорошего приёма сети и на зарядке. Но тогда вместо смартфона можно воткнуть одноплатник, неттоп или ноутбук. Там и root права из коробки, и твоё приложение не убьёт оптимизатор питания Android, и можно расширять хранилище. А у ноутбука даже так же есть аккумулятор на случай отключения электричества.
Ноутбук может сохранить функцию ноутбука (просто теперь его нельзя выключать и выносить из дома/офиса). Смартфон при реализации хотя бы минимальной доступности сайта, перестанет выполнять функцию смартфона.
Телеграмм гонит только твои сообщения (которые ты пишешь ты и которые пишут тебе), чужие сообщения через тебя не проходят. А ещё телеграмм использует push-и, так что в свернутом состоянии по сети гонятся только те сообщения, о которых ты должен получить уведомления (замьюченные чаты подгрузятся только при открытии приложения). Что в общем случае означает, что 99% времени он ничего не принимает и не передаёт, если только у тебя телефон не вибрирует непрерывно уведомлениями.
Клиент меш сети принимает и передаёт не только свои, но и чужие сообщения. Это в корне меняет дело. Вася в соседнем доме качает большой файл, а батарейка садится у вас обоих.
Меш сети работают либо от розетки, либо для какой нибудь сети датчиков с общим потоком данных несколько килобайт в час на все датчики.
Не вполне себе представляю как смартфон может быть веб-сервером без проброса портов. Мобильные операторы всех клиентов садят за NAT, ethernet-кабель в смартфон втыкать некуда. Остаётся только Wi-Fi, но там на роутере отлично настраивается проброс 80порта на >1023. Так же как и в варианте обратного туннеля на сервер с белым IP.
Лично для меня главным минусом Flutter является Dart. И даже не сам язык то, он довольно приятный, а библиотеки. Точнее их отсутствие, если речь о не графических вещах. Например, мне нужно было определить класс юникод символа, в большинстве языков это либо в стандартной библиотеке, либо в популярной хорошо протестированной сторонней. А для Dart я нашёл только какую-то deprecated библиотеку несовместимую с Flutter. Для библиотеки работы с bzip2 архивами тупо нет документации. С sax парсером XML тоже были какие-то проблемы.
То есть накидать красивый интерфейс на Flutter реально очень просто, на каждый чих есть библиотека. Но вот бизнес-логику сложнее дерганья внешнего бекэнда может оказаться проблематично реализовать.
В этом плане React Native выглядит приятнее, потому что в NPM есть буквально ВСЁ.
Только в конце статье вывод, что они очень плохо находят утечки.
А valgrind, если его правильно использовать, находит. Да, надо подготовить входные данные, чтобы активировать все ключевые пути исполнения (точно так же как и при написании unit test надо правильно подобрать тестовые данные, кстати, часто видел, что как раз и запускают unit testы под valgrind убивая двух зайцев, ведь как раз в тестах задача автивации всех путей исполнения уже решена), но при соблюдении этих условий он хотя бы работает.
Нахождение всех утечек одной кнопкой без тюнинга входных данных - утопия. Так как эта задача близка по духу к NP-полной "задаче остановки".
По хорошему, должны быть обновлены регламенты кодирования, с добавлением пункта "любая команда включения датчика должна сопровождаться проверкой его работоспособности", а датчики, в свою очередь, должны иметь функцию самотестирования (если даже у коммерческих MEMS акселерометров, которые ставят в телефоны, есть команда self test, то как её может не быть у space grade продукта). Но странно, если Роскосмос делает эти штуки десятки лет и до сих пор такого пункта в его регламентах нет. Так как ситуация типовая не только для лунной миссии, а примерно для чего угодно. Даже дешевый квадрокоптер с Али при включении чуть чуть шевелит двигателями, чтобы проверить их обмотки, а BIOS персонального компьютера проверяет ОЗУ, чексумму настроек и видеокарту.
Я работал с MEMS акселерометрами, в которых вообще нет движущихся частей. И у них всё равно была команда самотестирования. Как я понимаю, специальная схема создаёт сильное электромагнитное поле притягивающее микрогрузик внутри микросхемы, который в норме реагирует только на ускорение. И это отклонение грузика можно считать и сравнить с ожидаемым. Если слишком отличается, акселерометру плохо.
Там скорее всего не MEMS аксерерометр, но это только увеличивает количество параметров для тестирования. Например, у механического гироскопа можно измерять скорость вращения двигателей и/или их ток потребления.
Так что физически сделать так, чтобы код проверял что акселерометр включился и в первом приближении функционирует корректно - точно можно.
Во Франции запрещены смартфоны на уроках
По моему опыту и моего друга флагманы Samsung живут очень даже долго. Обновления ОС выходят, мощности хватает с запасом. Все кого знаю меняют их раз в 2-3-4 года без проблем, самый экстрим 5 лет.
Всё ещё нельзя генерировать имя файла на основе хеша.
А ещё я генерирую имена файлов с помощью SHA256 (борьба с дубликатами, плюс борьба с одноимёнными файлами с разным содержимым). Как это сделать c presigned request? Считать хеш файла на фронте? Ненадёжно, фронт может быть свободно модифицирован пользователем.
А ещё может захотеться всяких других валидаций типа ограничения mime типа файла, а может даже содержимого (в моём коде можно не только считать хеш, но и что-нибудь ещё, можно даже в реальном времени модифицировать данные загружаемого файла, например, сжимать gzip) и т. п. А ещё мы можем хотеть выполнить какие-то дополнительные действия после загрузки (например, внести запись о файле в БД). Причём хотим обеспечить некоторую транзакцинность (на случай неудачи в середине загрузки, закрытия вкладки браузера или потерю соединения пользователем сразу после загрузки и т. д.).
С download не совсем согласен. Например, мы можем хранить в S3-картинки и хотеть их отдавать прямо браузеру, который встречает тэги типа img, css-стили и т. д. И там мы не контролируем поведение "фронта" (по сути встроенных алгоритмов браузера).
Хотя в идеале надо грузить с ACL public и проксировать напрямую веб-сервером в S3 (либо настроить веб-сервер, чтобы добавлял нужные заголовки авторизации, срезал лишние заголовки и запрещал методы отличные от GET). Но всё равно приятно иметь download в бекэнде как минимум для локальной разработки, чтобы не было необходимости настраивать веб-сервер.
Крч многоступенчатый download неудобен в данном сценарии.
С upload в целом, действительно, может быть хорошая идея, но с другой стороны у нас течёт абстракция. Теперь фронт должен быть в курсе, что у нас S3-хранилище и как с ним работать. А так мы полностью абстрагируем хранилище. Можно грузить файлы хоть HTML формой без JS.
К тому же бекэнд на Rust должен иметь очень высокую производительность в пересылке бинарных потоков, вполне возможно на уровне всяких nginx. И зачем нам тогда усложнять систему.
Для sleep, думаю, его можно считать равным 20 мс, как в самом sleep и написано. Для bcrypt действительно можно было бы померить.
По идее важно учесть количество рабочих тредов в этом случае, потому что, очевидно, 1 bcrypt и 10 bcrypt в разных тредах будут выполняться разное время (даже если ядер CPU больше 10, есть, например, тепловой троттлинг, который общий на всех).
Я мерию накладные расходы фреймворков. При росте константной задержки (вызванной вычислениями или банальным sleep - этот код общий для всех трёх тестов) доля оверхеда в общих числах уменьшается. Разница между 7 и 12 мс (= 5 мс) может быть ощутима. Разница между 505 мс и 501 мс (= 4 мс) уже вряд ли будет кого-то волновать. Она не исчезает в абсолютных числах, но исчезает в относительных.
В чем проблема таргетинга рекламы по этим данным? Людям разного происхождения действительно интересны в среднем разные рестораны, например. Разные кухни.
А оскорбительная реклама и так запрещена. По национальности или нет.
Всегда использую типы без TZ, не отдаю преобразование часовых поясов на откуп сессии БД. Преобразую уже на беке или даже на фронте, если нужно только отобразить.
Потому что есть три разных времени:
Часовой пояс сервера (может быть вообще любым в зависимости от фантазии сисадмина и физической локации сервера).
Часовой пояс бизнес-логики. Ну то самое "посчитать количество рабочих дней". Очень легко при развитии системы оказывается, что их на самом деле несколько. Например, у фирмы появляется несколько филиалов в разных часовых поясах или в систему добавляют несколько независимых фирм в разных часовых поясах. И надо выбирать часовой пояс в зависимости от разных условий.
Часовой пояс пользователя. Нередко известен только фронту. Иногда нужно учитывать, иногда не нужно.
Короче, проще всего на часовой пояс сервера не полагаться, а принять, что все даты в UTC, а потом уже их переводить явно в нужный часовой пояс из ТЗ. Ну слишком уж легко отстрелить себе ногу. Ты глядишь на запрос и не знаешь, что он вернёт, не зная настроек сервера.
Не логичнее ли эти 232 тысяч было направить Тесле? Мне что-то подсказывает, что сидя в тюрьме заработать 493 тысячи очень сложно. Так что Тесла увидит свои деньги очень нескоро или никогда.
Неправильно. Нарушается контракт HashSet. Элемент после изменения хеша будет лежать на неправильной позиции. И это полностью ломает хеш-таблицу как структуру. Например, вы изменили элемент. А потом вставили элемент равный новому значению. Теперь у вас в хештаблице два одинаковых элемента, но один из них просто не на своём месте (и поэтому метод вставки его не заметил). Затем вы вставляете в хештаблицу ещё элементы, в ней кончается место и случается перехеширование. Что произойдёт в этот момент? Может быть сработает какой-нибудь assert и у вас случится исключение в месте вообще не связанном с исходной ошибкой. Может быть один элемент тихо потеряется. Может быть у вас теперь поиск начнет выдавать другой элемент, не тот что прежде. И держу пари это никак не регламентировано стандартом. Самое настоящее undefined behavior.
У вас после модификации ключа хештаблица превращается в бомбу, которая может взорваться (бросить недокументированное исключение, произвольно изменить видимое количество элементов) при вызове теоретически любого метода после изменения значения (даже если вы не пытаетесь обратиться к самому бракованному элементу). Их поведение больше не соответствует документации.
Зависит от целей.
Сохранить наиболее значимые события? Их и не забудешь. Человек пишущий "дорогой дневник, сегодня я сделал Маше предложение руки и сердца" будет без всякого дневника помнить о том, что его сделал и что чувствовал в тот момент не то что часами, целыми днями и неделями после события. Времени на запись хватит. А то том сказала ему продавщица в магазине "здравствуйте" или "добрый день" и о чем он забудет за секунду, в дневники и не будет внесена информация, максимум "сходил в магазин".
Отпустить мысль, на которой зациклился или дать ей более чёткую форму. Здесь просто альтернатива записи ещё хуже - ещё больше времени и сил потратишь, а результат будет ещё хуже.
Исследование. Тогда запись и есть основная работа. "8:30, подсолнух ещё не повернулся к солнцу". Но если человек так хочет записывать каждую секунду своей жизни, то с этим к психологу. Так как похоже на желание избежать эту самую жизнь или какая-то форма деперсонализации.
Начальник поехал в командировку на поезде или полетел на самолёте и сайт резко ушёл в офлайн. Зашёл в какой-нибудь подвальный склад - аналогично.
Чтобы держать что-то серьёзнее "Привет, Хабр", смартфон придётся оставить дома в районе хорошего приёма сети и на зарядке. Но тогда вместо смартфона можно воткнуть одноплатник, неттоп или ноутбук. Там и root права из коробки, и твоё приложение не убьёт оптимизатор питания Android, и можно расширять хранилище. А у ноутбука даже так же есть аккумулятор на случай отключения электричества.
Ноутбук может сохранить функцию ноутбука (просто теперь его нельзя выключать и выносить из дома/офиса). Смартфон при реализации хотя бы минимальной доступности сайта, перестанет выполнять функцию смартфона.
Телеграмм гонит только твои сообщения (которые ты пишешь ты и которые пишут тебе), чужие сообщения через тебя не проходят. А ещё телеграмм использует push-и, так что в свернутом состоянии по сети гонятся только те сообщения, о которых ты должен получить уведомления (замьюченные чаты подгрузятся только при открытии приложения). Что в общем случае означает, что 99% времени он ничего не принимает и не передаёт, если только у тебя телефон не вибрирует непрерывно уведомлениями.
Клиент меш сети принимает и передаёт не только свои, но и чужие сообщения. Это в корне меняет дело. Вася в соседнем доме качает большой файл, а батарейка садится у вас обоих.
Меш сети работают либо от розетки, либо для какой нибудь сети датчиков с общим потоком данных несколько килобайт в час на все датчики.
Не вполне себе представляю как смартфон может быть веб-сервером без проброса портов. Мобильные операторы всех клиентов садят за NAT, ethernet-кабель в смартфон втыкать некуда. Остаётся только Wi-Fi, но там на роутере отлично настраивается проброс 80порта на >1023. Так же как и в варианте обратного туннеля на сервер с белым IP.
Лично для меня главным минусом Flutter является Dart. И даже не сам язык то, он довольно приятный, а библиотеки. Точнее их отсутствие, если речь о не графических вещах. Например, мне нужно было определить класс юникод символа, в большинстве языков это либо в стандартной библиотеке, либо в популярной хорошо протестированной сторонней. А для Dart я нашёл только какую-то deprecated библиотеку несовместимую с Flutter. Для библиотеки работы с bzip2 архивами тупо нет документации. С sax парсером XML тоже были какие-то проблемы.
То есть накидать красивый интерфейс на Flutter реально очень просто, на каждый чих есть библиотека. Но вот бизнес-логику сложнее дерганья внешнего бекэнда может оказаться проблематично реализовать.
В этом плане React Native выглядит приятнее, потому что в NPM есть буквально ВСЁ.
Кто первый встал, того и тапки, например.
Только в конце статье вывод, что они очень плохо находят утечки.
А valgrind, если его правильно использовать, находит. Да, надо подготовить входные данные, чтобы активировать все ключевые пути исполнения (точно так же как и при написании unit test надо правильно подобрать тестовые данные, кстати, часто видел, что как раз и запускают unit testы под valgrind убивая двух зайцев, ведь как раз в тестах задача автивации всех путей исполнения уже решена), но при соблюдении этих условий он хотя бы работает.
Нахождение всех утечек одной кнопкой без тюнинга входных данных - утопия. Так как эта задача близка по духу к NP-полной "задаче остановки".
По хорошему, должны быть обновлены регламенты кодирования, с добавлением пункта "любая команда включения датчика должна сопровождаться проверкой его работоспособности", а датчики, в свою очередь, должны иметь функцию самотестирования (если даже у коммерческих MEMS акселерометров, которые ставят в телефоны, есть команда self test, то как её может не быть у space grade продукта). Но странно, если Роскосмос делает эти штуки десятки лет и до сих пор такого пункта в его регламентах нет. Так как ситуация типовая не только для лунной миссии, а примерно для чего угодно. Даже дешевый квадрокоптер с Али при включении чуть чуть шевелит двигателями, чтобы проверить их обмотки, а BIOS персонального компьютера проверяет ОЗУ, чексумму настроек и видеокарту.
Я работал с MEMS акселерометрами, в которых вообще нет движущихся частей. И у них всё равно была команда самотестирования. Как я понимаю, специальная схема создаёт сильное электромагнитное поле притягивающее микрогрузик внутри микросхемы, который в норме реагирует только на ускорение. И это отклонение грузика можно считать и сравнить с ожидаемым. Если слишком отличается, акселерометру плохо.
Там скорее всего не MEMS аксерерометр, но это только увеличивает количество параметров для тестирования. Например, у механического гироскопа можно измерять скорость вращения двигателей и/или их ток потребления.
Так что физически сделать так, чтобы код проверял что акселерометр включился и в первом приближении функционирует корректно - точно можно.