Мне еще понравилась фича TC - быстрый поиск (или точнее, быстрая фильтрация). В настройках программы регулируется на вкладке Quick Search. Позволяет путем ввода текста на любой панели с файлами быстро динамически фильтровать только нужные (по совпадению введенных символов как подстроки в их имени), без необходимости вызова окна поиска файлов.
Например, заходим на панели в какой-то каталог с кучей файлов (или в каталоге с вложенной структурой предварительно нажимаем Ctrl-B чтобы получить "плоский" вид всех файлов всех вложенных каталогов разом) и затем просто начинаем набирать часть имени нужных файлов (например, 'commander' для выбора всех файлов с таким словом, или '.jp' для быстрой фильтрации по расширению) и вот у нас на панели отображаются только эти файлы, причем очень быстро можно поменять этот фильтр, введя другую строку.
По сути, как поиск по названиям файлов, но функционально гораздо быстрее и удобнее.
Справедливости ради, при поиске в Гугле будет та же самая картина. Так что это не прихоть именно Яндекса. В целом поисковики стараются искать с учетом контекста и трендов.
Если же написать конкретнее "что такое сумерки", то увидим уже привычную расшифровку термина, и в Гугле, и в Яндексе.
Первая инфографика не в тему (или просто не упомянута в самом тексте). В ней говорится про то, сколько пользователей сами рады использовать различные хаки и эксплойты (видимо с намеком, что это тоже является вектором атаки) ради победы в играх.
Правило, которые надо запомнить на всю жизнь: в Oracle null + some_text = some_text. Практически во всех других базах = null.
В PG можно изменять используемые операторы, как в данном случае оператор конкатенации строк || Можно сделать так, чтобы логика работы была аналогична оракловому (сложение с null не будет обнулять результат), но тут уже для себя решать, если хотите сделать полную аналогию оракловому или сохранить стандарт PG. Примерно так выглядит:
create or replace function public.concat_null(text, text)
returns text as $body$
select concat($1, $2)
$body$ language sql immutable;
create operator public.|| (leftarg = text, rightarg = text, function=concat_null);
Приоритет выбора нужной версии (оператора/функции и т.п.) настраивается через задание search_path. Соответственно нужно понизить приоритет pg_catalog перед нашими, например так (обычно еще стоит oracle от orafce)
set search_path to "$user", public, oracle, pg_catalog;
И тогда
select null||'something'
будет как в оракле возвращать строку вместо null.
nvl — просто меняем на coalesce не думая, все работает.
только в оракле есть особенность, '' и null - одно и то же, в отличие от PG. в результате в оракле nvl('', value) идентично nvl(null, value)
coalesce ожидает точного значения: или '' или null. Так что может быть разница, если в оракле писали с учетом его особенностей работы пустых строк.
Думаю, речь про тот случай, когда название поля таблицы совпадает с названием самой таблицы. В таком случае запрос выведет только одно это поле. Например,
select doc
from doc
Но тогда вижу можно использовать приведение типов для получения результата из статьи:
Новая ситуация: я остаюсь перед выбором из двух вариантов. Один из вариантов выигрышный. Я выбираю наугад и, «очевидно», выигрываю с вероятностью ½ или проигрываю с той же вероятностью.
Разница в том, что у этих двух вариантов неодинаковая вероятность (приз же не перераспределяли после 1-й попытки). Вероятность приза в изначально выбранной двери равна 1/3, вероятность приза при смене двери равна 2/3, т.к. по факту при смене двери выбираешь не одну дверь, а все, кроме 1-й (т.е. 2 в случае 3 дверей).
Некоторым помогает понять пример с заведомо гораздо большим количеством дверей. Например, у нас изначально 100 дверей, за одной приз. После 1-й попытки ведущий открывает 98 заведомо пустых дверей. Вероятность приза за изначально выбранной дверью 1/100. Если после попытки сменим выбор, то мы как бы разом выбираем все остальные 99 дверей (из которых 98 ведущий уже исключил), так что вероятность выигрыша станет 99/100.
Данное сравнение со стримингом некорректно, т.к. в случае со стримингом идет оплата подписки, которая увеличивается в случае необходимости пользоваться дополнительным сервисом, а для игр — оплата за экземпляр, которая не изменяется в зависимости от площадки (на тот же Outer Worlds пришлось бы потратить одинаковую сумму что на стиме, что на эпике).
Ну да, говорит, я все забрал. А через час прилетает с выпученными глазами и истерикой, оказывается вместо клиентской базы на флешке ярлык на неё. Знаете, кто остался виноват? Нет, не я
А сотруднику оказывает надо было просто знать про первое правило «не утверждай» и на вопрос «Всё забрал?» ответить «Я думаю, да».
Это уже особенности перевода и особенности их речи.
В оригинале
This breaks when you enter a negative number. Can you please address this case?
В нашем переводе как раз и получается «Исправьте ошибку, пожалуйста». Кстати автор перевода этот момент с «пожалуйста» уже исправил.
То, что использовано «Can you please address this case?» вместо прямого «Address this case.», то это как уже упомянули, особенность их речи, не принято в повелительном наклонении выражаться.
Геймерским, я думаю, он считается потому, что изначально помимо обычного чата имел бесплатные каналы для голосового общения, активно использующегося в мультиплеерных играх. Помню как его подавали как замену всем текущим чисто голосовым клиентам: RaidCall, Ventrillo и т.п. Многие гильдии WoW так на него переползли. Потом к этому добавилась и интеграция с играми (лаунчер, магазин).
Сумма все же несколько другое, она представляет собой сложение всех элементов. А можно ссылку, где применяется произведение из одного числа, без указания множителя? Т.к. произведение подразумевает «взять некое число N раз».
Думаю, все пошло от некорректного (или устаревшего в связи с признанием 1 непростым) определения. В английском варианте основная теорема арифметики имеет как раз уточнение, отвечающее на ваш вопрос (wiki):
every integer greater than 1 either is a prime number itself or can be represented as the product of prime numbers
После первого этапа — проверки слива самого адреса, можно перейти ко второму — проверить пароли.
Если из названия утечки (внизу сайта) сразу не понятно, от чего утекли пароли, то можно проверить пароли от всех важных источников, связанных с этим адресом почты (в первую очередь собственно саму регистрацию почты).
Или напрямую, если доверяете честности HIBP, или через запрос списка хэшей по 5 символам: https://api.pwnedpasswords.com/range/{hashPrefix}
Можно использовать предложенные в комментариях скрипты для автоматической генерации хэша и проверки.
Выйдет быстрее, чем смена всех паролей при обнаружении компрометации адреса почты.
Проскакивала информация о том, что на Реддит есть некий интеллектуальный механизм сортировки «по полезности». Критерий полезности для меня лично оказался сокрыт.
Мне еще понравилась фича TC - быстрый поиск (или точнее, быстрая фильтрация). В настройках программы регулируется на вкладке Quick Search.
Позволяет путем ввода текста на любой панели с файлами быстро динамически фильтровать только нужные (по совпадению введенных символов как подстроки в их имени), без необходимости вызова окна поиска файлов.
Например, заходим на панели в какой-то каталог с кучей файлов (или в каталоге с вложенной структурой предварительно нажимаем Ctrl-B чтобы получить "плоский" вид всех файлов всех вложенных каталогов разом) и затем просто начинаем набирать часть имени нужных файлов (например, 'commander' для выбора всех файлов с таким словом, или '.jp' для быстрой фильтрации по расширению) и вот у нас на панели отображаются только эти файлы, причем очень быстро можно поменять этот фильтр, введя другую строку.
По сути, как поиск по названиям файлов, но функционально гораздо быстрее и удобнее.
Исследование: длительное сидение в смартфоне ухудшает память и вроде что-то еще.
Справедливости ради, при поиске в Гугле будет та же самая картина. Так что это не прихоть именно Яндекса. В целом поисковики стараются искать с учетом контекста и трендов.
Если же написать конкретнее "что такое сумерки", то увидим уже привычную расшифровку термина, и в Гугле, и в Яндексе.
Первая инфографика не в тему (или просто не упомянута в самом тексте). В ней говорится про то, сколько пользователей сами рады использовать различные хаки и эксплойты (видимо с намеком, что это тоже является вектором атаки) ради победы в играх.
Наоборот, задержка у тех, кто хорошо знает язык текста, т.к. они автоматически читают слова, а не просто называют цвет.
В PG можно изменять используемые операторы, как в данном случае оператор конкатенации строк || Можно сделать так, чтобы логика работы была аналогична оракловому (сложение с null не будет обнулять результат), но тут уже для себя решать, если хотите сделать полную аналогию оракловому или сохранить стандарт PG. Примерно так выглядит:
Приоритет выбора нужной версии (оператора/функции и т.п.) настраивается через задание search_path. Соответственно нужно понизить приоритет pg_catalog перед нашими, например так (обычно еще стоит oracle от orafce)
И тогда
будет как в оракле возвращать строку вместо null.
только в оракле есть особенность, '' и null - одно и то же, в отличие от PG. в результате в оракле nvl('', value) идентично nvl(null, value)
coalesce ожидает точного значения: или '' или null. Так что может быть разница, если в оракле писали с учетом его особенностей работы пустых строк.
Но тогда вижу можно использовать приведение типов для получения результата из статьи:
Разница в том, что у этих двух вариантов неодинаковая вероятность (приз же не перераспределяли после 1-й попытки). Вероятность приза в изначально выбранной двери равна 1/3, вероятность приза при смене двери равна 2/3, т.к. по факту при смене двери выбираешь не одну дверь, а все, кроме 1-й (т.е. 2 в случае 3 дверей).
Некоторым помогает понять пример с заведомо гораздо большим количеством дверей. Например, у нас изначально 100 дверей, за одной приз. После 1-й попытки ведущий открывает 98 заведомо пустых дверей. Вероятность приза за изначально выбранной дверью 1/100. Если после попытки сменим выбор, то мы как бы разом выбираем все остальные 99 дверей (из которых 98 ведущий уже исключил), так что вероятность выигрыша станет 99/100.
А сотруднику оказывает надо было просто знать про первое правило «не утверждай» и на вопрос «Всё забрал?» ответить «Я думаю, да».
В оригинале
В нашем переводе как раз и получается «Исправьте ошибку, пожалуйста». Кстати автор перевода этот момент с «пожалуйста» уже исправил.
То, что использовано «Can you please address this case?» вместо прямого «Address this case.», то это как уже упомянули, особенность их речи, не принято в повелительном наклонении выражаться.
Если из названия утечки (внизу сайта) сразу не понятно, от чего утекли пароли, то можно проверить пароли от всех важных источников, связанных с этим адресом почты (в первую очередь собственно саму регистрацию почты).
Или напрямую, если доверяете честности HIBP, или через запрос списка хэшей по 5 символам:
https://api.pwnedpasswords.com/range/{hashPrefix}Можно использовать предложенные в комментариях скрипты для автоматической генерации хэша и проверки.
Выйдет быстрее, чем смена всех паролей при обнаружении компрометации адреса почты.
redditblog.com/2009/10/15/reddits-new-comment-sorting-system
www.evanmiller.org/how-not-to-sort-by-average-rating.html