придумать реализацию для функции высшего порядка, которой часто пользуешься — наивную как в underscore или быструю как lodash — почему бы нет. но в описанном случае ведь ежу понятно, что карринг и частичное применение функций — разные вещи. для карринга арность функции должна быть фиксированой (см. определение). а то что было предложено сделать это плод какого-то нездорового воображения.
1. сокрытие внутренней файловой структуры компонентов.
2. подключение внешних библиотек.
3. поддержание общего порядка.
где-то тут же — загрузка тестов, сборка разных бандлов и прочее подобное счастье. понятно, что в сыром виде, как описывалось в этой статье, использование параллельно двух различных систем контроля различных зависимостей превращается в полное непотребство. но оригинал был написан осенью 2013 (ага, я сходил по ссылке). но в начале этого года tuchk4@ предлагал здесь уже гораздо более интересное решение: habrahabr.ru/post/216469/. любопытно, есть-ли какие-то новости про использование плагина в продакшене?
вот мне тоже интересно, чего стараются добиться интервьюеры, предлагая подобные задачи на собеседовании? интересный трюк, забавный. но какова практическая польза? ведь, если кто-то напишет такой чудо-код для продакшен, сами же выгонят за проф.невменяемость.
вечером наблюдал ситуацию, когда менеджерша в зале торопила каких-то студентов определяться с выбором бутылки потому, что после 23:00 (или сколько там) продать уже не смогут, тупо потому, что в кассовом чеке отражается как наименование товара, так и время когда этот самый чек был отбит. дескать, это вполне себе документ, и если неправильный товар отбивается в неправильное время, магазин за это дрючат.
я понял аргументацию так: поскольку наблюдаемая практика регулярно расходится с теорией, значит что-то не так в этой теории — может все это не про нашу реальность, а может ограничения заданы не верно. ведь с момента появления первых упоминаний о 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, а асинхронный код обладает «вирусным» эффектом (если на низком уровне появляется асинхронный код, то и весь высокоуровневый код должен быть асинхронным). ничего страшного, просто решение этой задачи усложняет решение двух предыдущих на порядок.
1. сокрытие внутренней файловой структуры компонентов.
2. подключение внешних библиотек.
3. поддержание общего порядка.
где-то тут же — загрузка тестов, сборка разных бандлов и прочее подобное счастье. понятно, что в сыром виде, как описывалось в этой статье, использование параллельно двух различных систем контроля различных зависимостей превращается в полное непотребство. но оригинал был написан осенью 2013 (ага, я сходил по ссылке). но в начале этого года tuchk4@ предлагал здесь уже гораздо более интересное решение: habrahabr.ru/post/216469/. любопытно, есть-ли какие-то новости про использование плагина в продакшене?
вечером наблюдал ситуацию, когда менеджерша в зале торопила каких-то студентов определяться с выбором бутылки потому, что после 23:00 (или сколько там) продать уже не смогут, тупо потому, что в кассовом чеке отражается как наименование товара, так и время когда этот самый чек был отбит. дескать, это вполне себе документ, и если неправильный товар отбивается в неправильное время, магазин за это дрючат.
то получается еще короче:
общий смысл такой же, как и с паролями: чем дольше живет сертификат, тем выше вероятность, что он перестанет быть для кого-то секретом. 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, а асинхронный код обладает «вирусным» эффектом (если на низком уровне появляется асинхронный код, то и весь высокоуровневый код должен быть асинхронным). ничего страшного, просто решение этой задачи усложняет решение двух предыдущих на порядок.
можно записать чуть компактнее, хотя смысл не меняется: