Я не противник, а сторонник open source в целом и в системах, обеспечивающих безопасность в частности (и антифрод в том числе). И совсем не сторонник STO.
Но надо быть объективными: ломать чёрный ящик гораздо сложнее, чем белый при прочих равных. Почему же в криптографии по-другому? В криптографических системах а) если детали реализации не ясны, то непонятно, можно ли доверять системе, б) открытость систем позволяет привлечь к проверке на несколько порядков больше ресурсов, в) позволяет алгоритму/протоколу жить дольше конкретной реализации.
То есть польза для криптографии от открытости просто перевешивает пользу от закрытости. А для антифрода это утверждение лично мне неочевидно. И статья не убедила меня.
Ещё один момент, который нехило подкрепляет предыдущий, это ваша "идеальная система защиты от DDoS". Фишка в том, что описав эту систему вы её сразу разрушили:
В вашем предложении антиDDoS слишком много от практик Spamhaus. А к этим ребятам вопросов очень много. Collateral damage там всегда на грани допустимого.
Ваша система сама становится почти идеальным оружием для DoS-атак. Сделать так, чтобы ваша подсеть попала в реестр запрещённых сильно проще, чем DDoSить.
Вопрос доверия и надежности такой системы решается блокчейном. Если коротко, то нет, не решается. Я не начинаю доверять реестру просто потому, что он на блокчейне.
По мне так, ваша антиDDoS система в том виде, как вы её описали — наивная утопия. Безусловно, если её сильно доработать, то она станет реализуемой, но от вашего примера там останется примерно ничего. Будет ли доработанная открытая антиDDoS лучше существующих решений? Не знаю, но выигрыша от открытости я пока точно не вижу.
Несмотря на мой опыт работы с 1С, я бы поспорил с необходимостью перевода IDE. Это же не только менюшки переводить, но и много всего "в кишках". Там слишком много всего разбросано, что переводить внешнего относительно IDE: плагины, внешние утилиты, логи. Боюсь, что там багов будет достаточно много, а реально целостного русскоязычного приложения не получится и всё равно придётся русскоязычные термины реверсить в английские, чтобы разобраться. А если переводить на TRL языки, то это вообще мрачный мрак. Пусть лучше на одном примитивном английском будет.
У них был и есть достаточно обособленный сайт https://jetbrains.ru/ — немного не того же стиля, чуть менее "продающий", не такой "няшный". Но. Но там есть информация о вакансиях, есть немножко статей на русском и ссылка на блог на хабре. Если честно, то даже не вполне понятно, а зачем тот основной сайт было переводить.
На мой взгляд Rust обладает очень неприятной для олимпиад строгостью и ограничениями. Для промышленного применения это прекрасно, но для рамок в 30-90 минут на задачу, которая пишется один раз и мозг не теряет контекст это может быть фатальным. Тут борроу-чекер и принуждение к иммутабельности может сыграть весьма злую шутку. Посмотрите на ставший уже классикой разбор реализации связанных списков, особенно на моменты в двунаправленном связанном списке (это в конце). Хотя я не исключаю, что написав хотя бы 20-50 KLOC олимпиадных задач это всё становится достаточно незначимым (но это 50-100 не самых мелких задач, то есть порядка года интенсивной работы с учётом загрузки в учёбе).
Купил книгу. Читаю — пока около 100 страниц, но впечатление уже сложилось.
Эх! Эту книгу бы мне 25 лет назад, я б за неё душу продал! Тогда, правда, С++ был… э… слегка другой, но это же мелочи :)
Что мне понравилось:
Акцент на типичных ошибках и пролётах в олимпиадах.
Акцент на типичных приёмах, экономящих силы и время на олимпиадах. Сюда же практичность приёмов: без размусоливаний всех возможностей того же vector на паре страниц всё, что про него надо знать в олимпиадных задачах.
Относительно доступное изложение. Ну то есть Дональда Кнута читать в разы сложнее.
Всё иллюстрируется кодом.
Что не понравилось:
Много неточных формулировок. Причём, судя по характеру неточностей — они таки пришли из оригинала. От изложения главы "3. Эффективность" и неаккуратного применения O-нотации в следующей главе меня вообще непрерывно бомбило. В той же главе ни слова про память, ни слова про системные вызовы (включая аллокацию/освобождение), а им там самое место.
В целом изложение доступно (я бы в старших классах осилил), но местами простую мысль закочерыжили в такие формулировки, что абзац надо по три раза перечитывать. Тут я не знаю, где источник кривизны — в оригинале или в переводе.
В этой книге органично бы смотрелось по 1-3 задачи в конце главы. А их нет.
Общее ощущение от книги, как от слайдов к крутому докладу. Ну то есть в ней процентов 10 от каждой темы. Классные 10% и самые важные, которые нужны в 80% случаев. Правда, как будто автор поставил следующий слайд и несколько минут рассказывал всё это, но ты, блин, видишь только слайд.
Итоговое впечатление очень положительное. Книга must have для тех, кто планирует выходить хотя бы на уровень областных школьных олимпиад, не говоря уже о глобальных контестах. Спасибо за книгу!
Про цены. Я не особо задумываясь купил книгу в "Лабиринте". Но там с моими большими скидками и с чёрнопятничной распродажей получилось около 1000 (а без них так вообще 1600+). А в самой книге написан адрес магазина издательства, где она по 800 рублей. Причём мне до их склада 10 минут пешком идти. Ну да ладно, не разорюсь, всё равно календарей с котом Саймона к новому году заказал :)
Да хотя бы тем, что феномены не объяснены. А значит, что из этой статьи человек не поймёт, как минимум разницу serializable/repeatable read. Это, кстати, весьма индикативный вопрос, например, часто кандидат на собеседовании говорит "я ваще крут в СУБД и уровни изоляции вдоль и поперёк", а на вопрос разницы serializable/repeatable read хотя и говорит "фантомы", но привести пример и объяснить что это за фантомы не может.
Ну и то, что уровни изоляции надо объяснять либо без СУБД вообще, либо с одной СУБД. Потому что реализации НАСТОЛЬКО разные, что потом у человека, которому объясняли, каша в голове.
ЗЫ: Это только моё мнение, на основании моего опыта объяснения уровней изоляций лет около 15.
Алгоритм примерно такой.
Сначала надо выбрать минимальный уровень изоляции, который гарантирует корректность поведения в данной транзакции (включая корректность данных с одной стороны и отсутствие взаимоблокировок с другой). Замечание про "в данной транзакции" весьма важное.
Обычно это решение достаточно легко следует из того, что вы делаете в транзакции.
Например:
Вывод списка в грид/на форму — обычно read committed, изредка read uncommitted (только в некоторых СУБД имеет смысл, в частности в старых версиях MS SQL, или если не используете RCSI)
Отчёты/формы, состоящие из одного запроса с соединениями/объединениями (join или union) — read committed
Отчёты/формы, состоящие из нескольких последовательных запросов или использующие временные таблицы — надо оценить, насколько тут нужен repeatable read (и действия должны быть в одной транзакции, иначе repeatable read не имеет смысла). Если не нужен, то read committed, если нужен, то repeatable read.
Пишущие транзакции (с проверкой условий/остатков, из нескольких запросов) — используйте по умолчанию не ниже repeatable read.
В MS SQL лучше (с точки зрения корректности данных и отсутствия взаимоблокировок) в пишущей транзакции для тех таблиц, которые меняются в данной транзакции использовать как можно раньше serializable. В других СУБД в зависимости от того, можете ли нарваться на фантомы.
Важно, что всегда сначала выбираем минимальный уровень, обеспечивающий корректную работу, и только потом смотрим, как это можно улучшить.
После того, как определились с базовым уровнем изоляции начинаем смотреть (правильность, производительность одного потока, производительность параллельных соединений с сервером, взаимоблокировки и блокировки/race condition горячих мест) и искать компромиссы. Тут уже парой абзацев не отделаться (статья превратится в книгу) — ситуаций и компромиссов даже в одной СУБД, даже типовых быстро становятся десятки. Цикл типичный: сбор информации, гипотеза, проверка, изменение, проверка применимости, внедрение и так по кругу.
Ни один из многочисленных элементов периодической таблицы не повлиял на ход истории так, как это сделал плутоний: Манхэттенский проект во время второй мировой, проект Тринити, Холодная война, катастрофа на Чернобыльской АЭС.
Интересно даже, как плутоний повлиял на урановый реактор? :) Тут уместнее вспомнить ПО "Маяк" в Челябинской области — там хотя бы производили плутоний и были инциденты в том числе с плутонием (но загрязнение на крупнейшей аварии всё равно было в основном по церию-144, цирконию-95 и стронцию-90).
Это, пожалуй, специфика теории чисел. В ней много задач, которые формулируются в терминах "нормального успевающего пятиклассника", но часто за этими простыми формулировками стоят не очень очевидные штуки.
В математике такой вопрос далеко не всегда правомерен. Многое из того, что делается в теории чисел, в алгебре, в матлогике не имеет "близкого" прикладного смысла и это нормально. В одних случаях решение может быть маленьким кирпичиком в общей картине — очередной частный случай, который помогает понять общее решение, в других — опережает прикладное применение на годы (а то и на века), в третьих — в процессе решения рождаются новые приёмы, техники и даже разделы математики (ну вот та же задача про расстановку ферзей — отличный полигон для SAT-решателей). В некоторых областях математики, правда, есть достаточно прямой "выхлоп", но он нередко базируется на фундаменте сотен и тысяч "ненужных" задач (как пример ЦПТ в теорвере или преобразование Фурье).
Это нормальное и естественное состояние фундаментальной науки. То, что прямого прикладного решения нет — не значит, что эти задачи не нужны. Иногда выстреливают и приводят к значительным открытиям именно такие задачи: вот для некоторых чисел решения не находятся и мы не понимаем почему. Если решение найдено при помощи перебора, то это тоже нормально — в современных задачах математики активно применяется вычислительная техника и помогает в переборе (а если перебор не сработал, там, где ожидалось, что сработает, то это отличный повод укопаться в задачу).
Это не плохо и не хорошо. Понятно, что решения задач, которые прямо сейчас применимы в других науках, в технике или в программировании, ценятся гораздо выше. Я имею в виду — ценятся впрямую в деньгах: гранты, ресурсы, престижность. Но к сожалению, мы не умеем достоверно предсказывать последствия фундаментальных исследований, поэтому важны и такие "непрактичные" задачи.
И все статистические оконные функции, и outer/cross apply, да даже банального exists нет (а в главе Using Subqueries to Solve Queries точно есть задачи, которые удобнее и понятнее решать exists). Не увидел union/except/intersect.
Есть запросы, где разный регистр ключевых слов ("Reporting Aggregated Data Using the Group Functions" — первая задача)
В некоторых запросах учит откровенно плохому (мне глаз резануло WHERE TO_CHAR (hire_date, 'YYYY') = '2008')
Дальше просто лень перечислять.
Занудство, конечно, но в этой фразе тоже есть неточность или неоднозначность трактовки многоточия. Обычно принято последнюю написанную цифру округлять с учетом последующей, а дальше идут ...5359879..., т.е. последнюю цифру точнее было бы написать, как "4". Но если многоточие трактовать именно как сокращение строки цифр, то всё нормально :)
Ничего интересного. Для жены писал программу, на которой она считала кандидатскую — в этой программе был расчёт достаточно хитрой разностной схемы с кучей переменных: диффуры в частных производных, а именно Навье-Стокс и проч. Так вот ошибки проявлялись либо на разных границах-переходах, либо начинали массово заражать модель NaNами, потому что x+NaN = NaN, а NaN чаще всего получается из +-Inf. Стоит отметить, что там бы я от такой ошибки огрёб именно полную сетку NaN.
Применительно к графике и физике игр — это будут примерно такие варианты:
Ничего заметного (потому что не успело накопиться)
Тупо вылет если ошибка повлияла на логику, а не вычисления.
Странные артефакты на граничных случаях
Блинки кадрами с мусором (если проблема только в расчёте изображения)
Вылет из-за арифметики, если пошло заражаться NaN или подобный эффект
Какой-то видимый, но не фатальный эффект в подобных расчётах возникает очень редко.
(PS: кандидатская была сделана честно, я только облегчал рутину вычислений и визуализаций)
Я не противник, а сторонник open source в целом и в системах, обеспечивающих безопасность в частности (и антифрод в том числе). И совсем не сторонник STO.
Но надо быть объективными: ломать чёрный ящик гораздо сложнее, чем белый при прочих равных. Почему же в криптографии по-другому? В криптографических системах а) если детали реализации не ясны, то непонятно, можно ли доверять системе, б) открытость систем позволяет привлечь к проверке на несколько порядков больше ресурсов, в) позволяет алгоритму/протоколу жить дольше конкретной реализации.
То есть польза для криптографии от открытости просто перевешивает пользу от закрытости. А для антифрода это утверждение лично мне неочевидно. И статья не убедила меня.
Ещё один момент, который нехило подкрепляет предыдущий, это ваша "идеальная система защиты от DDoS". Фишка в том, что описав эту систему вы её сразу разрушили:
По мне так, ваша антиDDoS система в том виде, как вы её описали — наивная утопия. Безусловно, если её сильно доработать, то она станет реализуемой, но от вашего примера там останется примерно ничего. Будет ли доработанная открытая антиDDoS лучше существующих решений? Не знаю, но выигрыша от открытости я пока точно не вижу.
Клингоны атакуют! :)
Тяжёлая судьба у вашего электрона, однако :)
Несмотря на мой опыт работы с 1С, я бы поспорил с необходимостью перевода IDE. Это же не только менюшки переводить, но и много всего "в кишках". Там слишком много всего разбросано, что переводить внешнего относительно IDE: плагины, внешние утилиты, логи. Боюсь, что там багов будет достаточно много, а реально целостного русскоязычного приложения не получится и всё равно придётся русскоязычные термины реверсить в английские, чтобы разобраться. А если переводить на TRL языки, то это вообще мрачный мрак. Пусть лучше на одном примитивном английском будет.
У них был и есть достаточно обособленный сайт https://jetbrains.ru/ — немного не того же стиля, чуть менее "продающий", не такой "няшный". Но. Но там есть информация о вакансиях, есть немножко статей на русском и ссылка на блог на хабре. Если честно, то даже не вполне понятно, а зачем тот основной сайт было переводить.
На мой взгляд Rust обладает очень неприятной для олимпиад строгостью и ограничениями. Для промышленного применения это прекрасно, но для рамок в 30-90 минут на задачу, которая пишется один раз и мозг не теряет контекст это может быть фатальным. Тут борроу-чекер и принуждение к иммутабельности может сыграть весьма злую шутку. Посмотрите на ставший уже классикой разбор реализации связанных списков, особенно на моменты в двунаправленном связанном списке (это в конце). Хотя я не исключаю, что написав хотя бы 20-50 KLOC олимпиадных задач это всё становится достаточно незначимым (но это 50-100 не самых мелких задач, то есть порядка года интенсивной работы с учётом загрузки в учёбе).
Купил книгу. Читаю — пока около 100 страниц, но впечатление уже сложилось.
Эх! Эту книгу бы мне 25 лет назад, я б за неё душу продал! Тогда, правда, С++ был… э… слегка другой, но это же мелочи :)
Что мне понравилось:
vectorна паре страниц всё, что про него надо знать в олимпиадных задачах.Что не понравилось:
Итоговое впечатление очень положительное. Книга must have для тех, кто планирует выходить хотя бы на уровень областных школьных олимпиад, не говоря уже о глобальных контестах. Спасибо за книгу!
Про цены. Я не особо задумываясь купил книгу в "Лабиринте". Но там с моими большими скидками и с чёрнопятничной распродажей получилось около 1000 (а без них так вообще 1600+). А в самой книге написан адрес магазина издательства, где она по 800 рублей. Причём мне до их склада 10 минут пешком идти. Ну да ладно, не разорюсь, всё равно календарей с котом Саймона к новому году заказал :)
Спасибо за наводку, заказал. Не так уж много книг хороших на эту тему.
Да хотя бы тем, что феномены не объяснены. А значит, что из этой статьи человек не поймёт, как минимум разницу serializable/repeatable read. Это, кстати, весьма индикативный вопрос, например, часто кандидат на собеседовании говорит "я ваще крут в СУБД и уровни изоляции вдоль и поперёк", а на вопрос разницы serializable/repeatable read хотя и говорит "фантомы", но привести пример и объяснить что это за фантомы не может.
Ну и то, что уровни изоляции надо объяснять либо без СУБД вообще, либо с одной СУБД. Потому что реализации НАСТОЛЬКО разные, что потом у человека, которому объясняли, каша в голове.
ЗЫ: Это только моё мнение, на основании моего опыта объяснения уровней изоляций лет около 15.
Алгоритм примерно такой.
Сначала надо выбрать минимальный уровень изоляции, который гарантирует корректность поведения в данной транзакции (включая корректность данных с одной стороны и отсутствие взаимоблокировок с другой). Замечание про "в данной транзакции" весьма важное.
Обычно это решение достаточно легко следует из того, что вы делаете в транзакции.
Например:
Важно, что всегда сначала выбираем минимальный уровень, обеспечивающий корректную работу, и только потом смотрим, как это можно улучшить.
После того, как определились с базовым уровнем изоляции начинаем смотреть (правильность, производительность одного потока, производительность параллельных соединений с сервером, взаимоблокировки и блокировки/race condition горячих мест) и искать компромиссы. Тут уже парой абзацев не отделаться (статья превратится в книгу) — ситуаций и компромиссов даже в одной СУБД, даже типовых быстро становятся десятки. Цикл типичный: сбор информации, гипотеза, проверка, изменение, проверка применимости, внедрение и так по кругу.
Интересно даже, как плутоний повлиял на урановый реактор? :) Тут уместнее вспомнить ПО "Маяк" в Челябинской области — там хотя бы производили плутоний и были инциденты в том числе с плутонием (но загрязнение на крупнейшей аварии всё равно было в основном по церию-144, цирконию-95 и стронцию-90).
Это, пожалуй, специфика теории чисел. В ней много задач, которые формулируются в терминах "нормального успевающего пятиклассника", но часто за этими простыми формулировками стоят не очень очевидные штуки.
В математике такой вопрос далеко не всегда правомерен. Многое из того, что делается в теории чисел, в алгебре, в матлогике не имеет "близкого" прикладного смысла и это нормально. В одних случаях решение может быть маленьким кирпичиком в общей картине — очередной частный случай, который помогает понять общее решение, в других — опережает прикладное применение на годы (а то и на века), в третьих — в процессе решения рождаются новые приёмы, техники и даже разделы математики (ну вот та же задача про расстановку ферзей — отличный полигон для SAT-решателей). В некоторых областях математики, правда, есть достаточно прямой "выхлоп", но он нередко базируется на фундаменте сотен и тысяч "ненужных" задач (как пример ЦПТ в теорвере или преобразование Фурье).
Это нормальное и естественное состояние фундаментальной науки. То, что прямого прикладного решения нет — не значит, что эти задачи не нужны. Иногда выстреливают и приводят к значительным открытиям именно такие задачи: вот для некоторых чисел решения не находятся и мы не понимаем почему. Если решение найдено при помощи перебора, то это тоже нормально — в современных задачах математики активно применяется вычислительная техника и помогает в переборе (а если перебор не сработал, там, где ожидалось, что сработает, то это отличный повод укопаться в задачу).
Это не плохо и не хорошо. Понятно, что решения задач, которые прямо сейчас применимы в других науках, в технике или в программировании, ценятся гораздо выше. Я имею в виду — ценятся впрямую в деньгах: гранты, ресурсы, престижность. Но к сожалению, мы не умеем достоверно предсказывать последствия фундаментальных исследований, поэтому важны и такие "непрактичные" задачи.
ELEVEN же!
Более того достаточно условия
first_name LIKE '____%'И все статистические оконные функции, и outer/cross apply, да даже банального exists нет (а в главе Using Subqueries to Solve Queries точно есть задачи, которые удобнее и понятнее решать exists). Не увидел union/except/intersect.
Есть запросы, где разный регистр ключевых слов ("Reporting Aggregated Data Using the Group Functions" — первая задача)
В некоторых запросах учит откровенно плохому (мне глаз резануло
WHERE TO_CHAR (hire_date, 'YYYY') = '2008')Дальше просто лень перечислять.
Итого — так себе списочек.
Посмотрите как на sql-ex.ru проверка делается (где-то там рассказывались детали).
Тоже неплохой набор задач
Занудство, конечно, но в этой фразе тоже есть неточность или неоднозначность трактовки многоточия. Обычно принято последнюю написанную цифру округлять с учетом последующей, а дальше идут ...5359879..., т.е. последнюю цифру точнее было бы написать, как "4". Но если многоточие трактовать именно как сокращение строки цифр, то всё нормально :)
Ничего интересного. Для жены писал программу, на которой она считала кандидатскую — в этой программе был расчёт достаточно хитрой разностной схемы с кучей переменных: диффуры в частных производных, а именно Навье-Стокс и проч. Так вот ошибки проявлялись либо на разных границах-переходах, либо начинали массово заражать модель NaNами, потому что
x+NaN = NaN, а NaN чаще всего получается из +-Inf. Стоит отметить, что там бы я от такой ошибки огрёб именно полную сетку NaN.Применительно к графике и физике игр — это будут примерно такие варианты:
Какой-то видимый, но не фатальный эффект в подобных расчётах возникает очень редко.
(PS: кандидатская была сделана честно, я только облегчал рутину вычислений и визуализаций)