Уже давно я слышал об инструменте для автоматизации сборки проекта — Ant, но как-то не мог найти ему реального применения в проектах на PHP. Компилить вроде ничего не надо, внешние библиотеки вполне можно подключить через svn:externals, оставались только тесты, которые свободно выполнялись через $ phpunit AllTests.php, да перенос изменений на рабочий сервер (svn export + небольшой самописный скрипт). Даже достаточно хорошая статья об использовании ant в eclipse не подвигла меня на использование сего инструмента, да еще и build файлы писать не хотелось…

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

Уже более семи лет занимаюсь разработкой на PHP, но некоторое время назад решил попробовать что такое Java и как с ней работать в web.

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

Интересует ли читателей Хабра (а особенно РНР разработчиков) материалы на эту тему? С чего стоит начинать. Какие аналоги существуют. Сравнения подходов и производительности. Об этом я планирую писать по мере собственного совершенствования у себя в блоге — нужно ли дублировать подобную информацию сюда?

 

Чего-то сегодня не спится совершенно… Возможно это тот самый знак, которого я так долго ждал? А знак мне нужен был, что бы решиться начать серию статей на основе реальной разработки проекта средних масштабов. Но не просто разработке в общем смысле этого слова, и даже не о разработке на основе Zend Framework, Doctrine ORM и пр. и пр., а о разработке начиная с постановки задачи, анализа и проектирования (с необходимой степенью глубины), поиска решений и реализации.
И раз уж первый абзац уже набран, то смысла останавливаться не вижу :) Приглашаю всех поучаствовать в процессе, который будет проходить на основе UP.

Данный пост посвящается любителям typehint'ов и строгой типизации, которой у PHP нет по определению.

копаясь недавно в мануалах по PHP, набрел на раздел о typehint'инге, и совершенно случайно полез в комментарии, где и нашел великолепное (хотя и тяжелое) решение для PHP5, как сделать язык строго типизированным. Под катом решение.

Часто ли вам приходилось сожалеть о том, что в PHP нет перечислений как таковых?

Да, кто-то обходился конвенцией именования и получалось нечто вроде:

define( 'COLOR_RED', 'F00' );
define( 'COLOR_GREEN', '0F0' );
define( 'COLOR_BLUE', '00F' );

Или нечто вроде:

// данную переменную ЗАПРЕЩЕНО модифицировать
$colors = array(
    'red' => 'F00',
    'green' => '0F0',
    'blue' => '00F',
);

Но оба подхода имеют существенные недостатки:

• В первом случае члены перечисления не образуют явной группировки
• Во втором случае есть риск что переменная будет изменена
• И в обоих этих случаях мы не можем делать проверку на тип переменной (type hinting)

Под катом предлагаю решение без вышеописанных недостатков…

GRASP — General Responsibility Assignment Software Patterns (основные шаблоны распределения обязанностей в программном обеспечении)

Когда речь заходит о термине «ООП», все непременно подразумевают Объектно-Ориентированное Программирование, но сегодня речь пойдет не о нем. Почти. Сегодня я бы хотел рассказать о принципах Объектно-Ориентированного Проектирования, а в частности о шаблонах GRAPS и области их применения.

НУ что — вот мы и дождались первый альфа релиз PHP5.3!

Из нововведений:

• Namespaces ( пока правда без документации )
  Late static binding и __callStatic
  лямбда-функции и замыкания
  добавлены некоторые экстеншны ( intl, phar, fileinfo и sqlite3 )
  Опциональная поддержка MySQLnd вместо libmysql
  отказ от поддержки Windows старше чем Windows 2000 (Windows 98, NT4 и т.д.)
  добавление нового синтаксиса: NOWDOC, ограниченный GOTO, сокращенный тернарный оператор (?:)
  
  
  P.S. обращаю внимание на авторское замечание: THIS IS A DEVELEOPMENT PREVIEW — DO NOT USE IT IN PRODUCTION!

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





P.S. Что бы использовать плагин в FF, необходимо установить расширение greasemonkey.


UPD: Повторное нажатие на кнопку, возвращает комментарии на место


UPD: Теперь форма добавления каментов не скрывается :)

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

И вот пришло время и я уделил некоторое время на создание более “правильного” интерфейса добавления тегов. Заранее прошу прощение у тех пользователей, у кого пример не откроется — тестировал только под Ubuntu/Firefox3…

Базовый функционал очень прост:
— возможность добавить новый тег AJAX запросом (только риквестер надо описать — заглушка уже имеется)
— возможность выставить вес каждого тега скролом (а если JS отсутствует — в соответствующей ячейке)

тут можно поглядеть рабочий пример.

P.S. А еще для полного счастья там добавлено автодополнение по некоторым тегам (PHP, MySQL ...) :)

P.P.S. Основной целью было не показать решение, а подтолкнуть к идее интерфейса меток.

UPD: Несколько упрощен GUI. Теперь достаточно скролить мышь непосредственно над нужным тегом. Также теги автоматически выбираются при наведении

Данная статья расчитана для двух типов разработчиков:
— кто еще не знаком с исключениями
— кто пытается найти более разумное использование исключениям

В статье я расскажу о самых основах исключений, о том как можно обходиться без них, а так же о том, как я вижу правильным использование некоторых возможностей языка…

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

Те, кто начинал знакомиться с PHP (тут и далее я буду подразумевать пятую версию), после другого процедурного языка программирования, так и не поняли что же такого в переходе от 4ки к 5ке и продолжают оформлять код привычными функциями, которые находятся на одном уровне по отношению друг к другу, а так же каждое действие проверяют на удачный код возврата. Но те кто знали об исключениях и классах…

Статья в первую очередь расчитана на начинающих разработчиков, либо для тех, кто только начинает переходить от процедурного стиля программирования к ООП, посему матерых гуру просьба не вгонять в минуса :)

Права доступа к свойствам и методам — это на первый взгляд всего лишь три слова: private, protected и public. Но что скрывается за ними? Какие преимущества это дает в разработке? И как их правильно использовать? Здесь, как и во всех других аспектах программирования, без практики не разобраться…

Одна из трех основных концепций ООП — наследование (другие две: инкапсуляция и полиморфизм). Вобщем-то именно для нее и были реализованы права доступов. Основанная идея наследования: Дочерний объект, при наследовании (extend) родителя перенимает себе все родительские методы и свойства, а так же может обзавестись своими собственными. Понимая эту базу, можно перейти в всему что находится ниже…

Объектно-ориентированное программирование — как стиль жизни. Это не просто применение конструкций типа class или interface — это способ мышления, когда любая сущность программы является не просто набором инструкций, а представляет из себя \«живое\» существо…

Думаю напоминать что такое ООП, в рамках данной статьи, будет лишним, посему перейду сразу к проблематике вопроса.

Разработчики, пришедшие в PHP из других языков программирования, и столкнувшиеся в нем (в РНР. тут и далее буду подразумевать РНР5 — прим.) с классами, недоумевают как их вообще возможно использовать. А все из-за того, что время жизни скрипта на РНР гораздо меньше, чем у прикладного ПО и составляет всего один цикл работы, в то время как прикладное ПО может жить и взаимодействовать со своими компонентами много дольше. В итоге миру является код, в котором классы реализуют всего-навсего отсутствующие в РНР namespaces.