Уже неоднократно на хабре (вот в этой публикации и в этой) ставился вопрос о том, что было бы хорошо кнопкам формы, отправляемой на сервер, ставить свойство disabled = "disabled".

Однако, до сих пор так и не разобрались, зачем это нужно и как все-таки это делать. Казалось бы, что может быть проще и о чем здесь вообще можно разговаривать, ан нет — на поверку все оказалось не так тривиально. Сразу замечу, что нижеследующие рассуждения применимы к обеим типам форм: как отправляемым через обычный SUBMIT, так и с помощью AJAX.

В одном из текущих проектов возникла задача поиска по данным разного типа, которая была успешно решена с помощью зарекомендовавшей себя поисковой машины Sphinx, но обо всем по порядку. 

Постановка задачи

В проекте есть на данный момент 2 зоны:

1. географическая зона, реализованная на базе Google Maps, которая отображает нанесенные пользователями на карту географические объекты (маркеры, маршруты и области);
2. информационная зона, которая представляет собой большой иерархически организованный каталог, содержащий информационные материалы.

Необходимо было решить задачу одновременного текстового поиска по 3-м типам объектов: географическим объектам, категориям информационной зоны и материалам информационной зоны — c возможностью фильтрации по дате публикации объектов и категориям, к которым они относятся.

Введение

В своей предыдущей статье я дал краткий обзор основных моделей хранения иерархических структур в реляционных БД. Как и положено тому быть, у многих читателей стал вопрос ребром о производительности представленных алгоритмов.

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

Идея такая: Нас трое и мы в течении целой недели, 24 часа в сутки 7 дней в неделю, т.е. ровно 168 часов, закрывшись в комнате и «выкинув» ключ будем делать стартап.

Краткая предыстория: Сегодня (17.12.08) мы (mimic, m2k и strel) собрались на организационную встречу СтартапПоинт. Рассуждая о том как нужно делать успешные стартапы, в шутку произнесли подобную идею (целую неделю безвылазно делать стартап, можно это даже через вебку в интернет транслировать). После 2х с половиной часов самомотивации приняли решение. Еще через час этот топик уже был написан на 15%.
Кстати, какой именно стартап мы будем реализовывать еще не известно. Но мы же стартаперы, гениальных идей революционных проектов у нас у каждого по несколько, не было только времени на их реализацию. Да-да, все стандартно, жалко было оставить нелюбимую работу, не хотелось ограничивать себя во сне и еде, хотелось хорошо отдохнуть с друзьями и т.д., ну вы меня понимаете?!

Цель: Создание успешного стартапа в лучших традициях начинающих бизнесов в гараже.
Задача: максимально ограничить себя, выйти из «зоны комфорта», чтобы c наибольшей вероятностью достичь поставленной цели.

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

На хабре часто обсуждаются принципы работы MySQL. Данный хабратопик посвящен механизмам блокировок, используемым в MySQL. Топик поможет начинающим изучать MySQL и, в некоторой степени, опытным хабралюдям.

Механизм блокирования в MySQL

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

Прочитал статью Оживление легенды: ставим ОС на Libretto 50 CT
в которой описывается способ №3 установки ОС Linux на HDD из виртуальной машины. И решил предложить другой вариант, как мне кажется более правильный, чем тот, который изложен в статье. Во всяком случае автору статьи, smashrod, советую попробовать. Может быть этот вариант окажется рабочим.

Бытует мнение, что связка LAMP (Linux+Apache+Mysql+PHP) не требует особой настройки и работает «из коробки». Это далеко не так. После того, как я долго убеждал товарища установить кеширующий акселератор PHP xcache, я решил провести небольшой эксперимент и попробовать выключить xcache на своём виртуальном сервере, находящемся под небольшой нагрузкой (около хита в секунду). В реальной жизни нагрузка на процессор мала, а вот память загружена сильно, т.к. её немного (256МБайт).

Результаты эксперимента превзошли все ожидания.

Как то гуляя в интернете наткнулся на интересную ссылку — Коды мобильных операторов. И очень мне захотелось иметь такую базу локально.
Под катом дамп mysql базы, php код для её использования и скрипт парсер для обновления.

Раз уж сегодня на хабре день РНР шаблонизаторов, то не могу не рассказать о MACRO — наиболее гибком шаблонизаторе с читаемыми шаблонами, среди известных мне.

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3, 4 и 5.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей и тэгировании кэшей.

Сегодняшний пост завершает эту серию, в нём обзорно мы поговорим о технических “мелочах”:

• анализ статистики memcached;
• отладка memcached;
• “RPC” с помощью memcached.

Полный текст всех разделов в виде одной большой PDF-ки можно скачать и посмотреть здесь (в разделе “Материалы”).

По долгу службы мне приходится работать с Cake и Sphinx. Однажды мне надоело делать поиск к сфинксу ручками, и я решил написать небольшой behavior.

Модуль для nginx, с помощью которого достаточно просто мониторить прогресс загрузки файлов на сервер. Ранее были подобные решения, через модули к php, ruby, через стороние скрипты, flash объекты итп. Автор предлагает универсальное решение на уровне web сервера. Подробную информацию и инструкции вы можете найти на wiki.codemongers.com (кстати, один из лучших проектов, посвященных nginx`у). Тут я хотел обратить внимание на другое.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т.к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т.к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.

update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.

В MySQL есть очень полезная функциональность — кеш запросов. Кеш запросов доступен в MySQL начиная с версии 4.0.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.

В этой статье я открою секреты того, как работает adme.ru, а именно я расскажу о том как устроено хранение статей и тэгов, как работает полнотекстовый поиск, поиск по тэгам и всё такое…

В статье приведён пример структуры таблиц, рабочий конфиг Sphinx и немного php кода с примерами выборок.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).

По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

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

Данная статья рассматривает одну из проблем хранения PHP-сессий в memcached: отсутствие их блокировки.

Введение

Ни для кого не секрет, что одним из самых популярных способов повышения производительности сайта является использование memcached. Об этом неоднократно говорили и приводили многочисленные примеры. Самый простой способ сделать это — использовать memcached для хранения сессий PHP. Для этого нет необходимости переписывать весь код, достаточно нескольких простых действий. Я не буду рассказывать, почему надо хранить сессии в memcached. Я расскажу о том, почему хранение сессий в memcached опасно.

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…