, вы же затёрли массив $data на boolean-значение. Да и параметр $item, полагаю, следовало бы оформить как ссылку, чтобы соответствовать другим участкам кода.
Т.е. лучше оформить так этот кусок
array_walk($data, function (&$item) {
$item += 1;
});
Поправьте, пожалуйста, фразу «Часовой пояс в Нью-Йорке — PST (-08:00)». На самом деле там стандартно EST (-05:00), а летом EDT (-04:00). Ну и в том же абзаце ниже ещё есть PST.
Несколько десяткой файлов в каталоге Вам кажется много (хотя никто не запрещает их группировать в подкаталоги).
А как тогда несколько сотен/тысяч строк в файле с трейтом (который нужно постоянно поддерживать), удобно так работать?
А если нужно сообщения об ошибках вынести в одно место, то достаточно использовать Yii::t().
Хорошо, только сегодня сел обновляться до Yii 2.0.14 (+ расширения). И хорошо, что задачу ещё не закрыл. Придётся проверить теперь все вызовы findOne(), findAll(). Но в моём случае эта статья ой как вовремя.
Аэрофлот не прав, поскольку на разных экранах у него разные даты. Когда автор проверял (ну, допустим) подробности заказа, стояла ПРАВИЛЬНАЯ дата. Можно на это давить.
Просто программисты сайта, видимо, знают, что с таймзонами нужно ОЧЕНЬ аккуратно обращаться, а программисты аппликейшена — к сожалению, нет.
Ага. Ну то есть если у нас тест сломался при подмене на return null, то всё хорошо, а если не сломался, то с тестами что-то не то. Просто при наличии строгой типизации наличие такого мутанта (как в return type) бессмысленно. Теперь вроде ясно. Спасибо.
Давно думал, что процент покрытия тестами не говорит о качестве этого покрытия.
Спасибо за статью.
Возник вопрос. Насколько я понял, чтобы использовать Infection, код должен быть написан в соответствии с типизацией php7? Или же налачия php-doc с секциями '@param' и '@return' будет достаточно (просто код писался ещё под php5.6, только недавно обновились до php7)?
Значит я что-то не так понял из статьи (да, я не пробовал GraphQL). Но я и не осуждаю данный подход (как кто-то мог подумать), в своих ситуациях вполне может подходить. Как идея, он мне даже нравится.
Я про тот случай, когда ко мне приходит фронтендщик, мол, мне нужен такой ендпойнт с такими-то данными (как пример, список постов и для каждого список ВСЕХ комментариев, пример вполне реальный, названия сущностей изменены, но суть та же, лимитирование, пагинация — нет, не слышал). И если у него будет возможность построить самому такой запрос с помощью GraphQL, я не смогу его отговорить, я об этом просто не буду знать. Опять же, если я что-то не так понял, прошу прощения.
С другой стороны, если уровень бекенд разработчиков недостаточен, чтобы построить более-менее нормальную REST архитектуру (с учётом всех пожеланий), то особой разницы может и не будет. Поэтому, повторюсь, в конечном счёте больше зависит от рук, нежели от технологии.
Имхо, давать фронтендщикам (при всём огромнейшем уважении к ним) писать запросы к БД посредством GraphQL (в статье об этом ни слова но в конечном счёте это так), нужны очень веские основания для этого и соответствующий уровень фронтендщиков (которые понимают как работает бэкенд и база).
Идея, конечно, интересная, отдать все нужные фронтенду данные одним запросом. НО. Всегда ли это нужно? Когда меня об этом просят, я начинаю задавать уточняющие вопросы, и очень часто оказывается, что не так уж и нужно, просто чуть удобнее (или так кажется), зато часто будет большой оверхед по производительности на сервере и клиенте (да-да, в т.ч. в браузере, хотя я понимаю, что GraphQL изначально предназначен снижать оверхед, но это очень сильно от рук зависит).
В тех случаях, когда действительно нужно в одном запросе отдать связанные данные, ок — это не проблема и в обычном REST. Не отдавать не нужные данные — тоже при необходимости оптимизации траффика реализуется.
К тому же, когда GraphQL API доступно в мир, там реально могут легко атаковать твой сервер на отказ от обслуживания сложными запросами. Т.е. даже знание бэкенд-разработчиком ВСЕХ видов запросов, которые составляет фронт-енд, не спасёт.
Я конечно раньше про это не читал, и могу ошибаться, но пока с моей колокольни выводы такие, не судите строго.
Спасибо за перевод.
Какие-то моменты знал и использовал, какие-то не знал и лично я использовать вряд ли буду (всё-таки много специфичного для фронт-энд), но кое-что почерпнул нового для себя как бэк-эндщика.
Примерно это я и имел ввиду, да.
Если меню и табы можно реализовать на чистом css, я как бы за (это же визуальное оформление).
Но не нарушать семантику. Так что поддерживаю.
Хотя лично я в тех же табах люблю урл без якорей (используя HTML5 History API). Правда без js тут уже не обойтись.
Но как рабочий вариант и без нарушения семантики :target мне кажется интересным. Нужно будет как-нибудь попробовать на досуге.
Спасибо. Буду знать. Файрвоксом почти не пользуюсь, просто как-то искал ради интереса галочку в настройках — не нашёл.
Насчёт моего "нельзя никак" Вы правы, погорячился ))
Валидатор и не должен ругаться. Может вы аяксом значения инпутов отправляете.
Но другой пример. Многие любят в тег p пихать то, что абзацем не является, чисто для упрощения вёрстки (чтобы class не писать). Это нарушение семантики или нет?
В html она и так не слишком богатая… html5 правда пытается это исправить...
Да, конечно интересно. И я в целом за то, что часть логики (отвечающей по сути за отображение), которая раньше была возможна лишь в js, переносится в html и сss: placeholder, transition и прочее. Я лишь против нарушения той минимальной, но семантики, что есть в html.
Интересный подход, заставил задуматься, но использовать на практике, думаю, не стоит.
работа в браузерах с выключенным JavaScript (если в наше время кто-то таким пользуется)
В скобках вообще ключевой момент, согласен.
В современных браузерах (по крайней мере в Chrome и Firefox) даже выключить нельзя никак js.
Насчёт злоупотреблений — да, можно согласиться (видал, когда ради одной единственной функции на 3 строчки подключают тяжеленную библиотеку, особенно когда это в моб. версии).
Но в данном случае вышло злоупотребление HTML и CSS. Как минимум нарушена семантика (используются элементы форм, а форм нету). Хотя сам подход, повторюсь, интересен (в академических смысле), я и не думал, что так можно.
Насчёт фото и background затея не очень — возможно проседание по СЕО. Я не сеошник и может меня поправят, по крайней мере это логично, в img можно (нужно) alt прописать, напр., да и не только поэтому, опять же семантика.
Да я уже понял, что вопрос не в вычисляемых значениях.
Насчёт __toString() не сообразил
понятно, что и насчёт других магических вызовов.
Пользователь Fesor же ответил выше.
Хотя ошибался не только я, но Вы поправили и там ))
А насчёт "проблемы оптимизировать" Сергей ответил уже, дважды.
Я даже полез было выяснять, что же за ZEND_FAST_CONCAT, напоролся на https://github.com/php/php-src/blob/master/ext/opcache/Optimizer/block_pass.c. Дальше решил в исходниках не разбираться и поверить Сергею Протько на слово ))
Сергей, можете пояснить, если opcache выключен, будет ли работать описанная оптимизация (хотя бы на encapsed-строках)?
У нас просто сейчас php5 и apc, но интересно же, что там в семёрке, на будущее.
Я понимаю, что вопросы детские, так и есть, простите. Но полагаю, что это интересно будет не только мне.
$dataнаboolean-значение. Да и параметр$item, полагаю, следовало бы оформить как ссылку, чтобы соответствовать другим участкам кода.Т.е. лучше оформить так этот кусок
А как тогда несколько сотен/тысяч строк в файле с трейтом (который нужно постоянно поддерживать), удобно так работать?
А если нужно сообщения об ошибках вынести в одно место, то достаточно использовать
Yii::t().P.S.: на истину также не претендую.
Создал тикет на обновление.
Есть вопрос насчёт @deprecated.
Будет ли заменён на в генераторах Gii в ветках 2.0? Вижу, что в ветке 2.1 уже заменили github.com/yiisoft/yii2-gii/blob/2.1/src/generators/model/Generator.php
Или всё-таки, пока используется совместимость с php-5.4, будет использоваться устаревший метод?
Есть фичи, которые раньше самому руками приходилось делать. Спасибо.
Аэрофлот не прав, поскольку на разных экранах у него разные даты. Когда автор проверял (ну, допустим) подробности заказа, стояла ПРАВИЛЬНАЯ дата. Можно на это давить.
Просто программисты сайта, видимо, знают, что с таймзонами нужно ОЧЕНЬ аккуратно обращаться, а программисты аппликейшена — к сожалению, нет.
Спасибо за статью.
Возник вопрос. Насколько я понял, чтобы использовать Infection, код должен быть написан в соответствии с типизацией php7? Или же налачия php-doc с секциями '@param' и '@return' будет достаточно (просто код писался ещё под php5.6, только недавно обновились до php7)?
Благодаря ему, даже глянул, какие есть библиотеки на php.
Я про тот случай, когда ко мне приходит фронтендщик, мол, мне нужен такой ендпойнт с такими-то данными (как пример, список постов и для каждого список ВСЕХ комментариев, пример вполне реальный, названия сущностей изменены, но суть та же, лимитирование, пагинация — нет, не слышал). И если у него будет возможность построить самому такой запрос с помощью GraphQL, я не смогу его отговорить, я об этом просто не буду знать. Опять же, если я что-то не так понял, прошу прощения.
С другой стороны, если уровень бекенд разработчиков недостаточен, чтобы построить более-менее нормальную REST архитектуру (с учётом всех пожеланий), то особой разницы может и не будет. Поэтому, повторюсь, в конечном счёте больше зависит от рук, нежели от технологии.
Идея, конечно, интересная, отдать все нужные фронтенду данные одним запросом. НО. Всегда ли это нужно? Когда меня об этом просят, я начинаю задавать уточняющие вопросы, и очень часто оказывается, что не так уж и нужно, просто чуть удобнее (или так кажется), зато часто будет большой оверхед по производительности на сервере и клиенте (да-да, в т.ч. в браузере, хотя я понимаю, что GraphQL изначально предназначен снижать оверхед, но это очень сильно от рук зависит).
В тех случаях, когда действительно нужно в одном запросе отдать связанные данные, ок — это не проблема и в обычном REST. Не отдавать не нужные данные — тоже при необходимости оптимизации траффика реализуется.
К тому же, когда GraphQL API доступно в мир, там реально могут легко атаковать твой сервер на отказ от обслуживания сложными запросами. Т.е. даже знание бэкенд-разработчиком ВСЕХ видов запросов, которые составляет фронт-енд, не спасёт.
Я конечно раньше про это не читал, и могу ошибаться, но пока с моей колокольни выводы такие, не судите строго.
Какие-то моменты знал и использовал, какие-то не знал и лично я использовать вряд ли буду (всё-таки много специфичного для фронт-энд), но кое-что почерпнул нового для себя как бэк-эндщика.
Примерно это я и имел ввиду, да.
Если меню и табы можно реализовать на чистом css, я как бы за (это же визуальное оформление).
Но не нарушать семантику. Так что поддерживаю.
Хотя лично я в тех же табах люблю урл без якорей (используя HTML5 History API). Правда без js тут уже не обойтись.
Но как рабочий вариант и без нарушения семантики :target мне кажется интересным. Нужно будет как-нибудь попробовать на досуге.
Спасибо. Буду знать. Файрвоксом почти не пользуюсь, просто как-то искал ради интереса галочку в настройках — не нашёл.
Насчёт моего "нельзя никак" Вы правы, погорячился ))
Валидатор и не должен ругаться. Может вы аяксом значения инпутов отправляете.
Но другой пример. Многие любят в тег p пихать то, что абзацем не является, чисто для упрощения вёрстки (чтобы class не писать). Это нарушение семантики или нет?
В html она и так не слишком богатая… html5 правда пытается это исправить...
Да, конечно интересно. И я в целом за то, что часть логики (отвечающей по сути за отображение), которая раньше была возможна лишь в js, переносится в html и сss: placeholder, transition и прочее. Я лишь против нарушения той минимальной, но семантики, что есть в html.
Интересный подход, заставил задуматься, но использовать на практике, думаю, не стоит.
В скобках вообще ключевой момент, согласен.
В современных браузерах (по крайней мере в Chrome и Firefox) даже выключить нельзя никак js.
Насчёт злоупотреблений — да, можно согласиться (видал, когда ради одной единственной функции на 3 строчки подключают тяжеленную библиотеку, особенно когда это в моб. версии).
Но в данном случае вышло злоупотребление HTML и CSS. Как минимум нарушена семантика (используются элементы форм, а форм нету). Хотя сам подход, повторюсь, интересен (в академических смысле), я и не думал, что так можно.
Насчёт фото и background затея не очень — возможно проседание по СЕО. Я не сеошник и может меня поправят, по крайней мере это логично, в img можно (нужно) alt прописать, напр., да и не только поэтому, опять же семантика.
Да я уже понял, что вопрос не в вычисляемых значениях.
понятно, что и насчёт других магических вызовов.
Пользователь Fesor же ответил выше.
Хотя ошибался не только я, но Вы поправили и там ))
А насчёт "проблемы оптимизировать" Сергей ответил уже, дважды.
Я даже полез было выяснять, что же за ZEND_FAST_CONCAT, напоролся на https://github.com/php/php-src/blob/master/ext/opcache/Optimizer/block_pass.c. Дальше решил в исходниках не разбираться и поверить Сергею Протько на слово ))
Сергей, можете пояснить, если opcache выключен, будет ли работать описанная оптимизация (хотя бы на encapsed-строках)?
У нас просто сейчас php5 и apc, но интересно же, что там в семёрке, на будущее.
Я понимаю, что вопросы детские, так и есть, простите. Но полагаю, что это интересно будет не только мне.