>Старайтесь отказаться от регулярных выражений при парсинге веб-страниц в пользу xpath.
>Это сделает ваш код проще, понятнее. Вы допустите меньше ошибок. Сократиться время отладки.
Допустим у меня есть такой узел Numbers, я хочу заменить его на Количество
Примитивнейше регулярное выражение, а как это сделать при помощи Xpath, ну хотя бы концептуально?
Не нужно мучится выбором между «плохими парнями» и «очень плохими парнями» это то самое «голосование сердцем», которое давно «привело в жопу».
Гораздо эффективнее оценивать конкретные инициативы.
Тот же Навальный привел способ, как добиться чтобы залатали яму во дворе — по закону!
Хочешь чтобы не было ям во дворе? Пиши жалобы по методу Навального.
Не хочешь — жди прихода «идеального парня» до второго пришествия и получай то что происходит. Так во всем.
Perl подарил миру такую замечательную вещь как регулярные выражения. Библиотека PCRE ( дословная расшифровка — регулярные выражения как в перле) нынче является неотъемлемым атрибутом любого приложения связанного с web.
В вопросе наличия информации в полной таблице и ее потери при исключении фул-вью мы кажется сошлись.
В вопросе того, что в 99% случаях фул вью рядовому пользователю ничего не дает я тоже соглашусь.
А вот в вопросе нужно ли устранять оставшиеся 1% проблем у нас отношение разное.
Я, с точки зрения провайдера считаю что нужно. Потратил время и деньги на AC-ку и свой блок адресов — используй. Если не хочешь, то должен осознавать то отказ от принятия решения на базу full-view ухудшит надежность в решении… тех самых 1% сбоев.
В большинстве компаний задача удовлетворения клиента и задача соблюдения процедур бизнеса противоречат друг другу.
В клиентоориентированной компании Светлану должны наказать (или поощрить) за то, что она не преодолела(преодолела) внутренние барьеры ради пользы клиента.
В обычной компании Светлану накажут за нарушение инструкции по обслуживанию клиента, за превышение полномочий.
К сожалению, в России компаний, которые на словах любят клиентов на порядок больше чем компаний, которые действительно это делают. И это огромное поле деятельности для небольших компаний в любом сегменте бизнеса!
У меня 1 аплинку к оператору A, второй аплинк к Оператору B. Имеем далее сайт находящийся в автономной системе C который доступен как через А, так и через B.
Причем как это обычно бывает A и B находятся в одном городе, но имеют связь между собой через франкфурт.
Нарисуйте конфигурацию БЕЗ full-view которая защитит передачу трафика при любом из двух возможных обрывов ликов у C.
«Ассимитрия на пиринге» это зло которое создают вот именно такие «оптимизаторы» которые никогда не слышали слова comunity. Кстати, в вашей статье это слово упоминается всего один раз в неизвестном мне сочетании «BGP bandwidth community».
Так же вы утверждаете что L3 свичи и Роутеры отличаются поддержкой комьюнити. Это не правда, совсем не другим они отличаются :)
«в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны» Хочется спросить, вы за свою жизнь хоть раз бгб-мултихоминг настраивали?
Это утверждение полная чушь! 10 лет занимаюсь работой с BGP и могу совершнно уверено сказать что:
Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает. А потому что на другом конце всгда есть такой же упертый, который упорно пытается свой исходняк влить вам совсем не в ту дырку в которую хочется принять вам. Об чем я пытаюсь сигнализировать.
Статья безусловно полезная, особенно для тех кто не в теме, но желает разобраться.
Но один пропущенный важный момент делает вредным конечный вывод.
Дело в том что интернет и протокол BGP подразумевает равноправное взаимодействие сторон.
Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность. Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.
Вместо того чтобы отдать решение о выборе исходящего трафика протоколу BGP, в котором динамически балансируются миллионы частных интересов, ты подкидываешь монетку и тыкаешь наугад. Фул вью это не 350 тысяч ненужных записей, а 350 тысяч заявлений разных участников о своей политике маршрутизации. Отказываясь от этой информации ты отказываешься от возможности самостоятельно принимать решение в выборе пути.
Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно.
Если возникнут вопросы как именно схема основной резервный снижает надежность BGP, могу привести примеры, но из прочтения статьи должно быть понятно.
Мне кажется Петруха, который сделал 239 заказов за год имеет право на заслуженное Здравствуте, Петр Иванович!
В любой индустрии важных постоянных клиентов на каком то уровне узнают по голосу. Очень праивильно чтобы это было с уровня колцанта, но понятно что не для всякого случая и не каждого клиента, про секс-шоп уже написали.
Ответ очевиден — дать задний ход. Потом либо разогнаться и пробить дорогу, либо свернуть и искать другую. 9 из 10 стартапов умирают, это не трагедия, это статистика.
На самых первых шагах стартапа очень важно чтобы пришел хоть какой нибудь успех — первый клиент который готов купить «идею», рабочий прототип и т.д. Для этого очень важно чтобы первый этап выполнили либо настоящие профессионалы, либо люди горящие работой.
У меня был стартап в телекоме незадолго до кризиса. Я нанимал менеджера по поиску новых объектов уже в кризис. Изначально я хотел предложить ему оплату 25 тысяч оклад + 25 тысяч бонус в случае нахождения объекта. Но при собеседовании он «додавил» нас и договорился на 40 тысяч оклад и 10 тысяч премия. Тогда показалось что он «настойчивый» и это качество поможет в работе. Но в процессе работы оказалось что его эти 10 тысяч не мотивируют, он получал свой оклад а выхлопа не было.
В результате когда грянул кризис в тяжелой форме у нас не было достаточно объектов, и денежный поток оказался отрицательный. Инвесторы в итоге фактически перепрофилировали проект (в телекоме такое возможно, инфраструктура остается)
Железное правило для стартапа: буксует человек — расставайся немедленно, иначе потом придется увольнять всю команду. А еще лучше не нанимать этого человека вовсе, а выполнить максимум работы самому.
Задача удаленного зеркалирования сайта решается путем полного реверс-прокси, при котором страница удаленного сайта подвергается проксификации, т.е. все внутрение линки examplesite.com заменяются на examplesite-ru.com
Насколько я понял из документации по nginx он работает по схеме бакенд- фронтэнд при которой оба имеют одинаковое имя examplesite.com, т.е. он попросту не может выполнить поставленную задачу.
<тэг span>Numbers</тэг span>
заменить на
<тэг span>Количество</тэг span>
>Это сделает ваш код проще, понятнее. Вы допустите меньше ошибок. Сократиться время отладки.
Допустим у меня есть такой узел Numbers, я хочу заменить его на Количество
Примитивнейше регулярное выражение, а как это сделать при помощи Xpath, ну хотя бы концептуально?
Гораздо эффективнее оценивать конкретные инициативы.
Тот же Навальный привел способ, как добиться чтобы залатали яму во дворе — по закону!
Хочешь чтобы не было ям во дворе? Пиши жалобы по методу Навального.
Не хочешь — жди прихода «идеального парня» до второго пришествия и получай то что происходит. Так во всем.
В вопросе того, что в 99% случаях фул вью рядовому пользователю ничего не дает я тоже соглашусь.
А вот в вопросе нужно ли устранять оставшиеся 1% проблем у нас отношение разное.
Я, с точки зрения провайдера считаю что нужно. Потратил время и деньги на AC-ку и свой блок адресов — используй. Если не хочешь, то должен осознавать то отказ от принятия решения на базу full-view ухудшит надежность в решении… тех самых 1% сбоев.
В клиентоориентированной компании Светлану должны наказать (или поощрить) за то, что она не преодолела(преодолела) внутренние барьеры ради пользы клиента.
В обычной компании Светлану накажут за нарушение инструкции по обслуживанию клиента, за превышение полномочий.
К сожалению, в России компаний, которые на словах любят клиентов на порядок больше чем компаний, которые действительно это делают. И это огромное поле деятельности для небольших компаний в любом сегменте бизнеса!
У меня 1 аплинку к оператору A, второй аплинк к Оператору B. Имеем далее сайт находящийся в автономной системе C который доступен как через А, так и через B.
Причем как это обычно бывает A и B находятся в одном городе, но имеют связь между собой через франкфурт.
Нарисуйте конфигурацию БЕЗ full-view которая защитит передачу трафика при любом из двух возможных обрывов ликов у C.
«Ассимитрия на пиринге» это зло которое создают вот именно такие «оптимизаторы» которые никогда не слышали слова comunity. Кстати, в вашей статье это слово упоминается всего один раз в неизвестном мне сочетании «BGP bandwidth community».
Так же вы утверждаете что L3 свичи и Роутеры отличаются поддержкой комьюнити. Это не правда, совсем не другим они отличаются :)
«в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны» Хочется спросить, вы за свою жизнь хоть раз бгб-мултихоминг настраивали?
Это утверждение полная чушь! 10 лет занимаюсь работой с BGP и могу совершнно уверено сказать что:
Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает. А потому что на другом конце всгда есть такой же упертый, который упорно пытается свой исходняк влить вам совсем не в ту дырку в которую хочется принять вам. Об чем я пытаюсь сигнализировать.
Там это все реализовано сто лет уже как.
Но один пропущенный важный момент делает вредным конечный вывод.
Дело в том что интернет и протокол BGP подразумевает равноправное взаимодействие сторон.
Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность. Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.
Вместо того чтобы отдать решение о выборе исходящего трафика протоколу BGP, в котором динамически балансируются миллионы частных интересов, ты подкидываешь монетку и тыкаешь наугад. Фул вью это не 350 тысяч ненужных записей, а 350 тысяч заявлений разных участников о своей политике маршрутизации. Отказываясь от этой информации ты отказываешься от возможности самостоятельно принимать решение в выборе пути.
Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно.
Если возникнут вопросы как именно схема основной резервный снижает надежность BGP, могу привести примеры, но из прочтения статьи должно быть понятно.
Или я не прав?
Задача решается при помощи
HttpSubsModule
Как то так :)
Забавно что в ATS и Ngnix обнаружил одинаковый баг, растущий видимо из библитеки PCRE.
По возможностям кеширования он все же хуже ATS, зато может отлично выполнять роль http сервера, что в моем случае плюс.
В любой индустрии важных постоянных клиентов на каком то уровне узнают по голосу. Очень праивильно чтобы это было с уровня колцанта, но понятно что не для всякого случая и не каждого клиента, про секс-шоп уже написали.
У меня был стартап в телекоме незадолго до кризиса. Я нанимал менеджера по поиску новых объектов уже в кризис. Изначально я хотел предложить ему оплату 25 тысяч оклад + 25 тысяч бонус в случае нахождения объекта. Но при собеседовании он «додавил» нас и договорился на 40 тысяч оклад и 10 тысяч премия. Тогда показалось что он «настойчивый» и это качество поможет в работе. Но в процессе работы оказалось что его эти 10 тысяч не мотивируют, он получал свой оклад а выхлопа не было.
В результате когда грянул кризис в тяжелой форме у нас не было достаточно объектов, и денежный поток оказался отрицательный. Инвесторы в итоге фактически перепрофилировали проект (в телекоме такое возможно, инфраструктура остается)
Железное правило для стартапа: буксует человек — расставайся немедленно, иначе потом придется увольнять всю команду. А еще лучше не нанимать этого человека вовсе, а выполнить максимум работы самому.
The threads support in nginx is currently broken and this patch does not
fix it.
--
Igor Sysoev
sysoev.ru/en/
Давайте в заметке про ATS обсуждать его фичи.
Термин я взял из известного скрипта анонимайзера:
www.jmarshall.com/tools/cgiproxy/
Вобще правильнее наверно взять и попробовать.
Я пробовал apache + mod_proxy_html — оно работает некорректно.
Пробовал apache + cgiproxy + mod_perl — оно работает сносно но очень медленно
ATS проксирут и работает чрезвычайно быстро.
Насколько я понял из документации по nginx он работает по схеме бакенд- фронтэнд при которой оба имеют одинаковое имя examplesite.com, т.е. он попросту не может выполнить поставленную задачу.