В большинстве встречавшихся мне rails проектов, структура контроллеров не имеет никакой организации и проект растет как придется. В больших проектах это приводит к тому что контроллеры становятся огромными (с десятками actions), а условные фильтры растягиваются на весь экран. Разобраться в таком коде бывает очень не просто.

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

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

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

Clustered index – форма организации таблицы в файле. В InnoDB данные хранятся в дереве, в таком же, в котором лежат обычные B-TREE ключи. Таблица InnoDB сама по себе уже является большим B-TREE. В качестве значений ключа используется clustered index. Согласно документации, в качестве clustered index выбирается PRIMARY KEY. Если PRIMARY KEY отсутствует – выбирается первый UNIQUE KEY. Если и такого нет, то используется внутренний 6-тибайтный код.

Что же вытекает из такой организации данных на диске?

В листе рассылки Git развернулась дискуссия о том, как язык программирования высокого уровня снижает производительность приложения, в связи с обсуждением JGit. Дискуссия особенно интересна, потому что в ней принимали участие программисты, эксперты высочайшего уровня как в C, так и в Java. Один из них — Шон Пирс (Shawn O. Pearce), известный Java-программист из компании Google, активный коммитер в Eclipse, соавтор Git и автор Java-имплементации Git под названием JGit. В своём сообщении он назвал реальные ограничения, с которыми сталкивается высококвалифицированный разработчик, пытаясь написать эффективный Java-код, сравнимый по производительности с максимально оптимизированным кодом C. Хотя письмо датируется апрелем 2009 года, но некоторые аргументы Шона до сих пор не потеряли актуальность.

List: git
Subject: Re: Why Git is so fast (was: Re: Eric Sink's blog — notes on git,
From: «Shawn O. Pearce» <spearce () spearce! org>

Как было сказано ранее, мы сделали много маленьких оптимизаций в коде Git на C, чтобы добиться реально высокой производительности. 5% здесь, 10% там, и внезапно ты уже на 60% быстрее, чем был раньше. Нико [Питре], Линус [Торвальдс] и Джунио [Хамано] — все они потратили определённое время в последние три-четыре года для оптимизации отдельных фрагментов Git, исключительно для того, чтобы он работал максимально быстро.

Каждый год тысячи людей впервые в жизни сталкиваются с необходимостью снять квартиру. Честно говоря, бизнес риелторских услуг по сдачи квартир внаем — то еще дерьмо, особенно в таком крупном городе как Москва. Именно по этой причине, каждый год появляется очередной юноша с «горящими глазами», который выдает очередной высер суперпроект помощи в поиске аренды.

Эти проекты очень похожи на бабочек. Они появляются жарким летом в высокий сезон, и умирают в морозную стужу. Так же как и бабочки красиво и бесполезно машут крыльями и исчезают не оставляя следа. А почему так получается? Некоторые мысли изложены дальше.

Мотив написания статьи

Читая хабр, извлек для себя много полезного: некоторые статьи заставляли много думать, некоторые вдохновляли на определенные действия, какие-то, возможно, предотвратят мои дальнейшие ошибки. И хотя на себя я работаю всего лишь год, за это время в моей жизни произошел ряд существенных изменений. Я получил для себя ответ на вопрос «быть или не быть», которым я задавался, работая «на дядю» и теперь хочу вдохновить тех, кто подумывает о том, чтобы вырваться из рабства вашего начальства и основать собственное дельце, но, вместе с тем, я не достиг особых высот, и нуждаюсь в совете тех, кто, собственно, преуспел.

Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

В не столь давно вышедшей версии jQuery 1.7 появился новый объект Callbacks, о котором сегодня и пойдёт речь.
В официальной документации jQuery.Callbacks описан, как многоцелевой объект, представляющий собой список функций обратного вызова (callbacks — далее просто колбэков) и мощные инструменты по управлению этим списком.

Я просматривал возможности этого объекта, когда он был ещё только в разработке, и надо сказать, что возможностей у него изначально было немного больше, чем осталось в релизной версии. Например, сейчас отсутствует возможность создания очереди (queue) колбэков, которые вызываются по одному на каждый вызов fire(). Видимо, команда jQuery, решила немного подсократить код, убрав «ненужные/редкоиспользуемые» возможности, чтобы сэкономить в весе библиотеки. Это маленький экскурс в историю Callbacks, но далее я буду описывать только доступные сейчас функции и в конце напишу небольшое возможное улучшение этого объекта.

Не так давно Monnoroch опубликовал несколько прекрасных вступительных статей по языку D2, и это было хорошо. Но, прочитав последнюю статью, посвящённую метапрограммированию, захотелось сделать ещё лучше и раскрыть тему немножко подробнее. Дьявол, как известно, в деталях — и именно внимание к мелочам делает реализацию meta-парадигмы в D2 столь удобной. Если вы не читали статью Monnoroch, рекомендую вначале ознакомиться с ней, т.к. в рамках этой не хотелось бы тратить время на базовые вещи.

Итак, если вам уже знакомы некоторые возможности шаблонов в D2, я хотел бы подробнее рассказать о том, что сопутствует им — инструментах статической интроспекции, нюансах CTFE и даже такой запретной, но притягательной вещице, как mixin.

Цель — больше наглядных примеров кода с комментариями и меньше слов.

Всегда мне не нравилось, как выводятся изображения на моих сайтах. Хотелось какой-то упорядоченности, зависимости. Поэтому, я полез искать скрипты и решения в гугле. После безуспешных поисков, решено было делать что-то самому.
Но что? Я стал смотреть, как сделан вывод картинок у популярных сайтов. Всё мне не нравилось, пока я не додумался посмотреть вывод в google images и google+. Меня поразило то, что я никогда этого не замечал картинки выравниваются по ширине и высоте не обрезаясь. Такой принцип я и захотел реализовать. Получается мозаика. И всё будто на своём месте.
Не долго думая, я сел писать код, который сможет вывести картинки так же.

Я люблю читать статьи о программировании, в которых нет ни строчки кода. Такие статьи отлично развивают «вглубь» и часто дают повод посмотреть на давно устоявшиеся вещи под другим углом. Поэтому, рискуя навлечь на свою и без того чахлую карму гнев определенного среза общественности, я всё же решил опубликовать эту статью, в надежде, что кому-то она даст не только пищу для размышлений, но и поможет по-новому взглянуть на свою деятельность.

Начало

Так сложилось, что на текущем месте работы программисты предоставлены самим себе. То есть, конечно, кодят на благо предприятия, но совершенно бесконтрольно, вплоть до отсутствия банального тестера. ТЗ даже на «тяжелые» программы редко превышает объема в три листа А4 (один из которых — подписи всех причастных).

Звонки по поводу проблем с ПО направляются напрямую программистам. С этого всё и началось.

[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

Сегодня я хочу выглянуть из своего окошка и поделиться знаниями по весьма сложной теме, в которой я буквально пару месяцев назад ничего не понимал. Зачем? Ну, мне кажется, что это просто здорово – разбираться в этом. А еще это может дать кому-нибудь повод для погружения в эту тему.

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

Жак Фреско — это человек, который уже много лет занимается идеей организации социальных структур будущего, основанных не на традиционных моделях экономики и потребления, а на возможностях современной науки. Цель проекта — устойчивое развитие цивилизации без конфликтов.

Жак родился в 1916-м году и успел застать Великую Депрессию, затем получил хорошее образование и стал известен в качестве промдизайнера и архитектора. В последние годы он занимается тем, что рассказывает о несколько фантастичном проекте своей мечты. Буквально пару дней назад в Digital October прошла его лекция (прямой телемост) про этот проект.


^{Жак в своей творческой лаборатории}

Вот основные тезисы:

• Политическая система, которая хорошо работала 50 лет назад, сейчас уже устарела.
• Большинству современных систем мы обязаны римлянам. Но у них было другое общество.
• Мы уже произвели огромную базу знаний. Нам нужно развивать её, а не считать деньги.
• Вот выкладки того, какими должны быть города, системы взаимоотношений и т.п.
• Интеграция будет медленной и плавной, но это нужно делать.
• Первое, с чего нужно начать — с изменения системы образования.
• Второе — переход к некоей форме правления, похожей на коммунизм.
• Третье — последовательная автоматизация всех рутинных процессов, включая правительственную работу.

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

Используемые лидерами алгоритмы были примерно одинаковые, базовых было два — поиск в ширину (BFS), для определения ближайшего пути к дальним целям и минимакс в ближнем бою. Дьявол скрывался в правильной методике выбора целей и тонкой настройке деталей.

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

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

Большую популярность эта технология моделирования получила в результате успешного применения и дальнейшего развития в области автоматического распознавания речи. Исследования скрытых моделей Маркова превзошли все конкурирующие подходы, и являются доминирующей парадигмой обработки. Их способность описывать процессы или сигналы успешно изучается в течение длительного времени. Причиной этого, в частности, является и то, что технология построения искусственных нейронных сетей, редко применяется для распознавания речи и аналогичных проблем сегментации. Тем не менее, существует ряд гибридных систем состоящих из комбинации скрытых моделей Маркова и искусственных нейронных сетей, в которых используют преимущества обоих методов моделирования (см. раздел 5.8.2).

Вашему вниманию представляю свой вольный перевод, обещанный г-ном Takezo в его комменте о будущем ИИ в GameDev.

Введение

Прикольно наблюдать за внутриигровой визуализацией, особенно если ты сам ее и создал! Однако, в погоне за этим ярким впечатлением легко забыть, что не нужно визуализировать все подряд.
Ниже вы найдете видео туториал по визуализации геймплея и ИИ, записанный в секретной исследовательской лаборатории AiGameDev.

Хочу рассказать несложное действие по оптимизации рабочего пространства, которое упростит жизнь многим пользователям GNOME Shell, привыкшим видеть в трее иконки любимых IM (Pidgin и др.), Skype или других приложений. В стандартной настройке они находятся в «нижнем» трее, вызов которого осуществляется наведением мыши на нижний край экрана. Неудобство упомянутого «нижнего» трея в плане общения по jabber, skype, icq и т.д. состоит в том, что пропустив от кого-либо сообщение (например, отойдя от ПК), увидеть его при возвращении без дополнительного вызова дефолтного трея невозможно. Иконка же на верхней панели сразу бросается в глаза, поэтому пропустить важное сообщение или не ответить на него вовремя менее вероятно.

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

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

Мы захотели узнать, почему уходят игроки и можно ли предсказать их уход. Предмет исследования – ММОРПГ Аион, однако наши результаты оказались применимы к широкому кругу игр и онлайн сервисов.

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.

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