У меня раньше для таких целей служил ноут Toshiba Portege M400. Это таблетка — у него монитор перевертыш, можно сложить как планшет экраном вверх, там прочный пластик над экраном(можно рукой опираться), вакомовский стилус и предустановленная программа MS One Note — вот где было удобно — рисуешь по экрану как по блокноту, можно по разлинованной под тетрадь подложке, качество рисования на высоте(тонкие линии, зависящие от силы нажатия), кнопку Save жать не надо(автомат), «бумажки» и сам «блокнот» не теряется… А потом он сдох (
Ну… Если подходить с озвученной точки зрения «добро и зло, верх и низ, право и лево, вперёд и назад, чёрное и белое...», тогда действительно мониторов должно быть два. При чем, судя по аллегориям, один из них должен быть развернут к пользователю задней стенкой )
А если вспомнить, что глаза у человека тоже два, так вообще все становится очевидным: один глаз — в один монитор, второй глаз — во второй монитор. Профит! )))
P.S. А можно я свою версию озвучу тоже? Вот она:
Оптимальное число мониторов — больше нуля! )))
Кстати, спасибо за идею. Я так или иначе планирую в дальнейшем эти данные обрабатывать. В основном для себя, но если в процессе появится что-то полезное, это полезное так же вывалю сюда на Хабр, не взирая на минусы от «неврубившихся», как это происходит с этой статьей )) Я почему-то верю, что если оно поможет хотя бы паре человек — работа была проделана не зря )))
Так вот, возможно ваша идея будет реализована. Как минимум с относительно небольшими затратами я могу реализовать конвертацию статей из фидов в библиотеку формата FB2(с проставлением авторов, ссылок на оригиналы и т.п.), возможно даже с автоподкачкой данных с оригинальных статей, т.к. некоторые подписки содержат в себе только анонсы до «ката», а не полные тексты статей. Ну а там и до PDF уже недалеко — либо помучиться и добавить опцию конвертации в PDF, либо найти пакетный конвертер FB2-to-PDF.
P.S. кстати, если вдруг вздумаете этого дождаться, то когда будете выкачивать данные этим скриптом, лучше делайте это без консолидации( параметр $GLOBALS['try_consolidate'] поставить в false ). Ибо обрабатывать данные небольшими пачками менее затратно по ресурсам, чем к примеру всасывать в себя фид Хабра, который целиком занимает более 50Мб в XML.
Он не парсит сами статьи. Он тупо выкачивает все, что отдает Гугл, и не конвертируя(не трогая кодировки и структуру с аттрибутами), укладывает на винт. Собственно для того и писался.
Что потом делать с этими данными, решать конечному пользователю.
Можно их распарсить и сделать pdf, как вы хотите, можно перекачать еще куда-либо…
Данный скрипт специально писался делать только то, что он делает и не более того — слить данные с Гугла, не затормаживаясь в это время их обработкой — топорный бекап.
То есть это средство, которое нужно запустить либо непосредственно перед первым июля один раз, либо для надежности запускать «чем ближе к первому июля, тем чаще», после каждой успешной сессии удаляя данные предыдущего запуска. В принципе особо часто и не нужно наверное…
Ну или типа того.
С тегами соответственно никак — все, что вам нужно, нужно делать с данными уже после.
Он поможет вам вытащить данные в последний момент, и когда ГуглоРидер окончательно закроется, уже не спеша их обрабатывать, никуда не торопясь.
Кстати, а вам «отмеченные» нужны именно в XML формате? Тогда да, скрипт поможет.
В json он тоже поможет вытащить, но в json эти спецфиды и сам Гугль отдает в их официальном экспорте данных ( www.google.com/takeout/ ): там отдается сам список фидов в OPML-формате(название, RSS-URL и WEB-URL), и еще json-файлы как раз с этими «спецфидами».
Чесно — не знаю. Я не проверял, отдает Гугл только с того момента, как текущий пользователь начал читать, или же с момента, как кто-то добавил этот сайт вообще впервые.
Есть намек в виде той же ленты Хабра — она тащится, начиная с поста с номером 195 в url, что как бы намекает, что ваш вариант рабочий, т.к. я на Хабре появился точно сильно позже, и соответственно добавил в читалку еще позже.
Выключаете параметр $GLOBALS['fetch_regular_feeds']=false, и вам вытащит только спецфиды: 'starred', 'notes', 'shared', 'shared-followers'. starred- это и есть со звездочкой. Остальные обычно немногочисленны.
Можете так же в коде найти строку $chlst=array('starred', 'notes', 'shared', 'shared-followers'); и оставить в массиве только 'starred' — и вытащит только его( при выключенном $GLOBALS['fetch_regular_feeds'] )
Вот как-то так.
Ну сам список фидов вытащит по-любому, но это мелочь, удалите за ненадобностью )
Хм… Первая же мысль появилась про печать на фольгированном текстолите. То есть об упрощенном изготовлении печатных плат. Но цена эту мысль сразу же убила (
P.S. вторая мысль в ту же тему: интересно, сколько будет стоить такая печать в розницу у тех, кто такой принтер имеет? То есть, очевидно, у рекламщиков…
Вот-вот. Поживем — увидим )
Я всего лишь говорил о том, что во многих ситуациях смена платформы не является сколь-нибудь заметной сложностью. И начальный прототип на Ардуине с последующим переходом на более навороченную платформу здесь выглядит вполне рентабельно.
Начать на Ардуине «тяп-ляп и навесной монтаж» позволяет очень быстро создать более-менее функциональный прототип и прикинуть общую архитектуру проекта в грубом приближении. А дальше уже в зависимости от реальных потребностей в мощи и быстродействии выбирается платформа — могут в итоге и на AVR остаться в общем-то )
>> В итоге то это всеравнона AVR будет
Вовсе не факт. То, что на ардуине можно прототипировать и отлаживать софт и потом заливать в итоге на AVR-семейство, еще не значит, что именно так все и делают. На ардуине в режиме макетки(это удобно) можно отлаживать например только периферийные обвесы и потом все на чистовую перенести на более навороченный и компактный ARM с блютузами-вайфаями и прочими прелестями.
Для хороших embed-программеров это ни разу не проблема в общем-то )
По ходу видео периодически показывают анализ положения тела игрока, и даже сравнение с другими футболистами есть. Это показывают, как работает «доударное» прогнозирование в прошивке данного робота и на какие нюансы алгоритм обращает внимание.
Это те моменты на видео, где на экране появляются стрелочки.
[зануда on]
После последнего удара показывают такой же анализ ситуации и сравнение с третьим ударом «в девятку», указывая на абсолютно идентичное передвижение Месси вплоть до самого момента удара(да и после тоже), и объясняя таким образом, почему робот на основе предварительного прогноза сначала дернулся не в ту сторону. Разница лишь в небольшом смещении ноги относительно центра мяча в сам момент удара. Видимо это и есть тот финт.
Если у робота действительно только одна камера, которая «во лбу», то это как раз объясняет, что с моно-зрением это скорее всего даже не косяк алгоритма — не видя глубины сцены, система не могла различить даже разницу в движении ноги прямо перед самым ударом, хотя разница есть и ее прекрасно видно с других проекций, но не «из глаза» робота.
[/зануда on]
>> Механизмы массового отслеживания нужны в случаях затруднения получения информации прямыми путями.
Если грабли случились где-то на внутренних звеньях системы, «массовые механизмы» лягут рядом с «прямыми путями». Так что не аргумент. Особенно в свете предложенного вами ранее способа "И пользователь в адресной строке добавив ".json" получает json вместо html.". Тут очевидно источник информации один и тот же, поэтому в случае проблем автоматом «лягут» оба способа.
А то знаете ли, бесплатный Windows тоже окажется нужен, если опросить кучу народа, но Майкрософт чего-то не спешит его раздавать )
Так же и ПР — им-то конечно, в отличии от редмондцев, не деньги зарабатывать на отслеживании — это изначально бесплатная услуга. Но при текущем раскладе с нагрузкой и ее последствиями раздавать всем желающим открытые механизмы падения серверов им явно не выгодно.
На счет перехода на личности вы передергиваете. Мы общаемся лично с вами и какие-то предположения я делаю исключительно по вашим утверждениям. Я не могу обобщать, не зная мнения других по этому поводу, потому и происходит то, что вам кажется переходом на личности.
По поводу XML, либ, комьюнити и прочего — мы с вами просто разные. Я не могу придерживаться стремления внедрять XML, .Net и подобные технологии где ни попадя. Особенно там, где они не нужны, и выполняют только функцию универсализации и удобства программисту, давая системе кучу лишнего оверхеда в виде жора процессора и памяти. И варианты «пофиг, компенсируем наращиванием вычислительных мощностей, благо они не дороги сейчас» меня тоже коробят.
Наверное я старомоден. Привык экономить байты среди гигабайтов )))
В крайнем случае по нашему контексту есть еще одна схема решения: у многих SMS-провайдеров рассылки отправлять можно как из личного кабинета, так и еще несколькими способами — загружать списки отправки обычным POST-запросом, XML-файлом, и самым бинарным из них — работать со шлюзом напрямую по SMPP протоколу. Я выбрал SMPP, при чем никаких чужих либ не использовал. Все, что мне надо, стараюсь писать сам и на самом низком уровне — так лучше контроль, где что происходит. Однако понимаю, что то, что проще мне, вовсе не обязательно проще другим. Зато в случае каких-либо проблем я смогу быстро локализовать и исправить ошибку, а не сыпать отмазками, что это разработчики какой-то там либы виноваты и ждать с моря погоды либо ковыряться в чужом коде.
>> Если отдавать XML менее ресурсоемкая задача, чем генерировать HTML
Да с какого перепуга? Физическому клиенту так или иначе нужно показывать HTML обрамление, включая шапку, меню и т.п. Сгенерировать для отслеживания только кусок HTML с таблицей трекинга ничем таким не отличается от генерации XML с теми же данными. Но в случае промежуточного XML все-равно кому-то нужно его парсить, чтобы эти данные привести в табличную форму на экране клиента. Либо серверу, формирующему конечный HTML, либо браузеру, встраивающему XML-данные в поля на страничке. И второе не факт, что будет нормально работать у всех клиентов, ибо хрен знает, кто там каким браузером пользуется.
Генерацию капчи, как отдельный механизм, тоже можно оптимизировать кучей разных способов.
>> Такой метод эффективнее, если запрос идет по области. Запросы по уникальным параметрам теоретически займут столько же времени.
Ага, как же. Теоретически. Даже упаковка запросов с перечислением типа «select… where… in (TR1, TR2, TR3, ...)», что считается само по себе не оптимизированным, однако даст приличный прирост производительности, т.к. уже не требует старта отдельной транзакции для каждого запроса. Вы вообще не забываете, что практически все SQL-СУБД имеют транзакционный механизм? Или вы не пользуетесь транзакциями и считаете, что их у вас поэтому нет? Я вас разочарую — они есть по-любому. А если вы ими явно не пользуетесь, значит они за вас стартуются сами клиентской либой и ой не факт, что оптимальным способом.
>> только для того, чтобы 1% клиентов мог запросить более одного трека
Что-то я сомневаюсь, что текущие массовые аггрегаторы отслеживания, обслуживающие многие «отслеживальные» программы для iOS/Android, а так же сайты, где под своим аккаунтом можно держать список своих посылок и гораздо удобнее ориентироваться, что где — это 1% клиентов. Если сравнивать с количеством народу, отправившего/ждущего посылку, то возможно и 1%. А если сравнить с только теми из них, кто самостоятельно лезет в инет для отслеживания, то 1% мне не кажется реальным. Довольно много народу предпочитает отслеживать посылки не через сайт ПР.
>> При чем здесь XML, если вы ранее говорили о протоколе общения с субд?
Протокол общения непосредственно с СУБД ограничен как правило клиентской либой для этой СУБД. Я же говорил о протоколе взаимодействия служб(сервисов, демонов и т.п.) между собой.
В том контексте я говорил о варианте решения, когда есть общая служба, отдающая трекинг «по паролю/ключу», и есть другие службы, типа аггрегаторов, а так же официальная страничка отслеживания, пользующаяся той же службой на общих основаниях. Так вот я говорил, что для взаимодействия этих звеньев между собой XML не нужен.
>> И при чем тут вообще синхронность, и в каком контексте понимать асинхронность?
Синхронность — это когда вы устанавливаете TCP-соединение, шлете туда запрос, получаете ответ, потом шлете следующий запрос, получаете следующий ответ. Вы можете послать туда пачку запросов сразу(буфферизация на уровне TCP), после чего ответы получаете на них последовательно, в том же порядке, в котором уходили запросы. Асинхронность предполагает, что ответы вам могут приходить не обязательно в том же порядке. То есть из пачки запросов более легкие ответы придут раньше, пока сервак все еще переваривает более тяжелые. По факту — принципы многозадачности в действии. И это по одному TCP-соединению. Без необходимости плодить кучу таких соединений на каждый внешний запрос.
>> И как может быть у протокола древовидная структура?
Или вы под XML понимаете не язык разметки текстового документа?
Имеется в виду древовидная структура данных, конечно, передаваемая в пакетах протокола. Читай не «простая табличная организация» данных, а «древовидная без ограничения вложенности». Вы ведь знаете, как устроена внутри сама разметка XML/HTML и какие структуры оно может хранить, да? ))
>> Супер пупер веб страничка банится как досер. А безответственной школоте провайдер блокирует доступ к интернету, до выяснения обстоятельств. [skipped blah-blah-blah]
Вы это серьезно? IT служба ПР должна звонить провайдерам, держать списки забаненных IP, подавать заявы в прокуратуру(вот я ждал, что еще это скажете) и прочее только ради того, что кто-то допустил какую-то синтаксическую ошибку в своем коде? Не проще ли уже известному(через договор и пароль/ключ) клиенту ограничить доступ к системе до устранения ошибки? Зачем держать списки забаненных «неклиентов» конторы, которые а) будут явно больше, чем список клиентов, и б) местоположение вредоносного(или просто кривого) кода может меняться, как и динамический айпишник. Будем банить целые подсети? ))))
>> И да, надежность железа выше надежности самописаного протокола, хотя бы потому, что железо можно зарезервировать, разработчика протокола зарезервировать пока не получилось ни разу.
>> Вот к XML, JSON, YAML есть описание, а к вашему протоколу с древовидной структурой описание есть?
Какого еще железа? Вы XML хардварным методом обрабатываете? И при чем здесь разработчик? На бинарный протокол составляется документ с описанием структуры и все. Никаких проблем с новыми разработчиками. Для клиентов-аггрегаторов можно и в XML транслировать, либо дать готовую клиентскую либу, если нужен для внешнего обмена именно «бинарник». Но все-таки, как раз XML обычно используют только при обмене данными с «внешним миром», где в его универсальности и человекочитабельности есть хотя бы смысл.
У меня такое ощущение, что вы боитесь всего, с чем не сталкивались. Поверьте, не так страшен черт, как вы его себе малюете. Более того, если сравнивать бинарные протоколы и XML по документации, так в XML заморочек еще больше. Кроме того, что «бинарник» может предоставлять абсолютно те же данные в той же структуре, только в машинно-ориентированном виде, без необходимости парсить текст, искать среди неиндексированного текста сами данные(офсеты), жрать излишнюю память и т.п. Хотя конечно, если пользоваться «стандартными» либами, и никогда не заморачиваться как оно работает внутри, что делает, сколько жрет процессора/памяти, способно ли восстановиться при мелких ошибках форматирования и прочее, тогда конечно, можно прикрутить к своему коду генерацию XML за 41 секунду и не париться )))
А еще можно отправлять к серверам ПР запросы «по одному» и тоже не париться по поводу производительности — «с моей стороны пинги вылетели»(с), поэтому это стопудов у них проблема. Я не при делах. Это они обязаны держать нагрузку, а не я оптимизировать что-то. Я же пользуюсь стандартными библиотеками, ага.
Впрочем, на счет экономической эффективности вы в какой-то степени правы. Всегда можно с работы выкинуть человека и нанять другого такого же. Это да.
Вот только… я хотел бы разговаривать все-таки о программистах, а не кодерах.
А не надо передергивать и сравнивать зеленое с теплым. Ввод капчи или других методов борьбы со сторонними массовыми запросами — не эквивалент маскировки пунктов выдачи. У вас не отобрали возможность отследить посылку. Отобрали только возможность генерить неконтролируемый трафик, создавая *свои* механизмы массового отслеживания. Ладно я бы еще понял ваши претензии, если б капча была нераспознаваемой.
>> организовать выдачу клиенту XML-ки задача более легкая чем HTML с капчей
Давайте ответим на два вопроса. Первый вопрос: более легкая задача для кого/чего? Для программиста(41 секунда), для сервера? Для которого из серверов: БД или Веб? Или тяжело для сервера генерации капчи(который может быть отдельным)?
А потом ответим на второй вопрос: для какого из перечисленных(или недоперечисленных — мы ж не знаем их внутреннюю кухню) звеньев более важно минимизировать нагрузку?
Далее я не понимаю, почему вы упираете на "2.1. Принимать к обработке треки по одному."
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
>> 3. Клиент не общается с СУБД поэтому клиенту отдается XML. Одно из другого само по себе еще не следует.
Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
>> Возможно спам или ддос.
Ранее о ддос я говорил лишь как о вытекающем при естественной нагрузке. О целенаправленной ддос-атаке я не говорил — это отдельная тема. Серверам ПР и естественной нагрузки на данный момент хватает, чтоб нередко «падать» или «залипать».
>> Это (прим.: речь явно о XML против бинарных протоколов) дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете.
«Владею своими протоколами». При чем протоколы эти асинхронны: запросы на одном TCP-канале не обязаны стоять в очереди и ждать, пока отработает каждый предыдущий. Проблем не знаю. ЧЯДНТ? Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда. В тех местах, где стороннему человеку делать нечего — и XML-ю делать тоже нечего, он там не нужен абсолютно.
>> 2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом.
А почему считаете бредом-то? Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров, то что в этом плохого-то? Что это отсечет либо хотя бы идентифицирует(даст обратную связь, чтоб админы ПР могли связаться и указать что и где поправить) безответственную школоту, случайно зациклившую свою «супер-пупер вебстраничку для отслеживания»? Или вы так боитесь своей деанонимизации? ))))
>> Такая огромная структура как Почта России боится ддоса?
А хрен их знает. С одной стороны в новостях читаешь периодически, сколько денег они тратят на сортировочные центры. С другой — общаешься с девченками в отделениях(даже в МСК) — там зарплаты такие, что даже смеяться стыдно. Что там у них в IT творится — это нужен интрудер, чтоб хоть как-то об этом судить. Так что на вашем месте я бы не применял свое видение, основанное на сидении в конторе, которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед), на структуру типа Почты России. Они явно ограничены в той или иной степени как в компетенции, так и в финансировании.
А если вспомнить, что глаза у человека тоже два, так вообще все становится очевидным: один глаз — в один монитор, второй глаз — во второй монитор. Профит! )))
P.S. А можно я свою версию озвучу тоже? Вот она:
Оптимальное число мониторов — больше нуля! )))
Так вот, возможно ваша идея будет реализована. Как минимум с относительно небольшими затратами я могу реализовать конвертацию статей из фидов в библиотеку формата FB2(с проставлением авторов, ссылок на оригиналы и т.п.), возможно даже с автоподкачкой данных с оригинальных статей, т.к. некоторые подписки содержат в себе только анонсы до «ката», а не полные тексты статей. Ну а там и до PDF уже недалеко — либо помучиться и добавить опцию конвертации в PDF, либо найти пакетный конвертер FB2-to-PDF.
P.S. кстати, если вдруг вздумаете этого дождаться, то когда будете выкачивать данные этим скриптом, лучше делайте это без консолидации( параметр $GLOBALS['try_consolidate'] поставить в false ). Ибо обрабатывать данные небольшими пачками менее затратно по ресурсам, чем к примеру всасывать в себя фид Хабра, который целиком занимает более 50Мб в XML.
Что потом делать с этими данными, решать конечному пользователю.
Можно их распарсить и сделать pdf, как вы хотите, можно перекачать еще куда-либо…
Данный скрипт специально писался делать только то, что он делает и не более того — слить данные с Гугла, не затормаживаясь в это время их обработкой — топорный бекап.
То есть это средство, которое нужно запустить либо непосредственно перед первым июля один раз, либо для надежности запускать «чем ближе к первому июля, тем чаще», после каждой успешной сессии удаляя данные предыдущего запуска. В принципе особо часто и не нужно наверное…
Ну или типа того.
С тегами соответственно никак — все, что вам нужно, нужно делать с данными уже после.
Он поможет вам вытащить данные в последний момент, и когда ГуглоРидер окончательно закроется, уже не спеша их обрабатывать, никуда не торопясь.
В json он тоже поможет вытащить, но в json эти спецфиды и сам Гугль отдает в их официальном экспорте данных ( www.google.com/takeout/ ): там отдается сам список фидов в OPML-формате(название, RSS-URL и WEB-URL), и еще json-файлы как раз с этими «спецфидами».
Есть намек в виде той же ленты Хабра — она тащится, начиная с поста с номером 195 в url, что как бы намекает, что ваш вариант рабочий, т.к. я на Хабре появился точно сильно позже, и соответственно добавил в читалку еще позже.
Выключаете параметр $GLOBALS['fetch_regular_feeds']=false, и вам вытащит только спецфиды: 'starred', 'notes', 'shared', 'shared-followers'. starred- это и есть со звездочкой. Остальные обычно немногочисленны.
Можете так же в коде найти строку $chlst=array('starred', 'notes', 'shared', 'shared-followers'); и оставить в массиве только 'starred' — и вытащит только его( при выключенном $GLOBALS['fetch_regular_feeds'] )
Вот как-то так.
Ну сам список фидов вытащит по-любому, но это мелочь, удалите за ненадобностью )
P.S. вторая мысль в ту же тему: интересно, сколько будет стоить такая печать в розницу у тех, кто такой принтер имеет? То есть, очевидно, у рекламщиков…
Я всего лишь говорил о том, что во многих ситуациях смена платформы не является сколь-нибудь заметной сложностью. И начальный прототип на Ардуине с последующим переходом на более навороченную платформу здесь выглядит вполне рентабельно.
Начать на Ардуине «тяп-ляп и навесной монтаж» позволяет очень быстро создать более-менее функциональный прототип и прикинуть общую архитектуру проекта в грубом приближении. А дальше уже в зависимости от реальных потребностей в мощи и быстродействии выбирается платформа — могут в итоге и на AVR остаться в общем-то )
Вовсе не факт. То, что на ардуине можно прототипировать и отлаживать софт и потом заливать в итоге на AVR-семейство, еще не значит, что именно так все и делают. На ардуине в режиме макетки(это удобно) можно отлаживать например только периферийные обвесы и потом все на чистовую перенести на более навороченный и компактный ARM с блютузами-вайфаями и прочими прелестями.
Для хороших embed-программеров это ни разу не проблема в общем-то )
Есть системы и с гораздо более быстрой реакцией.
Это те моменты на видео, где на экране появляются стрелочки.
[зануда on]
После последнего удара показывают такой же анализ ситуации и сравнение с третьим ударом «в девятку», указывая на абсолютно идентичное передвижение Месси вплоть до самого момента удара(да и после тоже), и объясняя таким образом, почему робот на основе предварительного прогноза сначала дернулся не в ту сторону. Разница лишь в небольшом смещении ноги относительно центра мяча в сам момент удара. Видимо это и есть тот финт.
Если у робота действительно только одна камера, которая «во лбу», то это как раз объясняет, что с моно-зрением это скорее всего даже не косяк алгоритма — не видя глубины сцены, система не могла различить даже разницу в движении ноги прямо перед самым ударом, хотя разница есть и ее прекрасно видно с других проекций, но не «из глаза» робота.
[/зануда on]
Если грабли случились где-то на внутренних звеньях системы, «массовые механизмы» лягут рядом с «прямыми путями». Так что не аргумент. Особенно в свете предложенного вами ранее способа "И пользователь в адресной строке добавив ".json" получает json вместо html.". Тут очевидно источник информации один и тот же, поэтому в случае проблем автоматом «лягут» оба способа.
А то знаете ли, бесплатный Windows тоже окажется нужен, если опросить кучу народа, но Майкрософт чего-то не спешит его раздавать )
Так же и ПР — им-то конечно, в отличии от редмондцев, не деньги зарабатывать на отслеживании — это изначально бесплатная услуга. Но при текущем раскладе с нагрузкой и ее последствиями раздавать всем желающим открытые механизмы падения серверов им явно не выгодно.
На счет перехода на личности вы передергиваете. Мы общаемся лично с вами и какие-то предположения я делаю исключительно по вашим утверждениям. Я не могу обобщать, не зная мнения других по этому поводу, потому и происходит то, что вам кажется переходом на личности.
По поводу XML, либ, комьюнити и прочего — мы с вами просто разные. Я не могу придерживаться стремления внедрять XML, .Net и подобные технологии где ни попадя. Особенно там, где они не нужны, и выполняют только функцию универсализации и удобства программисту, давая системе кучу лишнего оверхеда в виде жора процессора и памяти. И варианты «пофиг, компенсируем наращиванием вычислительных мощностей, благо они не дороги сейчас» меня тоже коробят.
Наверное я старомоден. Привык экономить байты среди гигабайтов )))
В крайнем случае по нашему контексту есть еще одна схема решения: у многих SMS-провайдеров рассылки отправлять можно как из личного кабинета, так и еще несколькими способами — загружать списки отправки обычным POST-запросом, XML-файлом, и самым бинарным из них — работать со шлюзом напрямую по SMPP протоколу. Я выбрал SMPP, при чем никаких чужих либ не использовал. Все, что мне надо, стараюсь писать сам и на самом низком уровне — так лучше контроль, где что происходит. Однако понимаю, что то, что проще мне, вовсе не обязательно проще другим. Зато в случае каких-либо проблем я смогу быстро локализовать и исправить ошибку, а не сыпать отмазками, что это разработчики какой-то там либы виноваты и ждать с моря погоды либо ковыряться в чужом коде.
Да с какого перепуга? Физическому клиенту так или иначе нужно показывать HTML обрамление, включая шапку, меню и т.п. Сгенерировать для отслеживания только кусок HTML с таблицей трекинга ничем таким не отличается от генерации XML с теми же данными. Но в случае промежуточного XML все-равно кому-то нужно его парсить, чтобы эти данные привести в табличную форму на экране клиента. Либо серверу, формирующему конечный HTML, либо браузеру, встраивающему XML-данные в поля на страничке. И второе не факт, что будет нормально работать у всех клиентов, ибо хрен знает, кто там каким браузером пользуется.
Генерацию капчи, как отдельный механизм, тоже можно оптимизировать кучей разных способов.
>> Такой метод эффективнее, если запрос идет по области. Запросы по уникальным параметрам теоретически займут столько же времени.
Ага, как же. Теоретически. Даже упаковка запросов с перечислением типа «select… where… in (TR1, TR2, TR3, ...)», что считается само по себе не оптимизированным, однако даст приличный прирост производительности, т.к. уже не требует старта отдельной транзакции для каждого запроса. Вы вообще не забываете, что практически все SQL-СУБД имеют транзакционный механизм? Или вы не пользуетесь транзакциями и считаете, что их у вас поэтому нет? Я вас разочарую — они есть по-любому. А если вы ими явно не пользуетесь, значит они за вас стартуются сами клиентской либой и ой не факт, что оптимальным способом.
>> только для того, чтобы 1% клиентов мог запросить более одного трека
Что-то я сомневаюсь, что текущие массовые аггрегаторы отслеживания, обслуживающие многие «отслеживальные» программы для iOS/Android, а так же сайты, где под своим аккаунтом можно держать список своих посылок и гораздо удобнее ориентироваться, что где — это 1% клиентов. Если сравнивать с количеством народу, отправившего/ждущего посылку, то возможно и 1%. А если сравнить с только теми из них, кто самостоятельно лезет в инет для отслеживания, то 1% мне не кажется реальным. Довольно много народу предпочитает отслеживать посылки не через сайт ПР.
>> При чем здесь XML, если вы ранее говорили о протоколе общения с субд?
Протокол общения непосредственно с СУБД ограничен как правило клиентской либой для этой СУБД. Я же говорил о протоколе взаимодействия служб(сервисов, демонов и т.п.) между собой.
В том контексте я говорил о варианте решения, когда есть общая служба, отдающая трекинг «по паролю/ключу», и есть другие службы, типа аггрегаторов, а так же официальная страничка отслеживания, пользующаяся той же службой на общих основаниях. Так вот я говорил, что для взаимодействия этих звеньев между собой XML не нужен.
>> И при чем тут вообще синхронность, и в каком контексте понимать асинхронность?
Синхронность — это когда вы устанавливаете TCP-соединение, шлете туда запрос, получаете ответ, потом шлете следующий запрос, получаете следующий ответ. Вы можете послать туда пачку запросов сразу(буфферизация на уровне TCP), после чего ответы получаете на них последовательно, в том же порядке, в котором уходили запросы. Асинхронность предполагает, что ответы вам могут приходить не обязательно в том же порядке. То есть из пачки запросов более легкие ответы придут раньше, пока сервак все еще переваривает более тяжелые. По факту — принципы многозадачности в действии. И это по одному TCP-соединению. Без необходимости плодить кучу таких соединений на каждый внешний запрос.
>> И как может быть у протокола древовидная структура?
Или вы под XML понимаете не язык разметки текстового документа?
Имеется в виду древовидная структура данных, конечно, передаваемая в пакетах протокола. Читай не «простая табличная организация» данных, а «древовидная без ограничения вложенности». Вы ведь знаете, как устроена внутри сама разметка XML/HTML и какие структуры оно может хранить, да? ))
>> Супер пупер веб страничка банится как досер. А безответственной школоте провайдер блокирует доступ к интернету, до выяснения обстоятельств. [skipped blah-blah-blah]
Вы это серьезно? IT служба ПР должна звонить провайдерам, держать списки забаненных IP, подавать заявы в прокуратуру(вот я ждал, что еще это скажете) и прочее только ради того, что кто-то допустил какую-то синтаксическую ошибку в своем коде? Не проще ли уже известному(через договор и пароль/ключ) клиенту ограничить доступ к системе до устранения ошибки? Зачем держать списки забаненных «неклиентов» конторы, которые а) будут явно больше, чем список клиентов, и б) местоположение вредоносного(или просто кривого) кода может меняться, как и динамический айпишник. Будем банить целые подсети? ))))
>> И да, надежность железа выше надежности самописаного протокола, хотя бы потому, что железо можно зарезервировать, разработчика протокола зарезервировать пока не получилось ни разу.
>> Вот к XML, JSON, YAML есть описание, а к вашему протоколу с древовидной структурой описание есть?
Какого еще железа? Вы XML хардварным методом обрабатываете? И при чем здесь разработчик? На бинарный протокол составляется документ с описанием структуры и все. Никаких проблем с новыми разработчиками. Для клиентов-аггрегаторов можно и в XML транслировать, либо дать готовую клиентскую либу, если нужен для внешнего обмена именно «бинарник». Но все-таки, как раз XML обычно используют только при обмене данными с «внешним миром», где в его универсальности и человекочитабельности есть хотя бы смысл.
У меня такое ощущение, что вы боитесь всего, с чем не сталкивались. Поверьте, не так страшен черт, как вы его себе малюете. Более того, если сравнивать бинарные протоколы и XML по документации, так в XML заморочек еще больше. Кроме того, что «бинарник» может предоставлять абсолютно те же данные в той же структуре, только в машинно-ориентированном виде, без необходимости парсить текст, искать среди неиндексированного текста сами данные(офсеты), жрать излишнюю память и т.п. Хотя конечно, если пользоваться «стандартными» либами, и никогда не заморачиваться как оно работает внутри, что делает, сколько жрет процессора/памяти, способно ли восстановиться при мелких ошибках форматирования и прочее, тогда конечно, можно прикрутить к своему коду генерацию XML за 41 секунду и не париться )))
А еще можно отправлять к серверам ПР запросы «по одному» и тоже не париться по поводу производительности — «с моей стороны пинги вылетели»(с), поэтому это стопудов у них проблема. Я не при делах. Это они обязаны держать нагрузку, а не я оптимизировать что-то. Я же пользуюсь стандартными библиотеками, ага.
Впрочем, на счет экономической эффективности вы в какой-то степени правы. Всегда можно с работы выкинуть человека и нанять другого такого же. Это да.
Вот только… я хотел бы разговаривать все-таки о программистах, а не кодерах.
>> организовать выдачу клиенту XML-ки задача более легкая чем HTML с капчей
Давайте ответим на два вопроса. Первый вопрос: более легкая задача для кого/чего? Для программиста(41 секунда), для сервера? Для которого из серверов: БД или Веб? Или тяжело для сервера генерации капчи(который может быть отдельным)?
А потом ответим на второй вопрос: для какого из перечисленных(или недоперечисленных — мы ж не знаем их внутреннюю кухню) звеньев более важно минимизировать нагрузку?
Далее я не понимаю, почему вы упираете на "2.1. Принимать к обработке треки по одному."
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
>> 3. Клиент не общается с СУБД поэтому клиенту отдается XML. Одно из другого само по себе еще не следует.
Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
>> Возможно спам или ддос.
Ранее о ддос я говорил лишь как о вытекающем при естественной нагрузке. О целенаправленной ддос-атаке я не говорил — это отдельная тема. Серверам ПР и естественной нагрузки на данный момент хватает, чтоб нередко «падать» или «залипать».
>> Это (прим.: речь явно о XML против бинарных протоколов) дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете.
«Владею своими протоколами». При чем протоколы эти асинхронны: запросы на одном TCP-канале не обязаны стоять в очереди и ждать, пока отработает каждый предыдущий. Проблем не знаю. ЧЯДНТ? Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда. В тех местах, где стороннему человеку делать нечего — и XML-ю делать тоже нечего, он там не нужен абсолютно.
>> 2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом.
А почему считаете бредом-то? Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров, то что в этом плохого-то? Что это отсечет либо хотя бы идентифицирует(даст обратную связь, чтоб админы ПР могли связаться и указать что и где поправить) безответственную школоту, случайно зациклившую свою «супер-пупер вебстраничку для отслеживания»? Или вы так боитесь своей деанонимизации? ))))
>> Такая огромная структура как Почта России боится ддоса?
А хрен их знает. С одной стороны в новостях читаешь периодически, сколько денег они тратят на сортировочные центры. С другой — общаешься с девченками в отделениях(даже в МСК) — там зарплаты такие, что даже смеяться стыдно. Что там у них в IT творится — это нужен интрудер, чтоб хоть как-то об этом судить. Так что на вашем месте я бы не применял свое видение, основанное на сидении в конторе, которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед), на структуру типа Почты России. Они явно ограничены в той или иной степени как в компетенции, так и в финансировании.