Когда я начал играть в BoxWorld (игра типа Sokoban) первые 20-30 уровней было интересно, но дальше сложность и однообразие стали перевешивать и я решил писать бота. Никакого хитрого алгоритма решения придумать не смог, поэтому писал брутфорс. Писал на C#.

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

Не так давно на Хабре была целая волна статей, посвященных ботам для браузерных игр: [1], [2], [3] и т.д.
Казалось бы все способы уже перебрали, но недавно я натолкнулся еще на один весьма интересный и менее трудоемкий способ.

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

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

Давайте создадим интерактивную карту. Чего-нибудь. Что значит интерактивную? Ну, она должна взаимодействовать с пользователем и с данными на веб-странице, на которой она расположена. Думаю, этого достаточно, чтобы считать её интерактивной.

Что же, и возьмём мы SVG. Почему? Да потому что с ним легко работать человеку, знакомому с HTML. SVG — это векторный формат, основанный на XML. То есть у SVG-рисунка есть своя DOM, к различным элементам можно применять CSS-правила и управлять старым добрым JavaScript'ом.

Что же, начнём?

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

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

Вступление окончено, переходим к советам!

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

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

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

Реальность такова, что Agile без правильных инженерных практик очень быстро закончится. Если вы не будете прилагать усилия, которые гарантируют высокий уровень качества разработки и состояния системы в целом, то по мере усложнения проекта контроль будет быстро утрачен. В результате сделать всё, что запланировано в итерации, у вас не получится, а о значимом релизе (значимый — значит, с какой-то новой функциональностью, которая будет доступна пользователям, а не просто рефакторинг) раз в месяц вы будете только мечтать, потому что стабилизация важного релиза будет занимать гораздо больше, чем месяц.

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

Javascript-библиотека stream.js вводит «новую»¹ структуру числовых данных: поток (stream). Это контейнер, который похож на массив (array) и связный список (linked list), но содержит неограниченное количество элементов, реализованное методом отложенных вычислений.

var s = Stream.range( 10, 20 );  
s.print(); // prints the numbers from 10 to 20

Для аргумента Stream.range( low, high ) можно указать только начальную границу диапазона Stream.range( low ), тогда поток будет состоять из неограниченного количества натуральных чисел. По умолчанию Stream.range() начинается с 1.

Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

Сегодня на ежедневном Stand-up'е я произнёс перед командой очень проникновенную речь о том, что мы пишем софт для людей и никого не интересует, насколько красиво код будет выглядеть изнутри, если пользователю будет неудобно с ним работать.

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

И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

Друзья!

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

Я живу в Сомали (точнее, в непризнанном государстве Сомалиленд на его территории) и уже третий год занимаюсь тут развитием системы высшего образования (а ещё Пиратской партии России — хоть к делу это и не относится, совпадение занимательное).
Раздумывая над тем, к какому же ещё роду деятельности приучить местных (отучив от пиратства), я натолкнулся на новость о том, что до конца года нас подключат к одной из крупнейших подводных отповолоконных магистралей мира, пролегающей по дну Красного моря совсем рядом (и соединяющей Европу с Азией). А учитывая то, что пользоваться этим каналом тут будет лишь совсем минимальное количество людей, мы получим тут один из самых быстрых интернетов на планете.
В этом контексте мне стала совершенно очевидной возможность попытаться создать здесь программу обучения, а также аутсорс-ориентированную контору, нацеленную на, как говорят на западе, Software Engineering. Короче, кодить — и учить этому пиратов.
Я отдаю себе отчёт, как сумашедше это звучит, и ничуть не удивлюсь, если многие из вас мне не поверят. Но я говорю совершенно серьёзно.

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

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

Представьте, у вас есть проект, состоящий из нескольких модулей и, например, jQuery или любая другая библиотеки в CDN. У вас есть огромное желание не показывать пользователю ваши глобальные переменные и по возможности не показывать jQuery и $. Ну и, конечно, сделать все без изменения кода проекта.
Причины для сокрытия глобалов могут быть разные: для красоты, из соображений безопасности, для затруднения анализа кода и другие. Пользователь взаимодействует с вашим кодом, используя события, которые он не сможет сломать — больше ему ничего и не нужно.

Самый очевидный способ — создать единственный namespace в который пассивно экспортировать прочие объекты, а jQuery и $ в конце удалить.

После сборки код будет какой-то такой:

(function(window, undefined){
    // include ./js/YourNamespace.js
    var YourNamespace = (function () {
        // что-то ещё
        return {};
    }());
    // include ./js/YourNamespace/SomeObject.js
    YourNamespace.SomeObject = (function () {
        // что-то ещё
        return function () {

        };
    }());
    // Cleanup
    delete window.$;
    delete window.jQuery;
}(window));

Это идеальный вариант, но чаще бывает не так. Посмотрите ваш код, такой ли он?

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

Введение

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

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

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

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

Марги Росс (Margy Ross) — Президент Kimball Group.

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

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

Я опишу одну известную и простую методику, с помощью которой вы сможете достигать свои цели. Только это. Не гарантирую, что это будет быстро или дешево или эффективно, но могу гарантировать одно — цель будет достигнута.

Методика общеизвестна и называется она — планирование.

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

Очередной топик с обзором нескольких интересных плагинов jQuery.

Mobily Map

Позволяет сделать интерфейс, подобный google-картам, на основе собственных изображений (возможность перетаскивать, ставить маркеры на изображении, реагировать на нажатие по ним и др.).
Узнать больше (англ.) | Посмотреть в действии