Рассказ о популярной универсальной архитектуре стека, в котором работает веб-приложение. Само приложение может быть написано на любом интерпретируемом языке с использованием любого фреймворка фреймворков. В данном случае это не важно, так как архитектура программной инфраструктуры — технологического стека, в котором оно работает, отличается мало.
Читать далее Архитектура веб приложений: экстерьер (видео-лекция)
Стала задача установить хорошую современную систему управления задачами и багтрекинга. Выбор пал на Redmine. Фактически, Remine — это улучшенный Trac. Написан Redmine на Ruby. Основное отличие от Trac по функционалу — работа с несколькими разными проектами в связке. Кроме того, у Redmine намного шире функционал, и сделан он добротней.
Как обычно, для установки некоего нового программного обеспечения в Линуксе сразу идем в Гугл и ищем подходящие HOWTO. По Редмайну я нашел несколько разных HOWTO, из которых каждый понемногу мне помог (см. ссылки внизу).
Читать далее Установка Redmine на Debian с СУБД Postgres. Работа по HTTPS.
На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. Сходу готового решения найти не удалось. На форумах постоянно констатировали, что SQL_CALC_FOUND_ROWS в постгри нет. Некоторые писали, что надо юзать count(*). Но еще из MySQL мне известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости. Читать далее Замена SQL_CALC_FOUND_ROWS или подсчет количества записей в PostgreSQL
На днях на работе решали вопрос о том, какой инструмент использовать для полнотекстового поиска информации. Рассматривалось много вариантов, среди которых был встроенный с версии 8.3 поиск в PostrgeSQL. К сожалению, одной маленькой мелочи не хватило в нем, чтобы мы могли его использовать. Очень горькая ложка дегтя в большой бочке меда.
Читать далее Камень в огород полнотекстового поиска в PostgreSQL
Поиск в MySQL. Часть 3 «FULLTEXT IN BOOLEAN MODE»
В первой части рассказа о поиске в MySQL рассказывается про использование полнотекстного индекса FULLTEXT. При поиске неких ключевых слов в большом массиве текста, хранящегося в БД, без использования индекса не обойтись. Однако родные возможности полнотекстового поиска в СУБД MySQL не обеспечиват функционал для поиска с учетом русской морфологии. Решение этой проблемы описывалось во второй части «Поиск с учетом русской морфологии». И вот недавно в описанном алгоритме обнаружился большой недостаток. Что это за недостаток и как с ним бороться и описано в этой статье.
Читать далее Поиск в MySQL. Часть 3 «FULLTEXT IN BOOLEAN MODE»
Эта запись будет не посвящена ничему конкретному. Просто набор интересностей, которые я повстречал за последние дни.
Неделю назад я инициировал обсуждение на одном сайтике на тему миграции с MySQL на PostgreSQL. В процессе обсуждения плавно сменили тему на сравнение этих двух популярных СУБД. В результате мне показалось, что почитать это обсуждение будет интересно и полезно многим программистам. В обсуждении участвовал известный программист PHP, автор двух книг по PHP, разработчик сервиса moikrug.ru Дмитрий Котеров.