InCube Chess: первая удачная реализация шахмат в трёхмерном поле

Привет!

Хотя в Хабре обычно не обсуждают игрушки, полагая их занятием несерьёзным – я сознательно сделал сегодня исключение. Очень уж редко в «игровой индустрии» происходит что-то действительно оригинальное. К тому же надобно, чтобы при яркой оригинальности оно осталось ещё и играбельным – а это уж совсем редкость. Но в данном случае, кажется, оба требования сошлись. В общем, я нашёл кое-что для настоящих «головастиков»…

Суть в том, что небольшая украинская фирма «InCube Games» выпустила одноимённые компьютерные шахматы: InCube Chess. И это не заслуживало бы ровно никакого внимания (мало ли шахматных программ?) – если бы не одна существенная деталь: поле для шахмат представляет собой не плоскую «доску» 8х8, а куб, 8х8х8. То есть борьба между фигурами игроков разворачивается не в двумерном, а в трёхмерном пространстве!

Если вы знаете о том, что WebKit умеет изменять вид тэга SPAN на кнопку, или на поле ввода, или если вы знаете каким свойством можно диктовать поведение элемента в момент тапа по нему, то вам не сюда.

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

Здравствуйте, друзья. За последний месяц я экспериментировал с псевдо-элементами, особенно, с их использованием в создании кнопок. Таким образом, удалось создать крутые эффекты, которые раньше можно было сделать только со спрайтами.

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

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

Веб-дизайнеры любят стилизировать стандартные элементы форм. Потом эти элементы приходиться реализовывать нам — верстальщикам.

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

Естественно, после всего этого я решил изобрести свой велосипед.

Пример разработан без дополнительных картинок с помощью CSS3. Демо-страница с песочницей здесь.

Однажды наткнулся на занимательный пост посвященный будущему логотипов. Авторы пытались заглянуть в будущее и представить как будут выглядеть известные бренды через несколько лет.

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

Совсем недавно в переписке с одним моим хорошим знакомым вновь возникла тема ответственности. В ходе обсуждения я решил обратиться к Christopher Avery's Responsibility Process — Процессу принятия ответственности от Кристофера Эйвери (позволю себе перевести это так).
К сожалению, русскоязычного материала на данную тему я в сети не нашел (по крайней мере, с ходу), потому решил, что будет полезно оформить это в виде поста.

Microsoft опубликовала демо-страницу улучшенной типографики для формата OpenType. Это альтернативные глифы, лигатуры, кернинг, дроби, малые прописные и минускульные цифры. Эффекты видны, если наводить на текст мышкой. Демо хорошо работает только в браузерах с поддержкой OpenType, сама Microsoft рекомендует IE10+ и Firefox 8+. В других браузерах могут проявиться не все эффекты, это ещё зависит от операционной системы.


^{Альтернативные глифы и малые прописные}

С Microsoft можно согласиться — OpenType действительно поднимает оформление текста в вебе на новый уровень, близкий к типографскому. Возможности этого формата явно превосходят @font-face.

09.01.2012 в «Smashing Magazine» была опубликована подборка бесплатных шрифтов.

В подборке представлены такие шрифты как: Homestead, Bree Serif, Levanderia, Valencia, Nomed Font, Carton.

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

P.S. Для того чтобы скачать шрифт установите 0 (ноль) в поле «Amount».

UPD: Smashing Magazine сново онлайн.

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

Приветствую вас, уважаемый хабрачеловек!

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



Система реализована на PHP (фреймворк Kohana 3) + MySQL, т.е. работает на любом нормальном хостинге в любом современном браузере.

Ранее я публиковал видеоуроки по Kohana 3. Кому интересно вот ссылка 1 и ссылка 2.

Что конкретно делает данная система:

• Администратор формирует дерево категорий (без ограничения глубины вложения подкатегорий).
• Преподаватель размещает учебные материалы в подходящий лист дерева. (Учебный материал – это офисные файлы, изображения и т.д. Файлы можно как загружать на сервер, так и указывать ссылку на сторонний ресурс).
• Преподаватель может разрешить доступ к учебному материалу как всем посетителям сайта (в том числе гостям), так и сделать доступным только авторизованным пользователям.
• Регистрация осуществляется по системе инвайтов (т.е. нужно знать секретный код, чтобы зарегистрироваться).

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

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

Содержание

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

Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

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

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)

В начале прошлого года мною уже поднималась тема пост-эксплуатации в домене Microsoft Active Directory. В предложенном ранее подходе рассматривался вариант ориентированный больше на случай утери административных привилегий, нежели их непосредственное использование. При этом само действо по возврату этих привилегий подразумевало «шумные» события и визуально палевные манипуляции в каталоге. Другими словами, для того, чтобы вернуть себе административные привилегии в домене, требовалось стать участником соответствующей группы безопасности, например, группы «Domain Admins».

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

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

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

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

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

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

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.