Взяли процесс организации труда и неумело его вкорячили. Резонно огребли проблем и сложностей. Начали проблемы решать по очереди и по одной. На выходе получили процесс-химеру, который не должен существовать.
Как участники процесса преобразования - не заметили, что родили монстра.
Да, жадные алгоритмы приводят к такому. "жадные" в данном случае могут иметь десяток трактовок но это уже не специально.
Мне рассказывали как выглядел отдел девушек-"божьих одуванчиков" в Яндексе, занимающихся классификацией NSFW картинок и поисковых запросов для детской фильтрации.
Я лично наблюдал примерно такую же картину в виде милейших созданий, которые извиняющимся тоном говорили: "у нас нету в лаборатории молотков... вот, разводной ключик, мы им мышек подготавливаем" (ключ весом килограмма в 2 весь бурый от запекшейся крови -- они реально мышек к исследованиям после экспериметов им "подготавливают")...
У автора статьи здесь явно бомбит и очень сильно, да. Формат изложения мыслей не из лучших, да. Однако же вы при этом не услышали главной мысли статьи -- согласно внешнего осмотра, имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монстру. И этого даже и не заметили.
Нужен полноценный рефакторинг, а не поза "у меня всё работает"
Таки я скажу что автоматизация видеонаблюдения должна включать в себя автоматизацию поиска аномалий. Человек не может эффективно пялиться в экран часами -- 99% времени интересное будет пропущено. Так что поиск аномалий -- первичен. Подсветк внезапного движения по необычным углам и/или по нестандартному марштуру даст больше.
Это шифр подстановки, в котором каждому символу на входе соответствует один символ на выходе.
Реализован в форме шифра цезаря (сдвига) с перемешиванием алфавита.
Строка представляет собой случайную перестановку алфавита, "-22" это ключ цезаря (берём -22ю букву из алфавита).
Декодинг через поиск символа в строке неэффективен (O(N^2)*), для десятка строк может и пофиг, для сотен уже может быть заметно -- почему и предлагаю классическое решение здесь через конвертацию его в прямую таблицу подстановки -- декодинг в таком случае линеен к числу символов.
* да-да, я знаю что "квадрат" тут некорректно, так как subst фиксированная и мы можем представить его как просто очень дорогую константу, но уж больно легко думать в категориях "на каждый символ строки мы должны пробежаться по всей другой строке" и плевать что это разные строки -- чаще всего вторая строка сильно больше первой так что оно даже хуже квадрата по факту
def decode(s: str) ->str:
subst = "Q&'()*+,a./FPvq5KMhSr:;<=>?@UIT-HGylCY3DL4We0kmit8Ep9X[\\]^z`BOAgj2xf1bVnZdcoRwJ7Nsu_6Q"
r = ''
for c in s:
if c >= '%' and c <= 'z':
r += subst[ord(c)-ord('%')]
else:
r += c
return r
print(decode('5WquWMKf.LMM'))
print(decode('CP9STl-UP19poPvv'))
Такая интерпретация декодирования не обрабатывает случай, когда исходный символ не найден в строке подстановки
Вообще это шифр подстановки обычный и исходя из "5WquWMKf.LMM" символ, не входящий в таблицу перекодировки, просто копируется как есть.
def decode(s: str) -> str:
subst = 'zcgXlSWkj314CwaYLvyh0U_odZH8OReKiNIr-JM2G7QAxpnmEVbqP5TuB9Ds6fFt%'
r = ''
for c in s:
p = subst.find(c)
if (p>=0):
r += subst[(p - 22) & 0x3F]
else:
r += c
return r
print(decode('5WquWMKf.LMM'))
print(decode('CP9STl-UP19poPvv'))
Даже если расстояние до начала цикла взаимопростое с длиной цикла?
Кстати, оптимизация "заец проверяет пересечение когда бежит" ломает гарантию встречи вначале
А где, кстати, доказательство что движение из точки встречи приведёт именно к началу цикла? Самое важное в посте отсутствует :)
Но при этом возможна лишняя бегодня кролика по циклу, к которому ползёт черепаха
Никты
Stadia была реально хорошей технологически. Прошёл кп2к77 на ней через браузер, и работало отлично на 1440p и 60фпс
Взяли процесс организации труда и неумело его вкорячили. Резонно огребли проблем и сложностей. Начали проблемы решать по очереди и по одной. На выходе получили процесс-химеру, который не должен существовать.
Как участники процесса преобразования - не заметили, что родили монстра.
Да, жадные алгоритмы приводят к такому. "жадные" в данном случае могут иметь десяток трактовок но это уже не специально.
В смысле, неочевидно?
Не пора ли тогда переименоваться в DmitrySpb73 ?
p.s.: поздравляю с "hitting the consistency goal" :)
Зависит от кучи переменных в имеющихся требованиях.
Например, может быть решено через:
Код в ORM слое
Можно повесить Server-side сниффер или прокси
Если не срочно -- то от Diff между бакапами до фонового сканнера
Ну и никто не мешает просто всегда в транзакции делать все вещи вручную. Иногда это еще и лучшее решение...
Мне рассказывали как выглядел отдел девушек-"божьих одуванчиков" в Яндексе, занимающихся классификацией NSFW картинок и поисковых запросов для детской фильтрации.
Я лично наблюдал примерно такую же картину в виде милейших созданий, которые извиняющимся тоном говорили: "у нас нету в лаборатории молотков... вот, разводной ключик, мы им мышек подготавливаем" (ключ весом килограмма в 2 весь бурый от запекшейся крови -- они реально мышек к исследованиям после экспериметов им "подготавливают")...
Короче, не надо встречать по профессии :)
Отдельный cuddle-ing room на выходе из meeting dungeon?... Звучит разумно, добровольно, главное чтоб SFW.
У автора статьи здесь явно бомбит и очень сильно, да. Формат изложения мыслей не из лучших, да. Однако же вы при этом не услышали главной мысли статьи -- согласно внешнего осмотра, имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монстру. И этого даже и не заметили.
Нужен полноценный рефакторинг, а не поза "у меня всё работает"
Предлагаете добавить в процессы стоп-слово?
это называется "ватерфейл"
:)
Таки я скажу что автоматизация видеонаблюдения должна включать в себя автоматизацию поиска аномалий. Человек не может эффективно пялиться в экран часами -- 99% времени интересное будет пропущено. Так что поиск аномалий -- первичен. Подсветк внезапного движения по необычным углам и/или по нестандартному марштуру даст больше.
Это шифр подстановки, в котором каждому символу на входе соответствует один символ на выходе.
Реализован в форме шифра цезаря (сдвига) с перемешиванием алфавита.
Строка представляет собой случайную перестановку алфавита, "-22" это ключ цезаря (берём -22ю букву из алфавита).
Декодинг через поиск символа в строке неэффективен (O(N^2)*), для десятка строк может и пофиг, для сотен уже может быть заметно -- почему и предлагаю классическое решение здесь через конвертацию его в прямую таблицу подстановки -- декодинг в таком случае линеен к числу символов.
* да-да, я знаю что "квадрат" тут некорректно, так как subst фиксированная и мы можем представить его как просто очень дорогую константу, но уж больно легко думать в категориях "на каждый символ строки мы должны пробежаться по всей другой строке" и плевать что это разные строки -- чаще всего вторая строка сильно больше первой так что оно даже хуже квадрата по факту
Можно еще развернуть таблицу:
Вообще это шифр подстановки обычный и исходя из "5WquWMKf.LMM" символ, не входящий в таблицу перекодировки, просто копируется как есть.