Viber вводит end-to-end шифрование вслед за WhatsApp и Telegram

Я только проверил. Нету, последний RPM 4.2.2

Viber вводит end-to-end шифрование вслед за WhatsApp и Telegram

Ну перепокавать можно, но это не отменяет того что они не хотят поддерживать в актуальном состоянии версии под линукс (ну в данном случае федора) и все что в первом комментарии. Кстати вопрос, если это так легко и просто сконвертировать, то почему они этого не сделали сами и не выложили? Может все не так просто там?

Viber вводит end-to-end шифрование вслед за WhatsApp и Telegram

Ну как стояла 4.2.2 так и осталась на сайте она же RPM. А какая версия на Вин? 5.0? Или уже выше?

Viber вводит end-to-end шифрование вслед за WhatsApp и Telegram

Ну и как это пошло у них последнее время линукс версия останется за бортом, на блекберри выше 7-й версии вайбер только с амазон маркета где так же апдейтов нету. Конечно введение шифрования это хорошо, но оно много куда не доберется у них. Да и опять же, закрытый протокол. Сказать можно все что угодно.

Project Tofino — новый браузер от Mozilla

Разница только в том, что движок можно форкнуть и будет форк который будете использовать только вы в своем «ещё одном браузере» который врятле наберет популярность. Так что не особо много разницы.

Project Tofino — новый браузер от Mozilla

Вы сможете сделать только форк и сделать свой «ещё один» браузер. Но врятле крупные игроки будут использовать вашу версию движка. Все будут так же использовать хромиум.

Project Tofino — новый браузер от Mozilla

Ну согласно статистике W3 браузер сафари имеет только 3.7% рынка и ИЕ имеет 6% рынка. За последние годы их доля на рынке только снижается. Тоесть мы двигаемся в сторону монополии движка хромиум. А монополия к сожалению такая вещь, что уже можно не спешить с развитием ведь все равно некому отвоевывать рынок. Значит медленное развитие движка, веб технологии сейчас развиваются огромными темпами, браузеры и так не успевают. Да и в целом в этом случае разработчики хромиум смогут диктовать какие веб технологии будут, а какие нет. Так как если им не нравится фича которую допустим выпустят в новом EcmaScript, они просто не добавят поддержку в свой браузер и фича умрет, так как её никто не будет поддерживать.

Project Tofino — новый браузер от Mozilla

Согласен, это хорошо только с точки зрения веб дева в том что не надо держать зоопарк, в целом как по мне отсутствие вменяемой конкуренции (Я не беру в расчет сафари и эдж(ИЕ) ) не пойдет на пользу развитию веба

Project Tofino — новый браузер от Mozilla

Ну помимо этого есть ещё сафари который на движке своем, но это стандартные браузеры встроеные в конкретные ОС. Но в целом их доля очень мала и если хромиум будет везде мы действительно имеем шанс вернутся в времена ИЕ6

Project Tofino — новый браузер от Mozilla

Итого выбор без выбора. Если ФФ таки умрет, то будет выбор браузера из браузеров на Chromium и на Chromium. Это конечно хорошо для меня как для веб разработчика, не нужно держать зоопарк браузеров, движок везде один, так что различия как я понял будут минимальны. Но мне лично не очень нравится работа движка Chromium, я предпочитаю Gecko. Ну и надо признать, браузер на электроне врятли взлетит.

Почему мы ненавидим уведомления на сайтах?

Мне кажется, что просто фича используется не по назначению, я разрабатывая онлайн риал-тайм чат использовал такие уведомления для того чтоб когда пользователь в другой вкладке или свернул браузер ему показывалось системное уведомление о том, что ему пришло новое сообщение. Так что мне кажется. что фича полезная.

Yii framework разбор кода

потому что он генерирует по шаблону, мне ещё никода не доводилось видеть в лайв проекте использование кода gii без изменений.

Yii framework разбор кода

Отдельные экшены имеет смысл только когда нужно использовать некий компонент который должен предоставлять экшн, для примера загрузка изображения в таком случае в контроллер просто подгружается компонент и экшн. Но вы же в статье показали пример на CRUD, а в CRUD мне сложно представить ситуацию, когда у двух сущностей будут идентичные экшены. А если создавать отдельный экшн для каждой сущности, то выйдет каша и классов.

Yii framework разбор кода

Все правильно, и вся бизнес логика у вас находится в модели, так зачем тогда вам 25 классов экшенов если достаточно 5 классов контроллеров, ведь обычно контроллер = сущность и согласно вашему примеру в каждом контроллере будет использоваться разная модель? Или одна? Хорошо, даже предположим, что экшены полностью идентичны для разных 5-ти контроллеров. Но учитывая что вся бизнес логика в модели, вы просто создадите класс-экшн для одной, двух строк. Да вы избавитесь от повторного использования кода, но, возникает три вопроса:

1. Почему нельзя реализовать все таки контроллер с этими экшенами и наследоватся от него?
2. Что вы будете делать когда один экшн одного контроллера потребует изменения логики? Создавать новый экшн-класс?
3. Стоит ли ради "избежания повторного использования кода" разрушать абстракцию данных сущность-экшн? Ведь этого можно избежать используя наследование контроллеров.

Yii framework разбор кода

Зачем 5 контроллеров с одинковым содержимым, если мы говорим о CRUD, то у нас одна сущность имеет 5 экшенов, тоесть если у нас 5 контроллеров (5 сущностей), то у нас 25 экшенов получается. И почему 5 моделей? Скорее 6, базовая модель плюс её наследеники если нужны. Таким образом у нас нормальный уровень абстракции, каждый экшн принадлежит к сущности контроллера и вызывает бизнес логику на основе входящих данных из модели. Все равно ведь Yii реализует парадигму MVC, тоесть даже в вашем случае вся бизнес логика должна быть в модели и у вас просто получается класс-экшн который просто вызывает бизнес логику из модели. Ваш подход применим только к RESTFull API и только если вы не реализуете бизнес логику в моделях, а реализуете её в экшенах.

Yii framework разбор кода

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

Yii framework разбор кода

Да, именно это я и пытался сказать. Зачем плодить класс для каждого экшена если можно наследовать контроллер и не разрушать абстракцию контроллер->экшн.

Yii framework разбор кода

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

Yii framework разбор кода

Просто я не очень понимаю, зачем отрывать экшен от контроллера, тогда ведь нарушается абстракция вся этого контроллера? А дублирование кода, да это плохо. Но в данном случае у меня все равно экшены относятся к контроллерам и не пишется множество не нужных классов, так как вся бизнес логика хранится в модели, ну и экшены у меня все таки просто принимают значения и вызывают метод модели, не более. И тогда никакого дублирования кода, нарушения абстракций и горождения кучи классов ради одного метода. Ведь YII следует парадигме MVC, а значит вся бизнес логика должна быть с моделях.

Yii framework разбор кода

Достаточно интересная статья, но вот момент с экшенами несколько сбивает с толку, тоесть если я правильно понял, вы предлогаете использовать каждый экшн = класс, а не как изначально в Yii когда экшн = метод контроллера. Таким образом вы призываете уйти от абстракции контроллера к абстракции его экшенов, но зачем? В целом я правильно понимаю, что у нас будет 4 класса с экшенами для CRUD контроллера?