девелопо

Пост добавлен: 27.03.2010 14:15:23
Теги: dev, стрём

Пятиминутка ненависти: php

Я начал изучение php шесть лет назад. И очень быстро вышел на, так сказать, конкурентоспособный уровень. Начиная с первых месяцев работы -- а работал я сразу над очень большим проектом, поддержка которого никогда не была простой задачей, -- я пытался устроить себе удовольствие от создания и изменения сайтов. Чем дальше, тем больше удовольствие заменялось на:

1) мучительную поддержку старого кода,

2) разработку методов создания нового кода, поддержка которого не превратится в пытку.

В итоге создание и изменение сайтов не происходит. Только борьба с кодом.

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

В чём-то я добился успеха. Считаю, что моя ORM по API и основным фишкам превосходит все аналоги. Однако ж при движении в некотором направлении другие направления всегда страдают. Читаемость против гибкости. Гибкость против производительности. Производительность против экономии трудочасов. Сумма положительных эффектов за вычетом сопряжённых отрицательных всегда остаётся на примерно одном уровне, как и удовольствие от работы. Не прибавляется.

Долгое время я надеялся, что причина моих неудач в несовершенных алгоритмах. Но есть стена, которая ограничивает красоту алгоритма возможностями языка. Появляется десять тысяч "нельзя". Результат каждой невозможности -- маленькое дополнение. Вместо 20 символов кода на строке пишешь 40. Используешь оболочки для вызовов, промежуточные слои классов для эмуляции виртуальных атрибутов. Каждая из проблем имеет решение в виде изящного костыля. В итоге приложение на php само становится огромным костылём, обречённым на убожество.

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

И придумал что-то, крайне похожее на Ruby.

 

Python, на мой взгляд, ему сильно проигрывает. Да, мотивации, которые привели к созданию Питона, тождественны. Да, технически это язык очень высокого уровня. Но эстетически код на Python вызывает у меня брезгливость, ничего не могу с собой поделать. Всевозможные кортежи, костыли, с ними связанные, зубодробительные итераторы, некрасивые классы и наследования. Мне противно даже стандартное расширение для питон-файлов: .py и .pyc. Пы и Пыц.

Ruby же просто совершенен. Его обвиняют в низкой производительности. Однако, особенно для малых проектов, второй сервер (и даже десятый) стоит существенно дешевле второго (третьего) программиста.

Единственное, что заставляет меня продолжать работать с php, это обилие кода, уже написанного мной на php. Колечко всё работает на php. И это очень грустно. Но я надеюсь, что со временем мне удастся работать с Ruby и вновь получать от этого процесса удовольствие.

Пост добавлен: 09.03.2010 13:35:22
Теги: dev

RFC #1

В процессе развития колечка появился концептуальный вопрос, в решении которого мне нужна помощь.

Вопрос: как сделать оформление сайтов в кольце. Требования:

- Должна быть возможность выразить себя через внешний вид сайта.

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

- Создание этой возможности должно быть мне по силам.

Вкратце рассмотрим существующие ныне варианты, их плюсы и минусы.

1) Что-то вроде ЖЖ: набор стилистических тем, которые можно редактировать после установки.

Каждая тема включает в себя море параметров: цвет заголовка, цвет подзаголовка, цвет ссылки если она заголовок, цвет ссылки если на неё навели мышку...

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

Под каждый параметр есть отдельное поле с названием и значением по умолчанию.

Плюсы: Кликнул -- получил другое оформление. После можешь редактировать это оформление.

Минусы: Если дизайнер не учёл какой-то возможности, ею сложно воспользоваться. Делать такие макеты очень дорого, у меня нет такой возможности. Макетов будет очень ограниченное количество, существенно меньшее, чем может быть народу в проекте.

2) Простое редактирование CSS-файла.

Это как сейчас. Плюсы: абсолютная гибкость оформления.

Минусы: смена вёрстки становится невозможной. Для оформления нужна дополнительная квалификация и крайнее задротство.

3) Как во ВКонтакте, с вариациями. Разрешить менять только картинку на главной страничке и пиктограммку в шапке. Всё остальное сделать настолько совершенным, чтобы всем хватало.

Плюсы: дешёвая программная часть реализации, предельно низкий порог вхождения.

Минусы: жёсткость, невозможность изменить общее ощущение от странички. Необходимость купить где-то этот идеальный макет.

4) Как в Твиттере. Вот посмотрите:

twitter.com/name_alari -- страничка в одном из стандартных оформлений.

twitter.com/AnnaBushueva -- сильно нестандартное оформление.

Что изменилось?

- фон правой колонки

- картинка фона

Всё. Несмотря на это, странички становятся индивидуальными. Вот ещё пример: twitter.com/dalailama.

Плюсы: очень низкий порог вхождения.

Минусы: всё же, колечко -- не твиттер и нуждается в бОльшем количестве средств выразительности.

5) Моя задумка.

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

В результате генерируются блоки CSS.

Плюсы:

- гибкость -- оформить визуально можно практически всё

- менять вёрстку всё ещё можно (хотя и дорого) -- нужно только иметь в голове связи

- не нужны проф. навыки для работы с дизайном

- благодаря контекстности не нужна тысяча вбитых типов полей (как в случае с жж)

Минусы:

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

- сравнительно высокая сложность реализации и поддержки

В конечном счёте, мне вроде как и нравится моя задумка, но смущает очень высокий порог вхождения в сравнении с тем же твиттером. Как упростить процесс оформления? Может, как-то связать несколько возможностей? Как при этом минимизировать затраты, коли я не двужильный и миллиона не имею?

Буду благодарен за любые комментарии.