4) И все же, я думаю, что лучше в облако. Просто из соображений управления бизнесом. Смотрите, вы на оптимизацию сети потратили немало человекочасов, причем в статье явно описан «удачный вариант», а за кадром, наверное, было еще штук 5 неудачных гипотез, на них тоже ресурсы потрачены — вот это все надо записать в циферку затрат (и она выйдет немаленькая). Как результат вы получили конкурентное преимущество — работа в оффлайне.
Покрытие и качество интернет увеличиваются с каждым годом — тут и моб сети улучшаются, и wimax покрытия встречаются, и спутники как магистральный провайдер дают возможность провести инет туда, где раньше и не думали. Рост этого рынка будет каждый год снижать пользу от «работы в оффлайне» и, думаю, по истечению следующей пятилетки сведет пользу к нулю.
Вы приводите пример — и в нем уже в конце процесса покупка билета — т.е. действие уже в онлайне. Поэтому польза от «работы в оффлайне» уже снижается до вопроса стабильности канала. Передачу данных на нестабильном канале тоже можно программно улучшить (убрать принцип «канал кратковременно упал => вся работа потерялась») — эта задача уже довольно хорошо изучена и не представляет большой сложности (говоря проще, не требует проверки гипотез — сразу можно написать рабочий вариант). Что еще снизит пользу от «работы в оффлайне».
От облака есть еще дополнительные преимущества: возможность сбора больших данных. А значит вы сможете улучшить свой алгоритм методом композиции нейросетей — т.е. выбрать те примеры, где ваша нейросеть справилась неудачно и построить еще одну, которая дораспознает эти ошибки. Из оффлайна делать это невозможно, из полу-оффлайна делать это сложнее.
А я думаю, что рынок 3D печати некоторым образом угрожает автопрому в части запчастей. Т.к. весь автопром сейчас перешел на модульную замену: когда меняется весь блок, а не только вышедшая из строя деталь. При этом стоимость блока может на порядки превышать стоимость сломанной детали. А еще (это чисто мое мнение) используется идея контролируемого устаревания деталей, когда они сознательно делаются со сроком службы 5 лет. А тут выходят на свет 3d принтеры с их возможностью создать любую пластиковую деталь. 3D печать дороже заводского изготовления детали (той же горячей формовки), но существенно дешевле замены модуля целиком. Поэтому массовое распространение чертежей и 3D принтеров может существенно сократить отрасль запчастей от производителя.
1с крайне сложно будет на этих рынках.
1) Основное преимущество 1с: это поддержка вечно меняющегося регламентированного учета в РФ. Оно сходит на ноль в других странах, т.к. в них нет столько изменений в регл учете. И тогда 1с придется конкурировать даже с чем-нибудь древним, 20 лет назад написанным. Проще говоря: конкуренция выйдет на порядки больше (даже не в разы).
2) В некоторых странах у малого бизнеса допускается вообще отсутствие регл учета. И поэтому 1с тут сможет конкурировать только в сфере управленческого учета, а значит придется конкурировать и с CRM.
3) У 1с тяжеловато с разделением продуктов по сложности. Больше 1с делит их по отраслям. А вот так, чтобы у «Управление торговлей» появилось 3 компоновки по функционалу/сложности/стоимости — такого нет. И механизмов скрытия от пользователя (функциональные опции) недостаточно, т.к. сложность всей конфигурации остается на высоком уровне (а значит теряет в производительности и выше стоимость доработки).
4) Зато у конкурентов много не-технических преимуществ: например, у них есть уже доля рынка и репутация. У некоторых (SAP) репутация такая, что внедрившие ее компании автоматически повышают свою капитализацию.
5) Про SAP отдельный разговор. У них с 1с концептуально противоположный подход к автоматизации.
Подход SAP: процессы должны быть такими, учет всегда таким. Перестраивайте фирму под них. Зато любой может посмотреть «отчет по продажам» и однообразно увидеть состояние фирмы.
Подход 1с: вот вам конструктор, там заложены пара базовых принципов, а дальше меняйте как хотите. Процессы и учет меняют под фирму. Поэтому тот же «отчет по продажам» может как угодно различаться и показывать разное в зависимости от фирмы и ее желаний.
Отсюда внедрение SAP повышает капитализацию (т.к. в фирму внедрили пусть не идеально работающие, но работающие процессы), а внедрение 1с никак не влияет на капитализацию (т.к. процессы могли остаться на любом пещерном уровне).
Не думаю. Обычно узкое место либо в пуле соединений (старт платформы внутри апача довольно затратный), либо в БД. Парсинг json проявится только на больших пакетах данных, а в приведенном примере, думаю, запросы по HTTP были штук на 5 полей.
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 код, затем его поймает какой-нибудь антивирус на компьютерах пользователей, передаст данные в облако, а затем выпишут блокировку агрегаторы антивирусов. И сайт станет почти недоступен для всех обычных пользователей. Без единого участия владельца сайта :)
Тестируемый код, хорошая архитектура и качественные логи — они всегда хороши. В любой ситуации.
Реальность же чаще такова, что есть код какого-то уровня легаси, часть из него вообще нельзя менять и где-то там произошел затык. И надо бы определить где и почему. И у меня стойкое ощущение, что с отладчиком это в разы быстрее, чем по логам. Просто потому, что (очень условно) отладчик позволяет «детализировать/обощать» информацию вплоть до функции. А с логами чаще всего в проектах лишь одна настройка уровня логов на весь проект. Бывает, что у каждого компонента своя настройка уровня логов, но я ни разу не видел возможностей задать для каждой функции свой уровень логов.
Покрытие и качество интернет увеличиваются с каждым годом — тут и моб сети улучшаются, и wimax покрытия встречаются, и спутники как магистральный провайдер дают возможность провести инет туда, где раньше и не думали. Рост этого рынка будет каждый год снижать пользу от «работы в оффлайне» и, думаю, по истечению следующей пятилетки сведет пользу к нулю.
Вы приводите пример — и в нем уже в конце процесса покупка билета — т.е. действие уже в онлайне. Поэтому польза от «работы в оффлайне» уже снижается до вопроса стабильности канала. Передачу данных на нестабильном канале тоже можно программно улучшить (убрать принцип «канал кратковременно упал => вся работа потерялась») — эта задача уже довольно хорошо изучена и не представляет большой сложности (говоря проще, не требует проверки гипотез — сразу можно написать рабочий вариант). Что еще снизит пользу от «работы в оффлайне».
От облака есть еще дополнительные преимущества: возможность сбора больших данных. А значит вы сможете улучшить свой алгоритм методом композиции нейросетей — т.е. выбрать те примеры, где ваша нейросеть справилась неудачно и построить еще одну, которая дораспознает эти ошибки. Из оффлайна делать это невозможно, из полу-оффлайна делать это сложнее.
1) Основное преимущество 1с: это поддержка вечно меняющегося регламентированного учета в РФ. Оно сходит на ноль в других странах, т.к. в них нет столько изменений в регл учете. И тогда 1с придется конкурировать даже с чем-нибудь древним, 20 лет назад написанным. Проще говоря: конкуренция выйдет на порядки больше (даже не в разы).
2) В некоторых странах у малого бизнеса допускается вообще отсутствие регл учета. И поэтому 1с тут сможет конкурировать только в сфере управленческого учета, а значит придется конкурировать и с CRM.
3) У 1с тяжеловато с разделением продуктов по сложности. Больше 1с делит их по отраслям. А вот так, чтобы у «Управление торговлей» появилось 3 компоновки по функционалу/сложности/стоимости — такого нет. И механизмов скрытия от пользователя (функциональные опции) недостаточно, т.к. сложность всей конфигурации остается на высоком уровне (а значит теряет в производительности и выше стоимость доработки).
4) Зато у конкурентов много не-технических преимуществ: например, у них есть уже доля рынка и репутация. У некоторых (SAP) репутация такая, что внедрившие ее компании автоматически повышают свою капитализацию.
5) Про SAP отдельный разговор. У них с 1с концептуально противоположный подход к автоматизации.
Подход SAP: процессы должны быть такими, учет всегда таким. Перестраивайте фирму под них. Зато любой может посмотреть «отчет по продажам» и однообразно увидеть состояние фирмы.
Подход 1с: вот вам конструктор, там заложены пара базовых принципов, а дальше меняйте как хотите. Процессы и учет меняют под фирму. Поэтому тот же «отчет по продажам» может как угодно различаться и показывать разное в зависимости от фирмы и ее желаний.
Отсюда внедрение SAP повышает капитализацию (т.к. в фирму внедрили пусть не идеально работающие, но работающие процессы), а внедрение 1с никак не влияет на капитализацию (т.к. процессы могли остаться на любом пещерном уровне).
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 это есть.
Реальность же чаще такова, что есть код какого-то уровня легаси, часть из него вообще нельзя менять и где-то там произошел затык. И надо бы определить где и почему. И у меня стойкое ощущение, что с отладчиком это в разы быстрее, чем по логам. Просто потому, что (очень условно) отладчик позволяет «детализировать/обощать» информацию вплоть до функции. А с логами чаще всего в проектах лишь одна настройка уровня логов на весь проект. Бывает, что у каждого компонента своя настройка уровня логов, но я ни разу не видел возможностей задать для каждой функции свой уровень логов.