я понял аргументацию так: поскольку наблюдаемая практика регулярно расходится с теорией, значит что-то не так в этой теории — может все это не про нашу реальность, а может ограничения заданы не верно. ведь с момента появления первых упоминаний о tdd уже больше десяти лет прошло, а вопросы все те же.
все равно не понятно, как им удавалось так четко сканировать, воспроизводя все эти полутона, блики и детали? это же куча времени. естественное освещение, за окном меняется день и ночь, погода, времена года. да и люди ведь не могут столько времени сидеть неподвижно.
вы говорите так, как будто это единственный случай утечки сертификатов за последний месяц.
общий смысл такой же, как и с паролями: чем дольше живет сертификат, тем выше вероятность, что он перестанет быть для кого-то секретом. shit happens, как говорится.
кстати, на недавно прошедшем pycon.ru, Armin Ronacher, в своем докладе, утверждал, что ssl сертификаты с длинным временем жизни, в плане безопасности, это крайне бестолковая затея — любой heartbleed раскроет все с потрохами, — и агитировал делать ротацию сертификатов раз в сутки.
… плюс это все должно работать в распределенной среде, обеспечивая перманентную доступность и аутентичность, плюс…
Original 17 rules
1. Every Xanadu server is uniquely and securely identified.
2. Every Xanadu server can be operated independently or in a network.
3. Every user is uniquely and securely identified.
4. Every user can search, retrieve, create and store documents.
5. Every document can consist of any number of parts each of which may be of any data type.
6. Every document can contain links of any type including virtual copies («transclusions») to any other document in the system accessible to its owner.
7. Links are visible and can be followed from all endpoints.
8. Permission to link to a document is explicitly granted by the act of publication.
9. Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies («transclusions») of all or part of the document.
10. Every document is uniquely and securely identified.
11. Every document can have secure access controls.
12. Every document can be rapidly searched, stored and retrieved without user knowledge of where it is physically stored.
13. Every document is automatically moved to physical storage appropriate to its frequency of access from any given location.
14. Every document is automatically stored redundantly to maintain availability even in case of a disaster.
15. Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents.
16. Every transaction is secure and auditable only by the parties to that transaction.
17. The Xanadu client-server communication protocol is an openly published standard. Third-party software development and integration is encouraged.
фишка в том, что в исходной постановке чуть-ли не каждый пункт тянет, как минимум на отдельную специализацию, если не на самостоятельную научную проблему. исключение из задачи каких-либо условий приводит к её существенному упрощению, и вы получаете либо dvcs, либо кеш, либо wiki, либо поисковый индекс, либо разметку, либо хранилище, либо cdn, либо www, либо соц.сеть, либо что-то еще из ныне привычного, в разработку которого была вложена не одна сотня человеко-лет.
Нельсона увлекла перспектива самостоятельно решить задачу именно ТАКОГО уровня — в исходной постановке и безо всяких компромиссов — дело всей жизни, ведь это того стоит. правда еще в конце прошлого века (гы), он уже с отчаянием, практически, говорил, что все это долбаная гордыня.
принципиальное отличие межу гипертекстом Нельсона и тем, что под ним подразумевается сейчас, примерно такое же, как между MVC и MVC. :)
основная идея была в создании технологии, где ни что, единожды опубликованное, не может быть утрачено или забыто, лишиться авторства, а ссылки (цитаты) — потерять связь с первоисточником. по смыслу, это ближе всего к wiki, пожалуй, хранящую все версии и позволяющую отследить любую правку (хотя проблемы цитирования и битых ссылок в wiki не решены).
кстати ссылка в статье со скромным словом «охарактеризовал» скрывает на самом деле весьма поучительное чтиво — «The Curse of Xanadu». ведь уже в 1995 году проект бил все мыслимые рекорды, обращая на себя внимание журналистов. в нем рассказывается по то, как это самый Нельсон пытался привести в порядок свои многочисленные записи, зачем придумал гипертекст, и в чем смысл Xanudu, и про его стартапы, а так же почему WWW это не то, что он якобы мог опередить, а то, что он пытался предотвратить. рекомендую.
детский сад) владелец авто выгоду получает (пусть, в виде оплаченного пассажирами ГСМ, хотя обычно — наличной), и налоги платить обязан, наравне со всеми. просто ввиду мизерности сумм, госорганам, как правило, это не интересно. что, в прочем, не делает сеё, несомненно полезное, занятие законным.
Автоматические сгенерированные парсеры весьма объёмны.
ваша статья тоже не маленькая. :) серьезно, классно, что вы так подробно объясняете причины выбора тех или иных решений и иллюстрируете суть простыми примерами реализации. практически, академичная статья. единственное, что на практике это использовать вряд-ли получится. для «промышленного» применения, при генерации js-парсеров, нужно учитывать еще ряд крайне важных «потребительских» характеристик, без которых, как говорят в народе, такая «простота хуже воровства».
во-первых, парсер обязан генерировать адекватные сообщения об ошибках, с классификацией проблем и четкой локализацией мест и причин их возникновения. обычное дело, когда код, связанный с анализом ошибок во входных данных и выводом соответствующих сообщений, занимает в объеме больше, нежели собственно код парсинга, как такового. важность момента может быть не очевидной на начальных этапах, но опыт будет дорого стоить. например, можно вспомнить как из стека BEM, после нескольких человеко-лет вложений в разработку и внедрение, был выкинут пресловутый bemhtml, вместе с его умопомрачительным DSL.
во вторых, парсер должен быть алгоритмически простым (в смысле «O») и быстрым. пусть char — парсит одну букву в строке. это универсально. но когда парсинг каждой буквы приводит к созданию объектов и вызову пачки методов, я сомневаюсь, что такая архитектура позволит достичь производительности сколь-нибудь выше плинтуса. именно поэтому «академические» реализации встречаются только в учебниках, а на практике грамматика компиляется в хитросплетенную, развесистую и только машине понятную «лапшу». это не прихоть. x4 в объеме кода приятнее, нежели x4 по потребляемой памяти или процессору.
в третьих, нужна возможность парсить асинхронно. в js, вы очень быстро с этим столкнетесь, поскольку асинхронность очень распространена в js, а асинхронный код обладает «вирусным» эффектом (если на низком уровне появляется асинхронный код, то и весь высокоуровневый код должен быть асинхронным). ничего страшного, просто решение этой задачи усложняет решение двух предыдущих на порядок.
еще опыт важен. nepster09 пишет, что в данном случае первый раз в жизни рисовал линии на канвасе через ангуляр. это обучение в чистом виде, а не производство. тут оценки будут состоятельны, разве что в дневнике. а так, сколько не оценивай, надо умножать на 3.1415. ну т.е. если б довелось решать задачу повторно, он бы наверняка уложился в рассчитанную оценку. ведь так?)
автор — дизайнер, а не программист. у них иная специфика. борьба идет со «сделать как лучше», а не «чтобы хоть как-то заработало». они могут остановиться в любой момент, продать пустое место как креатив, и т.п… отсюда time-boxing, да, рулит. :)
Например, роботу дается для анализа много страниц сервисов Яндекса, и он понимает, что на них на всех снизу есть ссылка «О компании»
…
/html/body/div/table/tbody/tr/td/div/ul/li/span/a вместо
верстка однотипных блоков может быть различной на разных сервисах (<a>О компании</a>, <b>О компании</b>) — её делали разные люди, в разное время, используя разные фреймворки. или просто один и тот же блок находится в разных состояниях (ссылка на текущую страницу — не ссылка). как вы это учитываете?
совпадения по именам функций это совсем не повод так делать. вносить расширения в прототипы — задача специализированных полифилов, которые обязаны до мелочей следовать стандартам.
поведение отдельных функций в библиотеке может в каких-то деталях отличаться от одноименных методов стандартных объектов (не со зла, конечно, а для общего блага — ленивость, расширенный интерфейс, и т.п.).и покуда библиотека не лезет в прототипы, это вполне допустимо.
общий смысл такой же, как и с паролями: чем дольше живет сертификат, тем выше вероятность, что он перестанет быть для кого-то секретом. shit happens, как говорится.
2. Every Xanadu server can be operated independently or in a network.
3. Every user is uniquely and securely identified.
4. Every user can search, retrieve, create and store documents.
5. Every document can consist of any number of parts each of which may be of any data type.
6. Every document can contain links of any type including virtual copies («transclusions») to any other document in the system accessible to its owner.
7. Links are visible and can be followed from all endpoints.
8. Permission to link to a document is explicitly granted by the act of publication.
9. Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies («transclusions») of all or part of the document.
10. Every document is uniquely and securely identified.
11. Every document can have secure access controls.
12. Every document can be rapidly searched, stored and retrieved without user knowledge of where it is physically stored.
13. Every document is automatically moved to physical storage appropriate to its frequency of access from any given location.
14. Every document is automatically stored redundantly to maintain availability even in case of a disaster.
15. Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents.
16. Every transaction is secure and auditable only by the parties to that transaction.
17. The Xanadu client-server communication protocol is an openly published standard. Third-party software development and integration is encouraged.
Нельсона увлекла перспектива самостоятельно решить задачу именно ТАКОГО уровня — в исходной постановке и безо всяких компромиссов — дело всей жизни, ведь это того стоит. правда еще в конце прошлого века (гы), он уже с отчаянием, практически, говорил, что все это долбаная гордыня.
основная идея была в создании технологии, где ни что, единожды опубликованное, не может быть утрачено или забыто, лишиться авторства, а ссылки (цитаты) — потерять связь с первоисточником. по смыслу, это ближе всего к wiki, пожалуй, хранящую все версии и позволяющую отследить любую правку (хотя проблемы цитирования и битых ссылок в wiki не решены).
ваша статья тоже не маленькая. :) серьезно, классно, что вы так подробно объясняете причины выбора тех или иных решений и иллюстрируете суть простыми примерами реализации. практически, академичная статья. единственное, что на практике это использовать вряд-ли получится. для «промышленного» применения, при генерации js-парсеров, нужно учитывать еще ряд крайне важных «потребительских» характеристик, без которых, как говорят в народе, такая «простота хуже воровства».
во-первых, парсер обязан генерировать адекватные сообщения об ошибках, с классификацией проблем и четкой локализацией мест и причин их возникновения. обычное дело, когда код, связанный с анализом ошибок во входных данных и выводом соответствующих сообщений, занимает в объеме больше, нежели собственно код парсинга, как такового. важность момента может быть не очевидной на начальных этапах, но опыт будет дорого стоить. например, можно вспомнить как из стека BEM, после нескольких человеко-лет вложений в разработку и внедрение, был выкинут пресловутый bemhtml, вместе с его умопомрачительным DSL.
во вторых, парсер должен быть алгоритмически простым (в смысле «O») и быстрым. пусть
char — парсит одну букву в строке. это универсально. но когда парсинг каждой буквы приводит к созданию объектов и вызову пачки методов, я сомневаюсь, что такая архитектура позволит достичь производительности сколь-нибудь выше плинтуса. именно поэтому «академические» реализации встречаются только в учебниках, а на практике грамматика компиляется в хитросплетенную, развесистую и только машине понятную «лапшу». это не прихоть. x4 в объеме кода приятнее, нежели x4 по потребляемой памяти или процессору.в третьих, нужна возможность парсить асинхронно. в js, вы очень быстро с этим столкнетесь, поскольку асинхронность очень распространена в js, а асинхронный код обладает «вирусным» эффектом (если на низком уровне появляется асинхронный код, то и весь высокоуровневый код должен быть асинхронным). ничего страшного, просто решение этой задачи усложняет решение двух предыдущих на порядок.
можно записать чуть компактнее, хотя смысл не меняется:
верстка однотипных блоков может быть различной на разных сервисах (
<a>О компании</a>,<b>О компании</b>) — её делали разные люди, в разное время, используя разные фреймворки. или просто один и тот же блок находится в разных состояниях (ссылка на текущую страницу — не ссылка). как вы это учитываете?отлично сказано! можно я это где-то запишу и буду цитировать?
из документации не очевидно, почему именно такой результат. тем не менее, разработчики underscore считают это поведение правильным.
в трекере мне предложили вот такой вариант для нахождения максимальной строки:
А, собственно, что Вы предлагаете, пока не понятно.
поведение отдельных функций в библиотеке может в каких-то деталях отличаться от одноименных методов стандартных объектов (не со зла, конечно, а для общего блага — ленивость, расширенный интерфейс, и т.п.).и покуда библиотека не лезет в прототипы, это вполне допустимо.