catap's blog ~ записки ёmacs'ера

В продолжение рассказа о списках стоит рассказать и о массивах в nginx.

«80% времени C++ программисты тратят на борьбу с C++»

Начиная цикл заметок о программировании для Nginx, хочется рассказать о списках.

Nginx — это web-сервер который используется многими для отдачи «статики» или как «прокся». Я не исключение. Но я не хочу его хвалить, и так все делают это. Я хочу вам рассказать о проблемах в нем,, которые есть, которые никто не исправляет и мимо которых вы все удачно проходите.

Подумалось сейчас. В IDE(Microsoft Visual Studio, например) человек обложен инструментами настолько, что ему чрезвычайно просто работать с плохим кодом. Вместо проработки интерфейса он будет пользоваться автодополнением, которое подскажет, например.

Общие идеи

Идея

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

Основа

В качестве предметной области берется разработка софта. В качестве базовой терминологии — git.

Пример работы

Делается репозиторий. Он может быть центральный, он может быть локальный. Предполагаем что репозиторий локальный. И его создал PM (менеджер проекта). Он создает событие «создал таск» с заданием для программиста, далее именуем его task1. Так же PM создает task2 и task3.

D (программист) клонирует (clone) к себе репозиторий PM. Он создает событие «начал делать» в task1 (если проводить аналогии с git то это запись в файл, а создание task’а это создание файла). После конца работы над task1 он создает событие «закончил работать» и событие «таск сделан».

И D и PM имеют доступ к репозиториям друг‑друга и иногда забирают новые события или таски друг от друга (pull’ят). Так же D может, если ему позволено, посылать события в репозиторий PM (push делать).

Еще немного мыслей

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

Паранойя

Естественно каждое событие можно подписывать pgp-ключом или pki-сертификатом. И как‑то учитывать их при постройке отчета.

Пример реализации

Для более понятного замысла был сделан пример реализации на bash вокруг git. Взять можно тут: http://catap.ru/repos/draft/tt.git.

Всплыла идея сделать «быстрый просмоторщик изображений». Причина появления задачи сообщение dottedmag.

Небольшое, не формальное, ТЗ

Задача:

Написать быстрый просмоторщик изображений.

Требования:

• возможность открытия любых изображений. Вплоть до 10 Гбайт (для простоты и что бы свести ее к алгоритмической предполагается простой формат)
• Возможность быстрого (в real time) масштабирования и скролирования изображения (задержка не больше 1 секунды)

Ограничения (для истиных мазохистов):

• Процессор, скажем Duron 750 mhz. Хотя каждый может выбрать его на свой вкус.
• Виртуальная память не более 128 мегабайт. Тут тоже можно выбрать на свой вкус. Сделаете потребление константным и независимым от картинки — мой респект.
• Всякие подкачки и временные файлы тоже можно свести к минимуму. Условия такие же как в ограничениях по памяти.
• Формат png или еще более веселый.

Отныне я член ALU за номером 196 ☺, принимаю поздвравления.

p.s. — да, у меня дошли руки заплатить челенский взнос

«Lisp есть могучий усилитель мыслей, и тем, у кого мысли, как правило, отсутствуют, он ничем не поможет»

Не могу не поделиться десятым правилом Гринспуна и следствием Морриса из него (только что для себя открыл):

„Любая большая система на C или Fortran содержит медленную, плохо продуманную, с кучей ошибок реализацию половины Common Lisp.“

Десятое правило Гринспуна

„…включая сам Common Lisp.“

Следствие Морриса