Александр Рублев, да не обращайте внимания, я просто злобный мерзкий тип.
Вы, видимо, большой молодец, раз делаете работающий полезный продукт. Я просто некорректно и довольно хамски попытался объяснить несуразность и неэффективность применяемых и рассматриваемых вами технологий.
Это моё личное нескромное мнение. Не принимайте близко к сердцу.
xmoonlight, я правильно понял, что вы предлагаете привязать весь букет хабра-сервисов к почтовому ящику, в качестве сервера которого у вас будет ваша поделка?
И это вместо того, чтобы вычитывать стандартными простыми средствами по imap или pop3 письма из ящика?
Ну.. такое себе решение.
ValeraShprot, вы применили метод getConversationMembers. посмотрите формат возвращаемого результата. Там есть items. Вот к нему, очевидно и применяете рандомный выбор.
javedimka, пардон, померещилось мне. Тут вы правы.
Если автор запускает на локалхосте - почему бы и не udp?
А вот тут нет. Если автор запускается на локалхосте, то ТЕМ БОЛЕЕ зачем ему UDP всё будет летать и так, а лишний слой протокола делать не придётся. Автору вообще проще всего использовать какой-нибудь микроферймворк вроде Flask. Вообще ничего лишнего писать не придётся.
А судя по тому какие и как вопросы задаёт автор, то я в недоумении что у него там за ERP и как он её написал.
Не, ну может эдакий маугли от разработки... нафигачил крутой GUI, умеет делать отчеты как-то, в архитектуре клиентского приложения не накосячил настолько, что можно легко прикрутить сетевой протокол и проект не вылезет за когнитивные способности автора.
UDP имеет смысл в каких-то играх, где нужно пересылать в реальном времени поток событий и можно пренебречь негарантированной доставкой пакетов или несохранением очередности. Или в каких-то интерактивных медиа-коммуникациях можно UDP использовать. Транслировать там что-нибудь быстро... Но делать ERP на голом TCP и десктопном приложении в 21 веке это всё равно, что паять игровой компьютер иа транзисторах самому. Наверно можно попробовать повторить на кухне тех-процесс и чипы запекать в духовке, но... это неоправданный расход времени и, что самое главное, сложности. Сложность - это основной ресурс в любой системе. Если она превысит пороговый уровень когнитивных способностей понимания человека, то проект погибнет под собственным весом. Для уменьшения сложности придумали всякие фреймворки, которые прячут сложность и рутину от программиста.
xmoonlight, а зачем для этого писать свой почтовик, тем более на php? Вы ж не пишете свой nginx, чтобы сделать сайт или свою реализацию сокетов для использования TCP IP. Любой почтовый ящик вполне можно проверять программно.
Хотя далёким людям виднее, наверно
Aricce, так других примеров больше адекватных не предложили. Или я пропустил?
Узнать какая там функция - это совсем другое. Давайте еще примеров, а-то не ясно. Сходи туда - не знаю куда.
Aricce, что-то вы непонятно чего хотите.
Формулы даты смерти, даже примерной формулы, не бывает. Существуют корреляции разного уровня, например мужчины в среднем живут меньше. Есть корреляция с большими выбросами в росте (карлики и люди сильно больше 2 метров роста очевидно проживут меньше в среднем) из-за проблем со здоровьем. Могут быть корреляции более сложные. Мне трудно сочинить для вас хороший пример, поэтому давайте пофантазируем на тему танкистов. Вроде как танкистов подбирали по малому росту и если есть какая-то корреляция рода войск с продолжительностью жизни, то эта корреляция будет и с ростом тоже.
И таких сложных корреляций очень много, мы не можем учесть все, потому что они не очевидны. А вот нейронная сеть может сузить разброс в некоторых случаях на основе каких-то многоуровневых неявных корреляций.
Но нужна огромная выборка для обучения. Речь идёт о сотнях тысяч и миллионах единиц размеченных данных.
Нейронная сеть не обязательно выдаёт дискретный сигнал, так что РЕШАТЬ вашу задачу нейросетями можно. Но РЕШИТЬ удовлетворительно -- не факт.
Есть такое понятие, как аппроксимация. У вас есть набор параметров (читай аргументов), и значение какой-то неизвестной функции. И таких кортежей у вас много-премного. Можно попробовать аппроксимировать ваше N-мерное многообразие какой-то функцией. Для простых плоских случаев это может быть, например, сплайн, или степенная функция, когда вы подбираете её коэффициенты и степени так, чтобы она максимально близко ложилась на ваше многообразие по среднеквадратичному отклонению.
Для больших размерностей ситуация сильно осложняется. Мне кажется это не ваш путь, даже если у вас в голове этот пример выглядит как адекватный первоначально поставленной задаче.
Резюмирую.
Если у вас не миллионы данных - забейте. Вам нейронки не помонгут.
Если вы не представляете какие требования и ограничения у вас по параметром ошибки в прогнозе, то, действительно, подбрасывайте монетку. Какая разница, если вы сами не знаете чего хотите?
Экспериментируйте. Если нейронки научили истреблять шакалов с довоенных фотографий и скоро научат снимать мультики и ставить балет на основе наскальной живописи,то ваша задача не выглядит как совсем уж бред. Правда.
Подтянитесь в математике. Нужно понимать что такое случайная величина, дисперсия, мат-ожидание, нормальное распределение.
Прочитайте Криптономикон. В этой задаче он вам не поможет, но чтиво захватывающее и может повернуть мозг в интересное русло.
Иван Шумов, вы слишком категоричны в суждениях, сударь.
Там, где можно применить кластерный анализ, вполне справятся и нейронные сети.
Вы сильно приуменьшаете значимость корреляций, а автор нигде не говорил о параметрах допустимой ошибки в прогнозе.
Вы верно подметили, что дата смерти - это, в общем-то, случайная величина, но у этой случайной величины есть свои сложные корреляции, есть мат-ожидание и дисперсия.
Кластерный анализ не позволит уловить сложные скрытые зависимости. Автор же не предоставил полный перечень данных, которые у него есть.
Может быть там среди них есть что-то, что сильно коррелирует с некоторыми группами риска: курение, профессия, хобби... Если у автора действительно большой обучающий размеченный датасет и невысокие требования к точности, то нейронка вполне может показать много сюрпризов и неожиданных корреляций.
вообще-то нейронку применить можно куда угодно. Вон люди свою биологическую применяют на каждом шагу. Ошибка - это вполне измеримая и контролируемая штука. Вполне можно хорошо учитывать корреляции с полом, индексом массы тела...
Обман водителей и оптическая навигация немного неклеются между собой. Если водила заглушил GPS, то забрызгать "нечаянно" камеру трекера вообще изи.
Нейросетью, к тому же, задачу навигации не решишь. Только, разве что, можно уточнить показания координат за счет анализа оптического потока.
Подключение к CAN-шине, периферийным датчикам, датчику топлива, датчикам открытия дверей, датчику работы двигателя и датчикам вращения колёс... всё это уже доступно в промышленных трекерах. Тут новизны не сыскать.
Тема про городскую инфраструктуру - это скорее про бэкенд и внешние интеграции. Устройство тут ни при чем.
Я переформулировал вопрос, адресовал вопрос сообществу, убрал ограничение на конкретный ресурс.
Вопрос касается спектра вариантов отношения администрации к упомянутой деятельности. Я понимаю, что даже в рамках одной организации могут существовать внутренние противоречия и разное отношение к данному вопросу.
Меня интересует именно опыт сообщества и возможные последствия.
Я удалил тег API из вопроса, но тег Телеграм оставил, поскольку вопрос касается именно этого мессенджера и его сообщества в первую очередь, в уж "Хабр Q&A" косвенно.
Спасибо за оперативную реакцию и своевременное предупреждение о нечаянном нарушении правил данного ресурса.
Спасибо, я подумаю над вашим предложением. Однако я собирался парсить не сами вопросы, а трекер и верхушку ленты для интерактивных уведомлений через бота. Почта в этом плане не так удобна.
Но в Правилах я явного обозначения позиции администрации к этому вопросу не увидел.
Более того, паразитирование, на мой взгляд, имело бы место, если бы я как-то монетизировал информацию или бота, но мне он нужен исключительно из соображений личного удобства пользования ресурсом. Если бы был штатный "уведомлятор" для Телеграма, я бы пользовался им.
Антон Муравьев, вы меня не поняли. Я говорил серьёзно. Это очень сильная точка зрения. Считается, что программа должна быть максимально простой для успешного и эффективного выполнения своей функции. При этом программа не должна стараться "выжить и что-то сделать любой ценой". Если что-то пошло явно не так, то правильнее безопасно и сразу упасть, чем успеть прилично попортить данные через полтора часа непрерывной работы на огромном датасете и залить в целевую БД частично некорректный ответ, который хрен оттуда потом вычистишь.
Антон Муравьев, я б на вашем месте защищался по-другому. Я бы сказал, что хорошая программа старается упасть сразу, как только что-то пошло не так. На мой выпад о том, что нет ассертов по другим критериям, я бы возразил в том смысле, что за параноидальными проверками в решении заведомо учебной задачи потеряется читабельность и понятность. Последнее, кстати, отличный гвоздь и в моё предложение относительно среза потенциально пустой строки. Судя по уровню автора вопроса, ему не очень понятен синтаксис условного оператора. Тонкости наших трюков ему не понять вовсе.
Антон Муравьев, если сначала ввели дату, а потом имя с инициалами и точкой, то у вас дата будет содержать копию фамилии. Понятно, что такой ввод, в общем-то, противоречит заданию, но код нужно в любом случае писать более надёжным, особенно если такого можно добиться простым использованием elif вместо if.
Чуть более спорной будет моя придирка к i[0]. Пользователь вполне может ввести пустую строку. В вашем случае будет исключение при обращении по индексу.
Лучше выработать у себя привычку всегда чуять такие тонкие места. Здесь можно было бы подстелить соломки так: i[:1]. Проверка по сути та же, но безопасная по отношению к пустой строке.
Александр Рублев, да не обращайте внимания, я просто злобный мерзкий тип.
Вы, видимо, большой молодец, раз делаете работающий полезный продукт. Я просто некорректно и довольно хамски попытался объяснить несуразность и неэффективность применяемых и рассматриваемых вами технологий.
Это моё личное нескромное мнение. Не принимайте близко к сердцу.