Вроде так себя ведут итераторы в любом языке, где они настоящие, а не просто у массивов есть два метода map/filter возвращающих новый массив. Без ленивости будет аллокация памяти на полный размер массива на каждый шаг обработки.
Такая же ситуация как в Rust будет в Java, например.
Вот ленивый async есть не везде, а ленивые итераторы везде.
Если предположить, что после купания электромобиль восстановлению не подлежит (так как 90% его ценности это батарея и электроника), то горение не выглядит чем-то ужасным. Под водой оно не сможет распространяться на другие объекты. Так что получается просто надо не вытаскивать его из воды, пока батарея не выгорит полностью. Сценарий горения в воде благоприятнее сценария горения на воздухе, где автомобиль может поджечь что-нибудь ещё.
Если супруг осознанный, то объясняется, почему не надо отвлекать и он старается не отвлекать. Договариваются о правилах о временных рамках и/или "когда я в наушниках" и т. д. При этом вне периода работы, вы готовы к обсуждениям вопросов скопившихся, пока вы были заняты. Короче, win-win, вам не мешают работать, вы можете так же сфокусированно и вдумчиво обсуждать вопросы волнующие супруга в нерабочее время.
Если супруг неосознанный, но вы по каким-то причинам оказались в этом браке, то дрессировка. Озвучивание правил, а затем следование им. Что ответа от вас недождуться, пока вы работаете. Как бы вам не мешали работать, вы не удовлетворите потребность супруга, но при этом важно не триггериться и не устраивать нравоучения, потому что это будет как минимум удовлетворять потребность во внимании и эмоциях, а надо именно не давать вообще ничего. А в нерабочее время наоборот. Подкрепление правильного поведения, игнор неправильного. Победит кто терпеливее и кто будет дольше придерживаться своей линии (один пытаться привлечь внимание, другой соблюдать правила работы).
Я, конечно, в браке ещё не был, но в романтических отношениях почему-то все очень быстро начинают выбирать первый вариант, а не второй.
Обычно в таких случаях суд просит переделать дом за свой счёт и выплатить неустойку заказчику.
Если это не единичный случай, то обвинение в мошенничестве может иметь место, но нужен умысел, типа исходно исполнитель планировал строить деревянные дома, у него вообще нет и не было каменщиков в штате.
Не знаю как про деревянный дом вместо кирпичного, но при сдаче квартир в новостройках периодически случается, что квартиры не полностью соответствуют паспорту (площадь отличается, планировка и т. д.), это решается обычно именно компенсациями и переделкой за счёт исполнителя.
Цыгане на улице обещают погадать, а не очистить карманы. Гадание может быть не очень эффективно в практическом смысле, но жертва/клиент непротив. Может верит, может для него это такое шоу.
Со всякими инфокурсами клиенты знают сколько денег отдадут, у них не заберут больше, чем они готовы заплатить, обычно заключаются договора и т. д.
Я согласен с автором статьи, что в первую очередь вопрос к рекламе. В моей картине мира все эти инфокурсы в сферах, где в принципе не существует объективно доказанных чётких путей достижения результата (нет 100% рабочего способа стать бизнесменом, даже никакой MBA не гарантирует повышение дохода по итогу, и тем более такие курсы от непонятно кого), это что-то вроде "художественное произведение которое может натолкнуть на полезные мысли и мотивировать достигать результат", не более того. Было бы неплохо, если это явно писали мелким шрифтом в рекламе.
Но само существование таких курсов мне не мешает. Кому-то может быть полезно.
Не совсем понял. Лазеры не то что воду греть могут, могут металл резать. В том числе лазеры видимого спектра (то есть ИК там нет, во всяком случае в значительных количествах). То есть никаких препятствий в нагреве объектов видимым светом нет.
По моему опыту и моего друга флагманы 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% времени он ничего не принимает и не передаёт, если только у тебя телефон не вибрирует непрерывно уведомлениями.
Клиент меш сети принимает и передаёт не только свои, но и чужие сообщения. Это в корне меняет дело. Вася в соседнем доме качает большой файл, а батарейка садится у вас обоих.
Меш сети работают либо от розетки, либо для какой нибудь сети датчиков с общим потоком данных несколько килобайт в час на все датчики.
Вроде так себя ведут итераторы в любом языке, где они настоящие, а не просто у массивов есть два метода map/filter возвращающих новый массив. Без ленивости будет аллокация памяти на полный размер массива на каждый шаг обработки.
Такая же ситуация как в Rust будет в Java, например.
Вот ленивый async есть не везде, а ленивые итераторы везде.
Если предположить, что после купания электромобиль восстановлению не подлежит (так как 90% его ценности это батарея и электроника), то горение не выглядит чем-то ужасным. Под водой оно не сможет распространяться на другие объекты. Так что получается просто надо не вытаскивать его из воды, пока батарея не выгорит полностью. Сценарий горения в воде благоприятнее сценария горения на воздухе, где автомобиль может поджечь что-нибудь ещё.
Если супруг осознанный, то объясняется, почему не надо отвлекать и он старается не отвлекать. Договариваются о правилах о временных рамках и/или "когда я в наушниках" и т. д. При этом вне периода работы, вы готовы к обсуждениям вопросов скопившихся, пока вы были заняты. Короче, win-win, вам не мешают работать, вы можете так же сфокусированно и вдумчиво обсуждать вопросы волнующие супруга в нерабочее время.
Если супруг неосознанный, но вы по каким-то причинам оказались в этом браке, то дрессировка. Озвучивание правил, а затем следование им. Что ответа от вас недождуться, пока вы работаете. Как бы вам не мешали работать, вы не удовлетворите потребность супруга, но при этом важно не триггериться и не устраивать нравоучения, потому что это будет как минимум удовлетворять потребность во внимании и эмоциях, а надо именно не давать вообще ничего. А в нерабочее время наоборот. Подкрепление правильного поведения, игнор неправильного. Победит кто терпеливее и кто будет дольше придерживаться своей линии (один пытаться привлечь внимание, другой соблюдать правила работы).
Я, конечно, в браке ещё не был, но в романтических отношениях почему-то все очень быстро начинают выбирать первый вариант, а не второй.
Обычно в таких случаях суд просит переделать дом за свой счёт и выплатить неустойку заказчику.
Если это не единичный случай, то обвинение в мошенничестве может иметь место, но нужен умысел, типа исходно исполнитель планировал строить деревянные дома, у него вообще нет и не было каменщиков в штате.
Не знаю как про деревянный дом вместо кирпичного, но при сдаче квартир в новостройках периодически случается, что квартиры не полностью соответствуют паспорту (площадь отличается, планировка и т. д.), это решается обычно именно компенсациями и переделкой за счёт исполнителя.
Цыгане на улице обещают погадать, а не очистить карманы. Гадание может быть не очень эффективно в практическом смысле, но жертва/клиент непротив. Может верит, может для него это такое шоу.
Со всякими инфокурсами клиенты знают сколько денег отдадут, у них не заберут больше, чем они готовы заплатить, обычно заключаются договора и т. д.
Я согласен с автором статьи, что в первую очередь вопрос к рекламе. В моей картине мира все эти инфокурсы в сферах, где в принципе не существует объективно доказанных чётких путей достижения результата (нет 100% рабочего способа стать бизнесменом, даже никакой MBA не гарантирует повышение дохода по итогу, и тем более такие курсы от непонятно кого), это что-то вроде "художественное произведение которое может натолкнуть на полезные мысли и мотивировать достигать результат", не более того. Было бы неплохо, если это явно писали мелким шрифтом в рекламе.
Но само существование таких курсов мне не мешает. Кому-то может быть полезно.
Не совсем понял. Лазеры не то что воду греть могут, могут металл резать. В том числе лазеры видимого спектра (то есть ИК там нет, во всяком случае в значительных количествах). То есть никаких препятствий в нагреве объектов видимым светом нет.
Во Франции запрещены смартфоны на уроках
По моему опыту и моего друга флагманы 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% времени он ничего не принимает и не передаёт, если только у тебя телефон не вибрирует непрерывно уведомлениями.
Клиент меш сети принимает и передаёт не только свои, но и чужие сообщения. Это в корне меняет дело. Вася в соседнем доме качает большой файл, а батарейка садится у вас обоих.
Меш сети работают либо от розетки, либо для какой нибудь сети датчиков с общим потоком данных несколько килобайт в час на все датчики.