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

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

Содержание

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

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Вышла новая версия знаменитой уже карты мира С++ от Алёны Сагалаевой и Джима. На карте отражены последние изменения, пришедшие к нам со стандартом С++11 — обратите внимание на хамелеона auto, Пресловутые Врата Анонимности, руины крепости std::auto_ptr и новые боевые юниты STL. Наслаждайтесь!



Оригинальный размер (18 Мб)
Зеркало
P.S. Сама Алёна не против использования карты в любых целях, правда, часть исходных картинок взята из интернета, а значит за полную чистоту копирайта никто вам поручаться не будет.

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

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

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

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

Долгое время занимаясь разработкой под Android, я постепенно пришел к выводу, что многих вещей мне, как разработчику, сильно не хватает. Тогда, в начале 2010-го, не хватало только C++ exceptions и RTTI. Без них любой нетривиальный C++ код просто не мог быть портирован на Android и требовал практически полного переписывания. Это было очень существенное ограничение, которое никак не давало мне покоя. К счастью, Android — это open source, поэтому, вооружившись максимой «если тебе что-то нужно, сделай это сам», я засел за работу. К моему удивлению, сделать поддержку полноценного C++ с исключениями и RTTI оказалось довольно несложно. Потребовалось всего около недели работы. Далее был сделан сайт, на который и были выложены получившиеся пакеты для Windows, Linux и Mac OS X, а также патч и инструкция по сборке.

Когда я начал писать эту статью, то понял, что глав выйдет на контроллер поболее:
Это сам джойстик, второй джойстик, вибрация и Мультитап (устройство для подключения 4 джойстиков в один порт) – он у меня есть.
Для самого джойстика существует две библиотеки, каждая из которых дает свою информацию.

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

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

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

Здравствуй Хабр!



После нескольких месяцев работы над исправлением ошибок и добавлением новых функции на суд общественности выношу новую версию Image Catalyst 2.1. В новой версии были сделаны ряд ключевых изменений.

Хочу поделиться способом, который позволит сэкономить несколько мегабайт «лишнего» веса в вашем iOS приложении. Зачем это может понадобиться? Во-первых, если ваше приложение чуть больше 20 Мб, то его нельзя будет скачать по 3G, а только используя Wi-Fi или синхронизацию c iTunes (ограничение со стороны Apple). Ну, а во-вторых, если вы любите все оптимизировать или просто хотите чуть-чуть сократить время загрузки вашего апа.
Все нижеперечисленные пункты я проверял и использовал в своем апе, сэкономив суммарно около 4 Мб. Кажется не очень то и много, но если, например, умножить на 5000 тысяч загрузок в день, то уже получим около 20 Гб сэкономленного трафика. Итак, приступим.

Не так давно на работе передо мной была поставлена задача реализовать механизм асинхронного обмена данными между веб-приложением на Java и веб фронт-эндом на стороне клиента. Задача заключалась в том, чтобы клиент получал апдейты с минимальной задержкой, при этом апдейты могли приходить со скоростью 100 апдейтов в секунду, так и 1 апдейд в минуту, т.е. желательно не слать лишних запросов со стороны клиента.

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

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

• Медленная загрузка с iso-образов
• Путаница в файлах нескольких систем(попробуйте разделить Ubuntu и BackTrack без костылей!)
• Невозможность поставить несколько однотипных систем(опять же, не используя костыли)
• И конечно, весь этот балаган мешается под рукой, когда нужно просто перекинуть несколько файлов.

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

Введение

Статья посвящена работе с MVVM и WPF. В ней описывается процесс разработки twitter client. Процесс разработки разбит на шаги. В конце каждого шага читатель параллельно пишущий приложение должен иметь работающее приложение. Каждый последующий шаг добавляет какую-то функциональность к написанному на предыдущем шаге. Используется thirdparty библиотека TweetSharp. Ссылку на исходный код, а так же оригинал статьи, написанный мной на английском, можно найти тут.
Статья рассчитана на новичков в WPF разработке. Но предполагается, что читатель имеет некоторый начальный опыт работы с WPF, в частности освоил data binding.
Я не буду писать зачем нужно использовать MVVM – считаю, что об этом хорошо написано в статье “Приложения WPF с шаблоном проектирования модель-представление-модель представления” от Джоша Смита. Если вы не хотите читать эту статью – просто поверьте мне – неверное спроектированное GUI в случае с WPF превращается в большую головную боль.

Предисловие

Несколько недель назад в просторах интернета я увидел очень заинтересовавшую меня вещь — iOS иконки на CSS3 полностью без картинок. Первое что подумал — «Я тоже так могу»! А спустя еще 5 минут для себя четко решил — «challenge accepted». Но чтоб не повторяться я решил немножко усложнить задачу — сделать не только иконки, но и сам девайс.

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

Итак, в тот-же день я решил сделать iPhone4 на CSS3 абсолютно без картинок, base64, canvas или SVG и добавить еще некоторую изюминку — интерактивные возможности:
— включение/выключение;
— блокировка при включении и разблокировка как в реальном iPhone;
— анимация «slide to unlock» текста на экране блокировки;

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

Почитав интервью создателей знаменитого бестселлера “Cut the Rope”, в котором утверждается, что на создание веревки ими было потрачено больше всего времени, я не поверил, что написать «алгоритм движения тяжелой нити» действительно так сложно, и для этого надо чуть ли не самим писать физический движок. Погуглив, готового ответа я не нашел, и решил попробовать сделать самостоятельно нечто подобное на cocos2D + Box2D.
За основу были взяты правила:

1. Цепь делать лучше с помощью прямоугольных тел, соединенных Revolute Joint’ами;
2. Чем тяжелее объекты составляющие цепь – тем она стабильнее;
3. Количество итераций при шаге – чем больше, тем лучше (мне хватило 3-х);
4. Очень помогает, если каждый кусочек цепи, помимо Revolute Joint’а соединить Distance Joint’ом.

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

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

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

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

“Think of SQLite not as a replacement for Oracle but as a replacement for fopen()”
— About SQLite

А также, скорее всего, под Android, BlackBerry и в сэнд-боксе браузеров для веб-приложений, но я не проверял.

Почему может быть нужно работать с SQLite напрямую?

Любой опытный iOS девелопер тут же упрекнёт меня за использование SQLite напрямую (вернее не напрямую, а через FmDb, но это почти всё равно что напрямую). Он скажет, что нужно использовать CoreData, т.к. оно много всяких ништяков делает автоматически, типа Undo и Redo. И в нём можно рисовать красивые схемки, которые потом приятно показывать заказчику. А в андроиде, например, есть OrmLite.

И я соглашусь – но до той поры, пока у вас база не перевалила, скажем, за 10 таблиц по 500,000 записей в каждой. А если таблиц 52, и есть особо жирные таблицы по миллиону и больше? И базу нужно синхронизировать с сервером через третий формат, к тому же заказчику критично, будет синхронизация длиться час или пять? Если вы встречали задачи такого объёма, добро пожаловать под кат! Если не встречали – то тоже, ведь никто не застрахован от проектов с большими данными, пускай даже таких мобильных и меньше.