Не откладывая в долгий ящик решил затестить сервис в боевых условиях побудки в питере в 7 утра. Результат — реклама нокии и на 7 минут позже назначенного.
Ну это крутоватое обобщение. Когда надо обраратывать больше тысячи-другой одновременных соединений модель «одно соединение — один поток» просто не вписывается ни в какие бюджеты.
С другой стороны пихать в колбэки операции которые а) должны выполняться asap, б) потребляют очень ограниченный ресурс (вроде запросов в БД) не очень понятно зачем.
> Статья про порно — 299 добавлений в избранное.
Извините, ещё не дочитал :)
> Так какого хера мне тогда во все статьи пишут «какое это отношение имеет к тематике Хабра!!! одынодын»
Люди натыкаются на различия между рельностью и своими идеалами и не находят ничего лучше, чем пожаловаться.
Во-первых техническую статью (особенно неслабо специфичную) я бы оценивал по количеству добавлений в избранное. И по этому признаку Ваша статья впереди упомянутых попсовых топиков.
Во-вторых хабр-место для того что даёт создателям трафик — это флуд и новости, такова реальность. Хотите писать технические тексты — заведите блог, это не сложно.
Для того чтобы переложить ответственность на разработчика потомка нужно детально задокументировать требования к потомку. Очень детально.
Мало того даже после этого, если Петя плохо прочитает документацию и напишет кривое расширение, его коллега Вася с вероятностью 90% сначала проедется по мозгам разработчиков библиотеки и только потом по мозгам Пети.
Ответственность когда что-то пишется и ответственность когда что-то ломается и отлаживается в общем слабо связаны. Да потом можно будет сказать «разработчик потомка — засранец». Вот только автор бибилиотеки перед этим проползёт на брюхе по обоим кодовым базам, а автор расширения получит подробное описание проблемы.
> Overriden. Делать методы с оператором доступа, чтобы можно было переопределить методы. (как минимум protected, используйте очень редко уровень доступа меньше защищенного)
> Last Version is Evil. Не использовать ключевое слово final для функции и классов. Позволять переопределять функции и классы
В теории хорошо. На практике это означает что работать с такими методами безопасно нельзя, надо проверять выходы, ловить исключения. Это разрастание кода библиотек в разы.
Не совсем понятно как работает pipeline. Он пропускает все события через каждый обработчик? Тогда получается, что у нас сначало событие декодируется, потом кодируется назад, потом обрабатывается.
В первом листинге у вас есть код new PlayerHandler(decoder, encoder), но в листинге с самим PlayerHandler не приведён конструктор. Ворос: как используются эти два параметра, зачем они?
Ещё, в PlayerHandler есть аттрибут worker типа PlayerWorkerThread — что он делает? Почему он создаётся заново при каждом новом соединении и сохраняется прямо в аттрибут объекта и оттуда же берётся при отсоединении? Если он и правда поток, то это ведь всё та же модель что и со старым IO: одно соединение — один поток, нет?
Вы берёте асинхронный код, искуственно, только для дебага его синхронизируете по каким-то точкам и проверяете, что он правильно обходит эти новые точки синхронизации. Это круто, но никак не связано с правильностью работы кода в поле с выключенным дебагом.
Согласен. Гит выглядит наиболее популярным (или просто сообщество наиболее голосистое) при это у других систем не видно значительных и явных преимуществ. Так что да, в основном поддерживаю становление де-факто стандарта.
Опишите существующую. Внятное описание вашего сервиса уберёт половину негодующих из комментариев. Я, например прочитал «мой мега-сайтик-погоды с 9000 баннеров теперь потеряет 10% нагнанного чёрным SEO трафика и таки скатится ниже точки окупаемости».
С таким подходом к пользователям вы не будете зарабатывать независимо от любых фичей яндекса. Посмотрите вокруг: модель «заманить пользователя, показать банер, получить полкопейки, забыть о пользователе» близка к вымиранию.
С другой стороны пихать в колбэки операции которые а) должны выполняться asap, б) потребляют очень ограниченный ресурс (вроде запросов в БД) не очень понятно зачем.
Кроме того, асинхронность возможна не только на callback'ах. «реальный пример» может быть и без них.
Извините, ещё не дочитал :)
> Так какого хера мне тогда во все статьи пишут «какое это отношение имеет к тематике Хабра!!! одынодын»
Люди натыкаются на различия между рельностью и своими идеалами и не находят ничего лучше, чем пожаловаться.
Во-вторых хабр-место для того что даёт создателям трафик — это флуд и новости, такова реальность. Хотите писать технические тексты — заведите блог, это не сложно.
Мало того даже после этого, если Петя плохо прочитает документацию и напишет кривое расширение, его коллега Вася с вероятностью 90% сначала проедется по мозгам разработчиков библиотеки и только потом по мозгам Пети.
Ответственность когда что-то пишется и ответственность когда что-то ломается и отлаживается в общем слабо связаны. Да потом можно будет сказать «разработчик потомка — засранец». Вот только автор бибилиотеки перед этим проползёт на брюхе по обоим кодовым базам, а автор расширения получит подробное описание проблемы.
> Last Version is Evil. Не использовать ключевое слово final для функции и классов. Позволять переопределять функции и классы
В теории хорошо. На практике это означает что работать с такими методами безопасно нельзя, надо проверять выходы, ловить исключения. Это разрастание кода библиотек в разы.
Не совсем понятно как работает pipeline. Он пропускает все события через каждый обработчик? Тогда получается, что у нас сначало событие декодируется, потом кодируется назад, потом обрабатывается.
В первом листинге у вас есть код new PlayerHandler(decoder, encoder), но в листинге с самим PlayerHandler не приведён конструктор. Ворос: как используются эти два параметра, зачем они?
Ещё, в PlayerHandler есть аттрибут worker типа PlayerWorkerThread — что он делает? Почему он создаётся заново при каждом новом соединении и сохраняется прямо в аттрибут объекта и оттуда же берётся при отсоединении? Если он и правда поток, то это ведь всё та же модель что и со старым IO: одно соединение — один поток, нет?
Вы берёте асинхронный код, искуственно, только для дебага его синхронизируете по каким-то точкам и проверяете, что он правильно обходит эти новые точки синхронизации. Это круто, но никак не связано с правильностью работы кода в поле с выключенным дебагом.