Не совсем так. Всякие оффлайн-платежи (допустим, по подписке с карты снимают сумму раз в месяц) тоже работают через токенизацию. Токен в таком сценарии переиспользуется.
Собственно, технология токенизации далеко не нова, и используется в других странах.
Насколько я понял, то, что делают у нас сейчас — это внедрение внутреннего сервиса токенизации. Эдакий отечественный аналог Stripe и иже с ними.
Таким образом обходится ограничение на передачу данных на иностранные сервера, в соответствии с Российским законодательством.
Реально информация о банковских картах передается только на сервер токенизации (который теперь будет внутри страны).
А зачем под L+R выделена полоса 15КГц (0-15), а для L-R — в 2 раза больше, 30КГц (23-53)?
Чего этим добиваются или какую проблему решают?
И как их потом суммировать для выделения отдельного левого и правого канала, если ширина полос разная?
Ясно, просто у вас другой юз-кейз. Вы ищете топ-левел инженера. Да еще, видимо, имеете возможность перекупить его из другой компании («заинтересовать»).
В случае же, когда ищется джуниор/миддл, такой подход не сработает. У них просто не будет публикаций, открытого кода на гитхабе, вот этого всего.
Огромное количество разработчиков не имеют публичной активности на гитхабе, которую можно посмотреть и оценить их уровень.
Дать рабочую задачу в качестве тестового задания — это супер. Но очень часто невозможно. Большой проект, сложное окружение, чтобы просто все настроить у себя на машине, кандидат потратит день. Не говоря уже о введении в то, что проект вообще делает, какие бизнес-требования надо реализовать и т.д.
А как вы решаете эту проблему? Или у вас всегда можно выдрать какую-то произвольную задачу из контекста и решать ее саму по себе?
Те же «декораторы в питоне» — если я ищу питон-разработчика в проект, написанный на питоне, и кандидат заявляет Х лет опыта с питоном, то ожидается, что основные концепции языка он должен знать.
Но более интересны фундаментальные вопросы, нежели детали конкретного языка/фреймворка/etc. Если собеседуем веб-разработчика — давайте спросим про то, зачем нужны куки, как именно с их помощью реализуют пользовательские сессии (вы удивитесь, как много людей, заявляющихся как уверенный мидл, не понимали, как это работает). Или про то, какие бывают уязвимости в веб-приложениях и как с этим бороться.
Дело даже не столько в конкретных знаниях. А в том насколько кандидат старается развиваться как профессионал в той или оной области. Невозможно знать все. Но не знать ничего — это тоже плохо. Надо хотя бы интересоваться тем, что происходит вокруг.
Возможно, в примере с комментариями к статьям, приведенным автором, nested set — как раз не лучший вариант. По ссылке на SO предлагают Flat Table в этом случае.
Действительно же hack. Меня смутил приведенный вами пайп-оператор — и я решил, что весь пример чисто синтетический.
Я так понял, что в php проблемы с запиливанием короткого синтаксиса именно с имеющимися парсером, который иначе пришлось бы сильно менять.
В Hack парсер писали с нуля, и у них такой проблемы не возникло.
Согласен, что предложенный вариант лямбд не идеален.
К сожалению, синтаксис все еще не такой уж короткий:
$result = array_map(function($x) => $x * 2, $elements);
Для сравнения, в Hack (статически-типизированный диалект php от Facebook):
docs.hhvm.com/hack/lambdas/introduction
return $people->map($name ==> $name. " Banks");
> так как любое * заставит просмотреть все элементы
Поскольку селекторы разбираются браузером справа налево, сначала браузер все равно выберет массив `.news__list-item` (самый правый элемент селектора). Так что на производительности это не отразится.
в нем тоже полно пакетов с «плавающими» зависимостями
monolithed А можно больше подробностей? На своих проектах такого не замечал. Да и документация (https://docs.npmjs.com/cli/shrinkwrap) утверждает, что версии всех пакетов будут фиксироваться.
Насколько я понял, то, что делают у нас сейчас — это внедрение внутреннего сервиса токенизации. Эдакий отечественный аналог Stripe и иже с ними.
Таким образом обходится ограничение на передачу данных на иностранные сервера, в соответствии с Российским законодательством.
Реально информация о банковских картах передается только на сервер токенизации (который теперь будет внутри страны).
Спасибо, более-менее ясно.
Чего этим добиваются или какую проблему решают?
И как их потом суммировать для выделения отдельного левого и правого канала, если ширина полос разная?
Вы только что описали работу ServiceWorker :) developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
В случае же, когда ищется джуниор/миддл, такой подход не сработает. У них просто не будет публикаций, открытого кода на гитхабе, вот этого всего.
Дать рабочую задачу в качестве тестового задания — это супер. Но очень часто невозможно. Большой проект, сложное окружение, чтобы просто все настроить у себя на машине, кандидат потратит день. Не говоря уже о введении в то, что проект вообще делает, какие бизнес-требования надо реализовать и т.д.
А как вы решаете эту проблему? Или у вас всегда можно выдрать какую-то произвольную задачу из контекста и решать ее саму по себе?
Технические вопросы задавать можно и нужно.
Те же «декораторы в питоне» — если я ищу питон-разработчика в проект, написанный на питоне, и кандидат заявляет Х лет опыта с питоном, то ожидается, что основные концепции языка он должен знать.
Но более интересны фундаментальные вопросы, нежели детали конкретного языка/фреймворка/etc. Если собеседуем веб-разработчика — давайте спросим про то, зачем нужны куки, как именно с их помощью реализуют пользовательские сессии (вы удивитесь, как много людей, заявляющихся как уверенный мидл, не понимали, как это работает). Или про то, какие бывают уязвимости в веб-приложениях и как с этим бороться.
Дело даже не столько в конкретных знаниях. А в том насколько кандидат старается развиваться как профессионал в той или оной области. Невозможно знать все. Но не знать ничего — это тоже плохо. Надо хотя бы интересоваться тем, что происходит вокруг.
Вообще надо понимать, что в зависимости от характера использования иерархических данных хранить их можно по-разному. Например, для дешевой операции вставки — тривиальный adjacent list, для дешевого поиска — nested set.
Вот здесь есть шикарное описание разных способов хранения деревьев в реляционных БД.
stackoverflow.com/questions/4048151/what-are-the-options-for-storing-hierarchical-data-in-a-relational-database
Возможно, в примере с комментариями к статьям, приведенным автором, nested set — как раз не лучший вариант. По ссылке на SO предлагают Flat Table в этом случае.
Я так понял, что в php проблемы с запиливанием короткого синтаксиса именно с имеющимися парсером, который иначе пришлось бы сильно менять.
В Hack парсер писали с нуля, и у них такой проблемы не возникло.
Согласен, что предложенный вариант лямбд не идеален.
wiki.php.net/rfc/arrow_functions
К сожалению, синтаксис все еще не такой уж короткий:
$result = array_map(function($x) => $x * 2, $elements);
Для сравнения, в Hack (статически-типизированный диалект php от Facebook):
docs.hhvm.com/hack/lambdas/introduction
return $people->map($name ==> $name. " Banks");
Поскольку селекторы разбираются браузером справа налево, сначала браузер все равно выберет массив `.news__list-item` (самый правый элемент селектора). Так что на производительности это не отразится.
`*` — зло, когда он стоит справа в селекторе.
monolithed А можно больше подробностей? На своих проектах такого не замечал. Да и документация (https://docs.npmjs.com/cli/shrinkwrap) утверждает, что версии всех пакетов будут фиксироваться.