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

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

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

Рассмотрим ситуацию, когда необходимо обрабатывать столкновения между объектами. Как вы в этом случае поступите? Вероятно, самым простым решением будет проверить каждый объект с каждым другим объектом. И это правильное решение, и все будет замечательно до тех пор пока объектов не много. Как только их станет порядка нескольких тысяч, вы заметите, что все стало как-то медленно работать. А если частиц несколько десятков тысяч или сотен? Тогда все замрет. Вот здесь уже интересно, на какие хитрости и оптимизации вы пойдете, чтобы решить такую проблему.

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

Содержание

1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение

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

А зачем вообще это нужно?

Предисловие

Новый блог GTK+ порадовал статьёй для начинающих и я решил попробовать что-то более простое, чем C++/C. Python оказался как нельзя кстати. Объём кода на Python для работы с GTK значительно меньше чем на C++, что не может не радовать.

PyGTK

PyGTK — биндинг библиотеки GTK для языка Python, PyGTK используется во многих открытых программах (например IM Gajim). Библиотека может быть очень интересна для Python программистов, поскольку проста в обращении и полностью скрывает реализацию GTK.

Под катом пример приложения.

На ХабраХабре наконец-то появился новый блог, посвящённый GTK. Присоединяйтесь! :-)

Привет, %username%!

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

GTK+ — это фреймворк для создания кроссплатформенного графического интерфейса пользователя (GUI). Наряду с Qt он является одной из двух наиболее популярных на сегодняшний день библиотек для X Window System.

Изначально эта библиотека была частью графического редактора GIMP, но позже стала независимой и приобрела популярность. GTK+ — это свободное ПО, распространяемое на условиях GNU LGPL и позволяющее создавать как свободное, так и проприетарное программное обеспечение.

Доброго всем времени суток!

Я долгое время читаю хабр, и мне все это время кажется, что тема 3д и анимации очень редко радует статьями работников данной сферы. Часто думал, чтобы такого написать, и вот идея оформилась. Я расскажу каким образом происходит первичный этап работы с данными Mocap(Мокап). Всем, кому это интересно — добро пожаловать под кат, осторожно, много картинок (кликабельны).

Rust — новый экспериментальный язык программирования, разрабатываемый Mozilla. Язык компилируемый и мультипарадигмальный, позиционируется как альтернатива С/С++, что уже само по себе интересно, так как даже претендентов на конкуренцию не так уж и много. Можно вспомнить D Вальтера Брайта или Go от Google.
В Rust поддерживаются функицональное, параллельное, процедурное и объектно-ориентированное программирование, т.е. почти весь спектр реально используемых в прикладном программировании парадигм.

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

В первой части я постарался дать понимание относительно того, как выбрать заказчика/исполнителя для проекта. Естественно, в одной статье нет возможности перечислить все, с чем приходится сталкиваться, но основы я постарался описать.

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

Ну, от слов к делу

С Новым годом! Опишу классический сюжет — оптимизацию длинной арифметики в C++ при помощи ассемблерных вставок. Однако, на Хабре его еще не было, поэтому после некоторых колебаний решил запостить сюда, вы уж простите, если сами когда-то писали то же самое и продвинулись дальше меня :-)

В сети Интернет есть немало информации о продуктах и технологиях компании Microsoft. Скорее всего, имея конкретный вопрос, воспользовавшись поисковыми системами, вы без труда отыщете ответ. Но такой подход может не подойти, если вы хотите шаг за шагом, начиная с азов изучить интересующую вас технологию. Около месяца назад по адресу www.msftva.ru была открыта Виртуальная Академия Microsoft на русском языке, позволяющая последовательно изучать продукты технологии в режиме онлайн.

В субботу на прошлой неделе «дело было вечером, делать было нечего», и мы с хабраюзером sourcerer разговаривали не понятно о чём. И почему-то речь зашла речь о задаче обратной к задаче построения графика функции по её выражению. То есть, например, у нас есть выражение y(x) = (cos^0,5x ⋅ cos 200x + |x|^0,5 − 0,7)(4 − x²)^0,01. График такой функции чем-то напоминает сердечко. Но нам был интересен обратный вопрос, как, имея, например, изображение сердечка, получить выражение для функции, графиком которой будет это самое сердечко.

Какие-нибудь ряды Фурье вспоминать не хотелось, а хотелось чего-то простого и красивого. Мы начали вспоминать известные нам результаты, связанные с этим вопросом. В результате получилась программка, которая по изображению генерирует ломаную линию, чем-то напоминающую исходное изображение. На примере котёнка по имени Гав это выглядит примерно так (смотреть лучше издалека):



Если интересно как такое сделать, а также узнать про формулу конопли, формулу, график которой является этой же формулой, то добро пожаловать под хабракат. (Будет много картинок.)

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-сентябрь 2011. В связи с повышенной конференционной активностью этой осенью вышла пауза с публикациями, но дальше такого наплыва мероприятий не будет.

Приветствую вас, друзья!

В ходе изучения материалов к экзамену CCNA Voice родилась идея оформить некоторую полученную информацию в виде отдельной статьи. Преследуя при этом две цели: одна корыстная — получше самому разобраться в изучаемом материале и разложить всё по полочкам в своём сознании; вторая альтруистическая — поделиться полученными знаниями с теми, кому это мало мальски интересно.

В статье поведаю о процессах кодирования голоса, кодеках как таковых и расчётах полосы пропускания, необходимой для передачи голоса в IP-сетях

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

С помощью псевдо-класса :target, мы сможем показывать изображения и переходить по ним.

Красивые изображения, используемые в демо-примерах, от Joanna Kustra, они используются на условиях лицензии Attribution-NonCommercial 3.0 Unported Creative Commons License.

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

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

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

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

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

Под хабракатом я опишу все демоны подробно


В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-август 2011.

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

Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.

Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.

Здесь я собираюсь осветить следующие вопросы:

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

Здравствуйте, Хабросообщество!

На хабре есть описание множества интересных структур данных, таких как деревья отрезков, дуча и т.п. Если Вам интересны сложные структуры данных, то добро пожаловать под кат!

В этой хабрастатье на примере паттернов Наблюдатель и Компоновщик рассмотрено, как применять принципы объектно-ориентированного программирования, когда стоит использовать композицию, а когда наследование. А так же рассмотрено, какие существуют способы повторного использования кода, кроме copy-paste.

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