> Есть вообще слова, для которых в русском языке звуков не предусмотрено «Thread» — «Тред» (тут «Поток» спасает)
В этот ѳред должен ворваться Mithgol и рассказать про Фиту
Потому что я единственный в проекте кто использует WebStorm, никто не будет из-за меня менять расширения для файлов, да и неправильно это, например для джанго шаблонов всегда используется .html но для них можно выбрать директорию в PyCharm'e, а для других типов файлов — нельзя. Чем делать для разных IDE разные настройки лучше уж один раз и навсегда сделать возможность или выбирать подсветку в текущем файле или выбирать подсветку для файлов определенного типа в определенной директории.
Есть еще у меня один feature request который в течении долгого времени вертится у меня в голове: было бы круто если бы WebStorm учитывал конструкции по типу
var _this = this;
var self = this;
и подсвечивал все дальнейшие вхождения _this или self в том же лексическом контексте так же как this
Я уже который год ждут когда вы добавите возможность выбрать тип файла независимо от расширения, например у меня в проекте есть и Handlebars шаблоны с расширением .html и ангуляр-шаблоны тоже с расширением .html было бы круто если бы была какая-то переключалка внизу как в Sublime или возможность выбора подсветки для файлов с одним расширением в разных директориях.
Я тоже не понимаю почему все от него прутся, крайне запутанное апи и плохая настраиваемость, по крайней мере я так и не смог его нормально использовать, особенно раздражало что нельзя иметь именнованые логеры и нормальные фильтры. Всем кто прется от винстона рекомендую посмотреть в сторону Intel github.com/seanmonstar/intel
ну или ваш форк =) github.com/btd/rufus
Из графиков не понятна целесообразность — судя по графику JQuery в PNG занимает что-то межу 50 и 60 КБ, а gzip судя по closure-compiler.appspot.com/home должен занимать 32КБ
Первое что я могу сразу сказать, что вот такой код я сразу прошу переписать, без обид. Вы понимаете что делаете? Для того чтобы понять что в итоге выбирается надо залезть в два разных места. Теряется прозрачность за счет этого весьма просто что-то сломать да так что еще и причина будет не очевидна. По этой причине лучше запрос так не дробить.
Очень-очень странное заявление, если например у нас есть список транзакций и у транзакции есть тип, статус, размер и дата, и нам нужно сделать фильтр по всем этим параметрам не будете же вы писать кучу запросов для каждого варианта. Более того, я могу с уверенностью сказать что любой нормальный проект на SQLAlchemy использует эти возможности и это абсолютно никого не смущает, а наоборот делает код проще и понятнее: github.com/mitsuhiko/bf3-aggregator/blob/master/bf3.py#L586bitbucket.org/danjac/newsmeme/src/43c4760f94a1308abce92661084b302ca229d7fe/newsmeme/models/posts.py?at=default#cl-45
То же самое относится и к реляциям, фильтрованным или нет — это отнюдь не редкая, а наоборот — самая и наиболее часто используемая фича в алхимии, это же в конце концов ORM, а не что-то там еще. Я просто не представляю как можно писать ручками каждый запрос если можно разбить все — вынести реляции, вынести часто используемые фильтры и группировки и зачем просто комбинировать их по мере надобности.
Эм. Поясните мне про что речь. Обычно если вы уж написали последовательный вызов функций в тексте, то так он и будет. Как вы его там менять собираетесь мне право интересно.
Так я именно про это и говорю — алхимия позволяет не писать последовательный вызов функций в одном месте. В одном месте мы можем сделать JOIN, во втором — второй JOIN, в третьем мы можем опять таки программно сконструировать фильтр, а в четвертом применить сортировку. Это же обычные методы, как мы захотим так их и скомбинируем. Это позволяет разбивать и выделать общие запросы и на этом и основывается вся работа в алхимии — вы создаете классы которые уже имеют все нужные вам реляции (с джоинами или без) которые затем просто фильтруются или на их основе делаются более сложные запросы.
В ponyorm скрыта сессия? Где?
Вот и я не знаю где, все что я вижу это глобальные функции типа commit и rollback которые на самом деле где-то управляют сессией но саму сессию я не вижу, и это меня смущает.
Ну, спорить не буду, как говорится на вкус и на цвет фломастеры разные. Но в SQLAlchemy цепочки методов сделаны не просто так, а для того что бы можно было программно конструировать разные запросы в разных частях приложения, в отличии от Pony где вы один раз написали генератор и все. Ну и то что все делается напрямую через сессию, которая не скрыта за какими-то декораторами для функций, тоже плюс, так как это питон и явное лучше неявного. Я тоже плевался когда переходил с Джанги, но как оказалось я просто не умел готовить алхимию. Сейчас работаю с Node.js и с грустью скучаю о алхимии.
Интересно, я уже давно слежу за PonyOrm, но мне почему-то наоборот казалось что оно настолько похоже на алхимию что мигрировать с одного на другое смысла нет. Единственное в чем я вижу разницу так это в способах создания запросов — генераторы в пони против обычных выражений типа: .filter((Person.birthday > d1940) & (Person.birthday < d1960)). Во всем всем остальном DSL почти 1 в 1 как алхимии, судя по докам.
На самом деле достаточно просто достичь справедливого распределения монет в PoS схеме. Ведь основная идея PoS это снижение стоимости транзакций на порядки и устойчивость к атакам 51%. Просто нужно оставить PoW как средство генерации монет, а PoS как средство проверки целостности транзакций для создания блоков. Почему авторы этого не сделали меня удивляет, ведь в таком случае было бы достигнуто то самое свойство биткоина за что его и полюбили — справедливость — ни Сатоши, ни первые майнеры не являлись владельцами всех биткоинов. Каждый мог присоединиться и ни вкладывая значительных ресурсов, ни идя на биржу, мог намайнить какие-то крохи.
Не понимаю почему минусуют этот комментарий, ведь сточки зрения техники и безопасности этот метод аутентификации отличается от привычной cookie-based аутенцификации только тем, что вместо куки теперь мы имеем файл
В каждом авторизационном файле хранится некоторая сгенерированная случайным образом строка символов, для которой в базе данных на сервере есть хэш, привязанный к определённому идентификатору пользователя.
Ну ведь это и есть cookie-based аутентификация.
Даже более того, если использовать такой способ как замену пароля, то он менее секурен чем куки+пароль, потому что любой троянец, да что там троянец, жена\любовница\брат\сестра сможет увести такой файл и получить полный доступ к пользовательскому аккаунту, включая смену настроек. Если же использовать такой метод в связке с паролем, то тогда отпадает весь смысл в такой авторизации, потому что если пользователь знает пароль, зачем его спрашивать какой-то файл? Точнее даже так — если пользователь имеет какой-то файл с уникальным идентификатором — зачем его разлогинивать и спрашивать идентификатор, когда можно этот уникальный идентификатор сохранить в куки?
Если прям так уж действительно хочется сделать аутентификацию без пароля, то почему бы не следовать стандартам — для жуткого энтерпрайза использовать клиентские SSL сертификаты, а для обычных пользователей сделать все через mozilla persona
В этот ѳред должен ворваться Mithgol и рассказать про Фиту
и подсвечивал все дальнейшие вхождения
_this
илиself
в том же лексическом контексте так же какthis
ну или ваш форк =) github.com/btd/rufus
Очень-очень странное заявление, если например у нас есть список транзакций и у транзакции есть тип, статус, размер и дата, и нам нужно сделать фильтр по всем этим параметрам не будете же вы писать кучу запросов для каждого варианта. Более того, я могу с уверенностью сказать что любой нормальный проект на SQLAlchemy использует эти возможности и это абсолютно никого не смущает, а наоборот делает код проще и понятнее:
github.com/mitsuhiko/bf3-aggregator/blob/master/bf3.py#L586 bitbucket.org/danjac/newsmeme/src/43c4760f94a1308abce92661084b302ca229d7fe/newsmeme/models/posts.py?at=default#cl-45
То же самое относится и к реляциям, фильтрованным или нет — это отнюдь не редкая, а наоборот — самая и наиболее часто используемая фича в алхимии, это же в конце концов ORM, а не что-то там еще. Я просто не представляю как можно писать ручками каждый запрос если можно разбить все — вынести реляции, вынести часто используемые фильтры и группировки и зачем просто комбинировать их по мере надобности.
Ну как мне сделать примерно так?
Это конечно немного наигранный пример, но в целом показывает именно то что я хочу описать — программное конструирование запросов
Они там есть, но не такие мощные как в алхимии
Ну вот вы и привели пример глобальных функций которые сами управляют сессией где-то у себя про что я собственно и говорю
Так я именно про это и говорю — алхимия позволяет не писать последовательный вызов функций в одном месте. В одном месте мы можем сделать JOIN, во втором — второй JOIN, в третьем мы можем опять таки программно сконструировать фильтр, а в четвертом применить сортировку. Это же обычные методы, как мы захотим так их и скомбинируем. Это позволяет разбивать и выделать общие запросы и на этом и основывается вся работа в алхимии — вы создаете классы которые уже имеют все нужные вам реляции (с джоинами или без) которые затем просто фильтруются или на их основе делаются более сложные запросы.
Вот и я не знаю где, все что я вижу это глобальные функции типа commit и rollback которые на самом деле где-то управляют сессией но саму сессию я не вижу, и это меня смущает.
.filter((Person.birthday > d1940) & (Person.birthday < d1960))
. Во всем всем остальном DSL почти 1 в 1 как алхимии, судя по докам.Ну ведь это и есть cookie-based аутентификация.
Даже более того, если использовать такой способ как замену пароля, то он менее секурен чем куки+пароль, потому что любой троянец, да что там троянец, жена\любовница\брат\сестра сможет увести такой файл и получить полный доступ к пользовательскому аккаунту, включая смену настроек. Если же использовать такой метод в связке с паролем, то тогда отпадает весь смысл в такой авторизации, потому что если пользователь знает пароль, зачем его спрашивать какой-то файл? Точнее даже так — если пользователь имеет какой-то файл с уникальным идентификатором — зачем его разлогинивать и спрашивать идентификатор, когда можно этот уникальный идентификатор сохранить в куки?
Если прям так уж действительно хочется сделать аутентификацию без пароля, то почему бы не следовать стандартам — для жуткого энтерпрайза использовать клиентские SSL сертификаты, а для обычных пользователей сделать все через mozilla persona