Просто про веб технологии

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

В нашем проекте LinkAider.com мы используем следующие понятия и классы при работе с Sphinx Search:

1. Сфинкс клиент, отвечающий за подключение, выполнение запросов и обработку ошибок. Для разработчика сфинкс клиент невидим, мы только сообщаем ему параметры подключения к searchd.
2. Сфинкс индекс – это один из основных классов, с которым работает разработчик, этот класс отвечает за формирование запросов и выполнение запросов через Сфинкс клиент, а также за обработку результатов запроса.
3. Сфинкс запрос – это еще один класс к которому обращается разработчик для составления запросов. Каждый запрос отвечает за свои индекс к которому обращается, а также содержит свои фильтры, группировки, сортировки и собственно сам запрос.
4. Сфинкс результат – это класс, который разбирает ответ сфинкса и предоставляет удобный интерфейс к информации по каждому запросу, также он содержит информацию об ошибках, которую испльзуетя Сфинкс клиент для логирования. Сфинкс результат используется разработчиками для создания запросов к базе данных и получения искомых данных.

Пример работы выглядит следующим образом:

1. Мы создаем объект Сфинкс индекс, который инициализирует Сфинкс клиент, устанавливая для него параметры подключения.
2. Потом мы создаем объекты запросы для каждого указываем фильтры, группировки и т.п., и указываем к какому индексу делать запрос. Запросов может быть один или несколько, несколько запросов обрабатываються паралельно, что улучшает общую производительность системы.
3. Каждый созданный запрос мы добавляем в Сфинкс индекс, при добавлении мы можем также указатьк какому индексу делать запрос.
4. Специальный метод Run класса Сфинкс индекс запускает все запросы и как результат возвращает нам объект Сфинкс результат.
5. Данные из Сфинкс результата мы используем чтоб создать запросы к базе данных и получить искомые данные.

Преимущеста, которые мы получем от работы с такой библотекой – это простота. Разработчик используя объект Сфинкс запрос может выполнять любые запросы.
Сфинкс результат предоставляет удобную обертку над массивом результата.
Нет необходимости помнить множество констант SphinxClient и парсить массив результата. В общем это выглдит так, как будто вы работаете с обычной таблицой, но не до конца. :)

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

Решение я вижу, в привязке каждого запроса к определенной таблице или группе таблиц.

По описнной выше логике я разрабатываю модуль Sphinx Search для Zend Framework, который я планирую выложить в откртый доступ очень скоро, возможно к новому году.

Поэтому хотелось бы узнать как вы используете Sphinx Search и какие преимущества и недостатки вывидите у вашего подхода.

Буду рад любым советам и рекомендациям.

TechDev stages объясняет основные шаги в разработке продукта решая бизнес задачи. Обязательно к прочтению новичкам и начинающим архитекторам.

Интересная статья описывающая важность умения читать код и документации.

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

Это был действительно серьезный и успешный программный комплекс, разрабатывавшийся десятками людей на тот момент на протяжении десяти лет, целиком написанный на С++, со своим собственным специализированным сервером БД, собственным встроенным языком программирования, собственным толстым клиентом, умеющим все, что может и не может пожелать трейдер, отказоустойчивый, работающий в реальном времени, сервера которого развернуты на ферме из сотен компьютеров и обслуживали порядка десятка тысяч пользователей одновременно.

Задание, которое мне было выдано, предполагало модификацию движка обработки данных и сервера, подкупало своей простотой, и практически свело меня с ума – завершить его я смог только через 7 месяцев после начала работ, после того, как прослушал лекции по архитектуре данного комплекса. Что характерно, после лекций пришлось выкинуть все, что я написал до них, и за два месяца сделать правильно.

В этот раз, перед тем, как что-либо писать, я предусмотрительно показал свой предварительный дизайн (подход к решению проблемы) Толу Корину (Tal Korin), автору и главному архитектору данной системы, и он направил меня в правильном направлении. У Тола ушло на это 5 минут. Это был первый случай, когда я сам инициировал дизайн-ревью (не зная, как оно называется), и был рад найденным у меня проблемам. После успешного выполнения данного задания я поступил в распоряжение Тола Корина, поскольку, с его слов и к моему безмерному удивлению, я оказался одним из немногих, кому пошли впрок лекции по архитектуре.

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности – я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

С этого момента я начал внимательно наблюдать за Толом, изучать его решения и подход, и твердо решил разобраться, что же это такое за неуловимая штука, которой я не понимаю. То есть, я «записался в ученики», и Тол с удовольствием взял роль наставника. И за несколько лет Тол сделал меня инженером, показав мне на практике, что это такое, и за что я ему буду всегда благодарен.

По большей части это напоминало дзен, когда вам дают задание, разрывающее мозг, вроде хлопка одной ладонью, и через некоторое время вы неожиданно ловите просветление. Удивительный опыт. Вот один небольшой пример, на что это было похоже.
- Тол, скажи, а как работает вот эта штука.
- Влад, вот этого я на самом деле не знаю. А ты почитай код, и разберись!
- Тол, ты издеваешься надо мной?! Здесь пятьдесят мегабайт этого гребанного недокументированного кода! Ты знаешь все Тол, и это ни для кого не секрет.
- Хорошо, смотри, – не стал спорить Тол, – Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
- Так. Ты сказал, вот эта фигня? Вот, открыл. Так… Тебе нужен вот этот метод. Читаем. Вот, смотри, он вызывает вот этого парня (так Тол называл классы и объекты – look – now this guy tell that guy to do this thing). Видишь? Вот, происходит тут то-то и то-то. Все просто.
- Спасибо, Тол! Теперь все ясно. А говорил – не знаешь!
- Я тебе говорю – код читай, блин! Все то же самое ты можешь сделать сам!
- Тол, ну в нем же нихрена не понятно без документации, – сказал я, будучи совершенно уверен, что я не смогу сделать того же сам. Происходящее напоминало ловкий фокус.
- Тебе, чтобы читать код, нужна документация? Прости – какая?
- Ну, там, диаграммы классов, например.
- У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. Сам понимаешь, у нас 50 инженеров, и разработка идет очень активная. Но если ты уверен, что она тебе поможет, я могу поискать, – участливо смотрит на меня Тол, – ну так что, искать?
- Не, устаревшая, мне, пожалуй, не поможет, – подумав, ответил я, – это ж я все равно должен весь код изучить, чтобы понять, где ей можно доверять, а где нет.
- На самом деле, я не уверен, что тебе сильно поможет даже новая, и поэтому я тебе и говорю: код – лучшая документация! – терпеливо разъясняет Тол, – Она _всегда_ актуальна, и _никогда_ не устаревает, помимо того, что более информативна чем диаграмма классов, конечно.
- Хорошо, я понял, а может, ты мне еще объяснишь, вот в этом месте как работает…
- Нет. Это ты мне объяснишь, после того, как прочтешь. Мне как раз надо скоро будет туда правки вносить. Давай, парень, я не тебя рассчитываю. Иди – читай код.
- Хорошо, Тол, – обреченно сказал я, и пошел читать код.

Да, надо сказать, я тогда немного обиделся на Тола, я думал, что он нифига не понимает. И долгое время считал, что он был не прав. Как-то года через три ко мне подошел коллега, с вопросом. Я был утомлен от работы, голова соображала вяло. К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

- Слушай, Влад, не поможешь, объясни, как работает вот эта подсистема?
Я вяло поднимаю глаза на коллегу, вижу безнадежность в его взгляде, тяжело вздыхаю, и решаю ему помочь. Хоть я ничего и не понимаю в этой подсистеме – так, рядом проходил.
- Хорошо, смотри, – тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод, – видишь, вот здесь что происходит?

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

- Вот, видишь, как все просто, – заканчиваю я. И к своему чудовищному удивлению добавляю, то, что надо сказать, потому что это правда:
- А вообще – читай код. Код – лучшая документация. Ты вот думаешь, я разбираюсь в этой подсистеме? Нет, я этот код вижу в первый раз, так же как и ты.
- Но этот код совершенно не документирован! Диаграммы хоть какие-нибудь бы!
- Смотри, – говорю я улыбаясь, окончательно осознавая, что Тол в очередной раз, как и всегда, оказался прав, – вот я запускаю Rational Rose, где у меня всосана вся наша система в режиме reverse engineering, и бросаю на чистый лист эти пять классов. Видишь? Вот тебе свежая, актуальная диаграмма. Какой смысл тратить усилия на документирование того, что устаревает за год, и может быть в любой момент восстановлено за пару минут? Если она тебе сильно поможет, я сейчас ее тебе распечатаю. Распечатать?
- Да нет, пожалуй, – задумчиво отвечает коллега, рассматривая диаграмму. Ясности она не добавляла.
- Вот. Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления. Поэтому я и говорю: код – лучшая документация. Читай код.

Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия “код – лучшая документация” дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате – рассчитывая только на свои силы, понимая – что код – основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, – можно достичь мастерства в reverse engineering и вообще понять, что это такое.

Создать свою структуру и пришлепать ее сбоку может любой дурак. Квалифицированный инженер-программист (с упором на первом слове, не путать с “программером”) умеет проводить анализ “чужой” подсистемы, восстановит мысль и идею автора, сможет мысль автора развить, продолжить ее, и эффективно решить свою задачу в рамках чужого подхода к проблеме. Все это – работая с кодом. Это отличительная компетенция архитектора, высший уровень инженерного мастерства. И это имеет весьма отдаленное отношение к “рефакторингу”.

Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая “плохие”. В его понимании, архитектор, не умеющий читать чужой код с “листа”, и не пишущий своего – подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором – вопрос нескольких лет.

Второй важный аспект этой философии – понимание того, что код пишется в первую очередь для человека, и только во вторую – для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования? Но это уже другая история.

Оригинал статьи здесь: http://gaperton.livejournal.com/32772.html

Автор: padraic
Оригинал: An Introduction to the Art of Unit Testing in PHP
Перевод: Ярослав Ворожко

Введение

В каждом языке программирования, тестирование является важным аспектом разработки. Если вы не тестируете свой код, то как вы будете знать, что получите то, что ожидаете?

Ручное тестирование может выполняется не регулярно и обычно в сокращенных рамках. Для тестирования исходного кода регулярно и глубоко применяют автоматические тесты, которые могут исполняються периодически. В PHP такие тесты обычно пишутся используя Unit Test framework – это фреймоврк, который позволяет тестировать исходный код приложения или библиотеки изолированными блоками функциональности, такими как классы или методы.

Как только блочное тестирование стало популярным, то это стало стандартом для таких приложений как Swiftmailer, Zend Framework и Symfony – все они используют блочное тестирование для проверки исходного кода.

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

От себя добавлю:

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