Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 120
Будем надеяться, что «Почта России» добирается до Хабра с той же скоростью, что и посылки до адресата.
Они мониторят интернет по ключевым словам. Когда я матерюсь на них в титтере или ЖЖ — часто отвечают.
Мониторят, скорее всего, не они сами, а Медиалогия.
Ну это фигня. На мой email, отправленный в конце августа, ответили в конце декабря. У них не только бумажная почта тормозит :)
Видно, что раньше вы посылки не отправляли. У них специальный фирменный бело‐синий (жёлтый для 1‐го класса) скотч с надписями (по крайней мере «почта россии») и, вроде, логотипом (но не у скотча для первого класса — там просто надпись, что это первый класс).
Правда про первый класс не знаю — заматывают ли они им всю посылку или только часть и заматывают ли вообще. Посылки первым классом я не отправлял. Для писем первого класса вместо скотча может быть штампик.
Правда про первый класс не знаю — заматывают ли они им всю посылку или только часть и заматывают ли вообще. Посылки первым классом я не отправлял. Для писем первого класса вместо скотча может быть штампик.
Я помню очень забавная ASCII капча была на кинопоиске (года так 3-4 назад). Цифры капчи состояли из нулей и единиц. Чтобы распознать символ нужно было всего лишь посчитать кол-во единиц на каждой строчке.
Так вот из-за вас, возможно, теперь мне приходится вводиться на сайте почты россии капчу!
И все таки интересно почему так любят у нас вставлять палки в колеса? Почему почта россии не сделает инструмент для всех желающих магазинов и сервисов для удобного отслеживания посылок? Хотя лучше не стоит даже пытаться понять.
И все таки интересно почему так любят у нас вставлять палки в колеса? Почему почта россии не сделает инструмент для всех желающих магазинов и сервисов для удобного отслеживания посылок? Хотя лучше не стоит даже пытаться понять.
ИМХО. Некоторым нужно отличиться не шумной победой, а громким фиаско. Кто чем может, тем и завоевывает внимание людей.
На самом деле у Почты РФ есть API — но не для всех… Чтобы получить доступ к трекеру напрямую — нужно подписать договор с почтой. Но вот мелкие интернет магазины этого сделать не могут, да и доступ им не дают.
Думаю я не первый додумался до парсера трекеров, но моя вина несомненно здесь присутствует.
Так вот из-за вас, возможно, теперь мне приходится вводиться на сайте почты россии капчу!
Думаю я не первый додумался до парсера трекеров, но моя вина несомненно здесь присутствует.
Ну так, на вскидку…
Вряд ли у них сервера расчитаны на большую нагрузку и вряд ли они умеют с этим эффективно бороться. Если контролировать список и количество тех, кто имеет доступ к API(у каждого «легитимного» свой хеш/ключ для доступа к инфе), это какая-никакая защита от DoS атак: не выдавать каждому желающему на каждый запрос полную инфу, не напрягая лишний раз сервера БД. Кроме прочего, те, кто имеет доступ к API, могут кешировать информацию хотя бы малым временем жизни(несколько минут или час к примеру), тем самым тоже снижая нагрузку на сервера ПР от особо нетерпеливых пользователей, присевших на кнопку рефреша в браузере(даже если на рефреш присели на сайте партнера).
На мой взгляд в принципе — это решение. По крайней мере решение данной части проблем с Почтой России. Сервисов отслеживания сейчас уже предостаточно. Необходимость заморочек с договором отсечет несерьезных «отслеживальщиков». Да, это минус, если хочется «самому для себя» написать такой сервис, но если взвесить все плюсы и минусы… ))))
Вряд ли у них сервера расчитаны на большую нагрузку и вряд ли они умеют с этим эффективно бороться. Если контролировать список и количество тех, кто имеет доступ к API(у каждого «легитимного» свой хеш/ключ для доступа к инфе), это какая-никакая защита от DoS атак: не выдавать каждому желающему на каждый запрос полную инфу, не напрягая лишний раз сервера БД. Кроме прочего, те, кто имеет доступ к API, могут кешировать информацию хотя бы малым временем жизни(несколько минут или час к примеру), тем самым тоже снижая нагрузку на сервера ПР от особо нетерпеливых пользователей, присевших на кнопку рефреша в браузере(даже если на рефреш присели на сайте партнера).
На мой взгляд в принципе — это решение. По крайней мере решение данной части проблем с Почтой России. Сервисов отслеживания сейчас уже предостаточно. Необходимость заморочек с договором отсечет несерьезных «отслеживальщиков». Да, это минус, если хочется «самому для себя» написать такой сервис, но если взвесить все плюсы и минусы… ))))
Готов спорить, что обслуживание api менее энергоемкая задача, чем обслуживание html странички с капчей. Заддосить html страничку опять же прощее. В любом случае, список в json весит в разы меньше чем полновесная страничка с этим списком. Да и потом результаты запроса на стороне сервера кешировать проще чем результаты генерации страницы.
Я бы пошел еще более простым путем: всего-то нужно предусмотреть возможность получения по этому адресу xml-ки вместо html. Для решения подобной задачи я в своих проектах трачу… 41 секунду + выкатка на production. И пользователь в адресной строке добавив ".json" получает json вместо html. Вуаля, по результатам мониторгинга нагрузки оказывается, что 200 веб серверов, обслуживающих трекер, уже не нужно, но выросла нагрузка на бд, итого: нужно выпилить 100 веб серверов, потому как слезные банеры с горами сложенных в кучу посылок вызывают больше негодования, чем улыбок, и ссылку на трекер в браузере сохранить в 146 раз проще, чем каждый раз прогружать весь сайт, а добавление 10(условно) бд серверов лугко справятся с обратокой трекера. И никаких api с ssh клучами. Ddos такой странички бесполезен, т.к. погибает в таком случае только один сервис, но не весь ресурс.
Я бы пошел еще более простым путем: всего-то нужно предусмотреть возможность получения по этому адресу xml-ки вместо html. Для решения подобной задачи я в своих проектах трачу… 41 секунду + выкатка на production. И пользователь в адресной строке добавив ".json" получает json вместо html. Вуаля, по результатам мониторгинга нагрузки оказывается, что 200 веб серверов, обслуживающих трекер, уже не нужно, но выросла нагрузка на бд, итого: нужно выпилить 100 веб серверов, потому как слезные банеры с горами сложенных в кучу посылок вызывают больше негодования, чем улыбок, и ссылку на трекер в браузере сохранить в 146 раз проще, чем каждый раз прогружать весь сайт, а добавление 10(условно) бд серверов лугко справятся с обратокой трекера. И никаких api с ssh клучами. Ddos такой странички бесполезен, т.к. погибает в таком случае только один сервис, но не весь ресурс.
Через API я могу запрашивать состояние до 3000 треков за раз, а здесь только одна посылка. если API будет открыт — не думаю что нагрузка станет меньше…
Обрабатывать по одному. Нагрузка, как мне кажется будет меньше, почему я так считаю? habrahabr.ru/post/164903/#comment_5686327
Нет, я про то, что нормальный API позволяет зпрашивать до 3000 треков за раз и когда всем это откроют — сервис однозначно ляжет (а он и так не образец стабильности, я вам доложу). Ну а поштучный API и так открыт (тот же SOAP — http://voh.russianpost.ru:8080/niips-operationhistory-web/OperationHistory?wsdl), просто почему-то, не афишируется…
Поштучный API может быть и на REST реализован, другое дело, что сервер может отрабатывать только GET и только с одним номером трека, а на остальные вопросы отвечать тупо 400. Не суть, на чем это реализовать. С этим справится даже новичок, у которого есть признаки мозга. Тем более, что у них оно реализовано. Однако для обслуживания таблицы с пятью или сколькототам колонками, SOAP возможно даже тяжеловат.
Технически все реализуемо и существует порядка 146 методов реализации данного API под любые нужды и объемы. А то что сервис не образец стабильности… «я не буду сверлить эту стену, потому что у меня руки кривые, стена вертикальная и вообще я боюсь вашего перфоратора. А если я попаду в провод или меня намотает на перфоратор? А?!». Как-то все это… не профессионально, мягко говоря.
Везде где надо работает, а они боятся ддоса. Я даже не знаю какую метафору выбрать для ИТ-директора Почты России — почти все подходят.
А нормальный API должен держать сотни тысяч запросов, а это более чем достижимые цифры без танцев с бубнами и шаманских погремушек.
Технически все реализуемо и существует порядка 146 методов реализации данного API под любые нужды и объемы. А то что сервис не образец стабильности… «я не буду сверлить эту стену, потому что у меня руки кривые, стена вертикальная и вообще я боюсь вашего перфоратора. А если я попаду в провод или меня намотает на перфоратор? А?!». Как-то все это… не профессионально, мягко говоря.
Везде где надо работает, а они боятся ддоса. Я даже не знаю какую метафору выбрать для ИТ-директора Почты России — почти все подходят.
А нормальный API должен держать сотни тысяч запросов, а это более чем достижимые цифры без танцев с бубнами и шаманских погремушек.
Я не очень понял смысл вашего послания. Я разве где-то говорил, что API должен быть в HTML-виде, что должны быть ssh-ключи, или что-то подобное? Я вообще о реализации конкретики где-то что-то упоминал? Почему вы за меня это додумали и критикуете эту «выдуманную» часть?
Но если хотите, мы поговорим и об этом.
Есть фактически две разные задачи: контролировать нагрузку на БД и дать доступ извне к отслеживанию отправлений, включая доступ к «публичному или не очень» API.
И как раз более целесообразно в первую очередь контролировать нагрузку на БД. Для этого можно сделать общий API доступа к запросам инфы по посылкам _только_ по «партнерскому паролю». Я бы в это звено никаких XML не пускал бы — XML является human-readable стандартом, для межсерверного общения он отнюдь не снижает нагрузку — его же еще парсить надо. И ваши «я в своих проектах трачу… 41 секунду» очень похожи на московское «я сделал ремонт у себя в квартире», это когда данная фраза фактически в подавляющем большинстве случаев означает «я только заплатил», а не «я его реально сделал сам». То есть ваша фраза всего лишь одначает, что вы вписываете пару строчек, которые вызывают либо некий кусок чужого кода, либо вами же ранее написанного(тогда вы уже лукавите — не честную 41 секунду тратите), который и формирует на выходе XML.
В общем, для общения с БД я ввел бы binary-протокол, более быстрый и легкий для машинной обработки, чем любые ваши XML.
А уж далее ставится один или несколько серверов с доступом извне, которые и будут обслуживать непосредственно клиентов, будут им предоставлять уже более удобный API на базе XML или любой human-readable структуры, но которые по сути будут только тем и заниматься, что выполнять преобразования binary<->xml, первично проверяя легитимность доступа, отсекая явно спуффинговые запросы(с различного рода ошибками и несоответствиями) и являющиеся как раз теми буфферами, каждый из которых может «упасть» без особых последствий для всех остальных узлов системы. На них же можно возложить задачу кеширования инфы из БД, дабы один и тот же трек не спрашивать у БД чаще, чем раз в N минут. И к ним же можно прикрутить средства сбора статистики, чтоб мониторить и понимать, «чего сервисам не хватает».
Так вот. Если сделать эту систему, тогда можно начинать раздавать доступ к API в том виде, в котором это сделано сейчас — пусть по договору(пусть даже по формальному бесплатному), пусть с выдачей ключей/паролей каждому «партнеру» и т.п. В таком случае страничка отслеживания на сайте ПР(которая с капчей и о которой в данном топике речь идет изначально) может быть технически реализована, как еще один «партнер» — то есть выдать этой страничке свой ключ и пусть она запрашивает внутри себя тот же самый API на общих основаниях.
P.S. И никаких ssh, ssl и подобных систем аля «пара открытый/закрытый ключ». Все знают, на сколько тупит HTTPS протокол против нешифрованного HTTP. Нафиг это надо — такие лаги, и такая нагрузка на процессорные ядра в задаче, где та сверхнадежность, которую они предоставляют — нафиг не нужна.
P.P.S. qnub вам все правильно написал — если открыть публичный доступ к API, «жадность» массовых отслеживальщиков не будет знать предела, поэтому будут и по 3000 и по 5000 номеров запрашивать за раз. И эти «разы» будут частенько повторяться.
Поэтому как обычный юзер, я тоже думаю «вот сволочи, закрыли мне возможность сделать себе удобное отслеживание», но как системный программер, я их вполне поддерживаю в данном вопросе. А там посмотрим, доведут ли они эту систему до ума, или будем их еще песочить в дальнейшем.
Но если хотите, мы поговорим и об этом.
Есть фактически две разные задачи: контролировать нагрузку на БД и дать доступ извне к отслеживанию отправлений, включая доступ к «публичному или не очень» API.
И как раз более целесообразно в первую очередь контролировать нагрузку на БД. Для этого можно сделать общий API доступа к запросам инфы по посылкам _только_ по «партнерскому паролю». Я бы в это звено никаких XML не пускал бы — XML является human-readable стандартом, для межсерверного общения он отнюдь не снижает нагрузку — его же еще парсить надо. И ваши «я в своих проектах трачу… 41 секунду» очень похожи на московское «я сделал ремонт у себя в квартире», это когда данная фраза фактически в подавляющем большинстве случаев означает «я только заплатил», а не «я его реально сделал сам». То есть ваша фраза всего лишь одначает, что вы вписываете пару строчек, которые вызывают либо некий кусок чужого кода, либо вами же ранее написанного(тогда вы уже лукавите — не честную 41 секунду тратите), который и формирует на выходе XML.
В общем, для общения с БД я ввел бы binary-протокол, более быстрый и легкий для машинной обработки, чем любые ваши XML.
А уж далее ставится один или несколько серверов с доступом извне, которые и будут обслуживать непосредственно клиентов, будут им предоставлять уже более удобный API на базе XML или любой human-readable структуры, но которые по сути будут только тем и заниматься, что выполнять преобразования binary<->xml, первично проверяя легитимность доступа, отсекая явно спуффинговые запросы(с различного рода ошибками и несоответствиями) и являющиеся как раз теми буфферами, каждый из которых может «упасть» без особых последствий для всех остальных узлов системы. На них же можно возложить задачу кеширования инфы из БД, дабы один и тот же трек не спрашивать у БД чаще, чем раз в N минут. И к ним же можно прикрутить средства сбора статистики, чтоб мониторить и понимать, «чего сервисам не хватает».
Так вот. Если сделать эту систему, тогда можно начинать раздавать доступ к API в том виде, в котором это сделано сейчас — пусть по договору(пусть даже по формальному бесплатному), пусть с выдачей ключей/паролей каждому «партнеру» и т.п. В таком случае страничка отслеживания на сайте ПР(которая с капчей и о которой в данном топике речь идет изначально) может быть технически реализована, как еще один «партнер» — то есть выдать этой страничке свой ключ и пусть она запрашивает внутри себя тот же самый API на общих основаниях.
P.S. И никаких ssh, ssl и подобных систем аля «пара открытый/закрытый ключ». Все знают, на сколько тупит HTTPS протокол против нешифрованного HTTP. Нафиг это надо — такие лаги, и такая нагрузка на процессорные ядра в задаче, где та сверхнадежность, которую они предоставляют — нафиг не нужна.
P.P.S. qnub вам все правильно написал — если открыть публичный доступ к API, «жадность» массовых отслеживальщиков не будет знать предела, поэтому будут и по 3000 и по 5000 номеров запрашивать за раз. И эти «разы» будут частенько повторяться.
Поэтому как обычный юзер, я тоже думаю «вот сволочи, закрыли мне возможность сделать себе удобное отслеживание», но как системный программер, я их вполне поддерживаю в данном вопросе. А там посмотрим, доведут ли они эту систему до ума, или будем их еще песочить в дальнейшем.
Смысл моего послания в том, что организовать выдачу клиенту XML-ки задача более легкая чем HTML с капчей, а отсюда я смысла в HTML-ке с капчей не вижу никакого. Смотрите сами, из каких соображений:
1. Сейчас трек реализован на HTML. Это дорого.
2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом. Такая огромная структура как Почта России боится ддоса?
Отсюда:
2.1. Принимать к обработке треки по одному.
2.2. Борьба с ддосом происходит не на уровне веб сервера отдающего XML. Т.о. сервис просто должен быть способен выдержать серьезную нагрузку. Скажем одного физического DL320 должно хватить на обработку до миллиона запросов в секунду.
2.3. Не силен в проектировании СУБД но предположу, что даже один физический экземпляр MySQL справится с выборкой 300-400 тыс записей по ключу.
В итоге, на хорошем оборудовании заддосить такую систему будет проблематично, точнее оно все равно будет отвечать, с задержкой, но будет.
3. Клиент не общается с СУБД поэтому клиенту отдается XML. В технические сложности общения между сервером приложений и сервером баз данных вдаваться не хочу, тем более писать свой протокол общения. Не такая уж и энергоемкая задача, чтобы заниматься ее разработкой и поддержкой. А поскольку все универсальные инструменты решающие нашу задачу уже изобретены, но тяжелы в угоду универсальности, зато надежны, то я бы просто блейд в корзинку добавил. Это дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете. Мне так кажется.
4. Да я решаю задачу формата выдачи данных за считанные секунды. На девелоперсокй машине строчка кода которую я добавлю будет обрабатывать до 1000 запросов в секунду в один поток.(включая обмен данными с СУБД). Production без оптимизации, сразу после добавления строчки… в районе 100000 запросов. Это вовсе не значит, что у меня на production 100 ядер :). И это не эффективный вариант.
Такой свервер доступен у любого хостинг провайдера и стоит в районе 8к рублей в месяц. Для Почты — это копейки. Более оптимальные решения на более быстром (чем мой Ruby on Rails) PHP или еще на более быстром Erlang займут у меня 24 часа, так долго потому, что я не ерланга на пхп не знаю. И на нормальном выделенном сервере мы вероятнее раньше упремся, как вы верно заметили, в производительность веб сервер или в производительность сервера баз данных, нежели в производительность сервера приложения.
И ни каких ssh, ssl и т.п.
А как веб программист, я все же считаю, что обслуживать выдачу HTML с капчей дороже и чем XML.
Даже если я не прав в своих предположениях, никогда не поверю в то, что перед отдачей клиенту Почтой России трека могут стоять какие-то капчи, призванные бороться с ветряными мельницами. Смешно до коликов.
1. Сейчас трек реализован на HTML. Это дорого.
2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом. Такая огромная структура как Почта России боится ддоса?
Отсюда:
2.1. Принимать к обработке треки по одному.
2.2. Борьба с ддосом происходит не на уровне веб сервера отдающего XML. Т.о. сервис просто должен быть способен выдержать серьезную нагрузку. Скажем одного физического DL320 должно хватить на обработку до миллиона запросов в секунду.
2.3. Не силен в проектировании СУБД но предположу, что даже один физический экземпляр MySQL справится с выборкой 300-400 тыс записей по ключу.
В итоге, на хорошем оборудовании заддосить такую систему будет проблематично, точнее оно все равно будет отвечать, с задержкой, но будет.
3. Клиент не общается с СУБД поэтому клиенту отдается XML. В технические сложности общения между сервером приложений и сервером баз данных вдаваться не хочу, тем более писать свой протокол общения. Не такая уж и энергоемкая задача, чтобы заниматься ее разработкой и поддержкой. А поскольку все универсальные инструменты решающие нашу задачу уже изобретены, но тяжелы в угоду универсальности, зато надежны, то я бы просто блейд в корзинку добавил. Это дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете. Мне так кажется.
4. Да я решаю задачу формата выдачи данных за считанные секунды. На девелоперсокй машине строчка кода которую я добавлю будет обрабатывать до 1000 запросов в секунду в один поток.(включая обмен данными с СУБД). Production без оптимизации, сразу после добавления строчки… в районе 100000 запросов. Это вовсе не значит, что у меня на production 100 ядер :). И это не эффективный вариант.
Такой свервер доступен у любого хостинг провайдера и стоит в районе 8к рублей в месяц. Для Почты — это копейки. Более оптимальные решения на более быстром (чем мой Ruby on Rails) PHP или еще на более быстром Erlang займут у меня 24 часа, так долго потому, что я не ерланга на пхп не знаю. И на нормальном выделенном сервере мы вероятнее раньше упремся, как вы верно заметили, в производительность веб сервер или в производительность сервера баз данных, нежели в производительность сервера приложения.
И ни каких ssh, ssl и т.п.
А как веб программист, я все же считаю, что обслуживать выдачу HTML с капчей дороже и чем XML.
Даже если я не прав в своих предположениях, никогда не поверю в то, что перед отдачей клиенту Почтой России трека могут стоять какие-то капчи, призванные бороться с ветряными мельницами. Смешно до коликов.
Я отвечу в разнобой, ладно?
>> организовать выдачу клиенту XML-ки задача более легкая чем HTML с капчей
Давайте ответим на два вопроса. Первый вопрос: более легкая задача для кого/чего? Для программиста(41 секунда), для сервера? Для которого из серверов: БД или Веб? Или тяжело для сервера генерации капчи(который может быть отдельным)?
А потом ответим на второй вопрос: для какого из перечисленных(или недоперечисленных — мы ж не знаем их внутреннюю кухню) звеньев более важно минимизировать нагрузку?
Далее я не понимаю, почему вы упираете на "2.1. Принимать к обработке треки по одному."
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
>> 3. Клиент не общается с СУБД поэтому клиенту отдается XML. Одно из другого само по себе еще не следует.
Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
>> Возможно спам или ддос.
Ранее о ддос я говорил лишь как о вытекающем при естественной нагрузке. О целенаправленной ддос-атаке я не говорил — это отдельная тема. Серверам ПР и естественной нагрузки на данный момент хватает, чтоб нередко «падать» или «залипать».
>> Это (прим.: речь явно о XML против бинарных протоколов) дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете.
«Владею своими протоколами». При чем протоколы эти асинхронны: запросы на одном TCP-канале не обязаны стоять в очереди и ждать, пока отработает каждый предыдущий. Проблем не знаю. ЧЯДНТ? Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда. В тех местах, где стороннему человеку делать нечего — и XML-ю делать тоже нечего, он там не нужен абсолютно.
>> 2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом.
А почему считаете бредом-то? Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров, то что в этом плохого-то? Что это отсечет либо хотя бы идентифицирует(даст обратную связь, чтоб админы ПР могли связаться и указать что и где поправить) безответственную школоту, случайно зациклившую свою «супер-пупер вебстраничку для отслеживания»? Или вы так боитесь своей деанонимизации? ))))
>> Такая огромная структура как Почта России боится ддоса?
А хрен их знает. С одной стороны в новостях читаешь периодически, сколько денег они тратят на сортировочные центры. С другой — общаешься с девченками в отделениях(даже в МСК) — там зарплаты такие, что даже смеяться стыдно. Что там у них в IT творится — это нужен интрудер, чтоб хоть как-то об этом судить. Так что на вашем месте я бы не применял свое видение, основанное на сидении в конторе, которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед), на структуру типа Почты России. Они явно ограничены в той или иной степени как в компетенции, так и в финансировании.
>> организовать выдачу клиенту XML-ки задача более легкая чем HTML с капчей
Давайте ответим на два вопроса. Первый вопрос: более легкая задача для кого/чего? Для программиста(41 секунда), для сервера? Для которого из серверов: БД или Веб? Или тяжело для сервера генерации капчи(который может быть отдельным)?
А потом ответим на второй вопрос: для какого из перечисленных(или недоперечисленных — мы ж не знаем их внутреннюю кухню) звеньев более важно минимизировать нагрузку?
Далее я не понимаю, почему вы упираете на "2.1. Принимать к обработке треки по одному."
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
>> 3. Клиент не общается с СУБД поэтому клиенту отдается XML. Одно из другого само по себе еще не следует.
Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
>> Возможно спам или ддос.
Ранее о ддос я говорил лишь как о вытекающем при естественной нагрузке. О целенаправленной ддос-атаке я не говорил — это отдельная тема. Серверам ПР и естественной нагрузки на данный момент хватает, чтоб нередко «падать» или «залипать».
>> Это (прим.: речь явно о XML против бинарных протоколов) дешевле и надежнее, чем владеть своим протоколом, со своими блекджеками и… ну вы знаете.
«Владею своими протоколами». При чем протоколы эти асинхронны: запросы на одном TCP-канале не обязаны стоять в очереди и ждать, пока отработает каждый предыдущий. Проблем не знаю. ЧЯДНТ? Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда. В тех местах, где стороннему человеку делать нечего — и XML-ю делать тоже нечего, он там не нужен абсолютно.
>> 2. Что может остановить Почту от открытия свободного API? Возможно спам или ддос. Видимо поэтому введены всякие договора. Лично я считаю это бредом.
А почему считаете бредом-то? Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров, то что в этом плохого-то? Что это отсечет либо хотя бы идентифицирует(даст обратную связь, чтоб админы ПР могли связаться и указать что и где поправить) безответственную школоту, случайно зациклившую свою «супер-пупер вебстраничку для отслеживания»? Или вы так боитесь своей деанонимизации? ))))
>> Такая огромная структура как Почта России боится ддоса?
А хрен их знает. С одной стороны в новостях читаешь периодически, сколько денег они тратят на сортировочные центры. С другой — общаешься с девченками в отделениях(даже в МСК) — там зарплаты такие, что даже смеяться стыдно. Что там у них в IT творится — это нужен интрудер, чтоб хоть как-то об этом судить. Так что на вашем месте я бы не применял свое видение, основанное на сидении в конторе, которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед), на структуру типа Почты России. Они явно ограничены в той или иной степени как в компетенции, так и в финансировании.
>> Для которого из серверов: БД или Веб?
Для веб, БД сервер учавствует в выдаче трека и в том и в другом случае.
Отдельный сервер генерации капчи тоже стоит денег. Если отдавать XML менее ресурсоемкая задача, чем генерировать HTML, то сервер капчи может быть вообще не нужен?
Минимизация нагрузки на сервер БД, не решается капчами :) Капча лишь препятствует получению трека.
>> Далее я не понимаю, почему вы упираете на «2.1. Принимать к обработке треки по одному.»
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
Тому кто должен видеть HTML не нужен XML.
>> Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
Такой метод эффективнее, если запрос идет по области. Запросы по уникальным параметрам теоретически займут столько же времени. Экономия будет разве что на этапе обработки запроса, упаковки и отправки. Открывать дыру для потенциального перегруза сервера базы данных только для того, чтобы 1% клиентов мог запросить более одного трека — не целесообразно.
>> Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда.
Чота я запутался.
В XML нет текстового парсинга, парсить нужно при приемке данных, но не при отправке.
Любое текстовое сообщение придется парсить.
При чем здесь XML, если вы ранее говорили о протоколе общения с субд?
И при чем тут вообще синхронность, и в каком контексте понимать асинхронность? И как может быть у протокола древовидная структура?
Или вы под XML понимаете не язык разметки текстового документа?
>> Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров?
Шутите? минимальный бюракратический гемор и Почта России не могут быть локализованы в одном пространстве-времени, либо не могу наблюдаться локальной измерительной системой — человеком. Оптимизация бюракратического механизма стоит дороже, чем обеспечение обработки формата данных в запросе, именно поэтому в таком случае организация дополнительной бюрократии, чтобы без капчи получать трек — бред.
Супер пупер веб страничка банится как досер. А безответственной школоте провайдер блокирует доступ к интернету, до выяснения обстоятельств. Т.о. безотвественность школоты лечится раз и на всегда, без нанесения тяжких телесных повреждений, без лишения свободы, без нанесения материального вреда, а просто строгим звонком технической службой с требованием прекратить злодеяния во избежании. 146 раз школота подумает, прежде чем создаст рецидив. Деанонимизации я не боюсь, у меня даже телефон в профиле в свободном доступе, могли бы и проверить перед предъявлением подозрений :)
>> которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед)
Вот некрасиво на личности переходить.
XML — один из примеров реализации языка разметки. Это может быть JSON, YAML, это может быть строка с разделителями в виде \t и \n. Вот к XML, JSON, YAML есть описание, а к вашему протоколу с древовидной структурой описание есть? А разрешите ознакомиться? А HTML от XML чем принципиально отличается для «вычислительных мощностей», в HTML тоже жуткий парсинг и оверхед.
И да, надежность железа выше надежности самописаного протокола, хотя бы потому, что железо можно зарезервировать, разработчика протокола зарезервировать пока не получилось ни разу.
Да и в случае с компенсацией железом человеческих симпатий, я не забываю про экономическую эффективность. Если человеческие симпатии экономически неэффективны, то проще с человеком попрощаться.
А зарплаты на почте такие, потому, что люди согласны работать за такие зарплаты, спрос <-> предложение. И экономически неэффективных симпатий, которые не заткнуть никаким железом, у них очень много :)
Для веб, БД сервер учавствует в выдаче трека и в том и в другом случае.
Отдельный сервер генерации капчи тоже стоит денег. Если отдавать XML менее ресурсоемкая задача, чем генерировать HTML, то сервер капчи может быть вообще не нужен?
Минимизация нагрузки на сервер БД, не решается капчами :) Капча лишь препятствует получению трека.
>> Далее я не понимаю, почему вы упираете на «2.1. Принимать к обработке треки по одному.»
Принятие запросов «по одному» предполагает, что инфу по трекам мы отдаем только клиенту-человеку, зашедшему на сайт. Нахрена ему XML, если он в конечном итоге так или иначе должен видеть HTML?
Тому кто должен видеть HTML не нужен XML.
>> Если же мы предполагаем отдачу XML не физическому клиенту, а аггрегатору-партнеру(читай стороннему сервису отслеживания), то обрабатывать «по хрен знает сколько треков за раз» уже гораздо оптимальнее, чем эти «хрен знает сколько» треков он будет запрашивать «по одному». Транзакционный механизм при запросе сразу пачки(выборки) работает гораздо эффективнее, чем если эту пачку разбить на одиночные запросы.
Такой метод эффективнее, если запрос идет по области. Запросы по уникальным параметрам теоретически займут столько же времени. Экономия будет разве что на этапе обработки запроса, упаковки и отправки. Открывать дыру для потенциального перегруза сервера базы данных только для того, чтобы 1% клиентов мог запросить более одного трека — не целесообразно.
>> Структура такая же древовидная, как XML, только без текстового парсинга и оверхеда.
Чота я запутался.
В XML нет текстового парсинга, парсить нужно при приемке данных, но не при отправке.
Любое текстовое сообщение придется парсить.
При чем здесь XML, если вы ранее говорили о протоколе общения с субд?
И при чем тут вообще синхронность, и в каком контексте понимать асинхронность? И как может быть у протокола древовидная структура?
Или вы под XML понимаете не язык разметки текстового документа?
>> Если в конечном итоге они сделают бесплатную регистрацию и минимальный бюрократический гемор в оформлении этих договоров?
Шутите? минимальный бюракратический гемор и Почта России не могут быть локализованы в одном пространстве-времени, либо не могу наблюдаться локальной измерительной системой — человеком. Оптимизация бюракратического механизма стоит дороже, чем обеспечение обработки формата данных в запросе, именно поэтому в таком случае организация дополнительной бюрократии, чтобы без капчи получать трек — бред.
Супер пупер веб страничка банится как досер. А безответственной школоте провайдер блокирует доступ к интернету, до выяснения обстоятельств. Т.о. безотвественность школоты лечится раз и на всегда, без нанесения тяжких телесных повреждений, без лишения свободы, без нанесения материального вреда, а просто строгим звонком технической службой с требованием прекратить злодеяния во избежании. 146 раз школота подумает, прежде чем создаст рецидив. Деанонимизации я не боюсь, у меня даже телефон в профиле в свободном доступе, могли бы и проверить перед предъявлением подозрений :)
>> которая может докупкой железа компенсировать ваши симпатии к XML(который оптимален для человека, но абсолютно ресурсозатратен для вычислительных мощностей — парсинг и жуткий оверхед)
Вот некрасиво на личности переходить.
XML — один из примеров реализации языка разметки. Это может быть JSON, YAML, это может быть строка с разделителями в виде \t и \n. Вот к XML, JSON, YAML есть описание, а к вашему протоколу с древовидной структурой описание есть? А разрешите ознакомиться? А HTML от XML чем принципиально отличается для «вычислительных мощностей», в HTML тоже жуткий парсинг и оверхед.
И да, надежность железа выше надежности самописаного протокола, хотя бы потому, что железо можно зарезервировать, разработчика протокола зарезервировать пока не получилось ни разу.
Да и в случае с компенсацией железом человеческих симпатий, я не забываю про экономическую эффективность. Если человеческие симпатии экономически неэффективны, то проще с человеком попрощаться.
А зарплаты на почте такие, потому, что люди согласны работать за такие зарплаты, спрос <-> предложение. И экономически неэффективных симпатий, которые не заткнуть никаким железом, у них очень много :)
>> Если отдавать 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 секунду и не париться )))
А еще можно отправлять к серверам ПР запросы «по одному» и тоже не париться по поводу производительности — «с моей стороны пинги вылетели»(с), поэтому это стопудов у них проблема. Я не при делах. Это они обязаны держать нагрузку, а не я оптимизировать что-то. Я же пользуюсь стандартными библиотеками, ага.
Впрочем, на счет экономической эффективности вы в какой-то степени правы. Всегда можно с работы выкинуть человека и нанять другого такого же. Это да.
Вот только… я хотел бы разговаривать все-таки о программистах, а не кодерах.
Да с какого перепуга? Физическому клиенту так или иначе нужно показывать 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, либ, комьюнити и прочего — мы с вами просто разные. Я не могу придерживаться стремления внедрять XML, .Net и подобные технологии где ни попадя. Особенно там, где они не нужны, и выполняют только функцию универсализации и удобства программисту, давая системе кучу лишнего оверхеда в виде жора процессора и памяти. И варианты «пофиг, компенсируем наращиванием вычислительных мощностей, благо они не дороги сейчас» меня тоже коробят.
Наверное я старомоден. Привык экономить байты среди гигабайтов )))
В крайнем случае по нашему контексту есть еще одна схема решения: у многих SMS-провайдеров рассылки отправлять можно как из личного кабинета, так и еще несколькими способами — загружать списки отправки обычным POST-запросом, XML-файлом, и самым бинарным из них — работать со шлюзом напрямую по SMPP протоколу. Я выбрал SMPP, при чем никаких чужих либ не использовал. Все, что мне надо, стараюсь писать сам и на самом низком уровне — так лучше контроль, где что происходит. Однако понимаю, что то, что проще мне, вовсе не обязательно проще другим. Зато в случае каких-либо проблем я смогу быстро локализовать и исправить ошибку, а не сыпать отмазками, что это разработчики какой-то там либы виноваты и ждать с моря погоды либо ковыряться в чужом коде.
На счет перехода на личности вы передергиваете. Мы общаемся лично с вами и какие-то предположения я делаю исключительно по вашим утверждениям. Я не могу обобщать, не зная мнения других по этому поводу, потому и происходит то, что вам кажется переходом на личности.
По поводу XML, либ, комьюнити и прочего — мы с вами просто разные. Я не могу придерживаться стремления внедрять XML, .Net и подобные технологии где ни попадя. Особенно там, где они не нужны, и выполняют только функцию универсализации и удобства программисту, давая системе кучу лишнего оверхеда в виде жора процессора и памяти. И варианты «пофиг, компенсируем наращиванием вычислительных мощностей, благо они не дороги сейчас» меня тоже коробят.
Наверное я старомоден. Привык экономить байты среди гигабайтов )))
В крайнем случае по нашему контексту есть еще одна схема решения: у многих SMS-провайдеров рассылки отправлять можно как из личного кабинета, так и еще несколькими способами — загружать списки отправки обычным POST-запросом, XML-файлом, и самым бинарным из них — работать со шлюзом напрямую по SMPP протоколу. Я выбрал SMPP, при чем никаких чужих либ не использовал. Все, что мне надо, стараюсь писать сам и на самом низком уровне — так лучше контроль, где что происходит. Однако понимаю, что то, что проще мне, вовсе не обязательно проще другим. Зато в случае каких-либо проблем я смогу быстро локализовать и исправить ошибку, а не сыпать отмазками, что это разработчики какой-то там либы виноваты и ждать с моря погоды либо ковыряться в чужом коде.
Следуя такой логике — пункты приема посылок надо тщательно маскировать и ни кому не говорить где они, тем самым снизим поток посылок (своеобразный перманентный DDOS), тем самым решим еще часть проблема Почты России.
А не надо передергивать и сравнивать зеленое с теплым. Ввод капчи или других методов борьбы со сторонними массовыми запросами — не эквивалент маскировки пунктов выдачи. У вас не отобрали возможность отследить посылку. Отобрали только возможность генерить неконтролируемый трафик, создавая *свои* механизмы массового отслеживания. Ладно я бы еще понял ваши претензии, если б капча была нераспознаваемой.
Механизмы массового отслеживания нужны в случаях затруднения получения информации прямыми путями. Для решения таких задач всякие разные RSS-ы придумали еще до большого потопа. Метафора с маскировкой пунктов приема посылок мне очень нравится :)
>> Механизмы массового отслеживания нужны в случаях затруднения получения информации прямыми путями.
Если грабли случились где-то на внутренних звеньях системы, «массовые механизмы» лягут рядом с «прямыми путями». Так что не аргумент. Особенно в свете предложенного вами ранее способа "И пользователь в адресной строке добавив ".json" получает json вместо html.". Тут очевидно источник информации один и тот же, поэтому в случае проблем автоматом «лягут» оба способа.
А то знаете ли, бесплатный Windows тоже окажется нужен, если опросить кучу народа, но Майкрософт чего-то не спешит его раздавать )
Так же и ПР — им-то конечно, в отличии от редмондцев, не деньги зарабатывать на отслеживании — это изначально бесплатная услуга. Но при текущем раскладе с нагрузкой и ее последствиями раздавать всем желающим открытые механизмы падения серверов им явно не выгодно.
Если грабли случились где-то на внутренних звеньях системы, «массовые механизмы» лягут рядом с «прямыми путями». Так что не аргумент. Особенно в свете предложенного вами ранее способа "И пользователь в адресной строке добавив ".json" получает json вместо html.". Тут очевидно источник информации один и тот же, поэтому в случае проблем автоматом «лягут» оба способа.
А то знаете ли, бесплатный Windows тоже окажется нужен, если опросить кучу народа, но Майкрософт чего-то не спешит его раздавать )
Так же и ПР — им-то конечно, в отличии от редмондцев, не деньги зарабатывать на отслеживании — это изначально бесплатная услуга. Но при текущем раскладе с нагрузкой и ее последствиями раздавать всем желающим открытые механизмы падения серверов им явно не выгодно.
Я оплачиваю почтовое отправление, а поскольку живу в двадцать первом веке, то ожидаю привычный современный сервис. Импотенция ПР оправдана только монополией. Такого рода бесплатные сервисы — маркетинговые издержки, которые при правильном подходе окупаются сторицей.
Autodesk, для студентов предоставляет чуть менее чем полный перечень своих продуктов бесплатно, сам пользовался.
Adobe распространяет пакет CS2 бесплатно.
А стояли эти десктопные пакеты значительно дороже чем все десктопные windows всех версий вместе взятые.
А Microsoft такойже не userfriendly монополист как и ПР.
У меня складывается ощущение, что неспособность реализовать простой сервис в ПР связана не с техническими трудностями, которые решаемы, а с жадностью и неумением считать маркетинговую выгоду.
Реши UPS захватить почтовый рынок в России — ПР капитулирует без боя.
Autodesk, для студентов предоставляет чуть менее чем полный перечень своих продуктов бесплатно, сам пользовался.
Adobe распространяет пакет CS2 бесплатно.
А стояли эти десктопные пакеты значительно дороже чем все десктопные windows всех версий вместе взятые.
А Microsoft такойже не userfriendly монополист как и ПР.
У меня складывается ощущение, что неспособность реализовать простой сервис в ПР связана не с техническими трудностями, которые решаемы, а с жадностью и неумением считать маркетинговую выгоду.
Реши UPS захватить почтовый рынок в России — ПР капитулирует без боя.
Посоветую ещё освоиться с OpenCV, если хотите продолжать развиваться в этом направлении (кода выйдет меньше и работать будет в несколько раз быстрее).
Можно написать модуль для PHP на C++ с использованием OpenCV, будет быстрее в разы
Год назад была делема, на чем писать API сервис с модулей распознования. Так как за все это отвечал наш отдел, то конечно сначала долго и упорно выбор склонялся к PHP (Есть под PHP Биндинг OpenCV). Но затем все же было решено что проще будет весь сервис реализовать на ASP.NET MVC + EMGU (все собирается под Mono, при должном желании можно задеплоить и никсах).
Как вариант еще был реализация API На питоне, и как по мне это был бы самый простой вариант. Но к сожалению на тот момент питон я знал лишь на уровне простых структур.
А извращения с экстеншенами на PHP я лично считаю глупой затеей. Да, иногда это профитно, но я вижу в этом смысл только в рамках уже существующего проекта, который переписывать будет дороже чем возиться со своими экстеншенами.
Как вариант еще был реализация API На питоне, и как по мне это был бы самый простой вариант. Но к сожалению на тот момент питон я знал лишь на уровне простых структур.
А извращения с экстеншенами на PHP я лично считаю глупой затеей. Да, иногда это профитно, но я вижу в этом смысл только в рамках уже существующего проекта, который переписывать будет дороже чем возиться со своими экстеншенами.
Почта РФ на каникулах, походу. посылка торчит с 25.12 в Москве
Мою посылку вечером 31 декабря отправили с Казанского вокзала, а 2 января она прилетела в Пулково :)
Это её штатный режим работы, всё нормально.
Мои посылки из Гонкога отслеживаюся только после того как я их получу. Это новый способ торможения у почты России.
У меня недавно была такая проблема, что посылка из штатов отслеживалась на иностранных сайтах, но отслеживалась на сайте Почты России или сайте ЕМС. На сайте usps указывалось, что даже попытка вручения была, а у Почты России даже такого трекинга в базе не было. Я уже позвонил в ЕМС, так как отправили мне через express mail international, оператор меня отшила, только успев я сказать две буквы отправления, мол такие посылки они возят. На Почте России сказали, что если нет в базе, то нет на территории страны. А на следующий день мне вручили посылку в отделении ЕМС. И если б она потерялась, то я бы не смог подать заявление на розыск. За лет 5 посылок ни разу такого не было.
Еще одна посылка из штатов была отправлена в Россию 21 декабря и только вчера засветилась в трекинге у таможни.
Еще одна посылка из штатов была отправлена в Россию 21 декабря и только вчера засветилась в трекинге у таможни.
У меня недавно была такая проблема, что посылка из штатов отслеживалась на иностранных сайтах, но отслеживалась на сайте Почты России или сайте ЕМС.
Я уже позвонил в ЕМС, так как отправили мне через express mail international, оператор меня отшила, только успев я сказать две буквы отправления, мол такие посылки они возят.
Безумно хотел понять смысл. Прочитал раз, прочитал два, прочитал три.
Может это во мне дело и я не могу понять смысл. Можете по-подробнее расписать?
Дико понравился пост, спасибо!
так вот из-за кого лежит сайт почты постоянно, с 502.
Если бы они сделали нормальный API вместо детских каптч, ничего бы не лежало
Что-то мне подсказывает, что сайт ПР лежит из-за ПР. Они, как это водится, решили несуществующую проблему, сломав работающий сайт. До введения капчи сайт ПР ложился гораздо реже.
И что особенно мило — это их анонсы своихговнововведений и фэйлов
CAPTCHA защитит клиентов Почты России от роботов
Сайт, лежавший три дня был списан на атаку «хакеров».
Что характерно, с сайта снесли текст этой «новости» и убрали ее из поиска, чтобы не позориться
www.russianpost.ru/resp_engine.aspx?Path=RP/INDEX/RU/Home/Search&keyword=%D0%A5%D0%B0%D0%BA%D0%B5%D1%80%D1%8B
www.russianpost.ru/resp_engine.aspx?Path=RP/INDEX/RU/Home/Search&keyword=%D0%A5%D0%B0%D0%BA%D0%B5%D1%80%D1%8B
А казалось бы — сделай время прохождения посылок в рамках разумного — и роботов таких писать-то не будут.
И что особенно мило — это их анонсы своих
CAPTCHA защитит клиентов Почты России от роботов
Сайт, лежавший три дня был списан на атаку «хакеров».
Что характерно, с сайта снесли текст этой «новости» и убрали ее из поиска, чтобы не позориться
www.russianpost.ru/resp_engine.aspx?Path=RP/INDEX/RU/Home/Search&keyword=%D0%A5%D0%B0%D0%BA%D0%B5%D1%80%D1%8B
www.russianpost.ru/resp_engine.aspx?Path=RP/INDEX/RU/Home/Search&keyword=%D0%A5%D0%B0%D0%BA%D0%B5%D1%80%D1%8B
А казалось бы — сделай время прохождения посылок в рамках разумного — и роботов таких писать-то не будут.
Когда-то недавно заходил в трекинг и наблюдал такую картину: грузится «пустая» страница, на которой javascript-ом идёт расшифровка каких-то данных, а потом через время переход на нужную страницу. Подобное поведение проявлялось случайным образом, иногда было, иногда нет. При этом время задержки такое большое, что в большинстве случаев казалось, что сайт просто не работает. Так что до страницы трекинга иногда ещё и добраться надо…
Скришоты процесса работы были сделаны специальной программой — которая выборочно вставляет свой логотип на скриншоты, обращать на него внимание не стоит.
А как же PrintScreen? И да, логотип программы случайным образом совпал с вашей аватаркой) Не пиар ли?
Нет, это не пиар, а простая упрощенна и классная программа в стиле printScreen
да и зачем вообще было код картинками вставлять…
Программа nShots — мною написана, поэтому и водяной знак там схож с моей аватаркой. PrtSc — не удобно, нужно сохранить, потом загрузить, а там всё сразу…
А зачем вообще лепить водяной знак? Он очень сильно подрывает эм… используемость программы. Многие не захотят рекламировать какой-то там сайт на своих скриншотах (плюс создается впечатление, что их автор — администрация Вашего ресурса). Чтобы как-то протолкнуться среди тучи подобных программ, нужно предложить что-то новое или исправить недостатки конкурентов, но никак не добавлять новые.
Ололо сам себя в клетку посадил.
Меня терзают смутные сомнения на счет существования этой программы! Где скачать дэмо, бету или альфу версию? Хотя бы скриншот покажите!
niesoft.ru/nshots.zip — программу для себя писал.
Кстати, если кому-то будет полезно, то Win+PrtScr в восьмёрке прекрасно сохраняет скриншот в png-файл.
Какие капчи… Уже около месяца как API публично доступно:
$client = new SoapClient("http://voh.russianpost.ru:8080/niips-operationhistory-web/OperationHistory?wsdl");
$data=$client->GetOperationHistory(Array('Barcode'=>$rpo,'MessageType'=>0));
А где можно документацию почитать? Может ли простой человек, безо всяких договоров с почтой России и геморроя им пользоваться?
Только SOAP, REST'a нет?
Только SOAP, REST'a нет?
Под рукой только такая документация. Я как обычное физическое лицо без всяким проблем пользуюсь этим сервисом. REST`а, к сожалению, нет.
Спасибо за документацию, они даже док файл умудрились кривым сделать…
>Я как обычное физическое лицо без всяким проблем пользуюсь этим сервисом.
А вы подавали какое-то заявление? Каким образом вы своё приложение регистрировали?
>Я как обычное физическое лицо без всяким проблем пользуюсь этим сервисом.
А вы подавали какое-то заявление? Каким образом вы своё приложение регистрировали?
Вот так новость… Беру на заметку, где же оно раньше то было.
Хотя с другой стороны — написание подобного скрипта — хороший опыт для меня.
Хотя с другой стороны — написание подобного скрипта — хороший опыт для меня.
А киньте плз ссылку где это все задокументировано
Ну что ты будешь делать, даже новости у них «быстрые», через месяц о них узнают.
Вот же вам спасибищще огроменное! Наклепал для себя скриптик на питоне — теперь ну их нафиг сайты всякие. А смски самому себе можно и через гугл-календарь прикрутить в перспективе
Может, стоит им написать коллективное письмо, с просьбой выставить публичное АПИ? А то ведь каменный век какой-то…
P.S. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой.
P.S. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой. Я буду всегда обновлять комментарии перед отправкой.
хорошо бы написать еще скрипты для обхода очередей и суровых теток из Почты России. Тут AI плачет крокодильими слезами от безысходности.
Да уж, сделать капчу при запросе истории посылки — это надо было додуматься.
У них же был SOAP вебсервис для работы с треками? даж на хабре писали про него.
Возможно ли создание greasemonkey-скрипта, который бы при заходе на страницу трекинга «разгадывал» бы капчу и сразу вставлял бы её значение в поле ввода? Возможно ли капчу на javascript'e распознать? Или сторонний сервер все-таки понадобится?
Или, может, можно сделать так, что при нажатии на кнопку Найти, использовался бы упомянутый выше SOAP запрос?
Т.е. есть ли какое-то решение, которое могло бы обычного пользователя от ввода капчи избавить?
Или, может, можно сделать так, что при нажатии на кнопку Найти, использовался бы упомянутый выше SOAP запрос?
Т.е. есть ли какое-то решение, которое могло бы обычного пользователя от ввода капчи избавить?
Мне вот интересно, почему и в этом вопросе Почта России борется со своими клиентами? Что мешает им сделать нормальный API для отслеживания?
Или они хотят, чтобы пользоваться использование их услуг напоминало квест?
Или они хотят, чтобы пользоваться использование их услуг напоминало квест?
Боже, какой адский баннер!
а почему не выровнять все цифры (точнее теперь массив пикселей) по верхнему краю? Теоретически далее будет проще.
так их суп апи прекрасно работает. вот живой пример
А скриптом поделитесь?
Я бы, наверное, сдался, обнаружив, что высота цифр меняется. Автор молодцом!
Велосипед не в алгоритме, а в том что у них есть api
у ПР «детская» капча. Это ладно.
А слабо для почты Китая «распознавалку» написать?)))
Я пока, кроме ручного ввода, ничего не придумал…
А слабо для почты Китая «распознавалку» написать?)))
Я пока, кроме ручного ввода, ничего не придумал…
А эта вот загогулинка в самом начале имеет смысл? Линию же проходящуюся по тексту убрать по сути очень даже возможно. Хотя можно попробовать просто после бинаризации картинки попросту сделать erode/delite (дабы увеличить вероятность распознавания символов аля 6-ки в примере. Ну и дальше уже как захочется. Вариантов сделать простенький OCR достаточно много.
В моём случае эта линия никакой роли бы не сыграла, т.к у почты вариантов символов минимальное и я просто тыкал мышкой в закрашенные части картинки — тем самым показал программе где какая цифра.
В вашем случае на обучение уйдёт порядка недели.
В вашем случае на обучение уйдёт порядка недели.
Не думаю, что тут можно обойтись Вашим алгоритмом. Картинка большего размера, используются больше символов, и все хитро искажается. Скорее всего, тут нужно будет, как обычно, убирать линию, сегментировать и скармливать отдельно каждый символ нейросети. На всех этапах процесса распознавания будут возникать сложности, поэтому капча хорошая.
Мне кажется, автор поста достоин аплодисментов. OCR для удобства посетителей сайта — это мощно, снимаю шляпу.
Вот, кстати, интересная реализация использования суп апи от ПР на PHP.
Недавно почта России переделала старое АПИ да и сам сайт в целом…
Пришлось забывать про капчу и пользоваться официальной документацией.
Пришлось забывать про капчу и пользоваться официальной документацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой первый скрипт по разгадыванию капчи