«Индиана» — самописанный движок на питоне, на котором работает «Тёплый край» и ещё парочка интранет-сайтов. Не более чем велосипед, но велосипед удобный лично мне. Умеет при должном запинывании изображать блог, ленту ссылок, библиотеку, мини-форум и мини-вики.
Я несколько лет выпиливал лобзиком, мучился, и хоть бы одна собака сказала мне про величественность jQuery! Ну то есть я, конечно, слышал это название, но насколько кардинально jQuery меняет клиентский скриптинг — честно говоря, не представлял.
Всё дело, собственно, в том, что меня заело сделать нормальную галерею для фоточек вместо той галереи в стиле конца девяностых, что у меня была. Как оказалось, ничего сложного нет.
Сам скрипт можно посмотреть здесь: gallery.js. Он очень простой и наверняка в некоторых местах неоптимальный, но меня на первый раз устраивает.
Первый кусок добавляет в DOM-дерево элементы для оверлея и всплывающего окна с картинкой. Функция set_position
позиционирует и показывает окно с картинкой, а заодно и окно с текстом «Loading». Следующие три функции срабатывают при завершении загрузки картинки, щелчку по миниатюре и щелчку по кнопке закрыть или большой картинке, соответственно.
Кроме написаная самого скрипта, потребовалось чуть-чуть изменить скрипт генерации галереи. Вот что он выдаёт (курсивом помечены новые фрагменты):
<div style="float: left; margin: 0.5em; text-align: center; width: 150px; height: 160px"><a class="gallery" href="/users/helgi/g/parade/images/dsc_5805.jpg"> <img src="/users/helgi/g/parade/thumbnails/dsc_5805.jpg" alt="dsc_5805.jpg" title="Голова первой колонны"></a><br>Голова первой колонны</div>
И, конечно, пришлось дописать несколько строчек в таблицу стилей:
#gallery_overlay { position: absolute; left: 0; top: 0; opacity: 0.8; z-index: 900; background: black; display: none } #gallery_image, #gallery_loading { position: absolute; display: none; z-index: 990; background: white; padding: 10px; border: 1px black solid; width: auto } #gallery_image a { float: right; padding: 2px 5px; cursor: default; border: 1px solid; font-size: larger }
На работающую галерею можно посмотреть, например, здесь.
P.S. Кстати, моё собственное правило о границах применимости клиентских скриптов соблюдено: очевидно, что без джаваскрипта всё будет работать как прежде.
Тэги: indiana, webdev
Комментарии (9)
Починил закоррапченный репозиторий «Индианы». Даркс, конечно, хорошая штука, но у формата репозитория darcs-1.0 есть досадная проблема: эталонное дерево (pristine tree) лежит просто в виде таких же файлов, как и рабочая копия. Итог:
desktop.ini
, и опять-таки даркс решил, что они там были всегда.Способ, которым я починил репозиторий, чудовищен: я открыл старые патчи и тупо отредактировал их. Слава доброму дарксу, в меркуриале, который считает идентификатором патча хэш от него, это бы не прошло. Так что теперь репозиторий снова консистентен, и его можно клонировать, ура.
Хорошо, что у меня репозитории приватные (правда, зараза, их немало) — я смогу спокойно заменить коррапченные репозитории чистыми.
Дальше надо переходить на даркс версии 2.3, а потом на формат darcs-2.0.
Тэги: darcs, indiana
Написать комментарий
На работе мы подняли сайт на моём движке, конечно, не такой, как «Непостижимые поля». Там всё чинно: полезные советы из жизни си#, объявления о новом инфраструктурном коде и прочая программистская рутина.
Интересно другое. Я вновь получил то, чего мне, оказывается, не хватало два последние года: мгновенную отдачу при разработке движка.
Оно понятно, что отдельно должна быть боевая установка с реальными данными, а отдельно — тестовая, где фичи отлаживаются, а баги устраняются. И что даже мелкие изменения, а уж тем более крупные переделки надо устраивать в тихом уголке, где ничего нельзя запортить.
Но где тогда брать те эмоции, которые сопровождают правку кода на горячую, прямо по живому, на боевом сайте? Страх ошибиться пополам с предвкушением: вот сейчас, ещё строчка — и фича заработает!
Нет, крупные изменения, конечно, нельзя вносить не запланировав, не продумав, не оттестировав. Но зато и мелочью, если понимаешь, что эффект от неё появится через месяц-другой, после регулярного обновления, заниматься не хочется совершенно. Зачем? Успеется.
Редакция от 8 октября 2009
Тэги: indiana, программирование, работа
Написать комментарий
Я таки сделал это уродское облако; более того, что-то очень похожее я показываю в списке авторов. Мне не нравится, но остальные варианты ещё хуже.
Вывод всех тэгов по алфавиту в столбик не подходит для задачи «посмотреть, про что много написано», а вывод всех тэгов так же, но по количеству записей не годится для поиска взглядом.
Да и вообще в столбик очень много тэгов получается.
Можно сделать два метода сортировки — но см. предыдущий абзац. Так что пусть будет облако, пока ничего лучше не придумалось.
Заодно я переделал вывод страницы архива ссылок. А комментарии от гостей теперь скрываются только те, где есть ссылки (сделал по примеру Каганова).
Тэги: indiana, webdev
Комментарии (6)
Прикрутил (на скорую руку) старую добрую капчу «вы робот или человек?». Пока все комментарии от гостей всё равно скрываются до одобрения.
Тэги: indiana, warmland
Комментарии (1)
Пять лет прошло, и, однако, ничего не изменилось.
Люди делятся на две категории: нормальные и Верующие в Чудесную Мощь Баз Данных. Первые используют базы данных, когда это удобно, вторые — всегда.
Для того, чтобы написать движок блога, можно воспользоваться БД, а можно обойтись без неё. Кто-то считает, что с базой удобнее работать, кому-то требование иметь БД для работы движка кажется завышенным. Это всё вопросы вкуса.
«Тёплый край» не использует баз данных в первую очередь потому, что когда я начинал его писать, он жил у меня на ноутбуке. Я рассудил, что поднимать тяжеловесные сервисы мне совершенно не надо, и поставил не «Денвер» и не IIS, а маленький лёгкий сервер под названием xitami. И отладочная версия «Индианы», между прочим, до сих пор у меня на ноутбуке именно под xitami и работает.
Между прочим, по этой же причине у меня в «Индиане» нет поддержки mod_rewrite. Зато и требований никаких нет: IIS, xitami, «Апач» — всё сгодится, была бы поддержка CGI.
Так вот, когда Рус говорит: «Когда я начинал писать этот движок, один хороший человек [то есть я — Х.] советовал мне вообще отказаться от MySQL в пользу самописного интерфейса к текстовым файлам», — он, конечно, лукавит. База так база, тем более что вопрос совместимости его мало когда волновал. Но хранить изображения в базе — это уже даже не благородное безумство, а некий способ-делать-всё-через-выхлопную-трубу.
…[Я] недолго заморачивался на способе хранения изображений на сервере, а просто сделал то, что хотел сделать давно: изображения хранятся в базе, а не на ФС.
Если вы поленились сходить по самой первой ссылке, прочитайте прямо так:
When using a normal web server setup, images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal web server is much better at caching files than database contents. So it it's much easier to get a fast system if you are using files.
Официальная документация MySQL, «5.2.12 Other Optimisation Tips»
Или, если угодно, из другого источника, по-русски:
Не старайтесь поместить в базы данных всю информацию, которая у вас есть. Например, не нужно хранить там картинки, хоть MySQL это и позволяет. Помещая в базу данных двоичные образы графических файлов, Вы только замедлите работу своего сервера. Прочитать файл с картинкой с диска гораздо проще и, с точки зрения потребляемых ресурсов, экономичнее, нежели соединиться из скрипта к SQL, сделать запрос, получить образ, обработать его и, выдав нужные http-заголовки, показать посетителю веб-сервера. Во втором случае операция выдачи картинки потребует в несколько раз больше ресурсов процессора, памяти и диска. Также стоит помнить о том, что существуют механизмы кэширования веб-документов, которые позволяют пользователю экономить на трафике, а при динамической генерации контента вы фактически лишаете своих посетителей этой удобной возможности.
Дело не в том, что хранить изображения в базе маменька не велит, нет — дело в том, что организовать хранение не перректально, а обычным способом проще.
И первые грабли, на которые наступил Рус, это подтверждают. Если хранить изображения на диске, last-modified сервер отдаст сам.
Кстати, в проекте, над которым я работаю, есть необходимость хранения больших объёмов двоичных данных. И они — невероятно! — хранятся не в базе, а на диске. В виде файлов.
Тэги: indiana, webdev, мета
Комментарии (2)
Всё, доигрался. Произвольные «перепрыгивания» в нумерации версий привели к тому, что я только что запланировал версию indiana-0.5.99.01. Потому что first-public очень хочется сделать 0.6, а всякие мелкие доделки к «шестёрке» никакого отношения иметь не могут.
(Хотя у меня с номерами версий вообще всегда туго. Address Book начинался с версии 4.х, «Индиана» — сразу с 0.4…)
Впрочем, 0.5 появилась, когда я вынес «ТК» в интернет. Так что уж пусть 0.6 будет первой версией, для которой я выложу исходники. Это официальный ответ на вопрос об их публикации.
Тэги: indiana
Написать комментарий
Поскольку я практически переписал модуль журнала, решил поставить на пробу свежую версию движка на боевой сервер. Проблемы с sys.path я, кажется, поборол. Но mod_python продолжает злиться на кодировку, да и firstinit не отрабатывает.
Забавно другое. Хорошо, что в сентябре прошлого года я решил начать вести журнал сразу же, а не подождать до завершения работ над новым модулем. Работы эти начались аж в январе, да и сейчас еще продолжаются.
Это я к тому, что пришлось в очередной раз убедиться в справедливости утверждения «лучше плохонько, но сейчас, чем идеально, но потом».
Тэги: indiana, reflection, warmland
Комментарии (5)
Слегка подновил стилевую таблицу. Мне кажется, что новый вариант лучше воспринимается и выглядит легче за счёт увеличения числа элементов, использующих тёплые цвета вместо серого. Также я воспользовался рецептом Максима Захарова для создания более приглядного подвала, который размещается внизу всегда, вне зависимости от количества текста на странице.
Тэги: design, indiana, warmland, webdev
Написать комментарий
Для портирования под Internet Information Services в движке пришлось поменять до смешного немного. Более того, самый главный баг вообще бы не вылез, если бы я адаптировал транк, а не ветку 0.5.10/onr. Баг был связан с тем, что IIS, в отличие от apache и xitami, вешается при попытке повторного вызова cgi.FieldStorage() при POST-запросах. На других двух серверах просто возвращается пустая форма. В транке этот баг не вылез бы потому, что там я уже переделал всё ядро, и двойной вызов там убран.
Второй баг связан с тем, как IIS трактует переменную окружения PATH_INFO. Рассмотрим три сервера по порядку.
Под xitami все URL’ы выглядят так:
http://example.com/cgi-bin/sitename/?v=abc (GET) http://example.com/cgi-bin/sitename/index.py (POST)
Соответственно, PATH_INFO == "" (вполне логично).
На warmland.ru я использую mod_rewrite, и адреса переписываются так:
http://example.com/?v=abc -> http://example.com/cgi-bin/sitename/?v=abc (GET) http://example.com/index.py -> http://example.com/cgi-bin/sitename/index.py (POST)
И тут PATH_INFO == "".
IIS же считает, что все пути, по которым лежат сценарии, виртуальны.
http://example.com/?v=abc (GET) http://example.com/index.py (POST) http://example.com/dir/?v=abc (GET) http://example.com/dir/index.py (POST)
В первых двух примерах PATH_INFO == "index.py". Во вторых двух PATH_INFO == "dir/index.py". То есть IIS не только рассматривает путь как PATH_INFO, но и раскрывает directory default. Почему — неясно. Ясно только, что мои идеи использовать PATH_INFO накрылись медным тазом. Если я хочу поддерживать все три сервера, то надо быть очень конвенциональным — никаких рерайтов, никаких PATH_INFO.
Тэги: indiana, webdev
Написать комментарий