Тут речь идет о доверии участников, о некотором их равноправии, что ли. Когда дело заходит о деньгах, сразу можно ставить крест о совместном проекте: частью сознания сразу же начинаешь считать дивиденты, если изначально не оговорено о свободности этого проекта для всех его участников.
Есть, но не много — затыки случались на каждом шагу: может и тому что есть потребуется переделка. Так, оно будет иметь много общего с sqlalchemy и sqlobject, особенно на простых запросах-выборках. Неудобство возникает, когда к строкам требуется применять не такие уж и сложные преобразования, вклинивать пользовательский код, устраивать поддержку транзакций в нетранзакционных средах. Адрес jabber-а указан в конце статьи, и оставшиеся вопросы думаю имеет смысл перенести туда. К вечеру пятницы попробую увязать все наработки в один пучок. Кстати, открытый jabber канал уже работает?
Согласен. Иначе итог оказывается не очень жизнеспособен. Единственное «но», что ORM является основой сайтов, и разрабатывать его синтаксис + внутреннюю оснастку на этапе формирования динамики получалось бы еще хуже — замкнутый круг.
Коды активации были высланы, но получили ли их реальные люди, или их «закешировали» сами амазоновцы — тоже не ясно. Конечно вряд ли: тема скорей для очередного выпуска «Жадность» :)
5Копеек: быстродейственный ORM под python (Си, Python). Издалека может быть похож на LINQ, с построением за счет _только_ python синтаксиса, с последующей возможностью компиляции представления через AST в оптимизированное представление на том же python коде. Цель: кроссплатформенность; межсредность — под SQL и NoSQL решения; сделать из python оптимальную среду для веб>=20кодинга. Плюсы: минимум графики — вообще нет, поэтому не нужны труъ-математики Бамбея; в первом приближении — выполнимо; важен именно суп из разработчиков, поскольку то что уже есть иногда очень даже хорошо, но недостаточно — необходима многократная переработка и многостороний взгляд.
Тут, видимо, есть вкус и цвет, а следовательно — поспорим :) По мне, так такое внимание в первую очередь именно к деталям (развал и схождение, да — почему б и нет. Не всем же шашечки подавай) помогает получить представление всего образа в целом.
null, undefined, none, void — то что приходит на ум в виде примеров. Настройки — уже не настоль хороший пример, поскольку настройки могут прочитаться, или нет: из файла или иным путем. А синглтон должен существовать более-менее неизменным на протяжении не только всей жизни процесса. А если он ленивый? Код, описывающий его инициализацию может занять больше места, чем то место, на которое ссылается указатель. Если конфигурация должна быть одна на весь процесс — пожайлуста. Должен ли это быть синглтон — совершенно не обязательно. Ведь из чего исходят, задумывая конфигурацию синглтоном: нужна гарантия единственности? А как насчет других гарантий, что дают юнит тесты, и с которыми синглтоны не очень дружны по своей природе? Конечно дело вкуса, но вопрос остается открытым — наверное есть действительно какие-то примеры использования синглтона, если этому посвящено столько статей на хабре — однозначно должно быть парочка значимых, там, где критерий единственности был бы настолько потрясающим решением задачи, что прям — «вау». Я просто не вижу — откройте мне веки.
Вот я про то же: вроде бы может быть тяжеловесной хренью, но вот так вот чтобы придумать сразу на гора десяток различных примеров… — у меня и одного не получается. Все, что приходит в голову, является примером объектов несколько другого рода, и тогда Singleton — это вроде как неуместное применение паттерна. Расскажите о примере боевого использования тяжелого синглтона, чтоб отмести все подозрения?
А для чего нужен ленивый синглтон? Обычно он описывается небольшой структурой, и как бы непонятно зачем экономить? Если ж подобных этому классу — их тыщи и миллионы, то тогда другой вопрос — зачем столько синглтонов? Непонятно…
Кстати да, чего то непонятно, каким образом преобразовав 2 умножения и 1 сложение к 3 умножениям и 4 сложениям выигрывается время? Наверно нужно описать ограничение для данного утверждения?
RB начинает рвать все и вся если совместить ребалансировку с поиском позиции на вставку. Но это получается ограничение по мултизридовости, и интересно когда операций вставок приблизительно столько же, сколько и операций чтений — многовато ограничений. Поэтому AVL универсальней, ага. И насчет сортировок я бы не был столь категоричен — тут играет роль кеш процессора, и O(N*log N) раскрывается с хорошей такой констаной *ц. Для больших N и Ц будет намного больше, ибо дороги промахи не только в кеш процессора, но еще сильней будут стоить промахи в TLD кеш страниц, коих предвидится кошмарная туча.
Все корректно. Кое где можно было бы привести умножение вместо второй операции '%' — может съэкономить пару тактов, если часто вызываема будет, поскольку операция деления и взятия остатка не сможет быть даже гипотетически объединена в одну операцию конвеером процессора (существуют в разрыв им другие операции). Нахождение общего делителя интересный момент, но гораздо хуже, если коэффициенты будут иметь единицу в качестве онного.
от отцов, что видели: и эти сверкающие глянцем красивые игрушки, и детей из тех кому повезло и оторвало всего лишь губы и нос. По слухам, из прельстившихся выживших было немного, да и выживших был недолгий век. Возможно и Борис Николаевичу не гранатой руку оторвало — иначе как объяснить что РГД-33 так тихо бахнула: самые тонкие пальцы у десятилетнего пацана, и больше ничего не задело, никто рядом тоже не пострадал
По моему цель этой статьи привести ссылку на главных конкурентов АОП. Правда по куче противопоказаний это становится утвержденем, что конкурентов у АОП все еще нет.
Немцы тоже в свое время проводили социальный инжиниринг — разбрасывали детские игрушки. В свистульку дунул — челюсть оторвало, наручные часы завел — рук нет. Выжили самые осторожные и послушные. Неестественный отбор работает и тут.
Еще можно было бы добавить, что схема авторизации может маштабироваться на множество сайтов
как система OpenID. То есть закрытый ключ публикуется на доверенном сайте, а открытые ключи хранятся
на сайте регистрации пользователя. Иначе система напоминает PGP с удаленным недоверенным хранилищем
(что мешает подменить ключ на свой, с иным паролем?). Так на закрытый ключ можно было бы
ограничить распространение с помощью листа доступа с тем, чтобы исключить возможность
компрометации слабых паролей брутфорсом или словарным подбором. Подобная мера позволила бы менять
пароль в случае вероятности вскрытия этого секрета, и не потребовало бы обязательного отзыва всех
имеющихся сертификатов открытых ключей. Хотя вариант в протоколе заложить возможность отзыва
старого сертификата все же предпочтительней.
По сравнению с OpenID есть преимущество, что можно менять доверенный центр по своему желанию, и
вообще можно обойтись без такового (хранить секрет на локальном диске). То есть на момент авторизации
пользователя доверенный центр хранения приватных ключей может находиться в offline. Основной
отличительной чертой этого описания остается тенденция отказа от хранения пароля в чистом виде
где бы то ни было.
В довершение хочу заметить, что DSA больше подходит для воплощения данного алгоритма, так как
подпись на RSA (можно использовать SIGN(RND,e,N) вместо передачи HASH(RND) в ответе на запрос
авторизации, а в самом запросе отказаться от шифрации случайного числа) на порядок медленней,
чем в DSA.
как система OpenID. То есть закрытый ключ публикуется на доверенном сайте, а открытые ключи хранятся
на сайте регистрации пользователя. Иначе система напоминает PGP с удаленным недоверенным хранилищем
(что мешает подменить ключ на свой, с иным паролем?). Так на закрытый ключ можно было бы
ограничить распространение с помощью листа доступа с тем, чтобы исключить возможность
компрометации слабых паролей брутфорсом или словарным подбором. Подобная мера позволила бы менять
пароль в случае вероятности вскрытия этого секрета, и не потребовало бы обязательного отзыва всех
имеющихся сертификатов открытых ключей. Хотя вариант в протоколе заложить возможность отзыва
старого сертификата все же предпочтительней.
По сравнению с OpenID есть преимущество, что можно менять доверенный центр по своему желанию, и
вообще можно обойтись без такового (хранить секрет на локальном диске). То есть на момент авторизации
пользователя доверенный центр хранения приватных ключей может находиться в offline. Основной
отличительной чертой этого описания остается тенденция отказа от хранения пароля в чистом виде
где бы то ни было.
В довершение хочу заметить, что DSA больше подходит для воплощения данного алгоритма, так как
подпись на RSA (можно использовать SIGN(RND,e,N) вместо передачи HASH(RND) в ответе на запрос
авторизации, а в самом запросе отказаться от шифрации случайного числа) на порядок медленней,
чем в DSA.