Ох уж этот юниксвэй. Половина конфигурации лежит в json, половина в crontab.
Во-первых, неудобно, что сразу в одном месте все не видно. А неудобно => дорого поддерживать, т.к. любой новый сотрудник будет дольше с этим разбираться.
Во-вторых, не очень понятны преимущества выноса удаления старых бекапов в crontab. Более логичной выглядит идея удалять и проверять их тогда, когда создается новый файл. (т.к. чаще всего именно в этот момент старый бекап становится не нужен. а сама операция удаления дешевая по io ресурсам и нет смысла ее откладывать на малозагруженное время сервера).
В-третьих, ну почему же не сделали параметр у wal-g delete, чтобы просто указать «3 дня назад от текущей даты»? Очевидно, что это частоиспользуемый параметр (как и удаление по количеству бекапов). Вот зачем каждого админа заставляют писать эту математику с датой и ее форматированием?
Да даже проще. Типовой вариант с силовиками (правда, это не про серверную площадку, а про офисы): приходим, под любым предлогом забираем компьютеры, а потом ждем взятку за возврат компьютеров. Ведь без этого фирма не может работать. По закону, кажется, 6 месяцев могут компы не отдавать. Но чаще фирмы побаиваются требовать компы через суды и, получается, силовики получают в дар парк компьютеров.
Причем предлоги могут быть ну никак логически не связаны с изъятием компьютеров.
Мне кажется, первое и самое простое правило: не использовать провайдера с российской юрисдикцией. Решает сразу массу угроз. А потом уже переходить к техническим методам защиты.
Мы хотим получить максимальную прибыль, а значит можно «подогнать» ну или подобрать значение коэффициентов стратегии которое на выходе даст максимально ожидаемый результат.
Тогда еще не забывать о разделение выборки на обучающую и контрольную. Иначе получится робот, идеально торгующий на том промежутке, но абсолютно бесполезный в реальной ситуации.
1) не видно число сделок покупки и продажи. А без этого, возможно, стратегия только в одном направлении умеет работать.
2) Не видно исходных графиков цены, поэтому не очень понятно, где там тренды, в какую сторону и т.д.
3) Надо проверять на особенности эмуляции движения цены в тестере. (Например, некоторые тестеры внутри минутного графика эмулируют движение цены по 4 точкам: открытие-максимальная-минимальная-закрытие. И поэтому очень легко сделать грааль, ловящий это движение. Но в реальном рынке его нет).
4) Спреды, проскальзывания и комиссии надо считать всегда. Вручную задавая эти параметры в тестере. Т.к. они могут убить и всю прибыль.
5) Низкое число проигрышных сделок в данной стратегии является не совсем честным показателем, т.к. используется усреднение позиции (ака мартингейл). Оно с одной стороны переводит массу проигрышных сделок в выигрышные, а с другой очень быстро увеличивает просадку при движении рынка против вашей позиции.
6) Не вижу вообще управления рисками и хоть какого-то ограничения лота сделки в макс сторону. А без этого рискуем всем капиталом на счете.
Я так понимаю, идентификация по радужной оболочке легко ломается при использовании цветных линз. Предположу, что и обычные прозрачные линзы могут от своего положения создавать искажения.
А линзы очень распространены. И вытаскивать линзы перед каждой авторизацией — нерабочее решение.
Кроме всего прочего, это дорого. А ведь этими сканерами нужно оснастить каждого — т.е. условно у каждого как «зарядка к телефону» должен лежать еще и сканер оболочки.
Меня напрягает другая проблема: то, что источником соединения является браузер. А значит это соединение по loopback, подсети которого считаются доверенными и чаще всего незакрытыми фаерволом. Говоря проще, получается Firewall piercing.
И весь мир пока к этому не готов, имхо.
Я думаю, не все равноценно.
«Задача ждет» не отражает причины/источника ожидания. А, я так понимаю, таск на холде — это откладывание задачи по инициативе исполнителя (в гибких методологиях такое возможно). Т.е. тут потеря части смысла происходит.
Асайнь — из моего опыта это назначение задачи ответственному. Не встречал это в контексте создания задачи.
Отстрелить себе руку можно много чем и уж точно любой безопасностью.
Проблема на самом деле редкая — я для себя использую 20 неудачных попыток в день. Этого более чем достаточно, чтобы отделить нормального пользователя от атакующего. За 4 мес было 1 ложное срабатывание: когда в офисе массово начали пароли менять (а весь офис за 1 ип конечно же).
Но все довольно легко решается белыми списками. На ип адрес админа, на ип адрес офиса и т.д.
Если у ИТ аудитории, то копипаст. Но это скорее про «сокращение» — когда англ вариант значительно короче.
Я же писал про примерно одинаковые по длине.
Пример:
CD-ROM и КД-ПЗУ — оба термина имели право на жизнь, но англ использовался значительно чаще и поэтому второй умер.
Я бы добавил еще одну причину в ИТ: когда одновременно приходится читать или общаться на двух языках, то проще запомнить англ термин как использующийся чаще.
Мне постоянно кажется, что действия чиновников были бы хоть как-то адекватными для 2000х годов. Тогда каждый сайт заключал партнерские соглашения с рекламодателями, контролировал рекламу и мог расторгнуть. Но весь мир то живет в 2020м! А головы чиновников походу остались в 2000х.
Только мне кажется странной идея взять довольно низкопроизводительный процессор Эльбрус, да еще и посадить за него 6 пользователей?
Какие то уж очень «тонкие» клиенты получатся.
И стоимость пока что ужас-ужас. Взяв даже их планируемое снижение до 220к за 6 мест = это 35к на рабочее место. Пока что гораздо выгоднее собрать 6 отдельных рабочих станций.
Они будут независимы — например, при сгорании БП только один пользователь будет простаивать. Они будут производительнее. Их можно располагать сколь угодно далеко друг от друга. И даже возможно тысяч на 5 дешевле.
Идея с привязкой видео-фрагментов к документам продажи хорошая. Это как-то снижает трудоемкость, но все равно она остается на высоком уровне.
Сама проблема проистекает из наличия кассира — человека, через которого проходят и деньги, и товар. К сожалению, если кассиру допустимы любые манипуляции с этими двумя потоками — простых решений не существует.
В некоторых ситуациях привязка видео к продажам не поможет — например, если кассир выдал товар и получил наличку без оформления продажи — чтобы это найти все равно придется отсмотреть все видео за смену (если известна смена! а если не известна — то это легко может быть и за месяц и за два — до предыдущей инвентаризации).
Думаю, качественно эту проблему можно будет решить, только отделив поток товара от потока денег.
У меня, как у айтишника, другой вопрос — почему никто не занимается «принимающими» такие меры? Это ведь убьет источник проблемы => не нужно будет ни лиги, ни полиции этим заниматься.
Вполне логично, что если правительство принимает склонные к коррупции механизмы (пропуска, дефицитные товары, да и вообще сломавшееся правовое поле в РФ) — ими будут пользоваться мошенники.
Также вполне логично, что число мошенников вырастет при отсутствии нормальной работы.
Несомненно. Я и не говорил, что подходит везде и всегда. Но само применение очень удобно, когда надо найти «что изменилось» между старой и новой копией списка.
Во других языках мне приходилось перебирать элементы для этого.
К спискам я бы еще добавил крутые возможности по преобразованию их в множество (set). Т.к. после этого можно находить разность (пересечение) и сумму (объединение) множеств:
list( set(listA) — set(ListB) ) — выдай элемента списка А, отсутствующие в списке Б.
Во-первых, неудобно, что сразу в одном месте все не видно. А неудобно => дорого поддерживать, т.к. любой новый сотрудник будет дольше с этим разбираться.
Во-вторых, не очень понятны преимущества выноса удаления старых бекапов в crontab. Более логичной выглядит идея удалять и проверять их тогда, когда создается новый файл. (т.к. чаще всего именно в этот момент старый бекап становится не нужен. а сама операция удаления дешевая по io ресурсам и нет смысла ее откладывать на малозагруженное время сервера).
В-третьих, ну почему же не сделали параметр у wal-g delete, чтобы просто указать «3 дня назад от текущей даты»? Очевидно, что это частоиспользуемый параметр (как и удаление по количеству бекапов). Вот зачем каждого админа заставляют писать эту математику с датой и ее форматированием?
Причем предлоги могут быть ну никак логически не связаны с изъятием компьютеров.
Тогда еще не забывать о разделение выборки на обучающую и контрольную. Иначе получится робот, идеально торгующий на том промежутке, но абсолютно бесполезный в реальной ситуации.
2) Не видно исходных графиков цены, поэтому не очень понятно, где там тренды, в какую сторону и т.д.
3) Надо проверять на особенности эмуляции движения цены в тестере. (Например, некоторые тестеры внутри минутного графика эмулируют движение цены по 4 точкам: открытие-максимальная-минимальная-закрытие. И поэтому очень легко сделать грааль, ловящий это движение. Но в реальном рынке его нет).
4) Спреды, проскальзывания и комиссии надо считать всегда. Вручную задавая эти параметры в тестере. Т.к. они могут убить и всю прибыль.
5) Низкое число проигрышных сделок в данной стратегии является не совсем честным показателем, т.к. используется усреднение позиции (ака мартингейл). Оно с одной стороны переводит массу проигрышных сделок в выигрышные, а с другой очень быстро увеличивает просадку при движении рынка против вашей позиции.
6) Не вижу вообще управления рисками и хоть какого-то ограничения лота сделки в макс сторону. А без этого рискуем всем капиталом на счете.
А линзы очень распространены. И вытаскивать линзы перед каждой авторизацией — нерабочее решение.
Кроме всего прочего, это дорого. А ведь этими сканерами нужно оснастить каждого — т.е. условно у каждого как «зарядка к телефону» должен лежать еще и сканер оболочки.
И весь мир пока к этому не готов, имхо.
«Задача ждет» не отражает причины/источника ожидания. А, я так понимаю, таск на холде — это откладывание задачи по инициативе исполнителя (в гибких методологиях такое возможно). Т.е. тут потеря части смысла происходит.
Асайнь — из моего опыта это назначение задачи ответственному. Не встречал это в контексте создания задачи.
Проблема на самом деле редкая — я для себя использую 20 неудачных попыток в день. Этого более чем достаточно, чтобы отделить нормального пользователя от атакующего. За 4 мес было 1 ложное срабатывание: когда в офисе массово начали пароли менять (а весь офис за 1 ип конечно же).
Но все довольно легко решается белыми списками. На ип адрес админа, на ип адрес офиса и т.д.
Они эквиваленты в данном случае: дэйоф и отгул.
Я же писал про примерно одинаковые по длине.
Пример:
CD-ROM и КД-ПЗУ — оба термина имели право на жизнь, но англ использовался значительно чаще и поэтому второй умер.
Какие то уж очень «тонкие» клиенты получатся.
И стоимость пока что ужас-ужас. Взяв даже их планируемое снижение до 220к за 6 мест = это 35к на рабочее место. Пока что гораздо выгоднее собрать 6 отдельных рабочих станций.
Они будут независимы — например, при сгорании БП только один пользователь будет простаивать. Они будут производительнее. Их можно располагать сколь угодно далеко друг от друга. И даже возможно тысяч на 5 дешевле.
Сама проблема проистекает из наличия кассира — человека, через которого проходят и деньги, и товар. К сожалению, если кассиру допустимы любые манипуляции с этими двумя потоками — простых решений не существует.
В некоторых ситуациях привязка видео к продажам не поможет — например, если кассир выдал товар и получил наличку без оформления продажи — чтобы это найти все равно придется отсмотреть все видео за смену (если известна смена! а если не известна — то это легко может быть и за месяц и за два — до предыдущей инвентаризации).
Думаю, качественно эту проблему можно будет решить, только отделив поток товара от потока денег.
Также вполне логично, что число мошенников вырастет при отсутствии нормальной работы.
Во других языках мне приходилось перебирать элементы для этого.
list( set(listA) — set(ListB) ) — выдай элемента списка А, отсутствующие в списке Б.