У формы есть onsubmit. По-хорошему, отправку делают обработкой этого события с preventDefault, а не через onclick кнопки. Так и Enter в полях будет работать привычным образом, и всякие средства автозаполнения, и утилиты для Accessibility.
Я слышал, что в банкоматы специально ставят маленькие экраны с небольшим углом обзора, чтобы прохожие и сзади стоящие в очереди люди не видели твой баланс, сколько денег ты снимаешь или кладёшь и т. п. Кабы чего не вышло.
Циркулярная пила отрезала рабочему палец приняв его за дерево
Ставлю на то, что роботу в целом пофиг, что грузить, он просто выполняет зашитую последовательность поворотов сервоприводов, а техник не обесточил силовые приводы входя в зону движения манипулятора, как того требует техника безопасности.
Я из-за слишком серьёзного заголовка ожидал рассмотрение каких-то краевых случаев, где zero-cost abstractions оказываются не zero-cost. А внутри увидел совсем другое (я даже не могу сказать, что производительность именно ухудшилась, ибо время исполнения выросло в 10 раз, но и нагрузка на CPU уменьшилась в 10 раз).
Сама по себе статья полезная, но с "Помогите, итераторы делают мой код медленнее", у меня бы не было неоправдавшихся ожиданий от содержимого, я бы читал её именно как статью для новичков, а не понял это только в середине.
Вроде так себя ведут итераторы в любом языке, где они настоящие, а не просто у массивов есть два метода 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, а потом уже их переводить явно в нужный часовой пояс из ТЗ. Ну слишком уж легко отстрелить себе ногу. Ты глядишь на запрос и не знаешь, что он вернёт, не зная настроек сервера.
У формы есть onsubmit. По-хорошему, отправку делают обработкой этого события с preventDefault, а не через onclick кнопки. Так и Enter в полях будет работать привычным образом, и всякие средства автозаполнения, и утилиты для Accessibility.
Я слышал, что в банкоматы специально ставят маленькие экраны с небольшим углом обзора, чтобы прохожие и сзади стоящие в очереди люди не видели твой баланс, сколько денег ты снимаешь или кладёшь и т. п. Кабы чего не вышло.
Интересно, как дела с этим у этой штуки.
То есть они сами оплачивают своему ребёнку 350$ в месяц на то, что им не нравится, и хотят засудить поставщика услуг?
Ставлю на то, что роботу в целом пофиг, что грузить, он просто выполняет зашитую последовательность поворотов сервоприводов, а техник не обесточил силовые приводы входя в зону движения манипулятора, как того требует техника безопасности.
Я из-за слишком серьёзного заголовка ожидал рассмотрение каких-то краевых случаев, где zero-cost abstractions оказываются не zero-cost. А внутри увидел совсем другое (я даже не могу сказать, что производительность именно ухудшилась, ибо время исполнения выросло в 10 раз, но и нагрузка на CPU уменьшилась в 10 раз).
Сама по себе статья полезная, но с "Помогите, итераторы делают мой код медленнее", у меня бы не было неоправдавшихся ожиданий от содержимого, я бы читал её именно как статью для новичков, а не понял это только в середине.
Вроде так себя ведут итераторы в любом языке, где они настоящие, а не просто у массивов есть два метода 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, а потом уже их переводить явно в нужный часовой пояс из ТЗ. Ну слишком уж легко отстрелить себе ногу. Ты глядишь на запрос и не знаешь, что он вернёт, не зная настроек сервера.