В рамках недели ботов для браузерных игр.

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

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

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

Обычно результатом компиляции проекта является сборка (assembly) проекта, а также его зависимости (Referenced Assemblies). Однако иногда нужно чтобы результатом был один файл единственный файл, независимый от других сборок. Например простая утилита, которую можно будет куда угодно скопировать и она будет работать.

Пример

Условно говоря после:

    compile App\App.csproj  
    dir App\bin\Release  

Получаются:

    App.exe
    dep1.dll
    dep2.dll

Нам же нужно лишь один самодостаточный

    App.exe 

То есть содержащий в себе dep1.dll и dep2.dll

На Хабре уже присутствует решение со встраиванием зависимостей в ресурсы, здесь я покажу как это сделать с помощью ILMerge и Post Build Event в Visual Studio.

Давным-давно уже бредил мечтой собрать какое-нибудь устройство, пусть незамысловатое, но которое бы выполняло определенные действия под управлением компьютера. По профессии я web-разработчик, опыта в программировании микроконтроллеров никакого, но тема интересная. Навыков пайки тоже мало (ну наушники или проводки разные могу спаять конечно, но чипы паять не пробовал). Поэтому решил, что начинать необходимо с чего-то простого — например на основе уже готовой макетной платы с микроконтроллером. 

Что будет в посте?

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

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

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

Занимаясь стартапами я, наконец-то, дошел до той точки, когда нужно быть готовым отмасштабировать приложение на N серверов для 1M просмотров в день и я начал думать, как же это сделать наиболее эффективно с использованием Amazon Ec2.

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

Из недорогих серверов у амазона особого выбора нет. Изначально я планировал использовать для этого Small Instance — именно этот вариант рекомендует amazon по умолчанию. В нем 1.7 GB RAM, что довольно комфортно для windows, но только 1 ECU. На практике в памяти можно разместить 5-8 рабочих процессов, однако, толком работать одновременно они не способны — ядро одно и очень слабое: 1 ECU это всего-то 1 Ghz одного ядра Xeon образца 2007 года. По моим оценкам, примерный эквивалент — процессор Celeron на частоте 1.5 Ghz. Стоит такой сервер $0.12 в час ~ $86 в месяц, десяток — $860 в месяц… Было очевидно, что эта конфигурация сервера не совсем отвечает моим задачам.

Поэтому я решил попробовать Micro instance — всего-навсего 613 MB памяти, но зато:

• производительность достигает 2 ECU
• он в 4 раза дешевле
• можно использовать 64 битную платформу Windows Server 2008 R2 Core

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

Введение

Если Вы когда-нибудь слышали такие слова, как IoC, DI, AoP, но не имеете четкого понимания этих терминов, надеюсь, эта статья поможет в них разораться на примере работы с Microsoft Unity контейнером.

Представляю вашему вниманию перевод статьи "Mobile Form Design Strategies" от Chui Chui Tan. Перевели в компании UXDepot. Специально для пользователей Хабрахабра с одобрением издания UX Booth.

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

Интернет на экране мобильного телефона находится под влиянием нескольких важных факторов:

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

Введение

Плагин jQuery Templates – это «движок шаблонов», работающий на стороне клиента как расширение jQuery.

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

Разумеется, jQuery Templates – не единственный и не первый «движок шаблонов», но у него есть большое преимущество перед альтернативными вариантами – поддержка со стороны jQuery Team. Это позволяет нам не бояться того, что этот плагин окажется заброшенным, и различные проблемы, возникающие при выходе новых версий браузеров, придется решать своими силами.

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

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

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

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

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

Часто довольно трудно найти в базе нетипичную фамилию, например:

— Леха, поищи в нашей базе Адольфа Швардсенеггера,
— Шворцинегира? Нет такого!

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

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

В этой статье я рассмотрю наиболее известные алгоритмы, такие как Soundex, Daitch-Mokotoff Soundex, NYSIIS, Metaphone, Double Metaphone, русский Metaphone, Caverphone.

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

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

О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.

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

Вариантов немного:

• использовать виджеты от разработчиков поисковых систем (Google, Яндекс, etc): легко внедрить, привычный для пользователя интерфейс, поддержка морфологии, исправление слов по словарю, возможно более быстрая индексация сайта поисковыми системами, но, как правило ограниченные возможности по настройке и неизбежное запаздывание индексации;
• использовать встроенные в СУБД средства (например FULLTEXT-индекс для MySQL): достаточно легко внедрить, актуальный поисковый индекс, полный контроль над настройкой и внешним видом, но, чаще всего очень низкая производительность на больших объемах данных, отсутствие учета морфологии, либо, в худшем случае, полное отсутствие подобных средств в СУБД;
• использовать отдельную библиотеку/систему полнотекствого поиска.

Третий вариант кажется самым лучшим, ведь он сочетает достоинства двух других вариантов. Правда и здесь не обошлось без недостатков — библиотека требует установки, иногда даже запуска демона (например Sphinx), что может быть неприемлемо.

Решений существует масса, у каждого есть свои достоинства и недостатки. Я бы хотел подробнее остановиться на относительно малоизвестной библиотеке Xapian.

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

Как Вы знаете — в разработке объёмного JS-приложения где используется популярнейшая библиотека jQuery наступает момент когда остро встаёт проблема производительности. Все силы кидаются на амбразуру профайлера, каждый вызов скрупулёзно исследован, каждый функционально нагруженный кусок реализации обнюхан со всех сторон и выправлен. Но беда поступает не с той стороны, откуда её ждут 90% разработчиков. Селекторы — Как много в этом слове.
Давайте разберёмся — как работает эта магия и почему поиск DOM-элементов может стать причиной падения производительности приложения.

Проблема

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

Решение

.NET позволяет компилировать и выполнять код. Более того, исполнять код можно безопасно, сузив круг ресурсов, которые может использовать выполняемый код.

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.