Архив рубрики: Программирование

Плагины для GlotPress

И очень даже просто. Создаете файл в plugins, а дальше — все как в WordPress. Активируется всегда, служебные заголовки не нужны. Потому что админки, где они будут читаться для включения и отключения, просто нет.

[sourcecode language=»php»]
<?php
function sayHello() {
echo "<p>Hello dolly,… well, hello, dolly.</p>;";
}
add_action(‘after_hello’, ‘sayHello’);
?>
[/sourcecode]

Метки: , ,

GIT

Системы управления версиями (Version Controll Systems) нужны для того, чтобы хранить все промежуточные изменения вносимые в файл. Это не обязательно инструмент программиста, но программистам возможность вернуться к моменту «когда все работало» наиболее нужно. А еще это инструмент совместной работы — когда каждое изменение фиксируется в репозитории, а потом оттуда синхронизируется у всех остальных участников команды. Однако, VCS это прежде всего система управления версиями, а потом уже — инструмент для совместной работы. Программисту-одиночке она так же полезна, как и разбросанной по всему миру большой команде разработчиков. Ну, так вот…

Их много, всех эти CSV, Subversion, Bazaar, Mercurial и так далее. У каждой своя концепция, свой подход. Но и общее есть — хранить все изменения («revision» — в глупом буквальном переводе «ревизия», более логичное и правильное слово «версия» было занято термином «version»), фиксировать ключевые моменты версиями и по необходимости разделять разработку на ветви («branch»), которые используются для параллельной разработке нескольких вариантов продукта, существенно отличающихся друг от друга функционалом. Ветки, впрочем можно снова сливать между собой и снова разделять, условно разделяя их на «стабильные» (то есть проверенные и идущие в работу), «текущие» (то есть те, в которых идет дальнейшая разработка и исправление ошибок), «устаревшие» (не развивающиеся, но в которых продолжается исправление ошибок) и любых других по желанию (вплоть до отдельной ветки для каждого клиента системы с их индивидуальными настройками). А различие в основном — использовать ли централизованное хранилище («репозиторий» от английского «repository») или каждую рабочую копию использовать как автономный репозиторий; как нумеровать изменения и версии — в CVS принята система 1.0.1, 1.1, 2.0 и так далее, а в Subversion все изменения нумеруются последовательно, а версии оформляются отдельными ветками с произвольным именованием (tag/1.0, tag/2-pre-alpha или, к примеру, tag/final). Заканчиваем с общими словами и переходим к GIT… Читать далее

Метки: ,

Perl

perl -wle ‘(1 x $_) !~ /^(11+)\1+$/ && print while ++ $_’

Программа для вывода простых чисел. Вот это я понимаю, «магия слова».

XP

Extreme Programming

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

Не в этой ли моде причина всеобщей болезни срывов заявленных сроков — Doom3, Half-Life2, NeedForSpeed Carbon? Не говоря уже об отечественной Lada Racing Club — у этих вообще продукт доводился уже после поступления в продажу.

Не могло это быть простым совпадением, что-то одновременно повлияло на монстров игрового рынка. Теперь понятно — «модная болезнь» XP ударила по связке «цена-время-качество», закона сохранения энергии ведь никто не отменял. Причем на Западе, где дорожат репутацией, пострадал критерий «время», а у нас — «качество». «Дорога в будущее» по Гейтсу — идеалисты верят в «новый подход», а реалисты за красивыми сентенциями прячут банальное «клиент потерпит». Между тем «наше все» — это все-таки Юникс и тот свободный софт, который пишут энтузиасты под лозунгом «Code is poetry». Наверное, во мне говорит дух индивидуализма. А еще — любовь к своему делу. И такой «экстрим» мне не по душе…

phpTAL

PHP Template Attribute Language

Одно из решений извечного вопроса web-разработки — «как разделять функциональный код, дизайн и наполнение?». Что делать это надо, вроде бы уже решили, а вот выбор того как это делать…

Подобно тому, как FastTemplate, написанный изначально на языке PERL, а потом перенесенный на PHP (одна из этих реализаций, кстати сказать, принадлежит мне), phpTAL является частью проекта ZOPE (однако, каково название), изначально написаного на языке Pyton, а потом вошел в состав пакета Smarty. В общем-то это не удивительно — технологии быстро становятся кросс-платформенными, а новые «инструментальные» продукты предпочитают предлагать разработчику уже известные технологии, а не каждый раз предлагать изучить что-то новое.

Преимущество phpTAL над FastTemplate декларируется в расширенных возможностях настройки шаблонов. Эти возможности предлагаются в виде специализированного языка программирования, на котором можно определять условия вывода того или иного блока, значение переменных, даже получение доступа к внешним данным. Да, поведение шаблона теперь можно определять достаточно подробно. И вроде бы все хорошо, но не отпускает смутное ощущение идиотизма ситуации…

Если нашей первоначальной целью было разделение кода от дизайна, чтобы дизайнер и программист независимо друг от друга могли работать над одним проектом «не пересекаясь», зачем снова все смешивать в «коктейль Молотова» и в сверстанном коде шаблона запрятывать дополнительную логику исполнения на дополнительном языке программирования? Зачем на ровном месте создавать еще одну технологию и стандарт, которую надо изучать, еще уровень проектирования, который усложняет разработку, еще один компонент системы, который снижает производительность и уже не может работать без «протезов» вроде кеширующей генерации кода и предопределенной обработки исключений, которая накладывает дополнительные ограничения на свободу действий программиста? Как же в таком случае принцип необходимого и достаточного, который в шутливой форме формулируется как KISS-принцип («Keep It Simple, Stupid» — «Делай проще, дурачок»)?

Когда-то я написал собственную реализацию Fast Template для php, когда используемая внешняя библиотека дала необъяснимый сбой. Функциональность ее была, конечно, весьма аскетичной и развивалась в основном «вглубь»,а не вширь — то есть путем оптимизации кода, а не расширения его функциональности. И было время, когда мне казалось, что внутри шаблона необходимо сделать какой-либо механизм, позволяющий тут же, «не отходя от кассы», определять поведение этого шаблона. И тогда мне это казалось правильным и необходимым. И вот мне предоставился случай увидеть свет в конце пути, крайнюю степень развития этой идеи. Сейчас она уже не кажется мне такой правильной и необходимой. Однажды разделенные, код и дизайн не должны снова смешиваться. Эту стадию «гремучих смесей» мы уже проходили…