Настройка своего сервера debian/ubuntu

Мини шпаргалка по настройки полноценного сервера на основе дистрибутивов Linux Debian/Ubuntu. В инете полно такого материала, но везде по чуть-чуть, приходится тратить время на поиск инфы, здесь постарался собрать все что потребуется для запуска своего сервера.
Предполагается что вы только что установили минимальный дистрибутив Дебиана и законнектились по ssh.

Организация Модели. Управление доступом

Введение

Продолжаем размышления на тему организации модели и сегодня поговорим об управлении доступом или другими словами - авторизации, т.е. процесса проверки (предоставления) определенному лицу прав на выполнение некоторых действий.

Эта тема особенно важна для интернет/интранет приложений, где число пользователей заранее неизвестно, а количество различных операций и ресурсов велико. Как и в прошлой заметке, несмотря на то, что речь идет о Zend Framework и компоненте Zend_Acl, все размышления могут быть применены к любому фреймворку и платформе.

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

Прежде чем перейти к прочтению статьи, рекомендую ознакомиться с официальной документацией по Zend_Acl.

Организация Модели: Валидация данных.

Введение

Эта статья является продолжением рассуждений на тему  организации модели и посвящена организации процесса валидации данных. И не смотря на то, что практическая часть выполнена на Zend Framework, приведенные рассуждения в равной степени могут быть применены к любому фреймворку и даже платформе.

Большинство данных поступает в модель из внешнего мира, через html-формы, различные сервисы, почту и т.д. При этом, всегда необходимо производить валидацию и фильтрацию этих данных, т.к. они не надежные.

Например, при поступлении данных из html-форм  в Zend Framework'е удобно использовать компонент Zend_Form. Это мощный компонент, позволяющий структурировать данные, производить гибкую фильтрацию и валидацию данных, а так же имеет механизмы вывода, включая вывод ошибок валидации.

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

Избежать дублирования можно, если перенести всю проверку данных в Модель. Таким образом, мы всегда сможем гарантировать, что Модель корректна, даже если данные поступают не из пользовательских форм.

Организация Модели в Zend Framework

Введение

Этой статьей я хочу начать небольшой цикл заметок и мыслей об организации модели  в Zend Framework. Тем более что сам фреймворк мало что предлагает в решении этого вопроса. Как говорят разработчики фреймворка: Модель - это то что вы должны реализовать сами, это ваша работа.

Возникают вопросы, а как реализовывать модель, как это сделать правильно? Единого ответа нет, т.к. Модель слишком специфична и реализовывать ее можно по разному, и зависит это от множества факторов.

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

Поддержка PHP 5.3 Namespaces для Zend Framework 1.10

Введение

Этот пост посвящен продолжению разработки CMF на базе Zend Framework 1.10.x. 

Так как проект совсем на начальной стадии, частенько приходится переносить файлы внутри проекта по разным каталогам, т.к. структура еще не устоявшаяся. И вот после очередного переноса, опять пришлось лазить по коду и переименовывать кучу классов, что бы они соответствовали своему новому расположению. После чего появилось сильное желание перевести свой код на нэймспейсы PHP 5.3. Во-первых, родные нэймспейсы позволяют избавиться от полукилометровых названий классов; во-вторых, при перемещении класса, достаточно исправить только заголовок объявления нэймспейса, ну и в третьих, проект изначально задумывается для PHP версии 5.3 и выше, так что заботиться о том что нэймспейсы не будут доступны  - глупо.

Перевод документации для Mockery

Mockery - это объектно-ориентированный PHP фреймворк для mock-объектов, написанный Pádraic Brady одним из участников Zend Framework Community Review Team (CR Team). 

 

Mockery сделан как независимый фреймворк и поэтому совместим с любым фреймворком для модульного тестирования (PHPUnit, SimpleTest...).

Вот небольшой список характеристик и возможностей Mockery:

• Полная поддержка Mock-объектов и Заглушек (Stub)
• Легкий, fluent API
• Гибкая настройка mock и stub
• Запись взаимодействия объектов
• Синтаксис приближенный к естественному языку
• Поддержка обобщений (untyped)
• Простые частичные mock-объекты на основе реальных объектов
• Поддержка порядка вызова подменяемых методов как в пределах локальных, так и в пределах глобальной области
• Встроенная очередь для возвращаемых значений, при повторных вызовах
• Поддержка ожиданий по умолчанию
• Поддержка замены ожиданий и их наложения
• и т.д.

Более подробно вы можите ознакомиться с фреймворком Mockery, а так же предпосылками к его появлению в блоге Pádraic Brady.

 

Оригинальная документация доступна здесь. Так же я с удовольствием перевел ее на русский, для популяризации как этого фреймворка (а он мне  действительно понравился), так и самой методологии Test Driven Development.

Памятка по исключениям php 5.3+

Начиная с PHP версии 5.3.0+ прикладному разработчику по умолчанию доступна библиотека SPL (Standart PHP Library), которую теперь даже нельзя отключить опциями компиляции. В связи с этим, можно безопасно пользоваться решениями предоставляемыми этим расширением. В этой заметке я хотел бы осветить набор стандартных исключений, предоставляемых SPL.

Кеш-драйвер для Doctrine на основе Zend_Cache

Продолжаем серию статей посвященную интеграции Doctrine 2.0 и Zend Framework 1.10. В этой статье мы добавим поддержку кеш-драйвера для Doctrine на основе Zend_Cache.

Введение

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

По умолчанию, в доктрине поддерживаются следующие драйверы:

• Doctrine\Common\Cache\ApcCache
• Doctrine\Common\Cache\MemcacheCache
• Doctrine\Common\Cache\XcacheCache
• Doctrine\Common\Cache\ArrayCache

Собственно для "продакшина" пригодны только первые три. Последний предназначен только для разработки и кеширует данные только в рамках одного запроса. Проблема заключается в том, что все эти три драйвера требуют дополнительного ПО, установленного на сервере.

В ZF есть отличный компонент для работы с кешем - Zend_Cache. Стоит отметить, что Zend_Cache кроме поддержки APC, XCache, Memcache умеет работать с простыми файлами, SQLite и другими бэкэндами. Напишем адаптер, позволяющий Doctrine работать c Zend_Cache.

Интеграция Zend Framework 1.10 и Doctrine 2.0

В этой статье я продолжу разработку некого каркаса приложения на Zend Framework'e, придерживаясь лучших практик из мира объектно-ориентированного проектирования. Мы шаг за шагом будем интегрировать Doctrine 2, а поможет нам Dependency Injection контейнер, который мы успешно интегрировали в предыдущей статье.

Интеграция Symfony DI-контейнера в Zend Framework 1.10.x

Возникло у меня желание, начать новый проект на Zend Framework'е с применением лучших практик из мира объектно-ориентированной разработки ПО и современных тенденций PHP-индустрии. Целью всего этого является конечно же обучение и закрепление изученного материала.

Первым делом, решил интегрировать Dependency Injection контейнер в Zend Framework.  Ибо без этого трудно добиться "хорошего" дизайна, кроме того я не смогу эффективно тестировать свои объекты и классы. Что бы лучше понять что из себя представляют DI-контейнеры, а так же паттерн Dependency Injection советую прочитать статью Мартина Фаулера, перевод которой доступен здесь.

В этой статье я шаг за шагом интегрирую Dependency Injection контейнер от Symfony в Zend Framework версии 1.10.x. При этом я постараюсь действовать согласно методологии TDD (Test Driven Development), а именно практики Test First - написание тестов, до реализации.

Установка Redmine - системы управления проектами

Мысль организовать свой процесс более упорядоченно и систематизировано витала давно. Долгое время пользовался бесплатными хостингами проектов, наподобие http://www.assembla.com/ и http://www.xp-dev.com/. В принципе для open-source проектов отличные решения. А вот для приватных проектов - на ассембле придется платить, а на xp-dev нельзя гибко настраивать доступ к проекту, либо полностью открытый проект, либо полностью закрытый от посторонних глаз. А хотелось бы совмещать: что-то открыть (например документацию, timeline), а что-то закрыть (код, внутреннею информацию и т.д). Да и эти хостинги довольно ограничены по возможностям. Платные же сервисы даже не искал, нет желания привязываться к ним.

Т.о. бесплатные хостинги отпали, платные тоже. Остается найти автономную систему, желательно полностью удовлетворяющую моим потребностям.

Продолжение перевода статьи М. Фаулера "Inversion of Control Containers and the Dependency Injection pattern"

Продолжение перевода статьи Мартина Фаулера "Inversion of Control Containers and the Dependency Injection pattern" оригинал которой доступен здесь. Первая часть доступна здесь.

Вольный перевод статьи Мартина Фаулера "Inversion of Control Containers and the Dependency Injection pattern"

Попытки разобраться с принципом ООП Инверсия зависимостей (Dependency Inversion Principle) привели к статье Мартина Фаулера "Inversion of Control Containers and the Dependency Injection pattern" оригинал которой доступен здесь. Поиски перевода на русский язык не увенчались успехом, поэтому решил сделать перевод, заодно и лучше понять эту статью и сам принцип.

ООП. Введение в хороший дизайн.

Решил разобраться с принципами объектно-ориентированного проектирования,  соблюдение которых приводит к "хорошему" дизайну. По-крайней мере, уж точно не приводит к "плохому" дизайну.