• Релиз Yii 2.0.15 и расширений баз данных с исправленными уязвимостями
    0

    Надо бы :)

  • Релиз Yii 2.0.15 и расширений баз данных с исправленными уязвимостями
    0

    Уже выпущены патчи 2.0.15.1, 2.0.13.3, 2.0.12.2.

  • Релиз Yii 2.0.15 и расширений баз данных с исправленными уязвимостями
    +2

    Я не был свидетелем этого решения, но думаю, что findOne() и findAll() были добавлены как вариация findByPk() с бОльшими возможностями, которые были недостаточно задокументированы.


    Для вресии 2.1 есть issue, возможно findByPk() вернётся :)

  • Исчерпывающие бенчмарки PHP 5.6, 7.0, 7.1, 7.2 и HHVM (2018)
    0

    Да, тестировали версию 2.6, которая на Yii1. Сейчас в разработке версия 3.0, которая на Yii2.

  • Исчерпывающие бенчмарки PHP 5.6, 7.0, 7.1, 7.2 и HHVM (2018)
    +1

    Забавно, что в бенчмарк попал Craft CMS, сделанный на Yii2, но не попал сам Yii2 :)

  • Yii 2.0.14
    0

    Да, будет заменён

  • Yii 2.0.14
    0

    Расскажу, как это было. PR с изменениями на пути к JSON – это более 90 комментов, дифф на 71 файл и овер 3800 строк кода. Там перемешалось много контекстов изменений: исправление одновременно несколько старых проблем, добавление нескольких новых возможностей, оптимизация API, реорганизация кода. Делить его на много мелких не получалось, так как все задачи в рамках этого PR – взаимосвязаны. Вычитать вдумчиво и целиком такой PR не деле оказалось отдельной сложной задачей, на которую не хватало концентрации ни у кого кроме SamDark, за что ему отдельное спасибо.


    Я понимаю, что мы (в больше мере – я) косякнули, а этот коммент – лишь попытка оправдаться, но не судите строго. Лучше приходите на GitHub – там всегда не хватает рук и свежего взгляда :)

  • Yii 2.0.14
    0

    Да, упустили это. Спасибо, что заметили. Добавлено в UPGRADE.md

  • Yii 2.0.14
    +1

    Привычка писать документацию и код с учётом того, что мы ещё поддерживаем PHP 5.4 :)

  • Yii 2.0.14
    +1

    Спасибо за уведомление, исправлено в коммите 1b3526d8 и войдёт в патч-релиз 2.0.14.1

  • Yii 2.0.14
    +1

    Список изменений, на которые нужно обратить внимание при обновлении описан в UPGRADE.md для 2.1. Перед релизом мы дополнительно структурируем этот список и напишем гайд по обновлению.

  • Yii 2.0.14
    +3

    Добавлю, что в отличии от перехода 1.1 → 2.0, обновление 2.0 → 2.1 – это эволюционное, а не революционное изменение. Основные цели релиза:


    • отказ от поддержки устаревших версий PHP, которые мешают использованию новых возможностей в коде ядра и усложняют поддержку проекта в долгосрочной перспективе, включая вопросы безопасности.
    • вынос из ядра в отдельные пакеты опциональных составляющих вроде jQuery, DI.
    • архитектурные улучшения и изменение публичного API там, где это требуется для реализации новых возможностей.

    Мы подготовим детальный гайд по обновлению приложения, чтобы процесс был однозначен и понятен.

  • Yii 2.0.14
    +1

    Нет, 2.0.14.0

  • Yii 2.0.14
    +1

    У нас семвер сдвинут на одну позицию вправо, потому получается 2.<major>.<minor>.<patch>

  • Make QR Codes Great Again или камерная революция от Apple
    0
  • Yii 2.0.12
    +4

    Черкануть на GitHub способ воспроизведения и упомянуть предполагаемую причину — это до 10 минут времени, которые сэкономят десятки часов других разработчиков, которые могут столкнуться с той же проблемой.


    Искренне не понимаю, как можно было обнаружить ошибку, поискать ее причину в своём проекте, посмотреть diff'ы кода фреймвока, найти там предполагаемую причину и потом перечеркнуть все потраченные усилия, не открыв issue.

  • Уязвимости выполнения произвольного кода в PHPMailer и SwiftMailer
    +1

    Если у вас есть публичные проекты, в которых разрешены email'ы по всем канонам RFC — поделитесь, пожалуйста, количеством пользователей, адреса которых не проходят валидацию по регулярке из EmailValidator в Yii.

  • Уязвимости выполнения произвольного кода в PHPMailer и SwiftMailer
    +3

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


    Учитывая, что пользователей с вычурным адресом по RFC ничтожно мало, нам проще пожертвовать ими в пользу безопасности.

  • Виджет мультиязычности в YII2 без использования базы данных
    +2

    Кроме того, название MultiLang мне не кажется само-описывающим. Пока не откроешь код, сложно однозначно сказать, что делает этот класс. Что-то про мультиязычность, но что именно?
    Я бы его назвал LanguageSwitcher. Согласитесь, сразу понятно, что это переключатель языков, не так ли?


    Если всё таки использовать composer и подключить оригинальное расширение, можно еще больше упростить себе жизнь. Структуру директорий можно свести до такой:


    frontend\
        widgets\
            LanguageSwitcher.php
            views\
                languageSwitcher.php

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

  • Виджет мультиязычности в YII2 без использования базы данных
    +4

    Спасибо за ваши старания, позвольте высказать свою критику по поводу архитектурных решений.


    'frontend\widgets\MultiLang\components\UrlManager'

    Предложенная иерархия директорий (и неймспейсов) не укладывается в хорошие практики. Виджеты — это виджеты, а компоненты — это компоненты. Если у вас есть компонент, а рядом с ним — виджет для работы с этим компонентом, при этом существует общая предметная область, с которой ведется работа — это больше похоже на расширение.


    Я бы предложил выделить это в отдельный репозиторий, или (если не планируется переиспользование) — разместить код в вашем проекте таким образом:


    frontend\
        extensions\
           MultiLang\
          Components\
            UrlManager.php
          Views\
            View.php
          Widgets\
                MultiLang.php

    содержание файла взято отсюда, можно следовать инструкции разработчика и использовать composer, но мы то делаем виджет, по этому просто скопируем UrlManager.php в наш виджет

    Копируя UrlManager.php в свой проект, вы лишаете себя чудесной возможности получать обновления с улучшениями и исправленными ошибками из оригинального репозитория. Отказ от использования composer в пользу копи-пасты — один из самых вредных советов для PHP разработчика в 2016 году.


    Что касается кода виджета:


    use yii\helpers\Html;
    
    class MultiLang extends \yii\bootstrap\Widget
    {
        public $cssClass;
        public function init(){}
    
        // ...
    }

    Класс \yii\bootstrap\Widget находится в отдельном репозитории yii2-bootstrap и наследуется от yii\base\Widget, добавляя некоторые методы для работы с Frontend-фреймворком Bootstarp. Вы не используете никаких возможностей этого класса, достаточно будет наследования от yii\base\Widget.
    Кроме того, вы указали лишний use и без какого-либо смысла предопределили метод init().


    В коде представления вы указали use Yii;, но каждый раз при обращении к Yii явно указываете namespace:


    \Yii::$app->request->get()

    Да и если следовать правилам распределения ответственности в MVC, представление не должно "добывать" данные самостоятельно — данные должен собрать тот, кто вызывает рендер представления. Было бы уместно избавится от обращения к компонентам request, controller и свойству language из представления, а перенести это в виджет.

  • Новости Yii 2. №1
    +2

    На уровне обработчиков событий XHR запросов. Код тут

  • Взлом вконтакте: украдены данные 171 миллиона пользователей
    0

    На странице https://www.leakedsource.com/blog/vk в разделе Passwords написано следующее:


    Passwords were stored in plaintext with no encryption or hashing. The methods VK used for storing passwords are not what internet standards propose because hackers can now see all 100 million passwords used on the site.

    Пароли хранились в открытом виде без шифрования или хеширования. Эта стратегия хранения паролей позволила хакерам получить все 100 млн паролей, используемых на сайте.

    Не хочется верить что в таком крупном и относительно взрослом проекте применяются такие небезопасные подходы. Хотя все подробности указывают на то, что сказанное выше — правда. Как-то совсем тупо получается :(

  • Как сделать быстрое веб-приложение или 8 советов разработчикам по оптимизации кода
    0

    То ли дело программировать ради решения задачи, забыв в том, что к коду еще придётся вернуться. Тогда гарантировано можно показать примеры своих работ, но главное — не показывать код :)

  • Как сделать быстрое веб-приложение или 8 советов разработчикам по оптимизации кода
    0

    Истину глаголите, сударь :) ORM — инструмент, а любой инструмент нужно использовать с умом

  • Как сделать быстрое веб-приложение или 8 советов разработчикам по оптимизации кода
    +10
    Тогда мы вынесли этот функционал в виде глобальной фунцкции в отдельный файл includes/sms.php и спокойно использовали в разных модулях в таком виде

    На дворе 2016 год, уже 5 лет как существует Composer. Тут вам и избавление от include 'sms.php', и запуск функционала по необходимости.


    В вашем примере с СМС вместо глобальных функций неплохо было бы сделать Helper-класс со статическими методами. А еще лучше — компонент приложения, зарегистрирован в Service Locator и доступный из экземпляра приложения — тогда будет и действительная гибкость настройки, и возможности для тестирования. А если заглянуть еще глубже, то отправку SMS сообщений нужно делать отложено через очереди, чтобы пользователь не ждал, пока ваше приложение сходит в чужое АПИ.


    В Diafan.CMS всего один шаблон для построения ссылок: /строковоеЧПУ/числовойпараметр3/другойчисловойпараметр25

    Очень плохо, что шаблон всего один и, скорее всего, прибит гвоздями к коду. Требования бизнеса поменяются и придётся переделывать код, вместо пары строк конфигурации.


    Минимизируйте количество запросов к БД

    А еще можно попробовать использовать ORM и решить многие описанные проблемы архитектурно. Кстати, все ваши примеры кода в этом блоке синтаксически неверны и жутко отформатированы (загляните в PSR).


    Вещи говорите местами правильные, но пора переходить на следующий уровень. PHP уже давно не такой, каким вы его показываете ;)

  • Шаг за шагом: Трансляция данных на flightradar24
    0
    Я тоже немного попараноил и пару дней после установки снифал весь трафик. Пролистал дампы, ничего интересного не нашел.
    Все, что стоит на малине есть на GitHub в репозиториях организации: https://github.com/flightaware
  • Шаг за шагом: Трансляция данных на flightradar24
    +1
    Нет, не пробовал. Согласно условиям FlightAware, я не имею права разбирать их коробку и что-либо делать с малинкой. Доступа по SSH нет, получить можно через Single user mode, но для этого нужно разобрать и достать флешку.
    Все работает из коробки без каких-либо проблем, а софт Flightradar24 стоит на домашнем компе, получает по локальной сети RAW данные от dump1090 и рестримит их на fr24. Конфиг:
    fr24feed.ini
    receiver="avr-tcp"
    fr24key="paste your key here"
    host="192.168.1.2:30002"
    bs="yes"
    raw="yes"
    logmode="1"
    windowmode="1"
    mpx="no"
    mlat="no"
    mlat-without-gps="no"
  • Шаг за шагом: Трансляция данных на flightradar24
    +2
    Расход трафика мизерный
    График с порта (5 кбайт)

  • Шаг за шагом: Трансляция данных на flightradar24
    0
    Я свой комплект получил от FlightAware
  • Шаг за шагом: Трансляция данных на flightradar24
    +3
    Отличный пост! Сам недавно стал принимать ADS-B данные. Хорошая антенна, будучи установленной на высоте около 30 метров, она дает 250+ морских миль покрытия (460+ км), что впечатляет.
    Антенна на 1090 MHz, 200 кб


    Сейчас на flightradar24 идет кампания по расширению покрытия и есть возможность запросить ADS-B оборудование бесплатно. Присылают антенну для 1090 mHz, GPS антенну для синхронизации времени, коробку с электроникой (Plug and play), 5 метров кабеля для GPS, 5 метров Ethernet кабеля и 5-10 метров коаксиального для ADS-B антенны. Запрос удовлетворяется на основании необходимости организации дополнительного покрытия местности, где вы планируете установить антенну. Вам нужно будет хорошо это все дело установить с обзором в 360 градусов, дать круглосуточный интернет и питание. Подать запрос можно тут.
    Кроме flightradar24 есть еще один похожий проект FlightAware. Сейчас они также заинтересованы в расширении сети сбора данных, потому готовы бесплатно прислать комплект очень хорошего оборудования, а именно: антенну для 1090 MHz; коробку с Raspberry PI и качественным ADS-B приемником (также Plug and play); 5-15 метров приличного коаксиального кабеля, 5 метров Ethernet, футболку и премиум на их сайте. Запросы принимаются тут.
    Кроме того, FlightAware не против, если вы будете делиться получаемыми данными с любым другим сервисом. Это значит, что вы можете запустить клиент flightradar24, сливать данные и иметь премиум еще и на flightradar24. Политику flightradar24 по этому поводу не знаю, потому работает ли в обратную сторону — не скажу.
    Так что если кто-то загорелся идеей и может установить антенну на хорошее место с отличным обзором без препятствий, накормить интернетом и электричеством — вы знаете что делать :)
  • Yii framework разбор кода
    +7
    Yii первой версии (о котором вы пишете) уже очень отстал от современных трендов PHP, потому прием улучшений прекращен, а датой End of life объявлен конец 2018 года. Если вы пишете новый проект — обязательно посмотрите на Yii2, там вы найдете гораздо более гамотные и современные архитектурные решения.
  • Анонимный Дед Мороз 2015-2016 — Пост хвастовства новогодними подарками
    +4
    Точно есть бан для плохих дедушек. А для плохих внуков есть?
  • Молчание GitHub: участники сообщества не могут заставить руководство платформы исправить ошибки платформы
    0
    Ага. Речь идет о вот этом issue: github.com/isaacs/github/issues/9
  • Анонимный Дед Мороз 2015-2016 — Пост хвастовства новогодними подарками
    +13
    Тогда просто ЛС, а не в трекер. Уведомления об ЛС падают на почту по умолчанию
  • Анонимный Дед Мороз 2015-2016 — Пост хвастовства новогодними подарками
    +13
    Хм, не ты ли мой дедушка? :) Мне дедушка написал перед НГ, что выбрал подарок, уточнил мой адрес и с тех пор не заходит :(

    А по сути — идея рассылки очень правильная. Уведомления от приложений в Хабрацентре на почту то не приходят.
  • Анонимный Дед Мороз 2015-2016 — Пост хвастовства новогодними подарками
    +18
    Еще раз пожалуйста, внучек. Расскажи вкратце о впечатлениях, как сходишь, пожалуйста :)
  • Как правильно внести свою лепту в Open Source проект: простые подсказки
    +6
    В любом крупном проекте найдется хорошая стопка issue или PR, которые висят месяцами или даже годами. Залипают обычно некритичные и часто сложновоспроиводимые проблемы, улучшения, сломы обратной совместимости, неоттестированные опасные PR. Рассматривая новый PR всегда перебираешь варианты: а нужны ли эти изменения, не дублируют ли они что-то существующее, не сломается ли чего, не зарыт ли тут слом обратной совместимости, придется ли менять документацию, и так далее.

    Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?

    Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
  • Как правильно внести свою лепту в Open Source проект: простые подсказки
    +2
    Отличная статья, спасибо. От себя добавлю, что нормальные описания PR или Issue очень важны. Есть много статей о том, как правильно составлять баг-репорты, но я представляю идеальный баг-репорт так:

    1. Суть проблемы;
    2. Минимальный код для воспроизведения и описание окружения;
    3. Текущий результат;
    4. Ожидаемый результат.

    Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
  • Клуб анонимных Дедов Морозов 2015-2016 на Хабрахабре
    +1
    В смысле уже есть и можно писать в ЛС? Или будет какая-то специальная процедура?
  • Наследование ActiveRecord's, описывающих одну таблицу (паттерн single table inheritance) в Yii2
    +3
    О черезмерно толстых моделях писал nepster09 в своей недавней статье Разработка приложений на Yii2 без опыта — прямой путь в АД, но по моему мнению, проблема сводится к сугубо архитектурной и решается очень аккуратно, хороший пример Tairesh и показал.

    Такая структура моделей может быть особенно полезной, когда разные типы одного объекта требуют разных правил валидации или специфического поведения. Описывание особенностей разных типов одной модели в одном классе быстро превращает его в сложноподдерживаемое месиво. А если еще и добавить сценарии — можно плакать. Проверено :)

    Что касается практики, я бы добавил, что создание объектов базового класса Car не всегда хорошая идея. Я вижу две стратегии:

    1) Car — суперкласс. Есть базовые правила валидации того, что есть у всех, типа
    [['type', 'name'], 'required']
    , но создание машин через этот класс невозможно, обязательно использовать уточненные классы. Это хорошо, когда каждый тип гарантированно имеет что-то свое, чего принципиально не может быть у базового и не пересекается с другими. Например, у спортивной машины, наверняка, не будет сцепного устройства для прицепа :)

    2) Car — общий класс машины. Применим, когда удовлетворяет требованиям для создания большинства записей, но лишь некоторые типы содержат что-то специфической и требуют отдельных правил, которые будут вынесены в отдельный класс.

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