CodeIgniter 4 — Интервью с Лонни Эцеллом

Интервью с Лонни Эцеллом (Lonnie Ezell) — одним из разработчиков PHP фреймворка CodeIgniter. Вместе с ним мы обсудим темы, касающиеся CodeIgniter и не только.


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


На заре развития интернета программисты одиночки, группы программистов, компании стали создавать сайты и веб-сервисы. Сначала данный процесс был долгий, требовал больших знаний от разработчиков. Однако, вскоре начали появляться фреймворки — программные платформы, состоящие из комплекса вспомогательных компонентов и библиотек, которые стали значительно облегчать разработку проектов.
И, пожалуй, одним из числа самых известных фреймворков является — CodeIgniter, созданный и развивающийся в компании EllisLab и несомненно занявший определенную нишу.

Как известно, этот фреймворк имел очень большие трудности в процессе своего развития. Однако, как бы странным это не было, он сумел выжить. После долгого застоя в развитии, CodeIgniter был передан новому владельцу Технологическому институту Британской Колумбии (от англ. British Columbia Institute of Technology — ВСІТ).

Разработчик ядра новой версии фреймворка, CodeIgniter 4, Лонни Эцелл согласился дать интервью и пообщаться с ним о CodeIgniter, инструментах разработки, фреймворках и увлечениях.

— Привет, Лонни! Я очень рад, что ты согласился дать интервью. Расскажи нам о себе, где ты работаешь и что ты делаешь.

— Привет, Илья. Благодарю тебя за вопросы для меня! Я был независимым консультантом полный рабочий день с 2009 года, хотя я делал веб-разработки за пределами моей основной работы в течение нескольких лет. Впервые я начал использовать CodeIgniter еще в 2006 году, если я правильно помню! На протяжении многих лет я работал с несколькими большими клиентами и партнерами, создавая разного размера и типа сайты, являясь ведущим разработчиком на некоторых довольно крупных проектах, в том числе:

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

Я также имел умеренный успех в паре проектов с открытым исходным кодом, Bonfire и Sprintf PHP, которые оба были созданы, чтобы обеспечить к использованию набор готовых инструментов для создания приложений на основе CodeIgniter.

— Каким образом ты начал работать над CodeIgniter 4?

— Как и все остальные, я наблюдал за CodeIgniter, проходя через его сухой период, когда EllisLab не обновлял его. Они объявили, что ищут нового владельца, и почти год прошел без каких-либо слов.

Очень не хотелось видеть, как он умирает, поэтому я связался с EllisLab, чтобы увидеть, что они искали в новом владельце, чтобы, если это просто возможно было, что я мог объединить команду и взять на себя право собственности. Вместо этого они только согласились передать новым владельцам, BCIT, хотя они еще не объявили этого.
Мне очень хотелось, помочь с проектом, поэтому я связался с Джеймсом Парри, чтобы увидеть, как я мог помочь. Несколько недель спустя, меня попросили быть частью Совета, который он собирал, чтобы помочь с фреймворком.

Я думаю, вы можете сказать, что я стал таким же активным в CodeIgniter 4, потому как я был слишком нетерпелив, чтобы увидеть этот фреймворк развитым! В то время как особенности обсуждались как на форумах и в Совете, я начал строить идеи, которые CI 4 мог бы использовать. Главной из них являлось размышление об основе Dependency Injection контейнера. Я играл с модифицирующим ядром версии 3, чтобы использовать контейнер, а также библиотекой событий, которую я создал для Sprint. Я знал, что вероятность его использования в конечном продукте была слабой, но я был взволнован о будущем. Поскольку элементы архитектуры проекта стали более устойчивыми, я начал заниматься одной частью за один раз, обсудив детали сначала с группой, затем возвратившись, чтобы сказать, «Эй, у меня есть первый проход в этом в месте. Мысли?». В основном мое рвение и моя способность выкроить больше времени, чтобы работать над ним, чем другие члены команды, закончились со мной взятием на ведущую роль в проекте — что-то, что я никогда не намеревался делать. Это — огромная, сложнейшая задача!

— Расскажи нам о текущей команде CodeIgniter. Сколько людей в команде? Кто несет ответственность за то, что в данном проекте?

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

Джеймс Парри является руководителем фреймворка, как член BCIT, курирующим проект. Он держит нас на пути и организовывает и является одной из главных причин, почему проект все еще жив сегодня.

Андрей работает над CodeIgniter в течение многих лет, прежде чем BCIT принял проект. Он последний оставшийся член того, что было командой реактора EllisLabs некоторое время назад, и был единственным хранителем фреймворка в течение нескольких лет, когда фреймворк был официально вял. Под его руководством, тем не менее, у 3 версии фреймворка было больше обновлений и исправлений ошибок, чем имела какая-либо предыдущая версия. Без его руки я убежден, CodeIgniter никогда не выжил бы. Он до сих пор занимается CI 3 и делает много исправлений безопасности и работы с сообществом на текущей кодовой базе.

Я в настоящее время руковожу над 4-й версией.

Мэт Уитни был удивительным членом сообщества в течение последних 3-4 лет, всегда предоставляя полезные и подробные ответы. Он является самым новым членом команды, и начал работать над слоем базы данных 4-й версии, прежде чем его не затянула немного назад основная работа. Хотелось бы надеяться, что он сможет быть активным снова в ближайшее время.

— CodeIgniter долгое время не развивался. Сможет ли CodeIgniter догнать другие фреймворки?

— Я предполагаю, что мне приходится нелегко с идеей «нагнать» как что-то, что это требуется. У каждого фреймворка имеется различная направленность и методология. Каждый из них удовлетворяет различные потребности для разных программистов, или даже различных приложений. В этом отношении CI 3 все еще имеет это место. Когда люди говорят такие вещи как «наверстывание», я думаю, что это происходит в основном в связи с тем, что чтобы не было отставания от того, что предлагает сам язык. Для меня большими пунктами, чтобы прийти к популярности, в последние годы являются Composer пакеты, Dependency Injection, и легкое тестирование, которые идут рука об руку. Composer был поддержан в CI 3, официально выпущен, и я успешно использовал его во многих проектах. Будет ли версия 4 идти в ногу с языком и многими из лучших практик популярных в настоящее время? Абсолютно. Dependency Injection используется повсеместно в фреймворке. Мы создаем способы упростить тестирование приложений с помощью PHPUnit и встраиванием этой поддержки в фреймворк. Поскольку PHP 7 является обязательным требованием, мы можем воспользоваться рядом новых функциональных возможностей языка без необходимости поддерживать совместимость с более старыми версиями PHP. И больше, конечно :)

— Многие опасаются, что CodeIgniter перестают быть простым, быстрым и гибким. Как сильно фреймворк изменится?

— Это абсолютно понятное беспокойство. Тем более, что вы смотрите на другие фреймворки и видите, насколько сложными они могут быть. И это — что-то, что я пытаюсь всегда иметь в виду. Где возможно, я попытался сохранять опыт разработчика очень похожим на то, к чему они привыкли в версии 3. Вещи не будут идентичны, но хранение простоты, и дружеские отношения были большой целью. Как только вы получаете удобное использование, делая все это по старому, вы обнаружите, что становится все более комфортно с несколькими конструкциями языка, такими как пространства имен, можно действительно расширить гибкость и мощь ваших действий, иметь доступность, которые вы никогда не делали прежде. Модуль, как функциональная возможность, может быть осуществлена с использованием пространства имен и несколько функций помощника, мы предусмотрели погрузку статического содержания, таких как помощники или отображения, от namespaced папок, например. Я думаю, что вы найдете, что большинство из действительно больших изменений находящихся в ядре фреймворка и являющихся вещами, которых вы никогда не должны касаться, если вы не хотите.

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

— Обратная совместимость для старых проектов будет нарушена? Насколько будет легко перенести приложения со старых версий фреймворка?

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

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

— Как долго будет поддерживаться CodeIgniter 3?

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

— Можем ли мы ожидать в будущем появления официального репозитория на GitHub для CI Community Apps?

— Я думаю, что это — прекрасная идея, но та, которая еще не была обсуждена в Совете. Это действительно приносит свои собственные проблемы, все же. Не наименьшее количество — появление, что у BCIT есть некоторая рука в поддержании тех проектов, которые не обязательно имели бы место. У нас в руках есть просто полный фреймворк! Я думаю, что гораздо более вероятно, чтобы увидеть каталог приложений и потенциально специальное пространство на форуме для некоторых приложений сообщества. Об этом действительно пока слишком рано говорить, но, тем не менее.

— С какими трудностями ты столкнулся при разработке архитектуры фреймворка?

— Я сказал бы, что есть два аспекта, которые я нашел наиболее сложной задачей, и они — оба пункты большей картины.

Во-первых, попытка найти баланс между «чистым» кодом и простотой является постоянной проблемой. Слишком много абстракций в коде может быть проблематичным, но современные концепции SOLID программирования побуждают нас разделять вещи друг от друга везде, что приводит к разным типам сложности, если вы не очень осторожны. Попытка не держать все части в вашем уме во время навигации через 7 или 8 слоев абстракций не лучше, на мой взгляд, чем наличие запутанного кода спагетти. Тогда он просто становится «лазаньей» :). На протяжении всего развития, моя общая практика должна была начаться с единым классом в памяти. Тогда части были бы выделены только по мере необходимости. Часто, массив действительно делает все, что нужно делать, не требуя Коллекции или Сумки быть созданными только для этой цели. Я обнаружил, что знание шаблонов проектирования может быть опасным в разы, и должно быть использовано, чтобы помочь вам реорганизовать вещи, а не проектировать с фронтом. Ничего из этого не предназначено, чтобы колотить SOLID, потому что я думаю, что принципы правильны. Я просто думаю, что они много раз злоупотребляются, и ключ находит тот баланс.

Во-вторых, и это связано с первой частью, является производительность. Большинство шаблонов, которые люди знают сегодня, прибывает из скомпилированных языков, и многие имеют прекрасный смысл в этом отношении, хотя они часто берутся слишком далеко. Чем больше слоев, которые ваше приложение имеет, или больше файлов, определенно, тем хуже фреймворк собирается выступить. По крайней мере, без любых дополнительных слоев в месте, чтобы выручить, как кэширование используемых классов в единый класс, и т.д. Это — постоянная проблема улучшить кодовое качество, не дрейфуя слишком далеко от сырой работы, которой известен CodeIgniter.

— На какой стадии находится CodeIgniter 4?

— В настоящее время мы как раз собираем место, где наш первый этап был поражен. Это означает, что почти все ядро фреймворка, включая то, как все части совмещаются, и системные работы в целом, имеются. Ты можешь взять то, что мы в настоящее время имеем и создать приложение из него. Маршрутизация работает, вид работает, многие меры безопасности уже находятся на месте, протоколирование, обработка ошибок, некоторые дополнительные инструменты отладки, они все на месте. Слой базы данных — последняя часть, прежде чем ядро будет сделано, и готово быть перемещенным в его дом в BCIT и открытым до большего количества помощи извне. И слой базы данных идет приятно, хотя в течение первого этапа он, вероятно, полностью будет поддерживать только одно или два ядра базы данных. Я должен добраться до документации, где мы теперь, и, как всегда, продолжать улучшать нашу тестовую оценку.

— Что ждет CodeIgniter в будущем?

— Я думаю, что CodeIgniter имеет большое будущее впереди. Лично, я готов начать использовать его новую версию! Я думаю, что гибкость и скорость поможет вернуть его популярность в сообществе разработчиков. Я также взволнован, чтобы видеть то, что сообщество делает вокруг него. Ты упомянул Community Apps, и я думаю, что это — прекрасная инициатива, чтобы произойти, хотя я поощрил бы людей сделать это в качестве основы фреймворка, насколько это возможно.

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

— Как обстоят дела с CodeIgniter на фрилансе? Он продолжает быть востребованным? Или на CodeIgniter поддерживают только старые проекты?

— Я думаю, что спрос на CodeIgniter во фрилансе определенно понизился и стал омраченным Laravel, Symfony и Zend. Хотя, это вовсе не значит что новые проекты не разрабатываются с ними. В моем внештатном опыте это действительно сводится к тому, о чем клиент знаком или услышал больше всего. Много раз клиенты, не слишком разбирающиеся в технологиях, и имеющие друзей, которые любят один или другой фреймворк, таким образом, они делают это требованием. В другое время, они будут доверять вам, чтобы знать лучшее и не заботиться.

— Какие инструменты в процессе разработки ты применяешь?

— Я стал огромный поклонник PHP Storm, как моей IDE. Я использую Sequel Pro на моем Mac для работы с базой данных. И, в зависимости от проекта, я буду иметь либо локальные настройки среды разработки через MAMP Pro или через Vagrant Box. В случае CI 4, у меня он работает как под MAMP и Homestead Improved Box, который дает мне легкий доступ к обоим Apache установке и NGINX установке.

Таковы мои основные инструменты, но я нашел более мелкие приложения, чтобы иметь неоценимое значение и использую довольно часто, тоже. Приложение Patterns позволяет легко экспериментировать и получать регулярные выражения. SourceTree для неежедневного использования Git. Iterm (или PhpStorm) для моих потребностей терминала. К Sublime Text еще привыкаю тоже, так как это установлено в качестве приложения по умолчанию в Finder для файлов кода, так как он открывает быстрый и имеет все силы и форматирование мне нужно. Приложение Color Picker получает много использования при преобразовании PSD в HTML / CSS.

— Какие другие фреймворки ты используешь в своей работе и почему?

— В то время как я попробовал много фреймворков, главными двумя, что я использую, является CodeIgniter и Laravel. CodeIgniter — это то, что я считаю «домашним». Он всегда делал 99%-й процентов тех вещей, что мне необходимо, без большого количества волшебства в нем, которое может время от времени мешать. Я использую Laravel, если клиент просит его, что они делают, кажется, все больше и больше. Я надеюсь, что версия 4 CodeIgniter может изменить это. :) Тейлор сделал большую работу с опытом разработчика, таким образом Laravel приятно использовать.

— Веб программирования стремительно развивается, появляются различные фреймворки, библиотеки, компоненты, которые делают процесс разработки быстрей. Программирование стало проще, но программисты не учатся думать и понимать, как это работает изнутри. Все идет именно к быстрой разработки приложений. Что можешь сказать об этом?

— Существует, безусловно, опасность у людей, не учащих основной язык и только изучающих инструменты RAD. Я думаю, что это особенно верно в первых годах карьеры разработчиков, когда они просто пытаются добиться поставленной цели. Это — плохая вещь, правда? Да и нет.

Это — проблема потому, что чем больше инструментов то кто-то должен учиться начинать делать что-то, тем больше препятствий, чтобы видеть, что что-то происходит. Для некоторых я думаю, является препятствием учится X, Y, и Z именно потому, что они могут начать делать A, и это является действительно проблемой, потому что они отступят и сделают что-то еще. Я знаю, что был виновен в этом, когда дело доходит до изучения ReactJS в последнее время.

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

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

— Те или иные инструменты чаще всего выбирают из за моды. Все подвержены моде. Что ты думаешь об этом?

— Я думаю, что у этого есть две части. Во-первых, людям нравится использовать то, что используют другие. Когда люди или сообщества начинают использовать новый инструмент, они уважают начало, используя новый инструмент, они думают, что должны использовать его, также, потому что это должно быть лучше. Вторая часть, являющаяся, что новые инструменты появляются, чтобы решить определенные проблемы, и я думаю, что все мы надеемся, что они решают ее лучшим способом, чем наши текущие инструменты. Поскольку наши проекты становятся более сложными, нам нужно больше различных инструментов, чтобы держать вещи, работающие гладко. Хотя кажется, что часто с помощью инструментов мы ведем к сложности в какой-то степени, где новые инструменты и/или решения необходимы, создавая цикл, который никогда не заканчивается, если мы определенно не вынуждаем нас выйти из него. В то время как мы никогда не будем знать, работает ли новый инструмент лучше, чем старый, я думаю, что часто лучше спросить нас, каково минимальное число инструментов, которые мы можем спустить с рук. Есть ли способ, который более прост (хотя возможно не совсем как легкий), который может привести нас к тому же самому конечному результату.

— Расскажи немного о твоем текущем проекте. Что ты делаешь сейчас?

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

— Давай отвлечемся от работы и поговорим о твоих увлечениях. Есть ли у тебя хобби? Как ты проводишь свое свободное время?

— В настоящее время, кажется, что все мое свободное время тратится на CodeIgniter! За пределами этого, я люблю играть музыку, или, по крайней мере, пытаюсь. Я нахожусь в Группе Пиратов, где традиционные морские лачуги и более современный мореходный тип музыки, который называется Capt'n. Черные морские псы, что это очень весело. Я играю на гитаре и флейте Вистл в этой группе.

— Насколько я знаю, ты написал несколько книг. Расскажи, что это за книги?

— Я написал две книги до сих пор, одну фантастический вымысел и другая нехудожественная.

Мой роман под названием «Дочь Солнца» (от англ. «Daughter of the Sun») был написан около 5 лет назад и издан независимо. Это роман-фэнтези о женщине, которая вынуждена видеть, как далеко она пойдет, чтобы спасти жизнь ее дочери из лап правителя, который хочет убить ее за волшебство, которым она владеет, взять власть и жить дольше.

Вторая книга, которую я в настоящее время заканчиваю, называется «Приктический CodeIgniter 3» (от англ. «Practical CodeIgniter 3» ) и доступен в leanpub.com/practicalcodeigniter3. Эта книга не претендует на руководство для начинающих по CodeIgniter, или для замены руководства пользователя. Вместо этого он предназначен, чтобы представить примеры и советы о том, как действительно заставить работать фреймворк на вас и вашу команду. Она включает в себя множество идей для настройки рабочего процесса, чтобы лучше подойти вам и описывает не столь распространенные для применения особенности CodeIgniter, с которым вы не можете быть знакомы, или, возможно, не обнаружили. Я решил написать это, когда я осмотрелся и понял, что никто не собирался писать книгу CodeIgniter из установленной прессы.

— Я очень рад, что ты дал интервью и потратил свое драгоценное время. Что бы ты хотел сказать читателям напоследок?

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

И всегда продолжайте учиться и расти.

Спасибо за интервью!



Ссылки по теме



Blog Lonnie Ezell: CodeIgniter 4 — Interview with Lonnie Ezell
Практический CodeIgniter 3 (Practical CodeIgniter 3) https://leanpub.com/practicalcodeigniter3
My Blog Interview with Lonnie Ezell
CodeIgniter Wikipedia: ru.wikipedia.org/wiki/CodeIgniter
Официальный сайт CodeIgniter: www.codeigniter.com
Официальный форум CodeIgniter: forum.codeigniter.com
CodeIgniter 4: https://habrahabr.ru/post/275657/
CI Community Apps: https://habrahabr.ru/post/276375/
Requests и Responses в CodeIgniter 4: https://habrahabr.ru/post/278489/
Внедрение зависимостей в CodeIgniter 4: https://habrahabr.ru/post/278641/
Маршрутизация в CodeIgniter 4: https://habrahabr.ru/post/278873/
Модули/HMVC в CodeIgniter 4: https://habrahabr.ru/post/279415/
Слой базы данных CodeIgniter 4: https://habrahabr.ru/post/280850/

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


  1. malinichev
    16.04.2016 23:03

    «компании стали создавать сайты и веб-серисы», очепятка, веб-серВисы


    1. condor-bird
      16.04.2016 23:04

      Спасибо, исправил.


      1. malinichev
        16.04.2016 23:40
        +3

        Не пробовали копировать текст в онлайн валидаторы? Полезная штука


  1. NeoCode
    16.04.2016 23:49
    +5

    Не обижайтесь, но местами впечатление что гугл транслейт)
    Когда-то мне, не имея опыта работы с фреймворками, понадобилось написать что-то для веба. Я выбрал CodeIgniter, и надо сказать что вроде-бы быстро в нем разобрался… теперь вот по определенным причинам вдруг ударило в голову что нужно разбираться в вебом…
    Посоветовали Ларавель — скачал, мама родная… 22 мегабайта! (весь CodeIginter был меньше мегабайта).
    В общем надеюсь что этот фреймворк будет развиваться и дальше.


    1. condor-bird
      16.04.2016 23:59
      +1

      Да, я тоже начал замечать, что мои переводы очень похожи на гугл транслейт :) Составлять вопросы сначала на русский, а потом переводить на английский еще как-то выходит, а вот наоборот получается не очень. Надо восполнять пробелы в английском.
      CodeIgniter легкий в освоении, только вот застрял когда-то. Ларавель ничуть не сложней CodeIgniter, приятный фреймворк.


      1. NeoCode
        17.04.2016 00:13
        +1

        С переводом я вас понимаю — структура языка немного другая, нужно очень тонко чувствовать и английский и русский, чтобы точно и красиво перевести…
        А с php я сам застрял где-то на уровне «hello word», все-же веб — не основная моя специальность. Но вот сейчас очень захотелось освоить это направление до более-менее профессионального уровня, поэтому мне бы надо для начала что-то общее о фреймворках и их архитектуре вообще, в применении к php (особенно новейшим возможностям языка и стандартам кодинга) и тому же Laravel. Я такое наблюдал со стороны на примере начинающих С++ программеров — вроде и язык знают, и код пишут, а полного понимания и ощущения структуры и архитектуры «всего в целом» нет…


        1. condor-bird
          17.04.2016 00:49

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


  1. NeoCode
    17.04.2016 00:12

    del


  1. L0NGMAN
    17.04.2016 02:13
    -1

    Я тоже любил CodeIgniter, но думаю что в 4-ой версии они пошли не верным путём. Изобретают свой велосипеды везде, не используют готовые компоненты (symfony http foundation и т.д.)


    1. condor-bird
      17.04.2016 12:31
      +2

      Не думаю, что использование, везде и всюду, компонентов Symfony является правильной вещью. Да, это быстро и хорошо, как, например, в случае с Laravel. Можно хоть самому на компонентах Symfony собрать свой фреймворк. В случае с CodeIgniter — это будет уже не торт CodeIgniter, к которому все привыкли. Давайте тогда трансплантировать органы Symfony и во все другие фреймворки. Но тогда они потеряют всю свою особенность и независимость.
      Не вижу ничего плохого в том, чтобы в CodeIgniter было все свое. Но в нем не будет запрета на самостоятельное использование компонентов Zend, Symfony etc.


      1. Fesor
        17.04.2016 12:50
        -1

        В случае с CodeIgniter — это будет уже не торт CodeIgniter, к которому все привыкли


        Вы можете просто поверх компонентов наваять своих адаптеров которые превращают все в никому не нужный старый CI. Только вот это не нужно. Да и «привычки» — это плохой аргумент. Надо как-то развиваться все же.

        Давайте тогда трансплантировать органы Symfony и во все другие фреймворки.


        Собственно так сейчас и происходит. Есть Symfony и Zend, и их компоненты используют все чаще. И это правильно, не стоит разводить фрагментацию решений на ровном месте. Если есть качественное решение — его надо использовать и развивать, а не лепить велосипед. Велосипед оправдан если вы уверены что можно сделать лучше, но без нарушения обратной совместимости никак. И это… ну словом надо ооочень хорошо знать что делаешь.

        Не вижу ничего плохого в том, чтобы в CodeIgniter было все свое.

        Так и хорошего в этом тоже нет. Все ще symfony компоненты имеют намного более сильную поддержку со стороны комьюнити. У них стабильный цикл разработки, более строгие внутренние процессы и т.д.

        Я боюсь что в случае с CI выйдет монолитная штука. А если так, в этом фреймворке не будет никакого смысла. Требования бизнеса в отношении фреймворков даже для PHP сильно изменились по сравнению с тем, что было лет 5-7 назад.


        1. condor-bird
          17.04.2016 13:34

          Я имел ввиду привычную среду, в которой пользователям CodeIgniter будет максимально просто перейти и комфортно работать на 4 версии. О развитии, это немного другое.
          О качестве решения еще рано судить, тем более всего-навсего ожидается альфа. Говорить о том, качественное ли это будет решение или нет, здесь не уместно будет, не попробовав в деле.
          Здесь как раз нарушение обратной совместимости будет, но не настолько сильное, что нельзя будет перенести старые проекты.
          На начальном этапе действительно возможна какая-то окаменелость. Но думаю, что это будет поправимо. Не стоит теперь уже смотреть на предыдущие версии и делать какие-либо сравнения с новой или сравнивать старые с другими.


          1. Fesor
            17.04.2016 13:54
            +1

            Мое личное мнение — я вообще не вижу смысла сегодня делать новые фреймворки. Ставку надо делать на отдельные компоненты и инвестировать нужно именно в развистие экосистемы, а не в написание очередных велосипедов.

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

            p.s. Но это мое личное мнение. Я работал только с CI2, и мне как-то этого хватило.


            1. condor-bird
              17.04.2016 14:49
              +1

              Я наоборот — не вижу ничего плохого в появлении новых инструментов, которые могут попытаться встать в ряды уже имеющихся или даже потеснить их. Ведь хорошо, когда есть из чего выбирать. У каждого своя экосистема у тех же Zend и Symfony. Появился Laravel, вокруг него образовалась его экосистема, образовалось комьюнити, начали его использовать etc.
              Так что, не думаю, что появление Laravel и его молодость бессмысленна. Так же как не бессмысленна реинкарнация CI. Хоть новых проектов на нем никто не создает, остаются множество старых проектов на поддержке и готовых перейти на новую версию.

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

              CI3 не сильно изменилась от CI2, за исключением того, что были добавлено несколько функций и сделано достаточно много исправлений безопасности и ошибок, исправление ошибок совместимости с php 7 etc.

              Все же CI4 будет отличаться от тех же давно старых CI1x, CI2x, CI3x. Это, пожалуй, относится к очень непонятному явлению, когда лет 5-6 назад, попробовав A или B версии, пользователь понимает, что инструмент ему не подходит/плохо организован/плохо поддерживает X функцию etc. И потом, даже с выходом версий C, D, E через несколько лет, он вспоминает версию A или B и перекладывает все недостатки предыдущих версий на текущую. Это относится не только к CI, а в вообщем. Кроме этого, очень часто можно замечать, когда сравнивают функциональные возможности инструмента X версии 1, с инструментом Y версии 2, которые, по сути, направлены на удовлетворение различных потребностей.
              Лично я, когда читаю статьи про такие сравнения, как минимум морщусь.