Pull to refresh
49
0
Александр @cyberface

User

Send message
Главное — лишь бы не Путхон
> Есть вообще слова, для которых в русском языке звуков не предусмотрено «Thread» — «Тред» (тут «Поток» спасает)
В этот ѳред должен ворваться Mithgol и рассказать про Фиту
Колбекам слава!
Потому что я единственный в проекте кто использует WebStorm, никто не будет из-за меня менять расширения для файлов, да и неправильно это, например для джанго шаблонов всегда используется .html но для них можно выбрать директорию в PyCharm'e, а для других типов файлов — нельзя. Чем делать для разных IDE разные настройки лучше уж один раз и навсегда сделать возможность или выбирать подсветку в текущем файле или выбирать подсветку для файлов определенного типа в определенной директории.
Есть еще у меня один feature request который в течении долгого времени вертится у меня в голове: было бы круто если бы WebStorm учитывал конструкции по типу
var _this = this;
var self = this;

и подсвечивал все дальнейшие вхождения _this или self в том же лексическом контексте так же как this
Я уже который год ждут когда вы добавите возможность выбрать тип файла независимо от расширения, например у меня в проекте есть и Handlebars шаблоны с расширением .html и ангуляр-шаблоны тоже с расширением .html было бы круто если бы была какая-то переключалка внизу как в Sublime или возможность выбора подсветки для файлов с одним расширением в разных директориях.
А потом рекомендую съездить в Камчатку, в Кубань и в Кавказ
Q уже не модно, сейчас в тренде Bluebird. Но AmdY скорее всего имел ввиду что async решает проблему каши из коллбеков
С каких пор medium.com принадлежит идея пихать бекграунд в виде картинки?
Я тоже не понимаю почему все от него прутся, крайне запутанное апи и плохая настраиваемость, по крайней мере я так и не смог его нормально использовать, особенно раздражало что нельзя иметь именнованые логеры и нормальные фильтры. Всем кто прется от винстона рекомендую посмотреть в сторону 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#L586 bitbucket.org/danjac/newsmeme/src/43c4760f94a1308abce92661084b302ca229d7fe/newsmeme/models/posts.py?at=default#cl-45
То же самое относится и к реляциям, фильтрованным или нет — это отнюдь не редкая, а наоборот — самая и наиболее часто используемая фича в алхимии, это же в конце концов ORM, а не что-то там еще. Я просто не представляю как можно писать ручками каждый запрос если можно разбить все — вынести реляции, вынести часто используемые фильтры и группировки и зачем просто комбинировать их по мере надобности.
Эм. У меня дурацкий вопрос. Что мешает это делать в случае ponyorm? Вызов там ровно точно такой же. Вызвали select написали что надо оно сгенерило.

Ну как мне сделать примерно так?
class User(db.Model):
  id =  db.Column(db.Integer)
  verified_transactions = db.relationship(
     Transaction,  primaryjoin=lambda: (Transaction.user_id == User.id) &
                                       (Transaction.verified == True)
  )
  unverified_transactions = db.relationship(
     Transaction, primaryjoin=lambda: (Transaction.user_id == User.id) &
                                      (Transaction.verified == False)
 )

class Transaction(db.Model):
  id =  db.Column(db.Integer)
  type = db.Column(db.String(32))
  amount = db.BigInteger() 
  user =  db.Column(db.Integer, db.ForeignKey(User.id))

def filter_txs_by_type(query, type)
   return query.filter(Transaction.type == type)

def filter_txs_by_amount_gt(query, amount):
   return query.filter(Transaction.amount > amount)

all_verified_txs = User.verified_transactions
verified_received_txs  = filter_txs_by_type(all_verified_txs, 'RECEIVE')
verified_received_txs_gt_1000 = filter_txs_by_amount_gt(verified_received_txs, 1000)   

Это конечно немного наигранный пример, но в целом показывает именно то что я хочу описать — программное конструирование запросов
Эм… а кто вам сказал что реляций в ponyorm то нет?

Они там есть, но не такие мощные как в алхимии

Официальная дока:

Ну вот вы и привели пример глобальных функций которые сами управляют сессией где-то у себя про что я собственно и говорю
Эм. Поясните мне про что речь. Обычно если вы уж написали последовательный вызов функций в тексте, то так он и будет. Как вы его там менять собираетесь мне право интересно.

Так я именно про это и говорю — алхимия позволяет не писать последовательный вызов функций в одном месте. В одном месте мы можем сделать JOIN, во втором — второй JOIN, в третьем мы можем опять таки программно сконструировать фильтр, а в четвертом применить сортировку. Это же обычные методы, как мы захотим так их и скомбинируем. Это позволяет разбивать и выделать общие запросы и на этом и основывается вся работа в алхимии — вы создаете классы которые уже имеют все нужные вам реляции (с джоинами или без) которые затем просто фильтруются или на их основе делаются более сложные запросы.

В ponyorm скрыта сессия? Где?

Вот и я не знаю где, все что я вижу это глобальные функции типа commit и rollback которые на самом деле где-то управляют сессией но саму сессию я не вижу, и это меня смущает.
Ну, спорить не буду, как говорится на вкус и на цвет фломастеры разные. Но в SQLAlchemy цепочки методов сделаны не просто так, а для того что бы можно было программно конструировать разные запросы в разных частях приложения, в отличии от Pony где вы один раз написали генератор и все. Ну и то что все делается напрямую через сессию, которая не скрыта за какими-то декораторами для функций, тоже плюс, так как это питон и явное лучше неявного. Я тоже плевался когда переходил с Джанги, но как оказалось я просто не умел готовить алхимию. Сейчас работаю с Node.js и с грустью скучаю о алхимии.
Интересно, я уже давно слежу за PonyOrm, но мне почему-то наоборот казалось что оно настолько похоже на алхимию что мигрировать с одного на другое смысла нет. Единственное в чем я вижу разницу так это в способах создания запросов — генераторы в пони против обычных выражений типа: .filter((Person.birthday > d1940) & (Person.birthday < d1960)). Во всем всем остальном DSL почти 1 в 1 как алхимии, судя по докам.
Чем же вам не понравилась алхимия? Самая мощная Python ORM, да DSL у нее очень даже ничего
Так же как и в SQLAlchemy — перегрузкой операторов
На самом деле достаточно просто достичь справедливого распределения монет в PoS схеме. Ведь основная идея PoS это снижение стоимости транзакций на порядки и устойчивость к атакам 51%. Просто нужно оставить PoW как средство генерации монет, а PoS как средство проверки целостности транзакций для создания блоков. Почему авторы этого не сделали меня удивляет, ведь в таком случае было бы достигнуто то самое свойство биткоина за что его и полюбили — справедливость — ни Сатоши, ни первые майнеры не являлись владельцами всех биткоинов. Каждый мог присоединиться и ни вкладывая значительных ресурсов, ни идя на биржу, мог намайнить какие-то крохи.
Не понимаю почему минусуют этот комментарий, ведь сточки зрения техники и безопасности этот метод аутентификации отличается от привычной cookie-based аутенцификации только тем, что вместо куки теперь мы имеем файл
В каждом авторизационном файле хранится некоторая сгенерированная случайным образом строка символов, для которой в базе данных на сервере есть хэш, привязанный к определённому идентификатору пользователя.

Ну ведь это и есть cookie-based аутентификация.

Даже более того, если использовать такой способ как замену пароля, то он менее секурен чем куки+пароль, потому что любой троянец, да что там троянец, жена\любовница\брат\сестра сможет увести такой файл и получить полный доступ к пользовательскому аккаунту, включая смену настроек. Если же использовать такой метод в связке с паролем, то тогда отпадает весь смысл в такой авторизации, потому что если пользователь знает пароль, зачем его спрашивать какой-то файл? Точнее даже так — если пользователь имеет какой-то файл с уникальным идентификатором — зачем его разлогинивать и спрашивать идентификатор, когда можно этот уникальный идентификатор сохранить в куки?

Если прям так уж действительно хочется сделать аутентификацию без пароля, то почему бы не следовать стандартам — для жуткого энтерпрайза использовать клиентские SSL сертификаты, а для обычных пользователей сделать все через mozilla persona

Information

Rating
Does not participate
Location
Саратовская обл., Россия
Date of birth
Registered
Activity