Такие вечеринки пытались проводить в Питере, в диджей-баре «Святые угодники». Их было, кажется, четыре. Возраст участников — 20-25 лет. Два раза действо срывалось: пришедшие парни сразу уходили, посмотрев на девочек. Без объективных причин. Я лично не заметил качественной разницы во внешности и возрасте между всеми разами.
Так что, советую иметь пару подсадных уток — количества участников обоих полов нужно уравнивать, приходить, наверняка, будут не все записавшиеся.
Контекст разговоров за столами — «Зачем ты сюда пришёл?». Это было удивительно, потому как я бы не назвал пришедших парней лузерами. Я помню одного достаточно успешного спортсмена, пару юристов и так далее. В общем, внешние атрибуты успеха были на виду.
Я для себя сделал вывод, что участие в подобной встрече как бы заставляет парня признаться себе в том, что он неуспешный самец, раз выбрал подобный способ знакомства.
Хотя, по факту, там общались именно те люди, у которых хватило силы преодолеть в себе этот барьер — а не слабаки. Либо те, у кого хватило ума не воспринимать происходящее всерьёз и относиться ко всему как к развлечению.
Эту точку зрения я вывел из общения с некоторыми парнями пост-фактум.
Насчёт девочек ничего определённого не скажу, однако, по субьективному ощущению — они казались отчаявшимися. Самыми яркими были подсадные утки.
Я могу понять парня, которому сложно, например, заговорить первым. На вечеринке знакомств эта проблема снимается. Для парня выгода очевидна.
Девочка при знакомстве, обычно, не проявляет инициативу активно — а лишь подаёт знаки. Так что, с позиции девочки я не вижу особой разницы в том смысле, идти ли ей на подобную вечеринку знакомств, либо, скажем, в клуб, бар или на выставку.
В общем, всё это было довольно занимательно, но оказалось нежизнеспособно.
Я сейчас делаю параллельно два проекта: один на ASP.Net MVC, а второй — начал на ROR. Оговорюсь, оба проекта будут малопосещаемыми — так что, скейлинг им не понадобится. Кроме того, они не связаны с вычислениями — так что, скорость тут тоже не играет роли. ASP.NET используется, так как нужна связь с 1C и потому заказчик поставил условие разрабатывать на C#.
Я увидел главное преимущество ROR: рельсы — однородная среда, содержащая решения большей части типовых задач, возникающих при разработке сайтов. Чего пока не скажешь об ASP.NET MVC.
Скажем, в ASP я не смог решить стандартными средствами следующие задачи:
— Доступ к данным через ORM (использую сторонний продукт — NHibernate; MVC в ASP это VC).
— Миграции.
— Простая работа с AJAX (конкретно — отправка файлов через AJAX).
— Работа с шаблонизаторами, кроме ASP (нужно писать свой плагин).
— Постраничный вывод.
— Загрузка и обновление тестовых данных в базе.
В ROR все эти задачи решились без особенных выкрутасов средствами, входившими в комплект — и описанными в документации, а не в гугле.
Любой инструмент хорош для своих задач. Мне обычно нужно сделать быстро, надёжно и изменяемо, а скорость выполнения стоит на десятом месте. Потому и изучаю ROR.
А можно подробнее насчёт скейлинга? И: что подразумевается под «шагом в сторону»? Видимо, при разработке на ROR, была какая-то конкретная проблема? Какая именно?
Простите, я спросил конкретно. Рассуждения о поведении сферического коня в вакууме хороши чтоб потрепать языком в пабе, но не здесь.
Не очень понимаю, что значит «простой инструмент». Возможно, инструмент простой в смысле KISS. Однако, я не нашёл существенных недостатков при сравнении с PHP/Symfony/Cake (PHP-опыт — шесть лет) — то есть, нет задачи, которую я не мог бы реализовать на ROR — но мог бы на PHP. При этом, по моему, не очень богатому опыту в ROR, на рельсах та же задача требует меньше времени, решается на порядок более комплексно и однородно, и требует меньше сил при поддержке и внесении модификаций.
Поэтому, ROR для меня привлекателен — и я спросил, что конкретно показала ваша практика. Мне хочется быть осведомлённым о повторных камнях. Какие конкретно подводные камни существуют?
В смысле вызова - ничем, а в смысле обработки - принципиально. В случае с отправкой сообщения - ни отправляющая, ни принимающая стороны не имеют информации друг о друге - в отличие от класс-ориентированного подхода, где интерфейсы объектов жёстко определяются интерфейсом класса.
Обрабатывать сообщение или отклонить - решает принимающая сторона. Говоря в терминах класс-ориентированного ООП, принимающая сторона имеет динамический интерфейс.
Такой подход понижает связность системы, а значит - делает её более устойчивой к изменениям, нежели чем при использовании статически типизированных классов. Во всяком случае, такую цель ставила себе команда XEROX Parc при реализации сообщений в Smalltalk.
На тему сообщений есть интересная статья (точное название не помню, из журнала "Byte" за 1981 год, найти можно на Smalltalk.ru). В ней описаны цели создания Smalltalk, как системы, основанной на сообщениях и преимущества такого подхода.
Асинхронность же тут ни при чём. И синхронная и асинхронная обработка сообщений примерно одинаково реализуются и в случае с вызовами, и в случае с сообщениями. По этим же причинам, мало общего с циклом сообщений Win32 API.
В таких статьях меня смущает формулировка "свой проект". Обычно, работа на себя по своему содержанию довольно сильно отличается от работы в офисе. В частности, как верно замечено, приходится осваивать навыки маркетинга, работы с людьми и так далее.
Если человек дизайнер и хочет заниматься дизайном - наверное, логичнее ему оставаться дизайнером (фотографом, программистом, верстальщиком - нужное подчеркнуть), а не превращаться в специалиста по продаже и перепродаже самого себя, либо в менеджера по продвижению собственного продукта - то есть, в специалиста по бизнесу. А это непременно происходит с каждым фрилансером/владельцем своего дела.
Это не плохо, и как подметил Кийосаки, умение зарабатывать деньги сейчас столь же важно, как умение читать и писать, и в школе этому не учат - а должны.
В общем, не только работа без души является критерием ухода в свободное плавание. Обычно, этим критерием являются определённые особенности характера. В ином случае, стоит просто сменить работу. :)
Моя мама - программист. Она писала в машинных кодах для ЕС ЭВМ и прочих экзотичесих машин. Дома хранится перфолента "Вова + Надя = Любовь". Вова это мой папа.
Кроме перфоленты, оберегается книга Денни Ван Тассела "Стиль, разработка, эффективность, отладка и испытание программ". Эта книга - примерно моя ровесница. И в ней, понятное дело, объектно-ориентированным программированием и не пахнет.
Одна из главных мыслей книги - такая: программы нужно делать понятными, легко модифицируемыми и модульными. При чём, модули лучше делать независимыми, а значит - заменяемыми.
Очень похоже на цели принципов ООП, хотя, примеры в книге приводятся одновременно на процедурном, функциональном и, если не ошибаюсь, линейном языках каждый. То есть, на трёх языках с разной парадигмой.
Безусловно, ООП облегчает процесс разработки модульных программ. Однако, само по себе использование ООП не гарантирует что модули вашей программы можно будет повторно использовать, либо безболезненно заменять.
ООП - не панацея от плохих программ и, тем более, плохих программистов. Плохо писать можно и на смолтоке и на лиспе, и на C++.
Панацея от плохих программ - грамотное проектирование и здравый смысл.
Конечно, ООП облегчает реализацию модулей и дисциплинирует. Чего стоят одни только шаблоны проектирования. Невозможно реализовать какую-нибудь там абстрактную фабрику в виде процедуры (вернее, возможно, но это не будет так же легко читаться). Но это не значит, что без использования ООП нельзя сделать легко поддерживаемую, эффективную и модифицируемую программу.
Основополагающие принципы разработки программ были сформулированы гораздо раньше принципов ООП, и, по большому счёту, независимы от парадигмы программирования.
Спорить о преимуществах того или иного подхода бессмысленно. Я вот, например, люблю велосипед больше чем роликовые коньки и считаю, что он ездит быстрее, но как-то раз не смог угнаться на нём за бывшей фигуристкой-роллершей.
Я так думаю, любая парадигма программирования (как и язык) в первую очередь отражает определённый способ мышления. Если кому-то удобно думать на английском - значит, вероятно, он и говорить будет на английском понятнее.
Есть класс-ориентированное ООП (C++), а есть прототипно-ориентированное (JS). Опять же, это немного разные подходы с разными преимуществами.
ООП в PHP очень далеко от принципов ООП, сформулированных Кеем. В PHP это немногим больше чем инструмент группировки функций.
Однако, и от этой группировки есть определённая польза. В любой программе сущности чаще всего отражаются структурами, и присутствуют временные переменные, относящиеся к экземплярам структур. Я думаю, программа только выиграет от объединения структур и функций в класс, да и плюс сразу станет понятно, может ли та или иная функция принимать на вход только один тип сущностей, либо все типы сущностей сразу (по аналогии с методами базовых классов).
В Smalltalk нет вызовов методов, но есть процедура отправки сообщения. При чём, отправитель не обязан (но имеет возможность) знать, есть ли в целевом объекте метод для обработки этого сообщения. А получатель, в свою очередь, не обязан сообщение обрабатывать, но и может, скажем, обработать неизвестное ему сообщение.
Такой подход позволяет понизить до минимума связность системы. Каждый объект существует в абсолютной изоляции от других и может быть легко заменён. Низкая связность == лёгкость модификаций == повторное использование. В понижении связности и была одна из целей создания Smalltalk как объектного языка, да и, наверное, одна из целей ООП в общем.
Как заявлял сам Кей, отказ от идеи обмена сообщениями в пользу вызовов снижает эффективность всей идеи.
Да, выскажу. Однако, нужно в этом основательно разобраться. Подход интересный, но, как я сказал, не совсем обычный и не совсем стандартный для языка PHP.
То есть, он сложен для понимания, а выбирают, обычно, не то что хорошо, а то что просто. В общем, обдумаю и напишу.
Судя по целям, это хорошая задумка. Единственный недостаток: без нормального руководства польза Frontier и этого поста для посторонних равна нулю. Я почитал документацию к API, но не понял из неё ровным счётом ничего.
В своих проектах я использую набор классов, представляющих из себя то же самое: гибкий MVC-каркас. Я навешиваю на этот каркас в качестве модели, по необходимости, Doctrine, SimpleMySQL или чистый API. Шаблоны делаются на xsl, но пару раз приходилось использовать смарти и чистый PHP.
Мне не нужны плагины (их роль часто играют шаблоны и базовые классы в доктрине) и не нужны генераторы, по скольку, админка делается, обычно, с использованием аякса по давно отработанным шаблонам.
Я так думаю, подобных MVC-"пустышек" тысячи: у каждого разработчика - своя, так почему бы не собрать лучшее из них в одну или несколько библиотек?
Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.
Если привести полностью, то будет что-то в духе:
<xsl:variable name="options" select="/root/options"/>
<xsl:apply-templates select="$options">
<xsl:with-param name="selected" value="/root/currentOption"/>
</xsl:apply-templates>
Запись достаточно громоздкая. Я ещё раз повторяю, XSLT - эффективный инструмент, но его синтаксис в приложении к языку шаблонов сайта мог бы быть проще.
Я не очень понимаю, в чём практический смысл большей части этих вопросов. Я использую PHP уже порядка пяти лет (PHP не единственный язык) и до сих пор затрудняюсь назвать по памяти больше трёх типов данных, или же вспомнить хотя бы десять функций работы с массивами по названиям. Я помню их не по названиям, а по назначению - и если нужно вспомнить сигнатуру вызова - лезу в документацию.
Собеседование это не тест на знания. Собеседование должно быть тестом на умение. Когда я искал программиста-напарника, первичным было тестовое задание, а не тест на бумаге. Само задание было достаточно простым, но с несколькими заковыками. В результате меня интересовало:
- Скорость выполнения задания (точнее, выполнено ли в срок).
- Результирующее количество ошибок.
- Качество кода.
- Использованные библиотеки (mysql_query против Doctrine::getTable() :) - то есть, умение не изобретать велосипед.
- Как спроектировано (plain php против отделения кода от шаблона).
По результатам теста, я сразу понимал, знает ли человек о существовании array_reverse или делает инвертирование руками, ну и так далее.
Навыки всегда отражают знания, поэтому, теоретические вопросы, тем более, такие сложные - в данном случае, бесполезны. Если хотите знать, насколько глубоко человек понимает сетевые протоколы - ну попросите вручную составить HTTP-запрос telnet'ом.
Бумажный тест у меня отсеивал тех людей, кто точно не справится и был нужен чтоб примерно понять кругозор: что человек знает, кроме PHP. И, если уж делать бумажный тест, вопросы нужно ставить, опять же, проверяющие навык.
Скажем, вопрос про версии PHP (вместо "в чём отличие версий"):
- Что выдаст этот фрагмент кода: "..." в PHP4 и в PHP5? Будет ли результат выполнения одинаковым?
Сразу станет ясно, знает ли человек в чём отличие версий и использовал ли он разные версии на практике. Если написать в этом фрагменте, скажем, var $public.
Вопрос про ООП:
- Что такое шаблоны проектирования? Какие шаблоны проектирования Вы применяете и зачем?
Что такое инкапсуляция - ответит любой, это словесная формула. Гораздо важнее, зачем она нужна. Однако, и это не так важно, как цель использования ООП. Поэтому, если человек даст ответ на вопрос "применяю шаблон Observable в JavaScript чтоб понизить связность визуальных компонентов на моей странице") - это сразу покажет, что в ООП он использует не только синтаксис, но и идею.
Кроме того, я бы добавил вопрос про TDD (Unit Testing):
- Что такое TDD и какими средствами можно реализовать его в PHP?
И добавил бы вопросы про XSLT, Smarty (и другие шаблонные движки) и JavaScript. Я понимаю, что ищется PHP-разработчик, а JavaScript - другая опера, но тем не менее, в реальности обычно оба программиста выступают в одном лице.
Что касается вопроса про OSI - это вопрос к системному администратору, а не к программисту на PHP.
Я не против XSLT, использую его почти во всех проектах. Лишь попытался описать минусы. Читаемость и писаемость :) всё же оставляют желать лушего. Я слышал что-то про краткий синтаксис, но не копал глубоко.
Я не писал о том что эти задачи нерешаемы. Я писал о том что XSLT не всегда удобен. XSLT - прекрасный инструмент, но для шаблонизации веб-страниц часто можно использовать что-то попроще.
Скажем, вместо конструкции из пункта 1 мне удобнее написать:
То же с конечными циклами: вряд ли кто-то согласится заменить конструкцию for на рекурсивную функцию в C++. В XSLT рекурсивные шаблоны - не удобное, а вынужденное решение, workaround.
Использую XSLT 4 года. В последние месяцы прихожу к выводу: это слишком универсальная технология. Для узкоспециальной задачи - веба - есть более функциональные и удобные решения.
Плюсы следующие:
1. Это стандарт. Значит, можно менять и расширять штат верстальщиков, не заботясь об известных им форматах хранения шаблонов - читай "языков программирования". Ситуация, когда приходится править вёрстку, вернее, вносить изменения внутри запрограммированного шаблона - довольно частая.
2. Поддержка именованных и параметризованных блоков в шаблонах. Smarty и erb заставляют эти блоки держать в отдельных файлах.
3. Генерация валидного (X)HTML.
Минусы:
1. Не слишком удобный декларативный синтаксис. Скажем, если генерируется список option'ов, конструкция, прописывающая аттрибут "selected" на XSLT выглядит гораздо длиннее, чем на erb.
2. В XSLT 1.0 мало функций. Вывод русской даты стандартными средствами - целый геморрой, хотя, конкретно в PHP можно вызвать внешнюю PHP-функцию. Тут и проявляются "прелести" синтаксиса.
3. Оверхед:
- Нужно прописывать DTD, заголовки, подгружать описания HTML-сущностей и
так далее.
- Данные приходится преобразовывать из формата языка программирования в
XML: эта операция создаёт избыточность внутри конкретного скрипта - одни
и те же данные приходится держать в переменных скрипта (выборка из базы)
и в XML.
4. Отсутствие конечных циклов (изменить $i от 1 до 3). Требуется, скажем, для генерации номеров страниц в постраничной навигации.
5. Не особенно удобно делать шаблоны текстовых писем (xml:space="preserve"): за переносами следить сложнее чем в случае шаблона на PHP. Аннонят конструкции вроде: " Здравствуйте! ... (тут перенос)... ".
6. XPath не позволяет делать некоторые типы выборок. К сожалению, не могу привести конкретный пример, но я с этим время от времени сталкиваюсь.
7. Что спорно и решаемо - скорость работы.
О, да, тут я полностью согласен! Взять хотя бы ручное закачивание PEAR-библиотек, отсутствие необходимых модулей PHP или невозможность собрать собственный интерпретатор. Хостинги иногда творят совершенно невообразимые вещи. Я для себя выбрал мастерхост - пусть, иногда поддержка там как в мультике - "выглядят они не слишком привлекательно, но ничего". :) Зато, ещё ни разу не упирался в нерешаемые проблемы с хостингом.
Нихрена не понял, что Вы хотели сказать. Если они используют UTF-8 - здорово, это шаг к упрощению, тем более, если учесть, что они могут позволить себе наращивать мощности серверов до бесконечности.
Я написал "Я лично". У меня таких мощностей нет, иногда приходится изголяться. И - я написал "Оставляю лазейку для перехода на UTF-8".
Кроме того, я не очень представляю как гугл обошёлся бы искомой 1251 на клиенте, если учесть всё многообразие его многоязычных версий.
Вообще, чтоб говорить сколь-нибудь аргументированно на тему гибридный вариант vs UTF-8 нужно иметь какие-то осмысленные данные по потерям производительности на UTF-8. Понятно, что UTF работает медленно, но насколько и можно ли в каждом конкретном случае пренебрегать потерями - не ясно.
Аргумент один: отсутствие необходимости следить за кодировкой. Там где критична скорость выполнения - то есть на сайтах с большой посещаемостью - лучше использовать гибридный вариант. На маленьких я лично использую UTF-8 и на клиенте и на сервере, но оставляю лазейку чтоб в случае чего без проблем мигрировать на этот самый гибридный вариант.
В конце концов, время сейчас такое, когда простота приносится в жертву скорости выполнения. Так что переход к ресурсоёмким, но простым технологиям это ход в духе времени.
Если я делаю сайт, мне в некоторых случаях важно не соответствие стандарту, а работоспособность. В частности, gmail плохо ведёт себя с '\r\n' - показывает лишние переносы строк. По моему опыту (точнее, результатам проверки в популярных программах-клиентах, и на почтовых сервисах большинства подписчиков на http://www.mixfight.ru), '\n' понимается в большем числе случаев, чем '\r\n', так что я буду использовать это разделение вопреки стандарту, пусть это и не лучшее решение.
Так что, советую иметь пару подсадных уток — количества участников обоих полов нужно уравнивать, приходить, наверняка, будут не все записавшиеся.
Контекст разговоров за столами — «Зачем ты сюда пришёл?». Это было удивительно, потому как я бы не назвал пришедших парней лузерами. Я помню одного достаточно успешного спортсмена, пару юристов и так далее. В общем, внешние атрибуты успеха были на виду.
Я для себя сделал вывод, что участие в подобной встрече как бы заставляет парня признаться себе в том, что он неуспешный самец, раз выбрал подобный способ знакомства.
Хотя, по факту, там общались именно те люди, у которых хватило силы преодолеть в себе этот барьер — а не слабаки. Либо те, у кого хватило ума не воспринимать происходящее всерьёз и относиться ко всему как к развлечению.
Эту точку зрения я вывел из общения с некоторыми парнями пост-фактум.
Насчёт девочек ничего определённого не скажу, однако, по субьективному ощущению — они казались отчаявшимися. Самыми яркими были подсадные утки.
Я могу понять парня, которому сложно, например, заговорить первым. На вечеринке знакомств эта проблема снимается. Для парня выгода очевидна.
Девочка при знакомстве, обычно, не проявляет инициативу активно — а лишь подаёт знаки. Так что, с позиции девочки я не вижу особой разницы в том смысле, идти ли ей на подобную вечеринку знакомств, либо, скажем, в клуб, бар или на выставку.
В общем, всё это было довольно занимательно, но оказалось нежизнеспособно.
Я увидел главное преимущество ROR: рельсы — однородная среда, содержащая решения большей части типовых задач, возникающих при разработке сайтов. Чего пока не скажешь об ASP.NET MVC.
Скажем, в ASP я не смог решить стандартными средствами следующие задачи:
— Доступ к данным через ORM (использую сторонний продукт — NHibernate; MVC в ASP это VC).
— Миграции.
— Простая работа с AJAX (конкретно — отправка файлов через AJAX).
— Работа с шаблонизаторами, кроме ASP (нужно писать свой плагин).
— Постраничный вывод.
— Загрузка и обновление тестовых данных в базе.
В ROR все эти задачи решились без особенных выкрутасов средствами, входившими в комплект — и описанными в документации, а не в гугле.
Любой инструмент хорош для своих задач. Мне обычно нужно сделать быстро, надёжно и изменяемо, а скорость выполнения стоит на десятом месте. Потому и изучаю ROR.
А можно подробнее насчёт скейлинга? И: что подразумевается под «шагом в сторону»? Видимо, при разработке на ROR, была какая-то конкретная проблема? Какая именно?
Не очень понимаю, что значит «простой инструмент». Возможно, инструмент простой в смысле KISS. Однако, я не нашёл существенных недостатков при сравнении с PHP/Symfony/Cake (PHP-опыт — шесть лет) — то есть, нет задачи, которую я не мог бы реализовать на ROR — но мог бы на PHP. При этом, по моему, не очень богатому опыту в ROR, на рельсах та же задача требует меньше времени, решается на порядок более комплексно и однородно, и требует меньше сил при поддержке и внесении модификаций.
Поэтому, ROR для меня привлекателен — и я спросил, что конкретно показала ваша практика. Мне хочется быть осведомлённым о повторных камнях. Какие конкретно подводные камни существуют?
В смысле вызова - ничем, а в смысле обработки - принципиально. В случае с отправкой сообщения - ни отправляющая, ни принимающая стороны не имеют информации друг о друге - в отличие от класс-ориентированного подхода, где интерфейсы объектов жёстко определяются интерфейсом класса.
Обрабатывать сообщение или отклонить - решает принимающая сторона. Говоря в терминах класс-ориентированного ООП, принимающая сторона имеет динамический интерфейс.
Такой подход понижает связность системы, а значит - делает её более устойчивой к изменениям, нежели чем при использовании статически типизированных классов. Во всяком случае, такую цель ставила себе команда XEROX Parc при реализации сообщений в Smalltalk.
На тему сообщений есть интересная статья (точное название не помню, из журнала "Byte" за 1981 год, найти можно на Smalltalk.ru). В ней описаны цели создания Smalltalk, как системы, основанной на сообщениях и преимущества такого подхода.
Асинхронность же тут ни при чём. И синхронная и асинхронная обработка сообщений примерно одинаково реализуются и в случае с вызовами, и в случае с сообщениями. По этим же причинам, мало общего с циклом сообщений Win32 API.
Если человек дизайнер и хочет заниматься дизайном - наверное, логичнее ему оставаться дизайнером (фотографом, программистом, верстальщиком - нужное подчеркнуть), а не превращаться в специалиста по продаже и перепродаже самого себя, либо в менеджера по продвижению собственного продукта - то есть, в специалиста по бизнесу. А это непременно происходит с каждым фрилансером/владельцем своего дела.
Это не плохо, и как подметил Кийосаки, умение зарабатывать деньги сейчас столь же важно, как умение читать и писать, и в школе этому не учат - а должны.
В общем, не только работа без души является критерием ухода в свободное плавание. Обычно, этим критерием являются определённые особенности характера. В ином случае, стоит просто сменить работу. :)
Кроме перфоленты, оберегается книга Денни Ван Тассела "Стиль, разработка, эффективность, отладка и испытание программ". Эта книга - примерно моя ровесница. И в ней, понятное дело, объектно-ориентированным программированием и не пахнет.
Одна из главных мыслей книги - такая: программы нужно делать понятными, легко модифицируемыми и модульными. При чём, модули лучше делать независимыми, а значит - заменяемыми.
Очень похоже на цели принципов ООП, хотя, примеры в книге приводятся одновременно на процедурном, функциональном и, если не ошибаюсь, линейном языках каждый. То есть, на трёх языках с разной парадигмой.
Безусловно, ООП облегчает процесс разработки модульных программ. Однако, само по себе использование ООП не гарантирует что модули вашей программы можно будет повторно использовать, либо безболезненно заменять.
ООП - не панацея от плохих программ и, тем более, плохих программистов. Плохо писать можно и на смолтоке и на лиспе, и на C++.
Панацея от плохих программ - грамотное проектирование и здравый смысл.
Конечно, ООП облегчает реализацию модулей и дисциплинирует. Чего стоят одни только шаблоны проектирования. Невозможно реализовать какую-нибудь там абстрактную фабрику в виде процедуры (вернее, возможно, но это не будет так же легко читаться). Но это не значит, что без использования ООП нельзя сделать легко поддерживаемую, эффективную и модифицируемую программу.
Основополагающие принципы разработки программ были сформулированы гораздо раньше принципов ООП, и, по большому счёту, независимы от парадигмы программирования.
Спорить о преимуществах того или иного подхода бессмысленно. Я вот, например, люблю велосипед больше чем роликовые коньки и считаю, что он ездит быстрее, но как-то раз не смог угнаться на нём за бывшей фигуристкой-роллершей.
Есть класс-ориентированное ООП (C++), а есть прототипно-ориентированное (JS). Опять же, это немного разные подходы с разными преимуществами.
ООП в PHP очень далеко от принципов ООП, сформулированных Кеем. В PHP это немногим больше чем инструмент группировки функций.
Однако, и от этой группировки есть определённая польза. В любой программе сущности чаще всего отражаются структурами, и присутствуют временные переменные, относящиеся к экземплярам структур. Я думаю, программа только выиграет от объединения структур и функций в класс, да и плюс сразу станет понятно, может ли та или иная функция принимать на вход только один тип сущностей, либо все типы сущностей сразу (по аналогии с методами базовых классов).
В Smalltalk нет вызовов методов, но есть процедура отправки сообщения. При чём, отправитель не обязан (но имеет возможность) знать, есть ли в целевом объекте метод для обработки этого сообщения. А получатель, в свою очередь, не обязан сообщение обрабатывать, но и может, скажем, обработать неизвестное ему сообщение.
Такой подход позволяет понизить до минимума связность системы. Каждый объект существует в абсолютной изоляции от других и может быть легко заменён. Низкая связность == лёгкость модификаций == повторное использование. В понижении связности и была одна из целей создания Smalltalk как объектного языка, да и, наверное, одна из целей ООП в общем.
Как заявлял сам Кей, отказ от идеи обмена сообщениями в пользу вызовов снижает эффективность всей идеи.
То есть, он сложен для понимания, а выбирают, обычно, не то что хорошо, а то что просто. В общем, обдумаю и напишу.
В своих проектах я использую набор классов, представляющих из себя то же самое: гибкий MVC-каркас. Я навешиваю на этот каркас в качестве модели, по необходимости, Doctrine, SimpleMySQL или чистый API. Шаблоны делаются на xsl, но пару раз приходилось использовать смарти и чистый PHP.
Мне не нужны плагины (их роль часто играют шаблоны и базовые классы в доктрине) и не нужны генераторы, по скольку, админка делается, обычно, с использованием аякса по давно отработанным шаблонам.
Я так думаю, подобных MVC-"пустышек" тысячи: у каждого разработчика - своя, так почему бы не собрать лучшее из них в одну или несколько библиотек?
Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.
<xsl:variable name="options" select="/root/options"/>
<xsl:apply-templates select="$options">
<xsl:with-param name="selected" value="/root/currentOption"/>
</xsl:apply-templates>
<xsl:template match="options/row">
<option value="{id}"><xsl:if test="$selected=current()/id">
<xsl:attribute name="selected">yes</xsl:attribute>
<xsl:value-of select="value"/>
</option>
</xsl:template>
Запись достаточно громоздкая. Я ещё раз повторяю, XSLT - эффективный инструмент, но его синтаксис в приложении к языку шаблонов сайта мог бы быть проще.
Собеседование это не тест на знания. Собеседование должно быть тестом на умение. Когда я искал программиста-напарника, первичным было тестовое задание, а не тест на бумаге. Само задание было достаточно простым, но с несколькими заковыками. В результате меня интересовало:
- Скорость выполнения задания (точнее, выполнено ли в срок).
- Результирующее количество ошибок.
- Качество кода.
- Использованные библиотеки (mysql_query против Doctrine::getTable() :) - то есть, умение не изобретать велосипед.
- Как спроектировано (plain php против отделения кода от шаблона).
По результатам теста, я сразу понимал, знает ли человек о существовании array_reverse или делает инвертирование руками, ну и так далее.
Навыки всегда отражают знания, поэтому, теоретические вопросы, тем более, такие сложные - в данном случае, бесполезны. Если хотите знать, насколько глубоко человек понимает сетевые протоколы - ну попросите вручную составить HTTP-запрос telnet'ом.
Бумажный тест у меня отсеивал тех людей, кто точно не справится и был нужен чтоб примерно понять кругозор: что человек знает, кроме PHP. И, если уж делать бумажный тест, вопросы нужно ставить, опять же, проверяющие навык.
Скажем, вопрос про версии PHP (вместо "в чём отличие версий"):
- Что выдаст этот фрагмент кода: "..." в PHP4 и в PHP5? Будет ли результат выполнения одинаковым?
Сразу станет ясно, знает ли человек в чём отличие версий и использовал ли он разные версии на практике. Если написать в этом фрагменте, скажем, var $public.
Вопрос про ООП:
- Что такое шаблоны проектирования? Какие шаблоны проектирования Вы применяете и зачем?
Что такое инкапсуляция - ответит любой, это словесная формула. Гораздо важнее, зачем она нужна. Однако, и это не так важно, как цель использования ООП. Поэтому, если человек даст ответ на вопрос "применяю шаблон Observable в JavaScript чтоб понизить связность визуальных компонентов на моей странице") - это сразу покажет, что в ООП он использует не только синтаксис, но и идею.
Кроме того, я бы добавил вопрос про TDD (Unit Testing):
- Что такое TDD и какими средствами можно реализовать его в PHP?
И добавил бы вопросы про XSLT, Smarty (и другие шаблонные движки) и JavaScript. Я понимаю, что ищется PHP-разработчик, а JavaScript - другая опера, но тем не менее, в реальности обычно оба программиста выступают в одном лице.
Что касается вопроса про OSI - это вопрос к системному администратору, а не к программисту на PHP.
<select name="..."><?= generate_options($options, $selected); ?></select>
против
<select name="..."><xsl:value-of select="php:generate_options($options, $selected)/></select>
:)
Я не против XSLT, использую его почти во всех проектах. Лишь попытался описать минусы. Читаемость и писаемость :) всё же оставляют желать лушего. Я слышал что-то про краткий синтаксис, но не копал глубоко.
Скажем, вместо конструкции из пункта 1 мне удобнее написать:
<select name="..."><?= generate_options($options, $selected); ?></select>
Это короче, понятнее и быстрее работает.
То же с конечными циклами: вряд ли кто-то согласится заменить конструкцию for на рекурсивную функцию в C++. В XSLT рекурсивные шаблоны - не удобное, а вынужденное решение, workaround.
Плюсы следующие:
1. Это стандарт. Значит, можно менять и расширять штат верстальщиков, не заботясь об известных им форматах хранения шаблонов - читай "языков программирования". Ситуация, когда приходится править вёрстку, вернее, вносить изменения внутри запрограммированного шаблона - довольно частая.
2. Поддержка именованных и параметризованных блоков в шаблонах. Smarty и erb заставляют эти блоки держать в отдельных файлах.
3. Генерация валидного (X)HTML.
Минусы:
1. Не слишком удобный декларативный синтаксис. Скажем, если генерируется список option'ов, конструкция, прописывающая аттрибут "selected" на XSLT выглядит гораздо длиннее, чем на erb.
2. В XSLT 1.0 мало функций. Вывод русской даты стандартными средствами - целый геморрой, хотя, конкретно в PHP можно вызвать внешнюю PHP-функцию. Тут и проявляются "прелести" синтаксиса.
3. Оверхед:
- Нужно прописывать DTD, заголовки, подгружать описания HTML-сущностей и
так далее.
- Данные приходится преобразовывать из формата языка программирования в
XML: эта операция создаёт избыточность внутри конкретного скрипта - одни
и те же данные приходится держать в переменных скрипта (выборка из базы)
и в XML.
4. Отсутствие конечных циклов (изменить $i от 1 до 3). Требуется, скажем, для генерации номеров страниц в постраничной навигации.
5. Не особенно удобно делать шаблоны текстовых писем (xml:space="preserve"): за переносами следить сложнее чем в случае шаблона на PHP. Аннонят конструкции вроде: " Здравствуйте! ... (тут перенос)... ".
6. XPath не позволяет делать некоторые типы выборок. К сожалению, не могу привести конкретный пример, но я с этим время от времени сталкиваюсь.
7. Что спорно и решаемо - скорость работы.
Я написал "Я лично". У меня таких мощностей нет, иногда приходится изголяться. И - я написал "Оставляю лазейку для перехода на UTF-8".
Кроме того, я не очень представляю как гугл обошёлся бы искомой 1251 на клиенте, если учесть всё многообразие его многоязычных версий.
Вообще, чтоб говорить сколь-нибудь аргументированно на тему гибридный вариант vs UTF-8 нужно иметь какие-то осмысленные данные по потерям производительности на UTF-8. Понятно, что UTF работает медленно, но насколько и можно ли в каждом конкретном случае пренебрегать потерями - не ясно.
В конце концов, время сейчас такое, когда простота приносится в жертву скорости выполнения. Так что переход к ресурсоёмким, но простым технологиям это ход в духе времени.