В postgresql по дефолту стоит достаточно высокое значение для autovacuum_vacuum_scale_factor, равное 0.2 (т.е. vacuum будет вызван, когда мертвых записей будет 20% от всей таблице).
Для многих проектов лучше уменьшить значение до 0.05 или даже до 0.02. Профит особенно хорошо будет заметен для таблиц, где вставки (inserts) происходят гораздо чаще, чем updates.
Проблема даже не в том, что чистка 20% таблицы может занять много времени (но и это тоже). Само наличие большого количества dead tuples влияет на скорость запросов к таблице (select) и на то, как используются индексы.
Но эти значения, конечно, лучше подбирать исходя из конкретных проектов/данных/таблиц.
Это далеко не всегда реализуемо. Если у запроса есть хотя бы несколько фильтров (особенно, по произвольной строке) и типов сортировок, то результаты запроса хранить не практично, т.к. количество вариантов запросов стремится к бесконечности.
Не говоря уже о том, что если хранить результаты запросов паджинации, то встает очень сложная проблема, как эти производные данные синхронизировать с основной таблицей, т.е. когда инвалидировать этот кэш.
Число оценок для топ-3 компаний с 5К+ сотрудников составляет 89, 24 и 39 человека. Это меньше 1% сотрудников.
Я очень рад, что у нас в России есть сервис для сбора информации об IT-компаниях и получаемых зарплатах, и всецело поддерживаю деятельность Моего Круга и их блог.
Но хотелось бы, чтобы больше людей пошли и оставили свой фидбек, чтобы сложилось более полное представление о рынке труда.
Конкретно в этом проекте — нет никакой возможности определить, что логины в системе есть. Восстановление пароля и регистрация молча принимают ваши данные и высылают письмо, которое разнится в зависимости от того, есть ли такой логин уже в системе ли нет.
Я знаю, что еще возможно определить, есть ли такой логин по скорости ответа сервера. Если сервер быстрее выдал ошибку о неправильных credentials, то значит такого логина в системе нет. Но чтобы увидеть эту разницу, необходимо несколько десяткой (мб сотен) запросов. Но этот маловероятный вид атаки у нас тоже не пройдет, поскольку после нескольких попыток логина появится обязательная к заполнению капча.
Мысль о том, что security не сочетается с usability до сих пор приходится слышать довольно часто.
Но ведь это ни разу не миф. Вот только навскидку то, что реализовывал в последнем проекте из того, что пользователю не очень удобно:
— password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.
— после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.
— при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик. Часть действий в своем профайле (изменение почты, например) требует обязательного подтверждения того, что пользователю принадлежит текущий привязанный ему почтовый ящик.
— если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет. Просто говорю, что credentials не подходят. А пользователю, в свою очередь, было бы гораздо удобнее, если бы я ему подсказал, есть ли вообще такой логин в системе или нет.
— я не говорю пользователям, не существует ли определенная страница или просто конкретно у него нет прав на эту страницу. Просто сообщаю, что данной страницы нет.
— и т.д. и т.п.
Все эти действия делают жизнь пользователей чуть менее приятными. Приходится удерживать от них часть информации; давать им больше проверок, когда у них что-то не получается сделать с первых попыток; и т.д.
Да даже в вашем примере с паролем: «Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.» — для многих это уже неудобно. Если пользователь до этого не пользовался менеджером ключей, то он не захочет делать это прямо сейчас и уж тем более не захочет слушать от вас, зачем ему этот самый менеджер ключей позарез понадобился.
Если читать быстрее (а это именно так!) то зачем смотреть видео?
Потому что многие провели гораздо больше времени, просматривая видео, чем читая. Соответственно, им в разы проще и обучаться за просмотром роликов, чем за чтением.
Говорю по личному опыту. По работе и на досуге читаю очень много информации на русском и английском языках. Соответственно, такой способ усвоения информация для меня удобней, и мне категорически не нравятся обучающие видео-ролики.
На испанском и немецком я, напротив, читаю очень мало, зато часто слушаю аудиокниги. В результате, когда приходится на этих языках что-то читать, то это непривычно и не комфортно. Смотреть на них видео / слушать аудио для меня гораздо проще и приятнее, чем читать.
Я читаю очень быстро, а слушаю ужасно. Я из за этого не могу аудиокниги воспринимать
Возможно, это дело привычки. Мне тоже сначала аудиокниги/подкасты жутко не нравились и информация усваивалась в разы хуже, чем с напечатанным текстом.
Но довольно быстро привык. Не помню, сколько привыкание заняло времени. Максимум, пару недель.
Аудиокниги начал слушать, чтобы ускорить изучение иностранных + чтобы можно было знакомиться с литературой, не напрягая глаза. В работе разработчика итак приходится много времени проводить смотря в монитор.
Я что-то подобное пару лет назад делал. Взял на вики частотный словарь (https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#English) и попробовал пройтись по нему.
Но это тоже абсолютно не надежный способ оценки своего словарного запаса. Во-первых, такие частотные словари содержат много мусора (имена, иностранные слова и т.д.), поскольку составляются автоматически. Реально выверенных хороших частотных словарей, обработанных людьми, я видел максимум на 8 или 10 тысяч слов.
Во-вторых, по той же причине, в списках много однокоренных слов.
В-третьих, не наступает такого момента, что до этого понимал все слова в списке, а тут раз, и перестал понимать. Грубо говоря, происходит как-то так: в списке от 10К до 11К самых частых слов узнаешь 98 слов из 100. На 15К-16К узнаешь 92 из 100.… На 55К-56К узнаешь 30 из 100. И так все равно очень сложно оценить, сколько знаешь слов.
В-четвертых, это занимает очень много времени. Никак не 8 часов. Когда слова в контексте, проще их узнавать. Когда они по одному, то постоянно возникают сомнения, а правильно ли я понимаю это слово, и начинаешь проверять его в словаре.
Вот. В общем, я не нашел надежного способа оценки реального словарного запаса, и считаю тесты, предоставленные в статье, наиболее простым и доступным способом оценки.
> Стандарты разрабатываются и обсуждаются неделями, месяцами и иногда годами
Мне кажется, что к правилам размещения скобочек это не относится. Например, в C# пишут скобочки как раз на отдельной строке, в отличие от php или Java.
Я думаю, что это вообще не важный и не принципиальный момент. Просто в пределах проекта (или группы проектов) надо придерживаться одинакового код стайла.
Зависит от человека.
Для кого-то такой подход сработает хорошо. Я знаю людей, которые в повседневной жизни по несколько раз перечитывают одни и те же книги, смотрят одни и те же сериалы и фильмы. Уверен, что при изучении языков они могут многократно повторять одно и то же.
Но лично для меня читать то, что вот только что читал — это невыносимая мука и скукота. Для меня гораздо эффективней — это двигаться дальше. К следующей книги или следующей главе.
Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!
Конкретно вот этот вот аргумент — так себе. В этом примере на 10 строк используется XMLHttpRequest, вместо которого сегодня смело можно использовать fetch.
отпуск начался, дня три позанимался в какой-нибудь программе по пару часов, ну может неделю, а потом забиваешь по разным причинам
Я просто ни разу не забивал. Я думал, что это нормально, что поначалу есть опечатки и сам процесс набора скорости медленнее, чем если смотреть на клавиатуру. Была уверенность, что со временем станет привычней, поэтому особо не парился и не смотрел на клавиатуру.
А что значит «запоминание» в вашем случае?
Что-то типа «пальцы левой руки находятся над фыва», «я находится под мизинцем левой руки», «ю находится справа от б» и т.д. Поначалу вспоминать сложно и долго, потом проще, потому (пару недель спустя) вообще не думаешь, что где находится.
У меня опыт отличается от того, что я прочитал в статье и в большинстве комментариев, поэтому я им поделюсь.
Лет 15 назад мне в руки совершенно случайно попала методичка по слепому методу печати (знакомые просили отсканировать для них). Пользуясь случаем, я ее прочитал. Запомнил клавиши за два дня. В первый день потратил полчаса, и в во второй день потратил полчаса. С этого дня по-русски печатал только вслепую. Поначалу медленно и с большим количеством опечаток. Иногда зависал, вспоминая, где находится нужная мне буква. Потом быстрее. Никакие упражнения никогда не делал.
Потом точно так же выучил английскую раскладку. Тоже ушло не больше часа и тоже скорость была поначалу ниже, чем, если смотреть на клавиатуру. Но освоение второй раскладки было гораздо проще. На английском я набрал скорость гораздо быстрее.
Спустя где-то полгода печатания я достиг своей максимальной скорости: 450-500 символов в течение небольшого промежутка времени (например, чтобы проверить скорость печати) и около 300 символов в спокойном режиме. Я думаю, это далеко не предельные числа и кто-то печатает гораздо быстрее, но для меня это скорость, которая не увеличилась за почти 15 лет. В принципе, такой темп меня устраивает. Программирование и переписка больше упирается не в скорость печати, а в скорость мышление.
Около года назад осваивал японскую раскладку (кана-мод). Тоже ушло меньше часа на запоминание символов, а потом пару недель раскачивался, чтобы печатать быстрее.
Честно говоря, я не знал, что кто-то испытывает проблемы при освоении слепой печати и занимается этим неделями и месяцами. Конечно, я не могу порекомендовать свой путь, но для меня он сработал отлично. Судя по комментариям, я такой не один.
(а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно)
В этом нет ничего необычного. Например, я зарегистрирован в 2013-м году, а получил приглашение только в 2018-м. Пять лет я просто читал хабр и был read-only пользователем.
Тут, конечно, статья не об английском, но все же employer — это наниматель. Работник — это employee. Ну или просто: кандидат, соискатель, работник, претендент.
В postgresql по дефолту стоит достаточно высокое значение для autovacuum_vacuum_scale_factor, равное 0.2 (т.е. vacuum будет вызван, когда мертвых записей будет 20% от всей таблице).
Для многих проектов лучше уменьшить значение до 0.05 или даже до 0.02. Профит особенно хорошо будет заметен для таблиц, где вставки (inserts) происходят гораздо чаще, чем updates.
Проблема даже не в том, что чистка 20% таблицы может занять много времени (но и это тоже). Само наличие большого количества dead tuples влияет на скорость запросов к таблице (select) и на то, как используются индексы.
Но эти значения, конечно, лучше подбирать исходя из конкретных проектов/данных/таблиц.
Не говоря уже о том, что если хранить результаты запросов паджинации, то встает очень сложная проблема, как эти производные данные синхронизировать с основной таблицей, т.е. когда инвалидировать этот кэш.
Число оценок для топ-3 компаний с 5К+ сотрудников составляет 89, 24 и 39 человека. Это меньше 1% сотрудников.
Я очень рад, что у нас в России есть сервис для сбора информации об IT-компаниях и получаемых зарплатах, и всецело поддерживаю деятельность Моего Круга и их блог.
Но хотелось бы, чтобы больше людей пошли и оставили свой фидбек, чтобы сложилось более полное представление о рынке труда.
Я знаю, что еще возможно определить, есть ли такой логин по скорости ответа сервера. Если сервер быстрее выдал ошибку о неправильных credentials, то значит такого логина в системе нет. Но чтобы увидеть эту разницу, необходимо несколько десяткой (мб сотен) запросов. Но этот маловероятный вид атаки у нас тоже не пройдет, поскольку после нескольких попыток логина появится обязательная к заполнению капча.
Но ведь это ни разу не миф. Вот только навскидку то, что реализовывал в последнем проекте из того, что пользователю не очень удобно:
— password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.
— после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.
— при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик. Часть действий в своем профайле (изменение почты, например) требует обязательного подтверждения того, что пользователю принадлежит текущий привязанный ему почтовый ящик.
— если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет. Просто говорю, что credentials не подходят. А пользователю, в свою очередь, было бы гораздо удобнее, если бы я ему подсказал, есть ли вообще такой логин в системе или нет.
— я не говорю пользователям, не существует ли определенная страница или просто конкретно у него нет прав на эту страницу. Просто сообщаю, что данной страницы нет.
— и т.д. и т.п.
Все эти действия делают жизнь пользователей чуть менее приятными. Приходится удерживать от них часть информации; давать им больше проверок, когда у них что-то не получается сделать с первых попыток; и т.д.
Да даже в вашем примере с паролем: «Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.» — для многих это уже неудобно. Если пользователь до этого не пользовался менеджером ключей, то он не захочет делать это прямо сейчас и уж тем более не захочет слушать от вас, зачем ему этот самый менеджер ключей позарез понадобился.
Неправда.
Потому что многие провели гораздо больше времени, просматривая видео, чем читая. Соответственно, им в разы проще и обучаться за просмотром роликов, чем за чтением.
Говорю по личному опыту. По работе и на досуге читаю очень много информации на русском и английском языках. Соответственно, такой способ усвоения информация для меня удобней, и мне категорически не нравятся обучающие видео-ролики.
На испанском и немецком я, напротив, читаю очень мало, зато часто слушаю аудиокниги. В результате, когда приходится на этих языках что-то читать, то это непривычно и не комфортно. Смотреть на них видео / слушать аудио для меня гораздо проще и приятнее, чем читать.
Возможно, это дело привычки. Мне тоже сначала аудиокниги/подкасты жутко не нравились и информация усваивалась в разы хуже, чем с напечатанным текстом.
Но довольно быстро привык. Не помню, сколько привыкание заняло времени. Максимум, пару недель.
Аудиокниги начал слушать, чтобы ускорить изучение иностранных + чтобы можно было знакомиться с литературой, не напрягая глаза. В работе разработчика итак приходится много времени проводить смотря в монитор.
Я что-то подобное пару лет назад делал. Взял на вики частотный словарь (https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#English) и попробовал пройтись по нему.
Но это тоже абсолютно не надежный способ оценки своего словарного запаса. Во-первых, такие частотные словари содержат много мусора (имена, иностранные слова и т.д.), поскольку составляются автоматически. Реально выверенных хороших частотных словарей, обработанных людьми, я видел максимум на 8 или 10 тысяч слов.
Во-вторых, по той же причине, в списках много однокоренных слов.
В-третьих, не наступает такого момента, что до этого понимал все слова в списке, а тут раз, и перестал понимать. Грубо говоря, происходит как-то так: в списке от 10К до 11К самых частых слов узнаешь 98 слов из 100. На 15К-16К узнаешь 92 из 100.… На 55К-56К узнаешь 30 из 100. И так все равно очень сложно оценить, сколько знаешь слов.
В-четвертых, это занимает очень много времени. Никак не 8 часов. Когда слова в контексте, проще их узнавать. Когда они по одному, то постоянно возникают сомнения, а правильно ли я понимаю это слово, и начинаешь проверять его в словаре.
Вот. В общем, я не нашел надежного способа оценки реального словарного запаса, и считаю тесты, предоставленные в статье, наиболее простым и доступным способом оценки.
Мне кажется, что к правилам размещения скобочек это не относится. Например, в C# пишут скобочки как раз на отдельной строке, в отличие от php или Java.
Я думаю, что это вообще не важный и не принципиальный момент. Просто в пределах проекта (или группы проектов) надо придерживаться одинакового код стайла.
Для кого-то такой подход сработает хорошо. Я знаю людей, которые в повседневной жизни по несколько раз перечитывают одни и те же книги, смотрят одни и те же сериалы и фильмы. Уверен, что при изучении языков они могут многократно повторять одно и то же.
Но лично для меня читать то, что вот только что читал — это невыносимая мука и скукота. Для меня гораздо эффективней — это двигаться дальше. К следующей книги или следующей главе.
Конкретно вот этот вот аргумент — так себе. В этом примере на 10 строк используется XMLHttpRequest, вместо которого сегодня смело можно использовать fetch.
Я просто ни разу не забивал. Я думал, что это нормально, что поначалу есть опечатки и сам процесс набора скорости медленнее, чем если смотреть на клавиатуру. Была уверенность, что со временем станет привычней, поэтому особо не парился и не смотрел на клавиатуру.
Что-то типа «пальцы левой руки находятся над фыва», «я находится под мизинцем левой руки», «ю находится справа от б» и т.д. Поначалу вспоминать сложно и долго, потом проще, потому (пару недель спустя) вообще не думаешь, что где находится.
Лет 15 назад мне в руки совершенно случайно попала методичка по слепому методу печати (знакомые просили отсканировать для них). Пользуясь случаем, я ее прочитал. Запомнил клавиши за два дня. В первый день потратил полчаса, и в во второй день потратил полчаса. С этого дня по-русски печатал только вслепую. Поначалу медленно и с большим количеством опечаток. Иногда зависал, вспоминая, где находится нужная мне буква. Потом быстрее. Никакие упражнения никогда не делал.
Потом точно так же выучил английскую раскладку. Тоже ушло не больше часа и тоже скорость была поначалу ниже, чем, если смотреть на клавиатуру. Но освоение второй раскладки было гораздо проще. На английском я набрал скорость гораздо быстрее.
Спустя где-то полгода печатания я достиг своей максимальной скорости: 450-500 символов в течение небольшого промежутка времени (например, чтобы проверить скорость печати) и около 300 символов в спокойном режиме. Я думаю, это далеко не предельные числа и кто-то печатает гораздо быстрее, но для меня это скорость, которая не увеличилась за почти 15 лет. В принципе, такой темп меня устраивает. Программирование и переписка больше упирается не в скорость печати, а в скорость мышление.
Около года назад осваивал японскую раскладку (кана-мод). Тоже ушло меньше часа на запоминание символов, а потом пару недель раскачивался, чтобы печатать быстрее.
Честно говоря, я не знал, что кто-то испытывает проблемы при освоении слепой печати и занимается этим неделями и месяцами. Конечно, я не могу порекомендовать свой путь, но для меня он сработал отлично. Судя по комментариям, я такой не один.
В этом нет ничего необычного. Например, я зарегистрирован в 2013-м году, а получил приглашение только в 2018-м. Пять лет я просто читал хабр и был read-only пользователем.
Тут, конечно, статья не об английском, но все же employer — это наниматель. Работник — это employee. Ну или просто: кандидат, соискатель, работник, претендент.
Прошу извинить за дотошность :-)