Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает
Ну вот я выше привёл пример того, как известным в узких кругах алгоритмах можно было бы сразу наметить план решения. Поэтому какие-то преимущества всё же даёт.
получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации.
Хороший олимпиадник сходу задаётся этими же вопросами. Более того, зачастую олимпиадники задают даже более тонкие вопросы, т.к. сразу могут подобрать варианты решения.
P.S. разумеется на реализацию этих решений могут уйти дни-недели-месяцы. Но в среднем хорошие олимпиадники не испытывают проблем с длительными задачами...
Я не уверен, что Вы здесь имеете ввиду под "бизнесом". Но если говорить с точки зрения подбора разработчиков, то хорошие технические навыки (в том числе опыт в олимпиадах) довольно важны и полезны с точки зрения продуктивности (разумеется при условии что они как работники нормальные — по это само собой разумеется)
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая. Но абсолютно аналогично не очень хорошая затея смотреть исключительно на технические навыки. Можно сказать аналогичную фразу
Все к тому, что человек с блестящими навыками программирования в бизнесе может хорошо себя показать, а может и наоборот. Потому что это очень разные вещи.
Разумеется при приёме на работу нужно также смотреть на социальные особенности человека (и вроде как почти во всех внятных местах смотрят)
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык. На умение работать с рутиной такой опыт не влияет ни положительно ни отрицательно — на это влияют другие, не связанные особенности характера.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
"Инвертированный индекс" — это вполне себе стандартная структура данных для решения подобных задач, тут не вопрос того, как я себе это представляю.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Дальше, если мы хотим например найти клиентов у которых в адресе встречаются w1 и w2, мы находим соответствующие списки клиентов и пересекаем их — это делается за линейное время от размера результата (по модулю логарифмов). Аналогично для поискаслов можно объединить списки за,, гдеесть размер результата.
Как строить и где хранить этот индекс — это отдельный вопрос. Можно его материализовать в бд (например в виде таблицы (word, client_id)). Можно материализовать в как отдельную структуру на диске. Вообще говоря, можно даже попробовать собрать этот индекс в памяти, прямо во время сверки — там не.
Подход к построению индекса сильно зависит от среды. Доступной памяти, возможностей организации структур данных, возможность итерации по бд и прочего. Тут Вы сами знаете лучше.
Дальше надо написать модуль поддержки этой витрины - [...]
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, [...]
Я прекрасно понимаю связанные сложности с поддержанием витрин и в целом жизненным циклом программных продуктов. И о том, что разработка отличается от олимпиады.
Но во-первых, про инвертированный индекс я писал несколько в отрыве от истории с олимпиадами.
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Не очень понимаю, почему олимпиаднику это не мешает. На моём опыте, когда людей с исследовательским характером ставят на рутину, они очень быстро выгорают, независимо от наличия олимпиадного опыта.
Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
На моей практике, это слабо связано с олимпиадами. Просто есть такие люди, которые больше по ресёрчу — они не могут долго в рутину. Среди них есть как олимпиадники, так и много тех, кто олимпиады не трогал. Поэтому выскажу гипотезу, что это просто нерепрезентативная выборка.
Причем, в заранее не можете сказать хватит вам простого решения или нет.
На самом деле, зачастую прикинуть как раз можно. По крайней мере в таких условиях, когда есть простые и конкретные ограничения, как в Вашем примере. И как раз этот навык олимпиады очень хорошо тренируют.
P.S. кстати говоря, хотя я понимаю, что задача с адресами уже была рассказана с учётом решения, но чисто по описанию и объёмам данных там сразу напрашивается классический инвертированный индекс. Вы, я так понял, пришли к похожему решению, но без слияний по бинпоиску. (к сожалению, не был готов пробираться через терминологию, чтобы понять решение по нормальному)
Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
От этого в вебе никуда не деться, и я это не прячу.
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Во-вторых, язык (потенциально, в пределе) способен на полное описание действительности. А математика — нет.
Почему нет?
Ту, которая очищена от качеств (и содержаний?), и состоит из количеств (и форм?).
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Потому что мы так придумали. Вопрос же в том, что такое F и что такое m. По сути своей, какова бы не была реальность, её можно в определённых пределах описать вторым законом Ньютона. Ну и напомню, что он является лишь приближением.
Но даже если отставить это в сторону и просто посмотреть на саму силу(которой не существует в объективной реальности, мы выдумали этот концепт). Допустим вот сила трения — это просто? Не особо.
Соотношение работает лишь как довольно грубое приближение. Коэффициент трения меняется в зависимости от кучи условий. Даже банально у движущегося тела и у покоящегося будут разные коэффициенты трения. Есть ещё сила трения покоя, которая вообще зависит от того, как сильно Вы пытаетесь пододвинуть тело. Есть вязкое трение, которое зависит от скорости. И так далее...
Ну и даже соотношениеявляется довольно сложным с точки зрения математики. Тут нужны какие-то вещественные числа, бесконечности и даже диффуры. Условный КА, или машина Тьюринга — гораздо проще этого закона.
К тому же, можно сделать функцию tokenize отдельной, которая бы создавала лексер и сразу вызывала функцию lexer.tokenize, и таким образом будет удобный для модификаций лексер и простой удобный юзерский интерфейс.
Об этом и речь. Не имею ничего против контекста. Просто не нужно показывать его в публичном интерфейсе.
Почитал исходники шифрования. Каких-то прям уязвимостей не увидел сходу. Хотя кажется многие вещи можно сделать проще. Например, попытки в ctime, которые ничего не дают (но они и не нужны здесь). Но это не шибко важно.
Важно то, что схема исходно сломана. Шифрование на клиенте принципиально требует доверия к серверу. Проблема в том, что ничего не мешает серверу просто взять и отдать конкретному одному клиенту другой жс код, который, например, пришлёт пароль на сервер.
Мобильное приложение чуть лучше защищает от подобной атаки, т.к. в магазине приложений видны все версии приложения. И то, тут есть вопросы ко всяким A/B тестам, которые магазины могут предлагать разработчикам...
В идеале, для шифрования на клиенте, обновление кода должно происходить только при подтверждении пользователя. Плюс какой-нибудь transparency report от третьих лиц...
Во-первых, в этой функции надо будет создавать обьект лексера, чтобы был общий контекст.
Ну так создайте, в чём проблема. Можете даже сделать реализацию функции tokenize как Lexer::new(s).tokenize(). Суть ведь не в этом.
Суть в том, чтобы публичный интерфейс был простым для простых использований. Если понадобятся опции — сделаете функцию tokenize_with_opts; ну либо уже через объект лексера. См каноничный пример serde_json::from_str.
Ну вот я выше привёл пример того, как известным в узких кругах алгоритмах можно было бы сразу наметить план решения. Поэтому какие-то преимущества всё же даёт.
Хороший олимпиадник сходу задаётся этими же вопросами. Более того, зачастую олимпиадники задают даже более тонкие вопросы, т.к. сразу могут подобрать варианты решения.
P.S. разумеется на реализацию этих решений могут уйти дни-недели-месяцы. Но в среднем хорошие олимпиадники не испытывают проблем с длительными задачами...
Я не уверен, что Вы здесь имеете ввиду под "бизнесом". Но если говорить с точки зрения подбора разработчиков, то хорошие технические навыки (в том числе опыт в олимпиадах) довольно важны и полезны с точки зрения продуктивности (разумеется при условии что они как работники нормальные — по это само собой разумеется)
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая. Но абсолютно аналогично не очень хорошая затея смотреть исключительно на технические навыки. Можно сказать аналогичную фразу
Разумеется при приёме на работу нужно также смотреть на социальные особенности человека (и вроде как почти во всех внятных местах смотрят)
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык. На умение работать с рутиной такой опыт не влияет ни положительно ни отрицательно — на это влияют другие, не связанные особенности характера.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
"Инвертированный индекс" — это вполне себе стандартная структура данных для решения подобных задач, тут не вопрос того, как я себе это представляю.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Дальше, если мы хотим например найти клиентов у которых в адресе встречаются w1 и w2, мы находим соответствующие списки клиентов и пересекаем их — это делается за линейное время от размера результата (по модулю логарифмов). Аналогично для поиска
слов можно объединить списки за,
, где
есть размер результата.
Как строить и где хранить этот индекс — это отдельный вопрос. Можно его материализовать в бд (например в виде таблицы (word, client_id)). Можно материализовать в как отдельную структуру на диске. Вообще говоря, можно даже попробовать собрать этот индекс в памяти, прямо во время сверки — там не.
Подход к построению индекса сильно зависит от среды. Доступной памяти, возможностей организации структур данных, возможность итерации по бд и прочего. Тут Вы сами знаете лучше.
Я прекрасно понимаю связанные сложности с поддержанием витрин и в целом жизненным циклом программных продуктов. И о том, что разработка отличается от олимпиады.
Но во-первых, про инвертированный индекс я писал несколько в отрыве от истории с олимпиадами.
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Не очень понимаю, почему олимпиаднику это не мешает. На моём опыте, когда людей с исследовательским характером ставят на рутину, они очень быстро выгорают, независимо от наличия олимпиадного опыта.
Или я Вас неправильно понял?
На моей практике, это слабо связано с олимпиадами. Просто есть такие люди, которые больше по ресёрчу — они не могут долго в рутину. Среди них есть как олимпиадники, так и много тех, кто олимпиады не трогал. Поэтому выскажу гипотезу, что это просто нерепрезентативная выборка.
На самом деле, зачастую прикинуть как раз можно. По крайней мере в таких условиях, когда есть простые и конкретные ограничения, как в Вашем примере. И как раз этот навык олимпиады очень хорошо тренируют.
P.S. кстати говоря, хотя я понимаю, что задача с адресами уже была рассказана с учётом решения, но чисто по описанию и объёмам данных там сразу напрашивается классический инвертированный индекс. Вы, я так понял, пришли к похожему решению, но без слияний по бинпоиску. (к сожалению, не был готов пробираться через терминологию, чтобы понять решение по нормальному)
Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Фальсифицируют аксиомы и гипотезы, а не теоремы/доказательства. Ошибка есть просто ошибка.
Я об этом же. Именно поэтому математика не есть наука (не использует научный метод)
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Почему нет?
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Нет. Она нефальсифицируема. Более того, в математике нет такого понятия как "ложная аксиома" — а это есть одно из ключевых требований дл науки.
Потому что мы так придумали. Вопрос же в том, что такое F и что такое m. По сути своей, какова бы не была реальность, её можно в определённых пределах описать вторым законом Ньютона. Ну и напомню, что он является лишь приближением.
Но даже если отставить это в сторону и просто посмотреть на саму силу(которой не существует в объективной реальности, мы выдумали этот концепт). Допустим вот сила трения — это просто? Не особо.
Соотношение
работает лишь как довольно грубое приближение. Коэффициент трения меняется в зависимости от кучи условий. Даже банально у движущегося тела и у покоящегося будут разные коэффициенты трения. Есть ещё сила трения покоя, которая вообще зависит от того, как сильно Вы пытаетесь пододвинуть тело. Есть вязкое трение, которое зависит от скорости. И так далее...
Ну и даже соотношение
является довольно сложным с точки зрения математики. Тут нужны какие-то вещественные числа, бесконечности и даже диффуры. Условный КА, или машина Тьюринга — гораздо проще этого закона.
Об этом и речь. Не имею ничего против контекста. Просто не нужно показывать его в публичном интерфейсе.
Почитал исходники шифрования. Каких-то прям уязвимостей не увидел сходу. Хотя кажется многие вещи можно сделать проще. Например, попытки в ctime, которые ничего не дают (но они и не нужны здесь). Но это не шибко важно.
Важно то, что схема исходно сломана. Шифрование на клиенте принципиально требует доверия к серверу. Проблема в том, что ничего не мешает серверу просто взять и отдать конкретному одному клиенту другой жс код, который, например, пришлёт пароль на сервер.
Мобильное приложение чуть лучше защищает от подобной атаки, т.к. в магазине приложений видны все версии приложения. И то, тут есть вопросы ко всяким A/B тестам, которые магазины могут предлагать разработчикам...
В идеале, для шифрования на клиенте, обновление кода должно происходить только при подтверждении пользователя. Плюс какой-нибудь transparency report от третьих лиц...
По поводу использования библиотек - ок.
Ну так создайте, в чём проблема. Можете даже сделать реализацию функции tokenize как Lexer::new(s).tokenize(). Суть ведь не в этом.
Суть в том, чтобы публичный интерфейс был простым для простых использований. Если понадобятся опции — сделаете функцию tokenize_with_opts; ну либо уже через объект лексера. См каноничный пример serde_json::from_str.
Вообще, лексер гораздо проще написать через Logos. Да и эффективнее это.
Также, лучше чтобы tokenize была функцией str -> Tokens, а не методом Lexer-а...