Добрый день, хаброжители. Прошло много времени с выпуска 2 версии книги по PostgreSQL — успела выйти версия 9.1 и 9.2 этой замечательной базы данных. Материалов по практическому использованию этой БД также накопилось немало, поэтому я решил выпустить обновление по книге. Итак, встречайте:«Работа с PostgreSQL: настройка и масштабирование», 3-е издание.

Как и раньше, в книге исследуются вопросы по настройке производительности PostgreSQL, репликации и кластеризации. Список изменений можно глянуть на странице книги. Любые пожелания или замечания можно высылать по почте (в моем блоге указано) или писать в github issues (или даже делать pull request на исправления). Приятного прочтения!

Страница книги: postgresql.leopard.in.ua
Исходники: github.com/le0pard/postgresql_book

Толстые модели сложны в поддержке. Они, конечно, лучше, чем контроллеры, захламленные логикой предметной области, но, как правило, нарушают Single Responsibility Principle(SRP). “Всё, что делает пользователь” не является single responsibility.
В начале проекта SRP соблюдается легко. Но со временем модели становятся де-факто местом для бизнес-логики. И спустя два года у модели User больше 500 строчек кода и 50 методов в public.
Цель проектирования — раскладывать растущее приложение по маленьким инкапсулированным объектам и модулям. Fat models, skinny controllers — первый шаг в рефакторинге, так давайте сделаем и второй.

Для стейджинга моих небольших проектов на Rails я использую Openshift. Впринципе для небольших проектов он очень удобен — удобный деплой, все самое необходимое из коробки. Чего еще душе может быть необходимо? Но душа захотела сфинкса, при том очень сильно хзахотела. Так как среди картриджей я сфинкса не обнаружил, то пошел в google за советом.
А в гугле ничего… Ну или почти ничего. Все советовали поднимать DIY, накатывать все вручную, некоторые из моих знакомых советовали пересесть на AWS, но я в упор не хотел признавать, что под OpenShift нельзя поднять сфинкс. А так как приложение уже крутилось под сборкой для рельс то и DIY создавать не хотелось и я, стал думать как же все-таки поднять sphinx в уже готовой среде.
Под катом то, что я придумал.

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

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

Вывод результата в JSON достаточно прост в Rails:

render json: @statuses

Это работает отлично, если нужно вывести небольшое количество записей. Но что случится, если нам потребуется вывести сразу 10'000 записей? Производительность серьезно просядет, а самыми затратными по времени окажутся сериализация JSON и операции с базой данных.

Если у вас когда либо возникала чудная ситуация, когда вы прописали ассоциации для моделей (has_one и belongs_to), accepted_nested_attributes, но хелпер fields_for не показывает форму то это пост поожет вам раз и навсегда избавится от этого «глюка». Заранее предупреждаю, что пост сугубо для rails разработчиков, и ни для кого никому, кроме как rails разработчикам интересен не будет!

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

Добрый день, уважаемые хабровчане. Представляю вашему вниманию свой небольшой проект – сетевой 2D-шутер на C#. Несмотря на то, что визуальная составляющая весьма простая – в наш век уже никого не заинтересуешь 2D-играми, некоторые архитектурные решения могут заинтересовать людей, собирающихся написать свою игру. В статье я расскажу о вариантах реализации ключевых моментов игры.

В предыдущем посте я описал, что this в javascript не привязывается к объекту, а зависит от контекста вызова. На практике же часто возникает необходимость в том, чтобы this внутри функции всегда ссылался на конкретный объект.
В данной статье мы рассмотрим два подхода для решения данной задачи.
1. jQuery.proxy — подход с использованием популярной библиотеки jQuery
2. Function.prototype.bind — подход, добавленный в JavaScript 1.8.5. Рассмотрим также его применение для карринга (частичного применения функции) и некоторые тонкости работы, о которых знают единицы.

Итак, EventMachine — быстрый и легкий фрэймворк для сетевого взаимодействия в Ruby. EventMachine используется событейно-ориентированный (асинхронный) механзим обработки сетевых соединений. (О различиях между синхронными и асинхронными моделями обработки сетевых соединений посвящено множество информации в сети).
Так как, в русскоязычном интернете очень скудная иноформация по этому замечательному gem'у выкладываю эту статью.

Я думаю, что в процессе изучения той или иной СУБД каждый из вас не раз изобретал велосипеды для решения своих задач, не зная о существовании той или иной функции или приема, которые бы могли в разы ускорить выполнение запросов и уменьшить объем кода. В данной статье я хочу поделиться с вами своим опытом работы с очень «добрым» и «отзывчивым» MySQL, часто позволяющему программисту делать вещи, которые другие СУБД переварить бы не смогли. Материал будет полезен скорее тем, кто только решил углубиться в чудесный мир запросов, но возможно и опытные программисты найдут тут что-то интересное.

Всем привет!
Сегодня я расскажу тебе, %USERNAME%, о башмаках и сургуче, капусте, королях координатах, проекциях, геодезических системах и совсем чуть-чуть о веб-картографии. Устраивайся поудобнее.

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

Вот, казалось бы, простая вещь — географические координаты. Широта и долгота, что может быть проще. А вот представьте, что вы очутились на необитаемом острове. Смартфон утонул, а других средств связи у вас нет. Остаётся только написать письмо с просьбой о помощи и по старинке выбросить его в море в запечатанной бутылке.

Вот только незадача — вы совершенно не знаете, где находится ваш необитаемый остров, а без указания координат никто вас не найдёт, даже если выловит ваше письмо. Что делать? Как определить координаты без GPS?

Приветствую всех! Многие разработчики вкурсе про замечательный модуль Nginx Push Module для веб-сервера Nginx. Многие его опробовали, пощупали.

Задача модуля – позволить веб-серверу Nginx выступать в качестве Comet-сервера.

Материала по использованию данного модуля достаточно: хороша официальная страница проекта, описание Basic HTTP Push Relay Protocol, а также многие статьи, например Nginx & Comet: Low Latency Server Push. Однако, во многих руководствах рассматривают лишь базовую конфигурацию модуля с использованием одного общедоступного канала всеми клиентами. Несмотря на огромную полезность, модуль не предоставляет разработчикам гибкое управление каналами, их защиту.

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

Иногда требуется создать форму, данные которой связаны с несколькими таблицами. К примеру, у вас имеется две модели: Owner и Car. При добавлении нового Owner'a хотелось бы, чтобы была возможность сразу добавить машину. С появлением Rails 2.3 это стало проще.

# Старый вариант (приблизительный)
def create
  @owner = Owner.new(params[:owner])
  ...
  if @owner.save
    @car = Car.new(params[:car])
    if @car.save
    ...
end

# Новый вариант, Rails 2.3+
def create
  @owner = Owner.new(params[:owner])
  ...
end

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

Какие проблемы может помочь решить этот пост?

• Что делать если у вас в списке процессов множественные селекты которым казалось бы никто не мешает?
• Что делать если всё хорошо настроено, запросы пролетают как ракеты и список процессов постоянно пустой, но на сервере высокий LA и запросы начинают работать немного медленнее, ну например вместо 100мс получается 500мс ?
• Как быстро масштабировать систему, когда нет возможности всё переделать?
• У вас коммерческий проект в конкурентной среде и проблему надо решать немедленно?
• Почему один и тот же запрос работает то быстро то медленно?
• Как организовать быстрый кеш и поддерживать его в актуальном состояние?

Неожиданно оригинальный подход я увидел тут в описании одной вакансии.

Дабы не сочли рекламой — всю инфу о работодателе выпилил.

Но за описание вакансии средствами ООП — однозначный респект!

public class JediJob extends GameDevJob implements IRemoteJob {
...

Полный исходник не влез до ката.

В отличие от Европы и Америки в России к сайтам знакомств преобладает осторожное отношение. Однако, надежда нажать на волшебную кнопочку и найти себе любовь не гаснет в сердцах многих. И мы должны эту надежду оправдывать. Конечно, сразу найти идеально подходящую “половинку” мы не обещаем, но предложить десятки, сотни или в отдельных случаях тысячи вариантов, отвечающих именно вашим запросам, просто обязаны. Что и делаем, причем очень быстро.

Средний поиск по базе из 11 миллионов анкет, имеющих от 4 до 30 параметров каждая, занимает у нас в среднем 3.5 милисекунды. И при этом кроме поиска демон-серчер «Мамбы» выполняет следующие, в том числе не вполне традиционные задачи:

• для каждой конкретной анкеты выдает ее место в поиске (каждый пользователь, заходя в свою анкету, видит сообщение «Вы находитесь на N месте в поиске»)
• выдает конкретную анкету из списка по первичному ключу
• производит непосредственный поиск анкеты по заданным параметрам

Несмотря на то, что наш поиск с самого начала разрабатывался собственными силами, время от времени возникали мысли использовать что-то уже известное, обкатанное и гарантированно эффективное. Ну, а если мы задумываемся о поиске, первым в голову приходит Sphinx.

Примечание переводчика: данный пост является логическим развитием, а точнее «предысторией» поста Вникаем в include и extend и был подсказан в комментариях к нему пользователем murr, за что ему большое спасибо.

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

Если классы — это объекты, то у них должен быть свой собственный класс. Классом всех классов (как объектов) в Ruby является класс Class:

# один из способов создать новый класс
Dog = Class.new
    
# общепринятый способ создания класса
class Dog
    # какая-то реализация собачьего поведения
end

Dog.class
=> Class

Бывают SQL-инъекции! А возможны ли NoSQL-инъекции? Да! Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД, противоположному популярным MySQL, Oracle Database и MSSQL. Так как интерес к перечисленным базам данных в последнее время значительно возрос, хакеры всех мастей просто не могли пройти мимо них.

Всем привет. Я — начинающий (относительно) Ruby on Rails разработчик. В данный момент разрабатываю приложение, которое использует несколько баз данных. Информации по данном вопросу в интернете не так много, как хотелось бы, поэтому решил собрать все воедино и поделиться с хабрасообществом.
Повторюсь, я считаю себя новичком в рельсах, поэтому это не статья о том, как делать правильно. Это просто сборник заметок о том, что и как делал именно я.