Спорный аргумент. Если автор сам пишет, что без случайного леса ручеек прибыли иссяк, значит не все так очевидно. Иначе интуитивных эвристик бы хватило, и деньги потраченные на 1000 серверков можно было бы потратить на что-то более другое.
Отличная задачка для олимпиадного программирования выходит. Составить такие индивидуальные списки для N провайдеров, чтобы вычислить K провайдеров, действующих в кооперации, и сравнивающих свои списки, чтобы отследить маркеры и выкинуть их перед публикацией.
Программист достаточно дорогой сотрудник и недостаточно эффективный, чтобы ходить и выяснять проблемы у бухгалтеров, которые то и говорить на одном языке с ним не могут. Потому и есть бизнес аналитики, саппорт, requirement аналисты. Это люди, которые, стоя дешевле, должны делать такую работу лучше
Интересно, во сколько бы обошлась камера, способная делать снимки с таким разрешением, чтобы по картинке в статье посчитать? И, боюсь, малинка не потянет потом такое разрешение процессить
Меня всю статью беспокоила мысль, почему автор не пытался выявлять пчел на дельтах соседних изображений. Все таки, выявить пчелу по характеру движения намного проще, чем по сливающемуся с фоном статичному контуру.
Так а в чем проблема, собственно? Такие команды иногда имеют запредельную эффективность. Оверхед 0. Пока конкуренты думают о том, как бы присобачить новый паттерн, фреймворк или тулинг, эти ребята генерят ценность. Иногда инвестиции в снижение бас фактора стоят дороже, чем сработавший бас фактор. Но, вообще, все от ситуации зависит.
Ничего принципиально нового. Большие данные + UGC. Платформа мессенджера, имея полный поток сообщений и жалобы, получает все возможности находить паттерны автоматизированно, и банить. Математические и хардверные предпосылки сейчас есть, как никогда ранее.
Если сообщения шифрованы end-to-end, это сложнее, но можно раскрывать исходные сообщения в момент жалобы на спам для обучения антиспам системы, и потом пересылать полученные на полном датасете жалоб эвристики на клиета, и фильтровать уже на нем.
В любом случае, надо использовать преимущество платформы перед спамерами — полный поток информации и машинное обучение, и не бить по больным местам клиентов — слабым процессорам и аккумуляторам гаджетов.
PS если мы говорим о межмессенджерном взаимодействии — то сила в объединении баз (точнее того, что можно объединить, не нарушив права юзеров)
Все равно в мелочах утонут. Даже без сраных стикеров (лучше бы их вообще из всех мессенджеров удалили) много нюансов на тему «каким алгоритмом жмется видео и картинки, и какое макс разрешение», что если мессенджер А понимает символ ~, а Б трактует его, как спецсимвол? А что, если * в одном мессенджере просто звездочка, а в другом — начало жирного текста?
Лично я наелся всего этого при написании бота, который одновременно и с ТГ и со скайпом работает через Microsoft Bot Framework. Только один маркдаун, который по разному парсится серверами ТГ и скайпа, сколько кровушки попил… а автоподстановка ссылок в скайпе та еще боль, и таких мелочей масса даже в примитивном, и ограниченном функционалом, общении человек <=> бот, а сколько, когда полная свобода?
Жесть. То есть, на старых телефонах будет лагать, на смарт часах будет еще и тратить пол батареи, а спамеры за копейки арендуют ботнеты и продолжат свое дело?
А что думаете о чем-то вроде elari.net/ru/product/nanophone-c с синхронизацией по блютусу + лопатой, лежащей в сумке.
И, кстати, по поводу корпоративных приложений и их нетребовательности к рессурсам. Я, к примеру, был вынужден отказаться от Galaxy SII потому, что скайп открывался более 30 секунд. Да и всякий корпоративный софт на тяжелых SPA типа jira, если надо открыть в десктоп версии с телефона (так, как мобайл версия бесполезна), хорошее железо ой как надо. Иначе можно вечность ждать.
Ну и, надо понимать, что программы и сайты будут все тяжелее. На хабре даже есть статья с призывом: «если пишете софт под мобильный сегмент, говнокодьте по-черному, забейте на производительность — все равно к моменту релиза выйдет новое поколение устройств, и там будет работать быстро»
Теоретически звучит интересно. А можете привести сравнение на исторических данных, на сколько % выгоднее быть пулом, работающим по вашему алгоритму по сравнению с постоянным метанием на самую выгодную монету? Интересно было бы увидеть гипотетические графики эквити пула, который вы предлагаете на истории в сравнениии с реальными эквити от мульти-майнинга. И при каком % от общей мировой мощности конкретного пула это начинает работать?
habr.com/company/iticapital/blog/248415
Программист достаточно дорогой сотрудник и недостаточно эффективный, чтобы ходить и выяснять проблемы у бухгалтеров, которые то и говорить на одном языке с ним не могут. Потому и есть бизнес аналитики, саппорт, requirement аналисты. Это люди, которые, стоя дешевле, должны делать такую работу лучше
Меня всю статью беспокоила мысль, почему автор не пытался выявлять пчел на дельтах соседних изображений. Все таки, выявить пчелу по характеру движения намного проще, чем по сливающемуся с фоном статичному контуру.
Если сообщения шифрованы end-to-end, это сложнее, но можно раскрывать исходные сообщения в момент жалобы на спам для обучения антиспам системы, и потом пересылать полученные на полном датасете жалоб эвристики на клиета, и фильтровать уже на нем.
В любом случае, надо использовать преимущество платформы перед спамерами — полный поток информации и машинное обучение, и не бить по больным местам клиентов — слабым процессорам и аккумуляторам гаджетов.
PS если мы говорим о межмессенджерном взаимодействии — то сила в объединении баз (точнее того, что можно объединить, не нарушив права юзеров)
Лично я наелся всего этого при написании бота, который одновременно и с ТГ и со скайпом работает через Microsoft Bot Framework. Только один маркдаун, который по разному парсится серверами ТГ и скайпа, сколько кровушки попил… а автоподстановка ссылок в скайпе та еще боль, и таких мелочей масса даже в примитивном, и ограниченном функционалом, общении человек <=> бот, а сколько, когда полная свобода?
И, кстати, по поводу корпоративных приложений и их нетребовательности к рессурсам. Я, к примеру, был вынужден отказаться от Galaxy SII потому, что скайп открывался более 30 секунд. Да и всякий корпоративный софт на тяжелых SPA типа jira, если надо открыть в десктоп версии с телефона (так, как мобайл версия бесполезна), хорошее железо ой как надо. Иначе можно вечность ждать.
Ну и, надо понимать, что программы и сайты будут все тяжелее. На хабре даже есть статья с призывом: «если пишете софт под мобильный сегмент, говнокодьте по-черному, забейте на производительность — все равно к моменту релиза выйдет новое поколение устройств, и там будет работать быстро»