В хаб по веб-разработке до сих пор раз в месяц постят информацию о том, что появились async/await. Раз в два месяца стабильно появляется пост, как пользоваться let/const.
Так что по стандартам веб-хаба эта публикация ни разу не баян)
имхо в большинстве случаев это лишнее и лучше просто показать пользователю сообщение, что имеются проблемы с сетью и попросить его перезагрузить страницу.
Так, во-первых, пользователь будет информирован, почему его приложение не отвечает на его действия (и перестанет тыкать элементы управления, вызывая ещё больше запросов). Во-вторых, так гораздо проще разрабатывать/поддерживать. Если мы хотим дать гарантию, что наше приложение нормально работает, если потерялось соединение, то это гораздо большее время тестирования и гораздо больше сценариев, которые надо проверить. Ну, и в третьих, если наш клиент автоматически пробует повторить запрос, то нужно дополнительно думать об идемпотентности PUT/POST/PATCH запросов.
Исключением являются ситуации, когда пользователь мог потратить большое количество времени, делая что-то (например, набирая текст статьи). Мы не хотим приводить пользователя в фрустрация, не сохранив всю его работу или хотя бы не предоставив ему возможность сохранить её вручную.
Это называется non-persistent XSS. Основная схема эксплуатации: вынудить пользователя каким-то образом перейти по ссылке злоумышленника (со стороннего сайта, например).
Главная проблема вр систем — это недостаточное для комфортного использования качество картинки
Кому как. Мне вот качество картинки в HTC Vive (даже не Pro, а в обычном) хватает за глаза.
Лично для меня проблема, описанная товарищем rPman выглядит гораздо острее. Имитации окружения остро не хватает, хотя итак иногда забываешь, что находишься в шлеме и предметы не реальны. У меня был случай, когда в Arizona Sunshine я упал, пытаясь облокотиться об окоп, чтобы лучше прицелиться снайперской винтовкой.
но только при возможности снять ограничение чем-то вроде ЕГЭ по инвестициям.
В статье указано, что, при наличии некоего финансового аттестата, физлицо может считаться квалифицированным инвестором. Я полагаю, что этот финансовый аттестат вполне подходит под то, о чем вы говорите.
Если команда исключительно русскоязычная, то зачем мучить разработчиков? Пусть пишут комментарии, логи и тикеты на русском языке. Это быстрее, понятней и не надо постоянно расшифровывать корявый, наполненный ошибками, английский.
Сотрудников опять же проще набирать. Если проект ведется полностью на английском языке (включая документацию и создание тикетов), то приходится отсекать некоторых кандидатов, которые по остальным критериями подходят.
Печально. Надеюсь, процент людей с такой мотивацией в индустрии не очень велик.
И если вы мне скажете, что не кайфуете от чувства собственного превосходства, то вы врете. Говорите мне про добрые цели, обучение новичков и благородство — я-то знаю, что вы просто от себя тащитесь в глубине души.
Не проецируйте на других свои комплексы. В индустрии много адекватных людей, которые занимаются код-ревью исключительно потому, что верят, что это благо для проекта и коллег.
Похожая конвертация используется в ЕГЭ. Или, по крайней мере, использовалась 10 лет назад.
За предмет можно было набрать определенное количество баллов, которое позже транслировалось в 100-бальную шкалу. Например, за математику можно было набрать максимум 37 баллов.
Конвертация выглядела следующим образом:
37/37 = 100 баллов
36/37 = 90 баллов
35/37 = 86 баллов
34/37 = 84 балла
Мне всегда казалось, что просто поделить набранный балл на максимально возможный и округлить к меньшему (34 / 37 ~ 91) было бы более прозрачной и справедливой системой.
Вести какую-то деятельность на гитхабе есть смысл только тогда, когда есть чем поделиться с миром, или интересно вести какой-то свой проект (пусть даже для себя), или хочется поучаствовать в open source разработке, или {вписать_свое}. В общем, когда это интересно тебе лично.
Заставлять себя этим заниматься ради туманных карьерных перспектив — это, имхо, не путь самурая.
Смысл любой дейтельности лежит в одной из плоскостей пирамиды Маслоу.
Вы слишком упрощаете его теорию.
Во-первых, человек никогда не находится чётко на одной из плоскостей. Даже если человек не доедает, не досыпает, у него всё еще присутствуют более высокие потребности (в принадлежности, в уважении, и т.д.).
Во-вторых, эта иерархия верна далеко не для всех. Для определенных людей, последовательность плоскостей может быть иной (потребность в уважении выражена гораздо сильней потребности в безопасности), вплоть до того, что некоторые слои могут практически полностью игнорироваться. И это, в принципе, нормально и не говорит о том, что что-то с человеком не так.
Это все написано самим Маслоу в его книге «Мотивация и личность».
Ну и совет «Заведите детей, если не знаете чего хотите» не выдерживает совершенно никакой критики.
проблема в том что очень много новичков тянут все хайповое в проекты
Справедливости ради: если у новичков есть полномочия тащить в проект все, что они хотят, то в проекте есть более глубокие проблемы, чем наличие хайповых технологий.
Буду рад, если порекомендуете книги, которые повлияли на вас.
Из не художественного и из того, что еще не упоминали в посте:
— Виктор Франкл, «Человек в поисках смысла». Автор описывает свой опыт пребывания в концлагере и как ему удалось это пережить.
— Михай Чиксентмихайи, «Поток». Концепт «потока» (полной увлеченностью текущей деятельностью), в принципе, довольно известен и часто упоминается в IT среде.
Я работаю со спрингом, но не знал о наличии этого класса. К сожалению, они добавили его только в Spring 5. Далеко не весь enterprise успел перейти на него.
Да, вы правы. Это рабочий вариант и он определенно достоин упоминания.
Из минусов стоит отметить, что далеко не всегда удобно использовать имя файла в запросе, поскольку:
— Клиентское приложение может и не знать имя файла до его запроса. Имя файла может быть не нужно на фронте и будет необходимость дополнительно попросить REST рассчитать имя файла.
— Работать с токеном / id в ресте удобней, чем с именем файла. И валидация, и поиск, и security проще.
Очень частая ошибка в интеграционных тестах — использование реальной базы данных
Ну почему сразу ошибка-то. Если пишешь какой-нибудь REST API, то очень удобно при тестировании этого реста сверятся с БД: смотреть, что были применены именно нужные изменения.
Для запусков тестов нужно будет настраивать внешнее окружение.
Во многих проектах каждому разработчику итак надо поднять свою БД. Благо, в проектах есть init и update SQL скрипты, которые сами все настроят.
Состояние внешних систем может отличаться на разных машинах перед запуском тестов.
Тесты могут очищать БД и накатывать нужные данные. В моем опыте здесь нет особых проблем с поддержкой.
Да, я согласен, что интеграционным тестам лучше не стучаться по HTTP к каким-нибудь 3d parties. Но имхо использование настоящей БД при тестировании — это удобно и естественно.
один символ может кодироваться в urf-8 тремя, четырьмя, а то и пятью байтами
Разве где-то сейчас используется UTF-8 с символами больше 4 байт?
Вроде в RFC 3629, который является официальным стандартом, указано, что «In UTF-8, characters from the U+0000..U+10FFFF range are encoded using sequences of 1 to 4 octets». И символы за пределами этого range запрещены («Restricted the range of characters to 0000-10FFFF»).
Но в предыдущей (давно устаревшей) версии стандарта (rfc2279) были возможны символы, требующие до 6 байт.
сравнить две строки без побайтового либо посимвольного прохода по ним невозможно.
Можно. Посмотрите на String::intern.
Вполне можно добиться того, что в куче не будет одинаковых строк. Т.е., если в разных местах в коде использовать одинаковое строковое значение, то оно будет указывать на один и тот же объект.
Я не знаю, насколько это поведение надежно, но данные оптимизации действительно имеют место быть при компиляции. Хотя я лично на них не полагаюсь, и пишу в коде string1.equals(string2) вместо string1 == string2. Но второй вариант тоже, в теории, будет работать достаточно стабильно.
Так что по стандартам веб-хаба эта публикация ни разу не баян)
Так, во-первых, пользователь будет информирован, почему его приложение не отвечает на его действия (и перестанет тыкать элементы управления, вызывая ещё больше запросов). Во-вторых, так гораздо проще разрабатывать/поддерживать. Если мы хотим дать гарантию, что наше приложение нормально работает, если потерялось соединение, то это гораздо большее время тестирования и гораздо больше сценариев, которые надо проверить. Ну, и в третьих, если наш клиент автоматически пробует повторить запрос, то нужно дополнительно думать об идемпотентности PUT/POST/PATCH запросов.
Исключением являются ситуации, когда пользователь мог потратить большое количество времени, делая что-то (например, набирая текст статьи). Мы не хотим приводить пользователя в фрустрация, не сохранив всю его работу или хотя бы не предоставив ему возможность сохранить её вручную.
Кому как. Мне вот качество картинки в HTC Vive (даже не Pro, а в обычном) хватает за глаза.
Лично для меня проблема, описанная товарищем rPman выглядит гораздо острее. Имитации окружения остро не хватает, хотя итак иногда забываешь, что находишься в шлеме и предметы не реальны. У меня был случай, когда в Arizona Sunshine я упал, пытаясь облокотиться об окоп, чтобы лучше прицелиться снайперской винтовкой.
В статье указано, что, при наличии некоего финансового аттестата, физлицо может считаться квалифицированным инвестором. Я полагаю, что этот финансовый аттестат вполне подходит под то, о чем вы говорите.
Сотрудников опять же проще набирать. Если проект ведется полностью на английском языке (включая документацию и создание тикетов), то приходится отсекать некоторых кандидатов, которые по остальным критериями подходят.
Печально. Надеюсь, процент людей с такой мотивацией в индустрии не очень велик.
Не проецируйте на других свои комплексы. В индустрии много адекватных людей, которые занимаются код-ревью исключительно потому, что верят, что это благо для проекта и коллег.
За предмет можно было набрать определенное количество баллов, которое позже транслировалось в 100-бальную шкалу. Например, за математику можно было набрать максимум 37 баллов.
Конвертация выглядела следующим образом:
37/37 = 100 баллов
36/37 = 90 баллов
35/37 = 86 баллов
34/37 = 84 балла
Мне всегда казалось, что просто поделить набранный балл на максимально возможный и округлить к меньшему (34 / 37 ~ 91) было бы более прозрачной и справедливой системой.
Заставлять себя этим заниматься ради туманных карьерных перспектив — это, имхо, не путь самурая.
Вы слишком упрощаете его теорию.
Во-первых, человек никогда не находится чётко на одной из плоскостей. Даже если человек не доедает, не досыпает, у него всё еще присутствуют более высокие потребности (в принадлежности, в уважении, и т.д.).
Во-вторых, эта иерархия верна далеко не для всех. Для определенных людей, последовательность плоскостей может быть иной (потребность в уважении выражена гораздо сильней потребности в безопасности), вплоть до того, что некоторые слои могут практически полностью игнорироваться. И это, в принципе, нормально и не говорит о том, что что-то с человеком не так.
Это все написано самим Маслоу в его книге «Мотивация и личность».
Ну и совет «Заведите детей, если не знаете чего хотите» не выдерживает совершенно никакой критики.
Справедливости ради: если у новичков есть полномочия тащить в проект все, что они хотят, то в проекте есть более глубокие проблемы, чем наличие хайповых технологий.
«sign up» во многих (если не в большинстве) случаях на англоязычных сайтах употребляется там же, где на русских бы писалось «Зарегистрироваться».
Из не художественного и из того, что еще не упоминали в посте:
— Виктор Франкл, «Человек в поисках смысла». Автор описывает свой опыт пребывания в концлагере и как ему удалось это пережить.
— Михай Чиксентмихайи, «Поток». Концепт «потока» (полной увлеченностью текущей деятельностью), в принципе, довольно известен и часто упоминается в IT среде.
Я работаю со спрингом, но не знал о наличии этого класса. К сожалению, они добавили его только в Spring 5. Далеко не весь enterprise успел перейти на него.
Да, вы правы. Это рабочий вариант и он определенно достоин упоминания.
Из минусов стоит отметить, что далеко не всегда удобно использовать имя файла в запросе, поскольку:
— Клиентское приложение может и не знать имя файла до его запроса. Имя файла может быть не нужно на фронте и будет необходимость дополнительно попросить REST рассчитать имя файла.
— Работать с токеном / id в ресте удобней, чем с именем файла. И валидация, и поиск, и security проще.
Ну почему сразу ошибка-то. Если пишешь какой-нибудь REST API, то очень удобно при тестировании этого реста сверятся с БД: смотреть, что были применены именно нужные изменения.
Во многих проектах каждому разработчику итак надо поднять свою БД. Благо, в проектах есть init и update SQL скрипты, которые сами все настроят.
Тесты могут очищать БД и накатывать нужные данные. В моем опыте здесь нет особых проблем с поддержкой.
Да, я согласен, что интеграционным тестам лучше не стучаться по HTTP к каким-нибудь 3d parties. Но имхо использование настоящей БД при тестировании — это удобно и естественно.
Разве где-то сейчас используется UTF-8 с символами больше 4 байт?
Вроде в RFC 3629, который является официальным стандартом, указано, что «In UTF-8, characters from the U+0000..U+10FFFF range are encoded using sequences of 1 to 4 octets». И символы за пределами этого range запрещены («Restricted the range of characters to 0000-10FFFF»).
Но в предыдущей (давно устаревшей) версии стандарта (rfc2279) были возможны символы, требующие до 6 байт.
Или я что-то упускаю?
Можно. Посмотрите на String::intern.
Вполне можно добиться того, что в куче не будет одинаковых строк. Т.е., если в разных местах в коде использовать одинаковое строковое значение, то оно будет указывать на один и тот же объект.
Я не знаю, насколько это поведение надежно, но данные оптимизации действительно имеют место быть при компиляции. Хотя я лично на них не полагаюсь, и пишу в коде string1.equals(string2) вместо string1 == string2. Но второй вариант тоже, в теории, будет работать достаточно стабильно.