1) Я бы задрал контраст в максимум. Это привело бы картинки к ч/б. А это ускорило бы обучение нейросети на порядки.
2) Использовал бы на картинках аугментацию поворотом и перспективой. Т.к. врятли вам в боевых условиях предоставят столь хорошо выровненные фотки.
3) Не уверен, что хорошо понимаю «метрическую сеть», но имхо
По выходу классифицирующей сети нельзя сказать, как сильно отличаются классы исходного алфавита, в то время как это хорошо видно по кластерам выходного пространства метрической сети.
Вроде на выходе классификатора имеем набор вероятностей, что объект относится к каждому классу. Если дельта между ними высокая => классы сильно отличаются. Дельта низкая => классы слабо отличаются. Не вижу особых различий с результатом-вектором из метрической сети.
4) Имхо, не имеет большого смысла оптимизировать нейросети для смартфонов. Т.к. чаще всего распознанные данные нужно куда-то после этого «загрузить», а значит все равно интернет доступен, а значит можно вынести распознавание на нормальное железо.
Бегло в код посмотрел, поэтому могу ошибаться:
1) Имхо, лучше бы использовать обертку над базой данных с функцией плейсхолдеров вместо конкатенации запроса с параметрами, т.к. обычно это прям напрашиваться на уязвимости. Чуть вы где-то забыли очистить переменную и можно легко стереть полбазы, вставив в параметры что-то вроде topic_id=7;delete from topics
2) Пароли в таблице users хранятся в md5 — это хорошо. Еще лучше добавить случайный salt — так вы получите разные хеши, если у 2х пользователей совпадают пароли.
3) executer.php->REPLY($args). Вы используете независимые запросы к базе: сначала для получения code, затем делаете инкремент, а затем пишете это в базу. Думаю, под нагрузкой получите баги в виде 2х смешавшихся потоков выполнения и там значение code буду задваиваться.
Я бы даже добавил, что в таких сферах, как банки, где собрана масса крайне важной личной информации (движения финансов) и способность распоряжаться деньгами клиентов — должен быть обязательный периодический независимый аудит безопасности с открытыми для всех результатами, чтобы клиенты понимали риск относительно своих денег и информации.
Вот и я присоединяюсь к вопросу. Если сотрудники могут перебрасывать деньги без уведомлений клиента и отражений в его истории операций — то в банковской сфере может творится что угодно. А «по умолчанию» ответственным за операции является таки клиент.
Так что, если это правда, то ситуация могла случиться плачевная: и деньги обналичены и клиент посажен за чужие действия.
Почти все эти пункты происходят из-за усиления конкуренции. То, что раньше работало в с подходом «тяп-ляп» и 5% эффективности (и давало достаточно преимуществ перед конкурентами) — теперь требует вдумчивого подхода.
Любовь к клиенту — не панацея, совсем. Вот пример из моей жизни: заказал в озоне 5 тарелок (последние. скидка, потому что «некомплект»). Вечером смотрю в ЛК: в заказе осталось 2 тарелки, 3 молча выкинули. Пишу в поддержку: «ребята, мне нужны либо 5, либо 0 (уберите их из заказа совсем)». Отвечают: хорошо-хорошо. И на следующий день привозят 2 тарелки…
Вот скажите, какая мне разница, как любят меня сотрудники поддержки, если они не могут договориться друг с другом?
Уверен, что процессы определяют качество и с каждым годом все больше. Нет процесса — все остальное бессмысленно: и любовь, и crm, и умение «продавать», и лидогенерация — они все упрутся в невозможность обработки заказа.
Направление интересное. Но, имхо, тут есть одна крайне сложная проблема: ваш метод базируется условно на «классификации». Нейросети вы при этом должны предоставить все варианты «правильного» трафика приложения (а неправильный, допустим, можно нагенерировать). Так вот сложность этой задачи схожа с методикой конечных автоматов — когда нужно описать все возможные ветвления программы. Боюсь, что в современном софте это крайне сложно. А без этого мы получаем, что чуть пользователь стал использовать ПО нестандартным способом — и технология пытается его отправить в категорию вредоносного и заблокировать.
А те методы, что вы в статье описываете — они не подходят чиновникам. Думаю, потому, что у них мера «выполненной работы» заключается в полностью заблокированном телеграме. А вы предлагаете скорее способы подгадить одной категории пользователей, другой — оно имеет место быть, но никак не приводит чиновника к «выполненной работе», т.е. вознаграждению.
В телеграме сделали настолько эффективную защиту, что заблокировать его нельзя!
Да нет, не сделали. Тут скорее проблема схожа с ПВО: когда поверхность самолета для радара маленькая — то он неотличим от птиц и перед вами выбор: либо сбивать всех птиц, либо пропустить самолет. С телегой, насколько я помню, адреса серверов доставляются push уведомлением и поэтому выбор прост: либо заблокировать вообще все push уведомления, что откатит отрасль мобильников лет этак на 10 назад, либо телеграм таки будет работать (то бишь менять адреса сервера и успешно доставлять их клиентам через push).
оОо. Т.е. простыми словами: они получили иск, потому что подсмотрели, как в стопочку детальки на складе сложить. Иногда коммерческая тайна/патентное право выдает невероятные результаты.
Да, своеобразно :) Чем-то напоминает подход ут10, только к справочнику иерархию добавили. Имхо, из описания пункта совсем неочевидно, что это за иерархия.
«Настройка уровней доступа к базе клиентов согласно иерархии подчиненности» — думаю, про этот пункт некорректно написано.
В ут10, например, этот уровень доступа задавался отдельным реквизитом (ГруппаДоступаКонтрагентов) и относительно варианта «по иерархии» позволяет даже больше вариаций покрыть. Например, частая проблема: есть клиенты только для отдела продаж, есть клиенты только для отдела закупок, а есть общие для них. В варианте иерархии придется разложить все по 3м группам и пользователю придется искать своего клиента в нескольких папках сразу.
Я бы даже сказал интереснее: завтра внедрят вредоносный JS код, затем его поймает какой-нибудь антивирус на компьютерах пользователей, передаст данные в облако, а затем выпишут блокировку агрегаторы антивирусов. И сайт станет почти недоступен для всех обычных пользователей. Без единого участия владельца сайта :)
Тестируемый код, хорошая архитектура и качественные логи — они всегда хороши. В любой ситуации.
Реальность же чаще такова, что есть код какого-то уровня легаси, часть из него вообще нельзя менять и где-то там произошел затык. И надо бы определить где и почему. И у меня стойкое ощущение, что с отладчиком это в разы быстрее, чем по логам. Просто потому, что (очень условно) отладчик позволяет «детализировать/обощать» информацию вплоть до функции. А с логами чаще всего в проектах лишь одна настройка уровня логов на весь проект. Бывает, что у каждого компонента своя настройка уровня логов, но я ни разу не видел возможностей задать для каждой функции свой уровень логов.
Из этой идеи мне не нравится:
1) Бизнес схемы. Сама механика использования бизнес схем — имхо, неудачная. Это выглядит красиво только на простых задачах, но превращается в ад, когда количество блоков в схеме приближается к 100, добавляются условные операторы, подобие циклов. Ни на один монитор это не влезает, поэтому начинают придумывать «группы блоков», которые можно свернуть/развернуть — но даже с ними быстро понять «код» — непросто. В классическом программировании уже давно этот вопрос решен: разделением на функции/классы ООП.
2) сама идея «программирования не-айтишниками». О нее уже многие набили шишки. Для не-айтишников приходится максимально упрощать апи, а для этого часто в жертву приходится принести производительность. Причем речь часто идет о потере производительности на порядки. А это быстро сводит на ноль идею масштабирования — ибо масштабированием мы пытаемся повысить производительность, а повышать ее перед этим убив в 10-100 раз — так себе идея.
3) отладка. В монолите мы ставим точку останова и смотрим, что передается. Легко по шагам проходим. Подобных инструментов для микросервисов пока не придумано. В микросервисах, я так понимаю, мы откатываемся назад в развитии средств отладки — по сути до «отладки принтом» — т.е. анализом километров избыточных логов, да еще и разбросанных по разным сервисам.
Сама теоретическая опасность есть. Хотя, мне кажется, курсы менее подвержены ей:
1) из-за готовой проблематики у студентов — больше расположенность учиться, а не фальсифицировать.
2) курсы довольно короткие и поэтому, если ими добрать ту же программу обучения, что в вузе — то курсов будет много. А значит и «проституток» придется искать много разных, что добавляет проблем. Сюда же отнесу, что курсы не страдают гигантоманией относительно традиционной системы обучения. Мега-экзамен = ЕГЭ, Мега-работа = диплом. Мега-учеба = 5 лет в вузе.
3) курсы часто бывают разных уровней и поэтому можно выбрать, какой конкретно нужен. В традиционной системе образования выбор часто отсутствует.
4) курсы, как правило, содержат более актуальные знания. В каких-то сферах знания устаревают медленно, а вот в ИТ крайне быстро и смысла в учебниках 30 летней давности мало. Это частично вытекает из простоты адаптации курсов, а она из п.3 и п.2., а частично из бюрократизированности плана обучения в традиционном образовании (и у меня еще чувство, что если разобрать этот ворох чиновников, то выяснится, что часть из них и не преподаватели, и опыта в этих областях не имели и вообще не понятно почему принимают решения).
Выигрывает не совсем исполнитель — а тот, у кого чужие деньги. Работает в обе стороны. Например, исполнитель с постоплатой также рискует сдать работу и не получить никаких денег.
Про перенос ответственности: в каких-то странах он есть в явном виде и есть судебная практика по таким делам — например, в США. Естественно, при этом государство не возвращает услугами, а лишь их стоимостное выражение. В каких-то странах (например, в нашей) юридически этого нет, но де факто вопрос остается все таким же: раз правительство может по своей воле разрушить бизнесы, то оно также должно и отвечать перед этими бизнесами (равно как и перед гражданами, которым бизнес отказал из-за форс мажора).
А я примерно понимаю, почему у нас в обществе невежественное отношение к эпидемии. Вот включает бабуля какой-нибудь офиц телеканал, а там — «да у нас всего пару умерших и 3 тыс заболевших. Это все заговор мериканцев, а уж мы то к нему 20 лет готовились и во всеоружии, враг не пройдет». Из этой информации следует почти нулевая опасность.
И примерно понимаю, почему столь негативное отношение к мерам карантина: вот эти пару официальных умерших ну совсем не сочетаются с массовыми мерами.
Я за то, чтобы наше государство определилось. Уж либо ситуация хорошая и тогда карантина не нужно, либо плохая и тогда он нужен. Но тогда и врать в СМИ не надо — чем информированнее граждане о реальной ситуации, тем лучше они без всяких адм мер будут противодействовать распространению вируса. А уж если нужны адм меры — то тогда и ответственность государства за весь ущерб.
2) Использовал бы на картинках аугментацию поворотом и перспективой. Т.к. врятли вам в боевых условиях предоставят столь хорошо выровненные фотки.
3) Не уверен, что хорошо понимаю «метрическую сеть», но имхо
Вроде на выходе классификатора имеем набор вероятностей, что объект относится к каждому классу. Если дельта между ними высокая => классы сильно отличаются. Дельта низкая => классы слабо отличаются. Не вижу особых различий с результатом-вектором из метрической сети.
4) Имхо, не имеет большого смысла оптимизировать нейросети для смартфонов. Т.к. чаще всего распознанные данные нужно куда-то после этого «загрузить», а значит все равно интернет доступен, а значит можно вынести распознавание на нормальное железо.
1) Имхо, лучше бы использовать обертку над базой данных с функцией плейсхолдеров вместо конкатенации запроса с параметрами, т.к. обычно это прям напрашиваться на уязвимости. Чуть вы где-то забыли очистить переменную и можно легко стереть полбазы, вставив в параметры что-то вроде topic_id=7;delete from topics
2) Пароли в таблице users хранятся в md5 — это хорошо. Еще лучше добавить случайный salt — так вы получите разные хеши, если у 2х пользователей совпадают пароли.
3) executer.php->REPLY($args). Вы используете независимые запросы к базе: сначала для получения code, затем делаете инкремент, а затем пишете это в базу. Думаю, под нагрузкой получите баги в виде 2х смешавшихся потоков выполнения и там значение code буду задваиваться.
Странно, вот даже обзоры библиотек по генетическим алгоритмам есть:
www.kaggle.com/getting-started/112297
Хороший подход. Схожий применяется в оптимизации градиентным спуском в нейросетях. Там «параметр» называется learning_rate.
Пример: www.pyimagesearch.com/2019/07/22/keras-learning-rate-schedules-and-decay (можно особо не вчитываться — на первом же графике понятен результат).
Так что, если это правда, то ситуация могла случиться плачевная: и деньги обналичены и клиент посажен за чужие действия.
Любовь к клиенту — не панацея, совсем. Вот пример из моей жизни: заказал в озоне 5 тарелок (последние. скидка, потому что «некомплект»). Вечером смотрю в ЛК: в заказе осталось 2 тарелки, 3 молча выкинули. Пишу в поддержку: «ребята, мне нужны либо 5, либо 0 (уберите их из заказа совсем)». Отвечают: хорошо-хорошо. И на следующий день привозят 2 тарелки…
Вот скажите, какая мне разница, как любят меня сотрудники поддержки, если они не могут договориться друг с другом?
Уверен, что процессы определяют качество и с каждым годом все больше. Нет процесса — все остальное бессмысленно: и любовь, и crm, и умение «продавать», и лидогенерация — они все упрутся в невозможность обработки заказа.
Поправьте, если я не прав.
Да нет, не сделали. Тут скорее проблема схожа с ПВО: когда поверхность самолета для радара маленькая — то он неотличим от птиц и перед вами выбор: либо сбивать всех птиц, либо пропустить самолет. С телегой, насколько я помню, адреса серверов доставляются push уведомлением и поэтому выбор прост: либо заблокировать вообще все push уведомления, что откатит отрасль мобильников лет этак на 10 назад, либо телеграм таки будет работать (то бишь менять адреса сервера и успешно доставлять их клиентам через push).
В ут10, например, этот уровень доступа задавался отдельным реквизитом (ГруппаДоступаКонтрагентов) и относительно варианта «по иерархии» позволяет даже больше вариаций покрыть. Например, частая проблема: есть клиенты только для отдела продаж, есть клиенты только для отдела закупок, а есть общие для них. В варианте иерархии придется разложить все по 3м группам и пользователю придется искать своего клиента в нескольких папках сразу.
В ут 11 — как раз по иерархии
#ДляОбъекта("")
#Иначе
#ПоЗначениямРасширенный( «Справочник.Контрагенты»,«Чтение»,"",
«ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ИерархияПартнеров КАК Т2
ПО Т2.Родитель = Т.Партнер»,
"",
«ГруппыПартнеров»,«Т2.Партнер»,"", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","" )
#КонецЕсли
Кодовая база ут11 и erp схожа. Так что, думаю, в erp это есть.
Реальность же чаще такова, что есть код какого-то уровня легаси, часть из него вообще нельзя менять и где-то там произошел затык. И надо бы определить где и почему. И у меня стойкое ощущение, что с отладчиком это в разы быстрее, чем по логам. Просто потому, что (очень условно) отладчик позволяет «детализировать/обощать» информацию вплоть до функции. А с логами чаще всего в проектах лишь одна настройка уровня логов на весь проект. Бывает, что у каждого компонента своя настройка уровня логов, но я ни разу не видел возможностей задать для каждой функции свой уровень логов.
1) Бизнес схемы. Сама механика использования бизнес схем — имхо, неудачная. Это выглядит красиво только на простых задачах, но превращается в ад, когда количество блоков в схеме приближается к 100, добавляются условные операторы, подобие циклов. Ни на один монитор это не влезает, поэтому начинают придумывать «группы блоков», которые можно свернуть/развернуть — но даже с ними быстро понять «код» — непросто. В классическом программировании уже давно этот вопрос решен: разделением на функции/классы ООП.
2) сама идея «программирования не-айтишниками». О нее уже многие набили шишки. Для не-айтишников приходится максимально упрощать апи, а для этого часто в жертву приходится принести производительность. Причем речь часто идет о потере производительности на порядки. А это быстро сводит на ноль идею масштабирования — ибо масштабированием мы пытаемся повысить производительность, а повышать ее перед этим убив в 10-100 раз — так себе идея.
3) отладка. В монолите мы ставим точку останова и смотрим, что передается. Легко по шагам проходим. Подобных инструментов для микросервисов пока не придумано. В микросервисах, я так понимаю, мы откатываемся назад в развитии средств отладки — по сути до «отладки принтом» — т.е. анализом километров избыточных логов, да еще и разбросанных по разным сервисам.
1) из-за готовой проблематики у студентов — больше расположенность учиться, а не фальсифицировать.
2) курсы довольно короткие и поэтому, если ими добрать ту же программу обучения, что в вузе — то курсов будет много. А значит и «проституток» придется искать много разных, что добавляет проблем. Сюда же отнесу, что курсы не страдают гигантоманией относительно традиционной системы обучения. Мега-экзамен = ЕГЭ, Мега-работа = диплом. Мега-учеба = 5 лет в вузе.
3) курсы часто бывают разных уровней и поэтому можно выбрать, какой конкретно нужен. В традиционной системе образования выбор часто отсутствует.
4) курсы, как правило, содержат более актуальные знания. В каких-то сферах знания устаревают медленно, а вот в ИТ крайне быстро и смысла в учебниках 30 летней давности мало. Это частично вытекает из простоты адаптации курсов, а она из п.3 и п.2., а частично из бюрократизированности плана обучения в традиционном образовании (и у меня еще чувство, что если разобрать этот ворох чиновников, то выяснится, что часть из них и не преподаватели, и опыта в этих областях не имели и вообще не понятно почему принимают решения).
Про перенос ответственности: в каких-то странах он есть в явном виде и есть судебная практика по таким делам — например, в США. Естественно, при этом государство не возвращает услугами, а лишь их стоимостное выражение. В каких-то странах (например, в нашей) юридически этого нет, но де факто вопрос остается все таким же: раз правительство может по своей воле разрушить бизнесы, то оно также должно и отвечать перед этими бизнесами (равно как и перед гражданами, которым бизнес отказал из-за форс мажора).
И примерно понимаю, почему столь негативное отношение к мерам карантина: вот эти пару официальных умерших ну совсем не сочетаются с массовыми мерами.
Я за то, чтобы наше государство определилось. Уж либо ситуация хорошая и тогда карантина не нужно, либо плохая и тогда он нужен. Но тогда и врать в СМИ не надо — чем информированнее граждане о реальной ситуации, тем лучше они без всяких адм мер будут противодействовать распространению вируса. А уж если нужны адм меры — то тогда и ответственность государства за весь ущерб.