Может войдёшь?
Черновики Написать статью Профиль
Proger_XP

Proger_XP +159

Вступил в наши ряды: 9 апреля 2012

Замечен в последний раз: 9 января 2017

Оставил на форуме: 1 024 сообщения и 11 тем

Последнее сообщение: 3 дня назад

Сайт: laravel.ru

GitHub: ProgerXP

Вы сможете отправить письмо, если войдёте

Статьи (32)

Два шаблона проектирования, которые сделают ваши приложения лучше

перевод

Применение шаблонов проектирования на практике может вызывать некоторые сложности. Представьте себе ситуацию. Маленький ребенок, интересующийся техникой, играет в игрушечные машинки. Тут подходим мы, и предлагаем ему начать проектирование и строительство автозавода по производству автомобилей (это именно то состояние, в котором я находился, когда меня не очень учтиво ввели в тему шаблонов). Но это не должно быть нашей на них реакцию. Данное руководство о двух шаблонах поможет вам существенно улучшить структуру вашего приложения и шаг за шагом постигать и внедрять новые технологии.

Шаблон репозитория

Хранилище является…

REST API в ваших пакетах

перевод

Зачастую у вас появляется желание предоставить вашим пользователям разные способы взаимодействия с вашим пакетом. Обыным решением является создать REST API к вашему пакету для обработки данных.

Изначально, я хотел получить приятный одностраничный интерфейс для Laravel-FAQ. Для этого в рамках подготовки к этому я работал над созданием гибкого REST API, который позволит добавлять реализованный функционал, когда мне это понадобиться…

Шаблон проектирования "Репозиторий" в действии

перевод

Две недели назад я обсуждал статью «Два шаблона проектирования, которые сделают ваши приложения лучше». После этого появился огромный интерес к демонстрации шаблона «Репозиторий» в действии. Сегодня мы посмотрим, как репозиторий подходит для Laravel Faq Page.

Просто говоря, репозиторий — это абстрактный слой между каким-либо хранилищем и вашим приложением или бизнес-логикой. Это примерно то же, как если бы вы могли подойти к полке для книг и взять нужные из них одним движением руки. Итак, давайте посмотрим на задачи…

Интервью с Jeffrey Way (2013)

перевод

Если вы читаете наш сайт какое-то время, то вы знаете, кто такой Джеффри Вэй. Он — миф и легенда, первый человек в развитии сайта Nettuts+ и влиятельный голос в сетевом сообществе разработчиков. И сейчас он энергично берется за обучающие он-лайн курсы на Tuts+.

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

Вопрос: Читатели хотят знать, где же на самом деле Джеффри Вэй?

У Laravel появятся платные премиальные компоненты

перевод

Оригинальная статья была опубликована 5 января 2014 года — прим. пер.

Taylor Otwell — непосредственный автор и руководитель проекта Laravel — вчера неожиданно заявил, что следующая версия Laravel (4.2) станет придерживаться модели «freemium» для некоторых «не критичных» компонентов. По его словам:

Ядро фреймворка должно включать только компоненты, которые нужны большинству веб-приложений. Но как быть с тем, что нужно многим из нас? Есть кое-каких отличные компоненты, которые я хочу создать за следующие 5 месяцев…

Тейлор: "Объединяя PHP"

перевод

В течении последних нескольких недель шли активные дискуссии на тему сообщества PHP, пакетов и «фракций». Поэтому я решил высказать свою точку зрения на эти вопросы. На сегодняшний день Laravel — самый полноценный эклектичный PHP-фреймворк из всех существующих. Другими словами, Laravel — единственный полноценный фреймворк, который активно борется против фракций (разработки библиотек, подходящих под использование только в определённой среде — прим. пер.).

Laravel, в дополнение к своим собственным библиотекам вроде Eloquent и Blade, также включает целых 23 пакета из открытого сообщества…

Ответ Тейлора на статью "Не используйте фасады"

перевод

Сегодня после обеда на Reddit появилась статья, которая предостерегает пользователей Laravel от использования так называемых «фасадов» (шаблон проектирования в ООП — прим. пер.).

В случае с Laravel, фасады — это то, что используется, когда вы делаете, на первый взгляд, статический вызов метода класса. Например:

PHP
Route::get('/''HomeController@showWelcome');

Eloquent - выборка, добавление и изменение записей

перевод

Eloquent — это название для очень гибкой и выразительном ORM-системы, входящей в состав Laravel. ORM обозначает Объектно-ориентированное представление — способ доступа к вашим таблицам БД, как будто это объекты. В двух словах, это очень классно.

ORM позволяет разрабатывать приложения быстрее и, если это качественная…

Защита данных - шифрование в Laravel

перевод

Иногда вам нужно защитить свои данные. В Laravel для этого есть два метода: одностороннее и двустороннее шифрование. Посмотрим на них подробнее.

Одностороннее шифрование

Одностороннее шифрование — лучший способ для сохранения паролей или других важных пользовательских данных. «Одностороннее» значит, что вы можете преобразовать данные в зашифрованную строку, но благодаря запутанным алгоритмам и высшей математике обратное преобразование не возможно.

С помощью этого вы можете легко хранить пароли ваших пользователей — им не нужно волноваться о том, что вы…

Миграции

перевод

Миграции — одна из наиболее моих любимых возможностей в Laravel. Я очень не люблю писать SQL — и класс PHPSchema позволяет создавать нужные мне таблицы даже не вспоминая об этом пресловутом «языке программирования». Кроме того, код, использующей PHPSchema очень красив и читается так же просто, как обычный связный текст.

Если вы до сих пор не сталкивались с миграциями — это просто способ описать в одном файле изменения вашей базы данных — при этом разные…

Есть ещё статьи

Комментарии (69)

Proger_XP
  1. чтобы не «насиловать» сервер в случае DDOS

О, ну это просто отговорка — в любом веб-приложении тонна мест, где можно получить DDoS: та же авторизация по определению требует тяжёлых вычислений хэша, или фильтр каких-нибудь товаров, который не может покрыть все поля индексами. А некоторые типы атаки (на канал) вообще не требуют никаких действий от сервера, ими можно завалить даже отдачу статики, безо всяких PHP. Конечно, специально создавать бутылочные горлышки не нужно, но именно защищаться от DDoS нужно на другом уровне (сетевом).

  1. в любом случае COUNT будет быстрее SELECT

Это спорно и зависит от типа запроса. Например, если в запросе нет ORDER B Y, то SELECT от SELECT с COUNT отличается только тем, что первый передаёт данные по сети, а второй нет. Если БД стоит на том же сервере, что и PHP — накладные расходы на копирование данных через память минимальны, зато сложный WHERE выполняется в обоих запросах дважды, что в зависимости от настроек БД и доступной памяти может не кэшироваться.

ИМХО, в первую очередь код должен быть кратким и «красивым» (последнее субъективно). Остальное это предоптимизация, которая обычно приносит больше проблем, чем пользы.

Proger_XP
  1. PS: лучше код гляньте, скажите — правильная ли реализация или я что-то не учел или мог бы сделать лучше?

Явных проблем не вижу, но есть два момента, из-за которых вы делаете два запроса вместо одного.

PHP
if (count($this->query) > 0) {

Это может вызывать повторный запрос, т.е. внутри paginator будет делаться два запроса (нужно проверить).

PHP
$items Article::filtered();
$total $items->count();
...
$items $items->skip(($page 1) * $per_page)->take($per_page)->get();

Здесь вы вначале делаете запрос с COUNT, дальше без, но с LIMIT. А зачем первый запрос вообще нужен? Ведь вы после второй выборки уже имеете массив; если он пустой — значит, PHP$page слишком велика и нужно выдавать 404 (по вашей логике). Нет смысла дополнительно вначале проверять общее число записей в таблице, это можно определить из второго запроса.

Proger_XP

ИМХО, это не может быть так — «зеркала» можно создать на любом сайте вообще без усилий, добавив любой параметр к URL (...?foo=bar); с «пустышками» сложнее, но тоже реально. Если такие проблемы и были, то когда-то давно, в то же время, когда URL были «обязаны» с точки зрения SEO иметь расширение .html, а JS-страницы не индексировались вообще.

Proger_XP
  1. К слову, эти же огрехи применимы и к текущей версии Habravel:

Потому что Habravel (внезапно) написан на Laravel, а автор описывает общую «проблему» Laravel. Не знаю, насколько это именно проблема в SEO, ИМХО, поведение логичное и поисковики его должны учитывать.

Proger_XP

Документацию уже частично обновили до 5.3, до 5.4 обновим в течении месяца-двух.

На этом сайте можно публиковать статьи после регистрации, так что хотите помочь — переводите и публикуйте, никто не мешает.

  1. Я «за», чтобы автор перевода ввёл развёрнутые пояснения для новичков в некоторых моментах.

Это перевод официальных английских доков с laravel.com, так что претензии надо направлять к ним.

Proger_XP
  1. жутко много шума

В смысле прыжков по фасадам, которые передают вызовы в другие классы? С этим ничего не сделать, это идеология ядра Laravel. Лично мне это тоже крайне мешает отлаживать проекты отладчиком.

Proger_XP

Шестой пункт (про наставника) выглядит притянутым за уши — есть люди, которым наставник противопоказан и они гораздо лучше во всём разбираются сами. Я сам такой. А остальные пункты дельные и, на мой взгляд, подходят для каждого.

Proger_XP
  1. но и свою предыдущую, которую многие посчитали полезной.

Да, вот это определённо зря, первая статья действительно была многим очень полезна. В твоей статье ничего обидного нет, наоборот, всё объяснено и затрагивает частую проблему.

Proger_XP

Автор исходной статьи «Автозагрузка пространства имён в Laravel 5.3» решил её выпилить, так что не ищите...

Proger_XP

Да, вот это именно то, что нужно. Подробное описание со ссылками на доки.

ИМХО, вариант с изменением файлов Composer напрямую намного трудозатратней, чем собственно правильное решение — 90% пакетов уже и так на GitHub, у 90% разработчиков там тоже есть аккаунт, поэтому тыкнуть Fork и поменять URL в composer.json это дело двух минут. А через энное число дней, когда уже забыл про свои правки в vendor, не придётся биться головой об стену, пытаясь понять, с чего вдруг всё сломалось, и тратить время на поиски пакета, который внезапно «стал несовместимым».

p.s: очень много ошибок в пунктуации — я исправил, но не забывай про запятые, иначе сложно читать.

Proger_XP
  1. меня интересовал только вопрос по PATH. с остальным проблем нет.

Вы с августа его не решили? Как насчёт Google? С ходу — первый вопрос на русском SO.

shPATH=$PATH:/path/to/composer/...
export PATH
Proger_XP
  1. P.S. А я так и знал — не получится в MVC по-человечески разнести логику и оформление.

У вас все посты совершенно в одном духе — как раньше было хорошо, как сейчас плохо. Причём без фактов и примеров, просто слова в вакууме.

Какая разница между представлением и логикой, если они пересекаются? Смысл их делить? Тогда уж писать всё в одном файле, как в WordPress, и не заморачиваться модными концепциями.

Proger_XP
  1. Перечисление данных массива, разделенных запятой, когда запятую в конце ставить не нужно

Только есть проблема с пробелами — т.к. у тебя там переводы строки и отступы, то в запятой + пробеле нет смысла, т.к. они и так подставляются. А вот убрать пробелы до запятой ты убрать не сможешь (если не ставить cssfont-size: 0 и т.д.).

Если контекст позволяет, то лучше решать через CSS (исчезает возможность копировать запятую, но иногда это даже полезно):

css.nice + .nice:before { content: ", "; }

Если нет, то нужно ставить запятую после блока, причём без пробелов/новой строки перед ней, а вот это уже не так красиво.

Proger_XP

Вопросы к самому Laravel, который меняет структуру даже в минорных релизах. Перевод официальной документации, просто старой (5.1). Кто хочет помочь обновить — пишите.

z80
Proger_XP
  1. Здесь ровно то же самое. Если ты хромой программист — Laravel тебе поможет.

Вы намеренно упускаете из виду стандартизацию? Есть компания, у неё раз в N месяцев меняются кадры (пусть даже раз в год). При этом продукт компании имеет цикл жизни N*10. Итого после каждой смены имеем затраты на изучение новым человеком вашего личного велосипеда. Когда он оправдан — хорошо, но в большинстве случаев это не так.

Используя фреймворк — Laravel или любой другой популярный — таких затрат нет в принципе.

Proger_XP
  1. Во всей литературе именно V из MVC на русском переводят как представление и реже вид. А конкретный файл это шаблон.

Когда я писал «в большинстве случаев их используют», то имел в виду их применение в повседневной речи (хотя бы и здесь на форуме), а не литературе. Там же, где сейчас засилье «вью».

  1. Что касается пыхи с 5.4 и this, то остались статические анонимки.

Да, действительно, про них я забыл. PHPstatic function без PHPuse, по идее, даёт полностью анонимную функцию.

  1. Я что то устал тут приператься.

Обычный обмен мнениями.

Proger_XP

Но термин представление нравится или нет является устоявшимся когда мы говорим о слое View из MVC. Не нравится он, ну можно использовать Вид еще.

"Представление"/"вид" действительно режут слух, т.к. в большинстве случаев их используют для обозначения конкретного, гм, представления (разметки/страницы/...), т.е. шаблона, а не для обозначении V в MVC. Учитывая это лучше уж привычные, хотя и не всегда корректные "шаблон" или "макет", чем "лэйаут" или "вью".

Почему же в доке они используются то один то другой и очень вольно? Потому что в php все анонимные функции реализованы через класс Closure (Замыкание).

В большинстве (всех?) распространённых веб-языках анонимная функция использует область видимости, где она объявлена, поэтому замыкание == анонимная функция. Чисто анонимные функции можно было получить в PHP 5.3, где $this был запрещён, если опустить use. Но это такие тонкости...

Proger_XP

Смысл работать в офисе при такой обстановке в стране? Даже при хорошей обстановке офис сильно ограничивает и зависимость от «дяди» спокойствия не добавляет.

Proger_XP

Что с ней не так? Переключатель wiki/markdown в нужном положении?

Proger_XP

Город абсолютно не имеет значения, если вы работаете фрилансом, что собственно и обсуждалось. Ваша ставка не зависит от места проживания, так что доход будет даже выше вне столицы. Естественно, работать надо на Запад, и естественно на английском. Курс рубля этому ещё как способствует.

Ещё больше отзывов