Интервью с Лонни Эцеллом (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, и легкое тестирование, которые идут рука об руку. Композитор был поддержан в 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 из установленной прессы.
— Я очень рад, что ты дал интервью и потратил свое драгоценное время. Что бы ты хотел сказать читателям напоследок?
— Есть много хороших фреймворков, которые вы можете использовать. Есть действительно нет «одиного прекрасного» фреймворка среди связки, так попробуйте столько из них, сколько вы можете, даже если это всего лишь просто часть личного проекта. Каждый из них научит вас новым способам работы, и думать о своем приложении, которое вы можете взять с собой. Таким образом, вы не попадете на конкурс популярности, который происходит вокруг фреймворков, но вы можете начинать понимать, какие фреймворки лучше всего работают для Вас и текущего проекта.
И всегда продолжайте учиться и расти.
Спасибо за интервью!
At the beginning of development of the Internet programmers of the single, group of programmers, the companies began to create the websites and web-services. At first this process was long, demanded big knowledge from developers. However, frameworks — the program platforms consisting of a complex of auxiliary components and libraries which began to facilitate development of projects considerably have soon begun to appear.
And, perhaps, one of number of the most known frameworks is — CodeIgniter created and developing in the EllisLab companies and which has undoubtedly occupied a certain niche.
It is known that this framework had very great difficulties in the course of the development. However, as if strange it wasn't, he has managed to survive. After long stagnation has been transferred in development, CodeIgniter to the new owner to Institute of technology of British Columbia.
The developer of a kernel of the new version of a framework, CodeIgniter 4, Lonnie Ezell has agreed to give interview and to communicate to him about CodeIgniter, instruments of development, frameworks and hobbies.
Ilya Cherepanov: — Hello, Lonnie! I am very pleased that you agreeing to be interviewed. Tell us a about yourself, where you work and what you do.
Lonnie Ezell: — Hello, Ilya. Thanks for asking me! I have been a full-time freelance consultant since 2009, though I had been doing web development outside of my main job for several years prior to that. I first started using CodeIgniter back in 2006, if I remember correctly! Over the years, I've worked with some great clients and partners, creating every size and type of site, including being the lead (often only) developer on some pretty big projects, including:
automotive sales portal with multiple dealer feed imports, user personalized searches, flexible dealer offers.
mystery shopper/quality control surveys for businesses with website and mobile app integration.
music licensing with flexible, personalized, search engine.
I've also had moderate success with a couple of open source projects, Bonfire and SprintPHP, which were both created to provide a set of ready-to-use tools for app creation on top of CodeIgniter.
Ilya Cherepanov: — How did you start working on CodeIgniter 4?
Lonnie Ezell: — Like everyone else, I watched CodeIgniter go through it's dry period when EllisLabs was not updating it. They had announced they were looking for a new owner, and almost a year went by with no word. Hating to see it die off, I contacted EllisLab to see what they were looking for in a new owner to see if maybe, just maybe, there would be a way that I could pull together a team and take over ownership. Instead, they had just agreed to transfer to the new owners, BCIT, though they hadn't announced it yet. I was eager to help out with the project, so I contacted James Parry to see how I could help out. A few weeks later, I was asked to be part of the Council he was putting together to help guide the framework.
I guess you can say that I became as active in CodeIgniter 4 as I have simply because I was too eager to see this framework mature! While features were being discussed both in the forums and in the Council, I started building out ideas that CI 4 might use. The main one being a Reflection-based Dependency Injection container. I played with modifying the core of version 3 to use the container, as well as an events library I had created for Sprint. I knew the likelihood of it being used in the final product was slim, but I was excited about the future. As elements of the project's architecture became more and more firm, I started tackling one piece at a time, discussing details with the group first, then coming back to say, «Hey, I've got a first pass at this in place. Thoughts?» Basically, my eagerness and my ability to carve out more time to work on it than the other team members ended up with me taking lead on the project — something that I never set out to do. It's a huge, daunting task!
Ilya Cherepanov: — Tell us about CodeIgniter current team. How many people in the team? Who is responsible for what in the project?
Lonnie Ezell: — The team has changed a couple of times since it was first put together based on members available time and interest. Currently, there are four active members, though I'm afraid that Mat's work life may be taking him in a different direction so I don't know how long he will still be with us.
James Parry is the framework's lead, as the member of BCIT that oversees the project. He keeps us on track and organized and is one of the main reasons the project is still alive today.
Andrey has been working on CodeIgniter for years before BCIT took the project over. He is the last remaining member of what was the Reactor team back in EllisLab's days, I believe, and was the sole maintainer of the framework for the couple of years when the framework was officially languishing. Under his guidance, though, version 3 of the framework had more updates and bug fixes than any previous version. Without his hand, I'm convinced CodeIgniter would never have survived. He is still the man behind CI 3 and does a lot with security fixes and working with the community on the current codebase.
I am currently lead on version 4.
Mat Whitney has been an awesome member of the community for the last 3-4 years, always providing helpful, detailed answers. He is the newest member of the team, and was starting to work on version 4's database layer before his work pulled him away for a bit. Hopefully, he'll be able to be active again soon.
Ilya Cherepanov: — CodeIgniter long time did not develop. Will be able CodeIgniter catch up other frameworks?
Lonnie Ezell: — I guess I have a hard time with the idea of «catching up» as something that's required. Each framework has a different focus and methodology. They each fill different needs for different programmers, or even different applications. In that respect, CI 3 still has it's place. When people say things like «catching up», I think it's mostly due to keeping up with what the language itself offers. To me the big items to have come to popularity in recent years are Composer packages, Dependency Injection, and easily testable, which go hand in hand. Composer has been supported in CI 3 since it officially released, and I've successfully used it many projects. Will version 4 keep up with the language and many of the best practices now popular? Absolutely. Dependency Injection is used everywhere in the framework. We're creating ways to simplify testing your application with PHPUnit and building that support into the framework. Since PHP 7 is a requirement, we're able to take advantage of a number of the new language features without needing to maintain compatibility with older PHP versions. And more, of course. :)
Ilya Cherepanov: — Many fear that CodeIgniter cease to be simple, fast and flexible. How many strong framework will change?
Lonnie Ezell: — That's a completely understandable concern. Especially as you look around at other frameworks and see how complex they can be. And it's something I try to always keep in mind. Where possible, I've tried to keep the developer experience very similar to what they're used to in version 3. Things won't be identical, but keeping the simplicity and familiarity has been a big goal. Once you get comfortable using it like you did the old way, you'll find that getting more comfortable with a few language constructs, like namespaces, can really expand the flexibility and power your have available that you never did before. Module-like functionality can be implemented using namespaces and a couple of helper functions we've provided for loading static content, like helpers or views, from namespaced folders, for example. I think you'll find that most of the really big changes are in the core of the framework and are things you don't need to ever touch, unless you want to.
What I'm trying to build here is an evolution of the framework we know and love, so there's certain expectations already in place, certain ways of working or things we're used to in the framework, that has to be maintained in order for it to keep the CodeIgniter name and not simply be a brand-new framework. I am trying very hard to make it live up to that standard, but still give you all of the flexibility you need to make the framework work for you no matter what you want to do with it.
Ilya Cherepanov: — Backward compatibility for legacy projects will be broken? How easy is it to migrate applications from older versions of the framework?
Lonnie Ezell: — For the first time the framework's history, backward compatibility will be truly broken. I would not view this as a project to upgrade an old project on, honestly, but one to start new projects on. There has been talk in the community of building a compatibility layer to ease the transition, but we will have to wait and see if anything comes of that.
At some point, though, this had to happen in order for the framework to continue maturing. If the framework would have been able to have continuous upgrades over the last few years, it might be a different story, so we felt that one big change in the framework, version 4, was needed. After that, we can continue to incrementally update functionality and maintain better compatability in the future, like has been the case from versions 1-3.
Ilya Cherepanov: — How long will be supported by CodeIgniter 3?
Lonnie Ezell: — There has not been a specific time frame in place, but the current goal is to continue to provide basic support for that version until it is no longer necessary. We understand that might be measured in years, not months, as many, many legacy projects will be on it.
Ilya Cherepanov: — Can we expect in the future appearance of the official repository on github for CI Community Apps?
Lonnie Ezell: — I think that's a great idea, but one that hasn't been discussed in the Council, yet. It does bring its own problems, though. Not the least is the appearance that BCIT has some hand in maintaining those projects, which wouldn't necessarily be the case. We've got our hands full with just the framework! I think it's much more likely to see a directory of apps and potentially dedicated forum space for certain community apps. It's really too early to tell, yet, though.
Ilya Cherepanov: — What difficulties have you faced when designing the architecture of the framework?
Lonnie Ezell: — I would say there's two aspects that I've found the most challenging and they are both bigger-picture items.
First, trying to find the balance between «clean code» and simplicity is a constant challenge. Too many abstractions in code can be problematic, yet modern SOLID programming concepts encourage us to split things apart everywhere, resulting in a different type of complexity, if you're not very careful. Trying to keep all of the pieces in your mind while navigating through 7 or 8 layers of abstractions is no better, in my opinion, than having spaghetti code. It just becomes «lasagna» then. :) Throughout development, my general practice has been to start out with the single class in mind. Then pieces would be separated out only as necessary. Often times, an array truly does everything you need it to do, without requiring a Collection or Bag be created just for that purpose. I have found that knowledge of design patterns can be a dangerous thing at times, and should be used to help you refactor things, not to design with up front. None of this is meant to bash SOLID, because I think the principles are sound. I just think they're overused many times and the key is finding that balance.
Secondly, and this is related to the first portion, is performance. Most of the design patterns that people know today come from compiled languages, and many make perfect sense in that respect, though they're often taken too far. The more layers your application has, or the more files, specifically, the worse the framework is going to perform. At least without any additional layers in place to help out, like caching used classes into a single class, etc. It's a constant challenge to improve the code quality without drifting too far from the raw performance that CodeIgniter is known for.
Ilya Cherepanov: — At what stage is CodeIgniter 4?
Lonnie Ezell: — Currently, we are just about to a place where our first milestone has been hit. That means that almost all of the core of the framework, including how all of the pieces fit together, and the system works as a whole, is in place. You could take what we have currently and build application's out of it as it is. Routing works, views work, many security steps are already in place, logging, error handling, some additional debugging tools, they're all in place. The database layer is the last portion to wrap up before the core is done and it's ready to be moved to its home at BCIT and opened up to more outside help. And the database layer is coming along nicely, though for the first milestone it will likely only fully support one or two database engines. I need to get documentation caught up to where we are now, and, as always, continue to improve our test coverage.
Ilya Cherepanov: — What awaits CodeIgniter in the future?
Lonnie Ezell: — I think CodeIgniter has a strong future ahead for it. Personally, I'm ready to start using this new version! I think that it's flexibility and speed will help bring back it's popularity in the developer community. I'm also excited to see what the community does around it. You mentioned Community Apps, and I think that is a great initiative to see happen, though I'd encourage people to make it as framework-agnostic as possible.
One of the goals we have for CodeIgniter that hasn't been talked about much, yet, is to have as many pieces of the framework usable on their own as Composer packages. I think this is great, because the framework has always had a very thorough set of helpers and libraries that I don't think many other frameworks seem to match, honestly, and it will be nice to see if developers find that as useful as I think it might be.
Ilya Cherepanov: — What about CodeIgniter on freelancing? He continues to be in demand? Or CodeIgniter supports only old projects?
Lonnie Ezell: — I think the demand for CodeIgniter in freelancing has definitely gone down, and become overshadowed by Laravel, Symfony, and Zend. Though, that's not to say that new projects aren't being built with them. In my freelance experience, it really comes down to what the client is familiar with, or has heard the most about. Many times clients aren't overly tech savvy, and will have friends that love one framework or another, so they make that a requirement. Other times, they'll trust you to know the best and won't care.
Ilya Cherepanov: — What tools during development you apply?
Lonnie Ezell: — I have become a huge fan of PHP Storm as my IDE. I use Sequel Pro on my Mac to work with the database. And, depending on the project, I'll either have the local development environment setup through MAMP Pro, or through a Vagrant box. In the case of CI 4, I've got it running under both MAMP and a Homestead Improved box, which gives me easy access to both an Apache install and an NGINX install.
Those are my core tools, but I've found smaller apps to be invaluable and used fairly often, too. The Patterns app makes it easy to experiment getting regular expression patterns just right. SourceTree for the non-daily use of Git. iTerm (or PHPStorm) for my terminal needs. Sublime Text still gets used some, too, as it is set as the default app in Finder for code files, since it opens quick and has all of the power and formatting I need. A ColorPicker app gets a lot of use when converting PSD's to HTML/CSS.
Ilya Cherepanov: — What other frameworks do you use in your work and why?
Lonnie Ezell: — While I've tried a number of the frameworks, the main two that I use are CodeIgniter and Laravel. CodeIgniter is what I consider «home». It has always done 99% percent of the things that I need it to without a lot of magic that can get in the way at times. I use Laravel if the client asks for it, which they seem to more and more. I'm hoping that version 4 of CodeIgniter can change that some. :) Taylor has done a great job with the developer experience, though, on Laravel, so it's mostly pleasant to use.
Ilya Cherepanov: — Web programming is growing rapidly, there are various frameworks, libraries, and components that make the development process faster. Programming has become easier, but programmers not learning to think and to understand how it works from the inside. Everything is going exactly to the rapid application development (RAD). What can you say about this?
Lonnie Ezell: -There is certainly a danger in people not learning the core language and only learning the RAD tools. I think this is especially true in the first years of a developer's career when they're just trying to get things done. Is that a bad thing, though? Yes and no.
It is a problem because the more tools someone has to learn to get started doing something, the bigger the hurdle just to see something happen. For some, I think the hurdle to learn X, Y, and Z just so they can start doing A is enough of a challenge that they'll back away and do something else. I know I've been guilty of that when it comes to exploring ReactJS lately.
It's not a bad thing, though, in the sense that some of those tools, like frameworks, help them be more productive up front, while helping reduce security issues, and hopefully teaching good programming practices along the way. If we compare the RAD tools that are starting to proliferate with the tools available for writing desktop software, I don't think it's bad that way, either. When creating desktop software, there are RAD tools that keep much of the complexity of the solution in the background, allowing you to focus on what's unique about that project. The same applies to Composer packages. We don't all need to know how the core of something like Guzzle works to be able to use it.
In the end, it's up to the developers to force themselves to keep learning the basics of their language so they can grow as a developer. I suppose it's the reliance on RAD tools to the exclusion of understanding the underlying concepts that is bad, not the abundance of tools itself.
Ilya Cherepanov: — Those or other tools often chosen because of fashion. All are subject to fashion. What do you think about it?
Lonnie Ezell: — I think this has two parts. First, people like to use what others are using. When people or communities they respect start using a new tool, they think they must use it, too, because it must be better. The second part being that new tools come about to solve specific problems, and I think we all hope they solve it in a better way than our current tools. As our projects become more complex, we need more or different tools to keep things working smoothly. It seems, though, that often it's through the use of tools that we drive the complexity up to a point where new tools and/or solutions are needed, creating a cycle that never ends unless we specifically force ourselves to break out of it. While we will never know if a new tool works better than an old one, I think it's often better to ask ourselves what the minimum number of tools we can get away with is. Is there a way that is simpler (though possibly not quite as easy) that can get us to the same end result.
Ilya Cherepanov: — Tell us a little about your current project. What are you doing now?
Lonnie Ezell: — I am just wrapping up a site that allows people to search for music by instrumentation, mood, speed, and more, and then license that music for use in online videos, movies, commercials, etc.
Ilya Cherepanov: — Let's digress from work, and talk of your passion. Do you have any hobbies? How do you spend your free time?
Lonnie Ezell: — Currently, it seems that my free time is spent on CodeIgniter! Outside of that, though, I love playing music, or at least trying to. I am in a Pirate band that traditional sea shanties and more modern sea-faring type music, called Capt'n. Black's Sea Dogs, that is a lot of fun. I get to play guitar and penny-whistle in that band.
Ilya Cherepanov: — As I know, you've written a few books. Tell, what is this books?
Lonnie Ezell: — I've written two books so far, one fiction and one non-fiction. My novel is titled, «Daughter of the Sun» and was written about 5 years ago and published independently. It's a fantasy novel about a woman that is forced to see how far she will go to save the life of her daughter from the clutches of a ruler that wants to kill her for the magic she wields and take the power to live longer.
The second book that I'm currently finishing up is called, «Practical CodeIgniter 3» and is available at leanpub.com/practicalcodeigniter3. This book is not intended to be a beginner's guide to CodeIgniter, or a replacement for the user guide. Instead, it's intended to provide examples and advice on how to really make the framework work for you and your team. It includes numerous ideas for customizing the workflow to better suit you, and describes not-so-common uses for features of CodeIgniter that you might not be familiar with, or might not have discovered, yet. I decided to write this one when I looked around and realized that no one else was going to write a CodeIgniter book from the established presses.
Ilya Cherepanov: — I am very glad that you gave an interview and spend your precious time. What can you tell readers at last?
Lonnie Ezell: — There are a lot of great frameworks out there that you can use. There's truly not «one perfect» framework among the bunch so try as many of them as you can, even if it's just part of a personal project. Each one will teach you new ways of working and thinking about your application that you can take with you. That way, you don't fall for the popularity contest that stems up around frameworks, but you can start to know which framework works best for you and the current project.
And always keep learning and growing.
Thanks for the interview!
Ссылки по теме
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/
Автор: condor-bird
