Комментарии 48
Не знаю как для прохождения собеседования поможет, но когда тебе говорят, что через 5 минут тебе нужно провести техническое собеседование, то хороший способ несколько вопросов подобрать :)
Никогда не понимал вопросов на собеседованиях в стиле «поиграй в интерпретатор». Как правило, они сопровождаются кодом за который по пальцам настучат при ревью, и который совсем оторван от реального кода проектов. К тому же о большинстве таких тонкостей при разработке предупреждает IDE.
Ну… Не все же пользуются IDE… Я например пользуюсь sublime, и иногда, при крупном проекте Visual Studio Code. PHPStorm мне в корне не импонирует почему-то…
НЛО прилетело и опубликовало эту надпись здесь
Вы сами то верите что многие разработчики профессионалы? У большей части просто зашкаливает самооценка, вот и всё…
Влезу, пожалуй. Как же Вы определяете критерий профессионализма? Неужто профессионал — это тот чел, который вместо грамотного выбора инструментов (той же IDE) предпочтет писать код в блокноте\vim'е и знает phpdoc наизусть? Если так, то пожалуй, можно будет Вас пожалеть, когда такой «про» в работе с Вами понапишет такой код, который прочитать и подправить под изменяющиеся требования будет невозможно, такой код, который руками лучше не трогать, чтобы не развалился…
Я ничего подобного не говорил… Спец — он и в Африке спец, и обычно он использует те инструменты, которые ускоряют процесс разработки! Я говорил про себя. Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор… Как по мне это ошибочное мнение, я например начинающий мидл, и я не хочу(и не могу) юзать IDE, от которой тормозит хром, и плеер с музыкой на компе…
8 гб оперативы, 4 ядра AMD. Я думаю, что этого вполне бы хватило для IDE, но нет, музыку слушать нереально, тормоза постоянные, и всё такое… Я не представляю какой нужен комп, для удобного юзанья PHPStorm…
Именно поэтому, я и юзаю VS Code, он лёгкий и удобный.
И так, по вашему мнению, я не специалист в разработке(я и не хочу таким называться, знаний маловато), ок, хорошо… Пусть будет так
8 гб оперативы, 4 ядра AMD. Я думаю, что этого вполне бы хватило для IDE, но нет, музыку слушать нереально, тормоза постоянные, и всё такое… Я не представляю какой нужен комп, для удобного юзанья PHPStorm…
Именно поэтому, я и юзаю VS Code, он лёгкий и удобный.
И так, по вашему мнению, я не специалист в разработке(я и не хочу таким называться, знаний маловато), ок, хорошо… Пусть будет так
Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор…
Пусть говорят, жирные тролли :)
я не хочу(и не могу) юзать IDE, от которой тормозит хром, и плеер с музыкой на компе...8 гб оперативы, 4 ядра AMD
Как Java-разработчик (проект на GWT, будь он неладен) использую IDEA, в это время открыт Хром, Огнелис и IE11, в фоне работает 2 томкэта, сервисами крутятся Апач и Постгрес, играет AIMP, открыт TeamViewer, и вполне комфортно работать, если только не запущу еще Эклипс :) 2 ядра Интел по 2ГГц, те же 8Г ОЗУ — язык не поворачивается назвать это суперкомпом :) ЧЯДНТ?
Я не говорил, что Вы — не специалист, я говорил о том, что специалист подбирает подходящие инструменты для разработки, вместо того, чтобы кодить в нотпаде :) И нет ни одной причины не пользоваться IDE
Кстати, отличный вопрос для собеседования. Разработчик претендующий хотя бы на мидла должен знать про профайлинг. phpstorm имеет встроенный инструментарий, чтобы самому определить тормоза, либо послать результаты разработчикам, чтобы они починили баг, вы же за это деньги платите.
Странна. Занимаюсь разработкой на Java под WebSphere Application Server. На ПК 4 гб ОЗУ, 2 ядра 3ГГц, отлично себя чувствовали IDEA, Chrome, WebSphere Application Server Base 8.5.5, Wowza и несколько других программ. Даже видео на YouTube мог смотреть. Озу забито на 92% но тормозов не заметно.
Вероятно просто все от того, что я все таки решил открыть файлик idea.vmoptions и поправить Xmx и Xms параметры?
Вероятно просто все от того, что я все таки решил открыть файлик idea.vmoptions и поправить Xmx и Xms параметры?
работаю на 12" макбуке, то есть мобильный проц, 2 ядра 1.1ГГц.
Обычно приходится держать открытыми сразу несколько проектов в PHPStorm. Нормально, ничего не тормозит.
Обычно приходится держать открытыми сразу несколько проектов в PHPStorm. Нормально, ничего не тормозит.
Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор…А если валишь дерево бензопилой, а не топором, то вообще не лесоруб…
8 гб оперативы, Core i5-4460, AMD Radeon R7 240 (2Gb), Ubuntu 16.04
Phpstorm 2016.1 в 2-3 окна, FF (десятка полтора вкладок), pgadmin, 2-3 терминала, Thunderbird, Teamviewer, Slack, Skype, Chrome иногда. Ни намёка на тормоза… ЧЯДНТ?
Phpstorm 2016.1 в 2-3 окна, FF (десятка полтора вкладок), pgadmin, 2-3 терминала, Thunderbird, Teamviewer, Slack, Skype, Chrome иногда. Ни намёка на тормоза… ЧЯДНТ?
Почти все современные редакторы используемые для написания PHP-кода имеют плагин или расширение статического анализатора кода. Это очень весомая экономия времени на обнаружение опечаток и каких-нибудь особенностей, непозволительных для использования в языке. Вы сами себе враг, если избегаете оптимизации процесса кодирования.
за который по пальцам настучат при ревью, и который совсем оторван от реального кода проектов
В этом же соль. Посмотреть как человек рассуждает. Показываем код и спрашиваем почему он работает или не работает… или просим самостоятельно определить результат.
У меня есть парочка таких задачек которые я изредка даю. И код, как вы сказали, оторван от проекта и мне бы дали по шапке на код ревью. Но ситуации там взяты из реальных проектов, просто ужато все до размеров 10-ти строчек кода (что бы не перегружать человека). И даже если человек не может ответить почему так, мне намного важнее рассуждения человека послушать, пусть даже они и не верны. Грустное солнышко он за неверный ответ не получит.
Я встречал такие вопросы, и часть из них была:
— Зависима от версии Php/MySQL или рабочего окружения.
— Ужасно преподнесена. Например:
$y = 10;
$z = 3;
$x = ( $y % 5 > 0 )? ( $z == 3)? $z * 2: $y + 3: ( $z < 3 )? $y — $z: $z++;
Чему равен x?
— Неполной. Т.е. иногда сам собеседующий путался в вопросе и примере кода.
И никогда не был полностью удовлетворен ответом на вопрос «зачем Вам нужен ответ на это?». Я не вижу преимуществ у людей, которые могут или не могут ответить на подобные вопросы. Игра в интерпретатор хороша при отлове сложных багов, но тут большую роль играет общее знакомство с проектом, а не отлов синтаксических или языковых ошибок (из них до кода проекта доходит лишь очень скромная и практически невесомая часть, т.к. обычно программист тестирует свой код хотя бы на ручном уровне).
Хотите понять мое мышление — дайте практическую задачу, и попросите меня изложить алгоритм решения на словах. Вы получите гораздо больше информации, и я получу минимум стресса и непонимания от вопросов, которые мне непонятны на идеологическом уровне.
— Зависима от версии Php/MySQL или рабочего окружения.
— Ужасно преподнесена. Например:
$y = 10;
$z = 3;
$x = ( $y % 5 > 0 )? ( $z == 3)? $z * 2: $y + 3: ( $z < 3 )? $y — $z: $z++;
Чему равен x?
— Неполной. Т.е. иногда сам собеседующий путался в вопросе и примере кода.
И никогда не был полностью удовлетворен ответом на вопрос «зачем Вам нужен ответ на это?». Я не вижу преимуществ у людей, которые могут или не могут ответить на подобные вопросы. Игра в интерпретатор хороша при отлове сложных багов, но тут большую роль играет общее знакомство с проектом, а не отлов синтаксических или языковых ошибок (из них до кода проекта доходит лишь очень скромная и практически невесомая часть, т.к. обычно программист тестирует свой код хотя бы на ручном уровне).
Хотите понять мое мышление — дайте практическую задачу, и попросите меня изложить алгоритм решения на словах. Вы получите гораздо больше информации, и я получу минимум стресса и непонимания от вопросов, которые мне непонятны на идеологическом уровне.
Я не вижу преимуществ у людей, которые могут или не могут ответить на подобные вопросы.
Так я такой бред и не даю и сам отвечаю на такие вопросы в духе "у меня такой код тупо не пройдет код ревью ибо я не могу сходу его прочитать", причем никто не кочевряжется и мы просто переходим дальше.
дайте практическую задачу, и попросите меня изложить алгоритм решения на словах.
Тип стандартную? Когда я дохожу до этих задачек то собеседуемый уже выложил с чем он работал и я приблизительно представляю скоуп "стандартных" для него задач. А вот как человек будет мыслить при поиске проблем, при отладке и т.д. Или задачки где xdebug не поможет отловить проблемы и нужно предложить быстрое решение как проверить что-то.
И повторюсь, я прибегаю к этим задачкам когда мне не понятно из его других ответов как человек мыслит и насколько он адекватен. То есть далеко не в начале собеседования. И интерпритатором в этом случае выступаю Я а не собеседуемый, он просто делает предположения а я говорю так это или нет.
К сожалению, не доводилось встречать Ваш подход на собеседованиях.
Что касаемо задач, они не обязательно должны быть стандартными. Главное, чтобы были из реального проекта и не слишком узкоспециализированные. Практически в любой компании появляются не совсем тривиальные задачи, которые могут представлять собой подпорку для задач на собеседовании с небольшой доработкой. И порой даже на решении стандартной задачи можно услышать очень оригинальные способы решения (как плохие, так и хорошие). Решение во-первых подкрепит или опровергнет то, что у человека в резюме, а во-вторых покажет, насколько развито у человека критическое мышление, если задача для него нова или он не сталкивался с подобным на прошлых работах.
Что касаемо задач, они не обязательно должны быть стандартными. Главное, чтобы были из реального проекта и не слишком узкоспециализированные. Практически в любой компании появляются не совсем тривиальные задачи, которые могут представлять собой подпорку для задач на собеседовании с небольшой доработкой. И порой даже на решении стандартной задачи можно услышать очень оригинальные способы решения (как плохие, так и хорошие). Решение во-первых подкрепит или опровергнет то, что у человека в резюме, а во-вторых покажет, насколько развито у человека критическое мышление, если задача для него нова или он не сталкивался с подобным на прошлых работах.
Из опыта. Самая лучшая проверка знаний, это попросить написать «фреймворк» при недостаточном времени (не обязательно при собеседовании). Сразу видно в каком направлении работает голова и знания ООП. К тому же будет что обсудить при повторном собеседовании.
попросить написать «фреймворк»
Что, имхо, некорректно, ибо, во-первых, порождает тонну вопросов, что же на самом деле хотят, т.к. фреймворков много и разных, для различных нужд и трудно выяснить, что же на самом деле хотят от тебя как от кандидата, а во-вторых, запросто уводит в патовую ситуацию, когда субъективизм видения собеседующего и собеседуемого на то, каким должен и не должен быть фреймворк, просто зашкаливает — особенно в условиях недостатка времени, когда закончить такое «тестовое» задание априори невозможно, и что там должно быть, а что нет, чтобы называться «фреймворком».
К примеру, несколько месяцев назад некий парниша написал статью на Хабре, где описал свой «фремворк» — «легковесный ORM», состоящий из одного класса и был закидан
И к тому же, на какой уровень собеседуемого Вы предлагаете использовать подобное задание — джуник, миддл или сеньор?
Очевидно, что на каждый уровень должны быть различные вопросы. И если человеку без опыта действительно нужно задавать вопросы в стиле «что выведет echo ''+0?», то мучать подобными вопросами сеньора — уже не уважать ни его, ни себя, и лучше поспрашивать о его опыте работы, используемых технологиях, проблемах, с которыми он столкнулся и как решал, без конкретики «напишите на листочке классы A и B, чтобы один наследовал другой и можно ли будет на объекте одного класса вызвать метод, определенный в другом».
И еще немного, о тестовых заданиях. Помню я, как мне предложили создать «админку» в стиле CRUD для редактирования сотрудников и их зарплат, на 8 часов, после чего мне отказали на том основании, что я сделал функциональность и совсем не позаботился о том, как оно выглядело — без стилей, сверстано таблицами и проч. В другом случае тестовым заданием было: зайти в их багтрекер, выбрать по вкусу баг их системы и исправить его — чем я даже заниматься не стал :) А Вы предлагаете писать «фреймворк».
Видимо не правильно выразился. У меня как-то было задание, написать простую страницу с логином используя ООП и «clean url» что по сути включает в себя создание простейшего рутинга и слоя доступа к базе данных.
Уже на данном этапе можно понять в какую сторону понесет разработчика учитывая нехватку времени. Кто-то просто пихает весь код в статические методы и называет это ООП. Кто-то начинает лепить ненужные абстракции.
Это всё относится к мидлу.
Сеньёрство это вообще страшный субъективизм, т.к. есть немало руководителей для кого просто 5-7 лет работы по специальности автоматом причисляет к «лиге сеньёров». Юниоров заставлять писать такие задание перебор.
Уже на данном этапе можно понять в какую сторону понесет разработчика учитывая нехватку времени. Кто-то просто пихает весь код в статические методы и называет это ООП. Кто-то начинает лепить ненужные абстракции.
Это всё относится к мидлу.
Сеньёрство это вообще страшный субъективизм, т.к. есть немало руководителей для кого просто 5-7 лет работы по специальности автоматом причисляет к «лиге сеньёров». Юниоров заставлять писать такие задание перебор.
Сеньёрство это вообще страшный субъективизм
Все субъективно. У кого-то джуниор это человек без опыта, хотя это подразумевает что человек может самостоятельно решать стандартные задачи, а человек без опыта это стажер.
Например я не всегда могу определить пограничные категории, вроде "джун переходящий в мидла" или "мидл переходящий в синьера" и потому приходится оперировать "чего умеет, насколько быстро будет развиваться и сколько просит". Так например можно взять более слабого разработчика чуть дороже если видно что за пару месяцев сможет быстро втянуться. А можно взять дорогого синьера которого придется еще и переучивать.
Ну и еще момент… почему-то в PHP сообществе очень большая редкость джуны с опытом работы с юнит тестами. Хотя как по мне это обязательно для джуниоров.
очень большая редкость джуны с опытом работы с юнит тестами
добавьте сюда внимание к устойчивости системы (в смысле безопасности). Почему-то, джуники считают своим долгом «склеивать» запросы в строку с переменными, а даже миддлы\сеньоры совсем не видят пограничных ситуаций от «а что, если пользователь ввел букву вместо цифры» до «а не придет ли сюда null и не сломает ли нам все.» Заметьте, это никак не коллерирует с написанием юнит-тестов — юниты тоже надо еще уметь писать :)
В итоге, 90% (субъективно) сайтов содержат детские ошибки и подвержены элементарным sql injection, xss — я уж молчу про timed attack, csrf и проч.
Почему-то, джуники считают своим долгом «склеивать» запросы в строку с переменными
Ничего страшного. Если "джуник" адекватный, ему можно один раз объяснить почему это плохо и не переживать. Тем более что сегодня большая часть джуников работают только с объектым API и запросы компилятся (во всяком случае меня такие джуники интересуют, которые работают с фреймворками и т.д.)
а даже миддлы\сеньоры совсем не видят пограничных ситуаций от «а что, если пользователь ввел букву вместо цифры» до «а не придет ли сюда null и не сломает ли нам все.»
Побочные эффекты мало кто учитывает. Потому это один из основных источников багов.
Заметьте, это никак не коллерирует с написанием юнит-тестов — юниты тоже надо еще уметь писать :)
коррелируется. Это умение составлять тест кейсы, умение проверить качество своего кода. Писать юнит тесты легко, сложно писать тестируемый код. А пытаться "переучиться" еще сложнее.
В итоге, 90% (субъективно) сайтов содержат детские ошибки
90% сайтов написаны на wordpress и подобных штуках с кучей плагинов написанных школьниками. Так что это нормально. Меня такие не интересуют. Что до timed attack… я слышал что кому-то удалось провернуть такое при работе с удаленным сервером (пинги более 10-ти милисекунд) но честно я считаю что заморачиваться на этой почве нужно только если это прописано в требованиях. Как правило задачи где это критично — это редкость. Ну а для хэшей паролей есть устойчивый к этому виду атак password api.
«а что, если пользователь ввел букву вместо цифры» — тут смотря что вы имеете в виду. Подсказывать пользователю, что он ошибся, указывать где и как, сейчас обычно задача фронтенда, наше же дело — привести к числу, пришедшую с фронта строку, если нет прямых требований выводить результаты валидации.
написать простую страницу с логином используя ООП и «clean url»
Здесь «фреймворком» и не пахнет, вопрос только в разделении слоев и уровне абстракции, чтобы эта функциональность с наименьшей болью вписывалась в существующую архитектуру и\или подстраивалась под использование одного или нескольких фреймворков, в стиле «здесь вьюшку можно написать используя шаблонизатор вместо голого пхп» и «а методы этого класса переписываем, чтобы он обращался к Zend-DB или чему-то еще», а «clean url» вместо правила в .htaccess конфигим через методы, предоставляемые фреймворком.
Таким образом, и монолит в виде статических методов и подход «фабрика фабрик фабрик» с интерфейсом на каждый класс — это всегда решение, запросто не выдерживающее критики, но зато развязывает руки собеседующему принять чела или не принять, вне зависимости от того, что понаписал «испытуемый».
Сеньёрство это вообще страшный субъективизм
Ну почему же. Я выше привел пример нормальных вопросов, а к тому же, сеньор — это не тот, кто способен писать одному ему понятный код, используя одному ему известные хаки и особенности интерпретатора и растить фреймворк над фрейморком, а тот, который умеет видеть потенциальные проблемы и предлагать несколько решений одной проблемы, от «сделать быстро и грязно» до «долго, дорого, но надежно», чей код прост, читаем и гибок, а также умеет организовать команду. Кстати, недавно об этом проскакивала статья.
и совсем не позаботился о том, как оно выглядело — без стилей, сверстано таблицами и проч.
Справедливости ради это говорит о том что вы решали задачу без учета пользователя вашей системы. Вы все же не для себя это делаете а для конечного пользователя, а ему должно быть удобно. Это многое говорит о разработчике. Тем более что для CRUD подобного и наличии Bootstrap-ов всяких 8-ми часов достаточно.
В другом случае тестовым заданием было: зайти в их багтрекер, выбрать по вкусу баг их системы и исправить его — чем я даже заниматься не стал :)
А вот это вы правильно сделали.
Почти согласен с Вами, но: не забываем, это было тестовое задание на 8 часов, а потом, я делал просто, и некрасиво, но не неудобно. Все-таки я программист, а не дизайнер и не верстальщик, и до сих пор считаю, что в первую очередь система должна работать правильно, а красивую картинку можно нарисовать и потом — главное, чтобы эта система позволяла себя легко «разукрасить» так, как душе угодно — хоть с многоязычностью и сменяемыми темами.
Да, Bootstrap бы меня тогда спас, если бы в то время он существовал :) К слову, сейчас как раз использую TwBs для разработки, в стиле «смотрится неплохо, но есть потенциал для вау-дизайна» при минимальных затратах на верстку.
Да, Bootstrap бы меня тогда спас, если бы в то время он существовал :) К слову, сейчас как раз использую TwBs для разработки, в стиле «смотрится неплохо, но есть потенциал для вау-дизайна» при минимальных затратах на верстку.
Все-таки я программист, а не дизайнер и не верстальщик, и до сих пор считаю, что в первую очередь система должна работать правильно, а красивую картинку можно нарисовать и потом
Я знаю слишком много продуктов где внутри все очень плохо зато снаружи все хорошо, и наоборот знаю продукты где внутри все круто но на это ушло слишком много времени и в итоге продукты… умерли) Просто потому что предположения о том как пользователи будут использовать продукт провалились. Если бы сделали чуть проще, хватило бы времени на адаптацию.
Да, Bootstrap бы меня тогда спас, если бы в то время он существовал :)
А вот это уже другой разговор.
Просто потому что предположения о том как пользователи будут использовать продукт провалились
В том и дело, что красивая картинка — с изображениями, анимацией и пр. — это одно, а удобство, юзабилити — совсем другое, и если первое можно отложить на потом, то второе закладывается еще на этапе проектирования и в целом определяет поведение и функциональность системы. И если углы у кнопочки можно закруглить в последнюю очередь, то тот факт, есть ли кнопочка или нет, расположена она вверху и продублирована ли для удобства внизу или запрятана в угол — зачастую решает, можно ли в целом пользоваться системой или ее придется серьезно переделывать; туда же поддержка AJAX и проч.
Так вот, если на первое я плюю, то на второе я очень даже обращаю внимание, и пусть при этом проект выглядит будто родом из 90х, с ужасными квадратными серыми кнопками — ведь это всегда можно приукрасить :)
Вопрос о том как пользователи будут использовать ваш продукт очень важен, без этого нельзя. Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.
Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
Требовать — странно, согласен. Но если чувак заморочался — это будет плюсом. Нет — можно будет и на эту тему поговорить, узнать что важно для человека. Бывают люди которым важно что бы код был идеален, а все остальное мелочи. Вот таких людей надо вовремя определять и смотреть потом на общую адекватность.
з.ы. не минусовал
потому, как
это недостойно, и изложил свою позицию. Но вижу, что и без меня с Вами не согласны :)
Сразу видно в каком направлении работает голова и знания ООП.
Есть намного более эффективные способы это проверить.
Проблема в том, что работодатели не понимают различие между «php-программистом» «HTML-верстальщиком» и дизайнером. Поэтому складывается такое мнение если ты «web-программист то должен все эти три профессий, если по принятии на работу ты написал отличный код, но дизайн сайта не красив, то тебя могут и не принять на работу.
Можно я чуть вброшу на вентилятор? Коллеги, а что вы думаете о тестах в апворк?
НЛО прилетело и опубликовало эту надпись здесь
А есть новые?
Благодарю, гляну.
Я помню там был ад на «кто лучше зазубрит пхп.нет, тот и сеньор.
И да, помню были проблемы с пониманием задания.
Сдал с трудом „на троечку“, и хоть очевидно что решать надо с открытым на второй машине гуглом, но как-то не хочется еще раз проходить. Нафик.
Но если обновились, то попробую. Благодарю.
Благодарю, гляну.
Я помню там был ад на «кто лучше зазубрит пхп.нет, тот и сеньор.
И да, помню были проблемы с пониманием задания.
Сдал с трудом „на троечку“, и хоть очевидно что решать надо с открытым на второй машине гуглом, но как-то не хочется еще раз проходить. Нафик.
Но если обновились, то попробую. Благодарю.
Для кандидата это хороший способ заранее узнать, надо ли будет работать с говнокодом в компании. Дали тебе задачку на i++ + ++i, а ты такой — «погодите, подобный код встречается в ваших реальных проектах? Так, ну я пошел!»
tests/classes/abstract_redeclare.phpt
Какой-то странный тест, ожидается, что метод не может быть повторно объявлен абстрактным, а ошибка ловится вот эта:
«Class fail contains 1 abstract method and must therefore be declared abstract or implement the remaining methods»
Какой-то странный тест, ожидается, что метод не может быть повторно объявлен абстрактным, а ошибка ловится вот эта:
«Class fail contains 1 abstract method and must therefore be declared abstract or implement the remaining methods»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подготовка к собеседованиям по PHP с использованием тестов (phpt) из исходников PHP