Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?

Мой перевод статьи Гвидо ван Россума:

Меня тут в шутку спросили: смогу ли я отсортировать миллион 32-битных int'ов в 2 мегабайтах памяти на Питоне. Во время размышления, мне пришло в голову задействовать механизм ввода-вывода с использованием буферной памяти.

Вообще, это именно шуточный вопрос — одни только данные займут 4 мегабайта, при условии бинарного представления! Правда, можно пойти на хитрость — взять файл, содержащий миллион 32-битных int'ов. Как же отсортировать их, используя минимальное количество памяти? Это должна быть какая-то разновидность сортировки слиянием, в которой небольшие куски данных сортируются и записываются во временный файл, после чего происходит слияние временных файлов для получения окончательного результата.

Вот мое решение:

Думаю, большинство из пользователей Ruby работали с Rails, и использовали их обработчики событий.

validate :validate_humanity_conflicts

validates_presence_of :radius # это не обработчик события, но декларация

Польза от них очевидна:

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

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

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

В данной статье представлена пошаговая инструкция по разработке простейшего расширения для FireFox.
Это частичный перевод оригинальной статьи.

Это не моя статья, а моего друга (его мыльце: templar8@gmail.com). Он очень хочет попасть на Хабр. У меня самого не хватает кармы для инвайта.

Меня всегда раздражали формы регистрации. Особенно, когда тебе до зарезу нужно получить какие-то возможности зарегистрированного пользователя, но только на один раз, к примеру, скачать какую-нибудь софтину или задать вопрос на узкоспециализированном форуме. В большинстве случаев формы регистрации там просто ужасны, хоть и не отличаются сильным разнообразием. Не имея ни малейшего желания заполнять пять-шесть помеченных звездочкой полей, я принужден скрипя зубами два(!) раза вписывать адрес электронной почты, разгадывать капчу и придумывать секретный вопрос. И после всех этих мучений, после того нажатия на заветную кнопку «сабмит», страница полностью перезагружается и радостно сообщает, что капча введена неверно, да и имя пользователя давно занято. И в довершение мучений от меня требуют перейти по ссылке, отправленной на мою почту, для активации аккаунта.

Решил проводить регулярные лекции и практические занятия со своими сотрудниками по программированию на PHP, MySQL, Javascript. А также другим технологиям необходимым для выпуска качественных сайтов. Начать решил с самого «верха», с HTML тэгов. Буду рад, любым комментариям :)
Сразу оговорюсь, что бОльшая часть информации я нашел в интернете, внизу статьи будут приведены ссылки на источники. Часть информации была переведена совместно с google translate.
Итак:

Почему так важен DOCTYPE

Вроде бы вы сделали все правильно, но ваш сайт почему-то не выглядит или не работает, как ожидалось, в последних версиях броузеров.
Вы написали правильный стандартный XHTML код и стандартный CSS. Вы воспользовались стандартной спецификацией для работы с DOM (Document Object Model), чтобы управлять динамическими элементами на странице. И все-таки, в броузерах, которые казалось бы сделаны с соблюдением именно этих стандартов, ваш сайт не работает. Скорей всего, ошибка кроется в неправильном заголовке DOCTYPE.
Эта небольшая статья расскажет вам о заголовках DOCTYPE, которые работают, а также объяснит практическое и теоретическое значение этого, казалось бы отвлеченного от реальности, тега.

В процессе работы с таблицами, для удобства восприятия, а также быстрого анализа, рано или поздно возникает вопрос вывода отсортированного содержимого этих таблиц. Эту задачу в web-программировании можно решить двумя способами:

• Сортировка на стороне сервера посредством SQL или backend'а;
• Сортировка на стороне клиента.

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

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

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Буквально несколько часов назад, после внимательного изучения комментариев вот к этому топику я был несколько удивлен что многие не очень любят использовать условия HAVING и похоже другие возможности СУБД. Скажу прямо — мне очень понравилась обсуждение простейшего и не работающего запроса, в результате которого многие узнали для себя много нового и познавательного (это мое личное мнение). Поэтому я решил сделать вот что — вывести три моих самых любимых задачи по знанию SQL (MySQL) на суд общественности.

Данные задачи абсолютно реальные, и в отдаленном светлом прошлом действительно имели место, и были благополучно решены жертвой некоторого количества рабочего времени и нервных клеток. Я уверен на 100% что они актуальны и по сей день, и будут актуальны еще долго. Сложными их назвать нельзя, но и очень простыми тоже (в зависимости от уровня подготовки конечно).

Dklab_multiplexor — это инструмент, который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Например, если на вашем сайте находится одновременно несколько сот тысяч посетителей, каждый из них может быть связан с сервером постоянным соединением, установленным из JavaScript. Это например, полезно при организации онлайн-чатов или мгновенных уведомлений.

Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях). Это лишь простейший инструмент, который наконец-то дошли руки опубликовать.

Зачем это нужно?

Предположим, посетители вашего сайта могут посылать друг другу сообщения. Если получатель в момент отправки находится на сайте (просматривает какую-либо страницу), ему немедленно выдается уведомление (всплывающее окошко на JavaScript).

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

Если вы не знаете, что такое HTTP-туннель, для управления MySQL предпочитаете десктопное приложение вместо веб-интерфейса и выполняется одно из следующих условий:

• у вас есть возможность выхода во внешний мир только через HTTP-прокси
• в вашей сети установлено ограничение на возможность работы только с 80 портом
• хостинг-провайдером разрешено работать с базой только через локалхост

то эта небольшая заметка для вас.

В продолжение, файловый браузер для CKEditor и TinyMCE, и просто для сайта.
Сборка имеет два скина: dark & light

Скриншоты кликабельны

Идея паттерна Observer заключается в создании зависимости типа один ко многим. При изменении состояния одного объекта(субъекта), зависящие от него объекты(наблюдатели) об этом оповещаются и обновляются. Это нужно для согласования состояния взаимосвязанных объектов без их жесткой связанности.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Katahdin — это интерпретируемый язык программирования, в котором синтаксис и семантика могут изменяться во время исполнения. Чтобы идея стала ясна, сразу приведу пример с официального сайта. В примере определяется операция получения остатка от деления ("%" в C, «mod» в Pascal).

class ModExpression : Expression {
  pattern {
    option leftRecursive;
    a:Expression "%" b:Expression
  }
 
  method Get() {
    a = this.a.Get...();
    b = this.a.Get...();
    return a - (b * (a / b));
  }
}


Введение

Я собираюсь рассказать об однострочных программах на Perl. Если вы овладете однострочным Perl`ом, то можете сэкономить кучу времени (я экономлю).

Цель поста — показать как Perl можно использовать заместо find, grep, awk, sed. В конце поста будет написано зачем это надо.

Быстрая разработка

Вдохновленный постами на западных блогах вроде «Clone TinyURL with 40 lines of Ruby» или «Clone Pastie in 15 Minutes with Sinatra & DataMapper» я решил попробовать пройти и заодно описать весь процесс реализации легковесного веб-приложения на руби, от проектирования до деплоймента.

Предисловие

Сидел я как-то тихим вечером, читал англоязычные сайты. Когда понадобилось перевести пару фраз, я как обычно открыл новую вкладку, набрал translate.google.ru, скопировал, вставил текст, нажал перевести, прочитал. И ведь такую длинную последовательность действий приходится проделывать каждый раз, когда есть необходимость перевести текст, пару фраз или целый абзац. Да, можно использовать какой-либо клиент для перевода, но окно программы придется открывать или доставать из-под других окон. Да, последовательность короче, но все равно длинная. Было бы здорово сократить последовательность действий до скопировать, нажать кнопку. Так появилась идея для апплета. Его логика такая:

• На панели появляется кнопка «GTranslate»
• Если вам надо перевести текст, то копируете его и нажимаете на кнопку
• Автоопределение языка

Вступление

На хабре, по-моему, уже почти все возможные графические API для руби рассматривались. Но почему-то все воспринимают и подают эти самые API исключительно как чистый код. Никаких тебе графических дизайнеров, никакой скоростной разработки GUI — сиди, вычисляй координаты ручками, подгоняй как надо. А зачем иначе, ведь на руби серьезных GUI приложений не написать.
А вот и нет! Если уж на то пошло, то на руби можно написать даже Wolfenstein. Но начинать лучше все-таки с чего-то менее глобального :)

Подготовка

Итак, попробуем написать что-нибудь не очень простое, достаточно GUI'евое и желательно не заморачиваясь на вычисление координат.