Pull to refresh
100
0
Иван Коробков @drJonnie

User

Send message
Нет, в джаве это именно расшифровыется как new io. Вот полное название JSR 51: New I/O APIs for the JavaTM Platform. В седьмой добавили NIO.2 JSR 203: More New I/O APIs for the JavaTM Platform («NIO.2»)
Подскажите, пожалуйста, будет ли приложение для айфона с плоским дизайном айос 7? Скоро айос 8 выйдет, Альфа-Лаборатория есть, офис веселый есть, а дизайн приложения все еще старый.
OMG, опять опен-спейс. Да как в нем вообще можно нормально работать?
Ага, как раз хотел вам об этом написать. Но в текущей версии не возможно реализовать идемпотентное добавление сообщений в очередь, возможно дублирование. Кажется, они хотят реализовать схему, подобную вашей, в будущих версиях.
Ок, спасибо. Еще один вопрос. Со стороны консьюмеров гарантировать exactly-once обработку сообщений можно, например, хранением текущей позиции в кольцевом буфере вместе с обработанными сообщениями. А как вы гарантируете exactly-once запись сообщений в zookeeper? Гарантируете ли вообще?
Не пытались использовать Kafka от Linkedin, учитывая, что вы уже используете zookeeper как кольцевой буфер, из которого разные бэкэнды читают одни и те же данные?
Ага, не удалась моя попытка для людей что-то новое и хорошее сделать. Мне уже в комментах предлагают даже модули патчить в рантайме и методы классов подменять для тестов. Брр.
А как объекты узнают про ваш мок? Напишите, пожалуйста, как бы вы переписали код с тестом из самого первого примера с User + Mailer.
Это скорее про моделирование интерфейсов. А вообще zope — это попытка сделать энтерпрайз в питоне. Во всяком случае так было раньше.
Скорее, зачем вообще нужно внедрение зависимостей, потому что сама концепция вне языка.

Смотрите, у вас в приложении много взаимодействующих компонентов. Например, как в статье, у вас есть Mailer, который отвечает за отправку электронной почты. Это может быть какая-то очередь, а может SMTP-клиент. Этот Mailer используется во многих местах: при регистрации пользователя, подтверждении почты, восстановлении пароля, в рекламных рассылках. Т.е. этот компонент используют различные классы.

В приложении для использования мейлера вам нужно его создать с правильными настройками один раз, а в тестах нужно использовать мок, а не настоящий мейлер, чтобы не отправлять почту по-настоящему. Вот это и позволяет внедрение зависимостей. Вы указываете, какие вам зависимости нужны в конкретных местах и не заботитесь об их инициализации.

Самой концепции много лет. Подробнее можно почитать на википедии, хотя информация там довольно запутанная. Нужно ли вообще внедрение зависимостей? Да, это не только мое мнение. Посмотрите на количество фреймворков, в т.ч. и от Гугла: Google Guice, Spring, Google Pinject, Objective-C Typhoon и многие другие.
Думал, я много вариантов рассматривал, но не получится. Пидеф функционально намного мощнее. Он поддерживает нормальные цепочки вызовов, а JSON-RPC только название метода и его аргументы. Например, в пидефе возможен такой вызов:
github().user("ivan-korobkov").repo("pdef").like();

Он уйдет вот таким запросом на сервер:
POST /user/ivan.korobkov/repo/pdef/like HTTP/1.1

Т.е. изначально пидеф намного ближе к обычному REST'у, только пока ограничений больше.
Хотелось бы чтобы сообщество разработчиков помогло с кодогенераторами для других языков. Точно не хватает PHP, JavaScript, Ruby, C++, C# и многих других языков. Если говорить про развитие самого языка, то на несколько месяцев думаю заморозить функциональность. Это поможет стабилизировать проект. В дальнейшем хотелось бы добавить аннотации и полноценную поддержку REST. Это два приоритетных направления. Плюс, возможно, появится официальный бинарный формат для серверного взаимодействия (скорее всего MessagePack).
Пидеф — это не протокол сериализации, в отличие от Protobuf, Avro, Thrift, MessagePack и Cap'n Proto. Формат данных может быть любым. По-умолчанию, это JSON. Если говорить о функциональных отличиях, то он поддерживает циклические зависимости, наследование и интерфейсы (как и Cap'n Proto). Плюс, пидеф использует HTTP, тогда как все остальные — собственные бинарные форматы передачи данных.
BTM — это и есть XA менеджер, он и выполняет. Ссылка есть в ответе на мой первый вопрос.
А что будет если менеджер two-phase коммита умрет в момент совершения транзакции, которая prepared на обоих базах данных, но закоммичена только на одном из них?
Каким образом обеспечиваете консистентное состояние при взаимодействии с двумя и более базами данных одновременно? Например, при продаже предмета нужно зачислить деньги одному игроку на шарде А и списать деньги с другого игрока на шарде Б. В целом, как обеспечиваете и обеспечиваете ли вообще атомарность распределенных изменений, затрагивающих несколько шардов? Спасибо.
Можете рассказать поподробнее:
  1. Для агрегации событий нами была разработана специальная СУБД
    Если я правильно понимаю, то для пользовательских данных вы используете реляционную базу данных, а для событий собственную. В этом случае, каким образом вы гарантируете консистентность данных между ними? Two-phase commit, idempotence или какой-нибудь другой механизм?
  2. Данные пользователей хранятся не только в памяти, но и сохраняются на диск, поэтому уведомления не теряются [при перезапуске демона]. Каким образом вы обеспечиваете durability и высокую производительность [25kreq/s]? append-only + fsync на несколько событий или иным способом? Возможна ли все-таки потеря данных при падении демона?
  3. Каким образом вы отмечаете отправленные события? Что будет, если электронное письмо или push-уведомление уже отправлено, событие еще не помечено, как отправленное, а демон упал? Будет ли одно и то же событие продублировано при перезапуске демона (т.е. получит ли пользователь два одинаковых сообщения)?

Спасибо.
Но круче:
def uniq(iterable):
  result = list(set(iterable))


Это не круче. Из названия функции не понятно, что она должен обязательно возвращать список. Лучше просто использовать set там, где нужны только уникальные значения, и не придумывать бессмысленных функций.
Большое количество реальных сравнений производительности Java написано людьми, у которых есть только начальные представления о ней. К сожалению, в этом случае легко получаются результаты, которые свидетельсвуют о ее низкой производительности. Чаще всего это происходит из-за отсутствия «прогрева» приложения перед тестированием (чтобы JIT заработал), плюс, незнание об автобоксинге примитивов в коллекциях (в джаве все примитивы преобразуются в объекты перед помещением в коллекции).

Однако во многих случаях производительность джавы может держаться на уровне C++. Лучшей статьей на эту тему, наверное, является Java vs. C Performance… Again от одного из прошлых сотрудников Sun и разработчика серверной версии JIT-компилятора, Cliff Click.

Information

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