Добрый день! Одним прекрасным днем мы обнаружили, что наш MSBuild деплой проект не хочет работать в новой среде: для создания и управления сайтами и пулами он использовал MSBuild.ExtensionPack. Падали ошибки, связанные с недоступностью DCOM. Среду менять было нельзя, поэтому кстати пришлась возможность написания собственных задач для MSBuild: msdn.microsoft.com/en-us/library/t9883dzc.aspx, было принято решения написать свои, которые работали бы через WMI (доступный на среде) Кому интересно, что получилось, прошу под кат.

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

С появлением у меня в первом классе Dendy вопрос кем я стану отпал сам собой буквально через пару недель — программистом конечно же. Я долго и упорно шел к этому, невзирая на отсутствие информатики в школе, работал в техподдержке известного всем регистратора параллельно с учебой в институте, но полноценная жизнь началась лишь в тот момент, когда меня наконец-то взяли хоть куда-то писать код.

Очень скоро я понял, что мало быть программистом, работающим от звонка до звонка и получающим за это деньги на карточку — всё самое интересное начинается, когда решаешь сам без всяких архитекторов, тестировщиков и тимлидов что-нибудь этакое написать и заставить работать. Желательно что-нибудь веселое и захватывающее. Игру, например.

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

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

• Реализация AI: как сделать максимально просто?
• RPC клиент-сервер: json или бинарная «самопальщина»?
• Асинхронные сокеты или многопоточная архитектура?
• Кеширование объектов на уровне приложения или больше памяти для СУБД?
• Работа с БД без Reflection API: действительно ли это так сложно?

        Сегодня мы продолжим рассматривать архитектуру и особенности реализации игрового backend'а на С++ для онлайн игры на примере ММО РПГ «Звездные Призраки». Это вторая часть статьи про сервер, начало можно прочитать здесь.

Привет, Хабр!

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

К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.

Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.



Много лет назад я думал, что программировать легко, но прошли годы, и я понял, что это не так. Всё из-за неверного восприятия того, что я считал программированием и того, какую работу выполняет программист.

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

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

Хочу немного рассказать про технологию OpenCV и её применение на языке программирования C#.

OpenCV (англ. Open Source Computer Vision Library, библиотека компьютерного зрения с открытым исходным кодом) — библиотека алгоритмов компьютерного зрения, обработки изображений и численных алгоритмов общего назначения с открытым кодом. Реализована на C/C++, также разрабатывается для Python, Java, Ruby, Matlab, Lua и других языков. Может свободно использоваться в академических и коммерческих целях — распространяется в условиях лицензии BSD.

На эту библиотеку я натолкнулся буквально недавно. На сайте toster.ru я задал вопрос про необычные темы для дипломных работ и в одном из ответов получил ссылки на результат работы с этой библиотекой. Вот некоторые из них:

www.youtube.com/watch?v=h9kPI7_vhAU
www.youtube.com/watch?v=256bg5_vNvg
www.youtube.com/watch?v=PUhwGTSNGhI

Эта статья — взгляд на тестирование ММО с «другой стороны баррикад», с точки зрения геймера. Я хочу рассказать о том, как сделать альфа-тест, ЗБТ и ОБТ эффективнее. И о том, почему бета-тестеры перестают писать баг-репорты и переходят «в оппозицию» к проекту.

Предисловие

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

Статья разбита на четыре раздела и написана в разговорном стиле. Я по порядку разбираю ошибки разработчиков на альфа-тесте, ЗБТ/ОБТ и при наборе тестеров после релиза. Те, кто хочет конкретики без долгих прелюдий и размышлений, могут сразу листать к последнему абзацу каждого раздела и выводам.

Игроки уходят из игр. Согласно одному из источников, в среднем менее 40% игроков возвращаются в бесплатную игру после первого раза. Важнейшая задача гейм-дизайнера – создать захватывающий продукт. Мы делаем игры для того, чтобы в них интересно было играть. Если они бросают наши игры слишком часто и быстро, мы не справились с задачей.

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

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

Привет, Хабр!

Не так давно я сходил на конференцию CLRium от sidristij, где увидел довольно простой и удобный способ для анализа исходного кода C# в MSVS 2015.

Задача взята из проекта, в котором я участвую: каждый аргумент со ссылочным типом должен иметь аттрибут NotNull или CanBeNull (которые потом использует ReSharper). В реальности, конечно, в самом проекты атрибуты являются только частью проверок, однако это не мешает им быть обязательными. Уже есть тесты, которые проверяют сборку и падают, если методы или конструкторы не содержат требуемых атрибутов, однако разработчики все равно довольно часто забывают их проставить, что приводит к падениям билдов, обновлению кода и т.д. Вот если бы Visual Studio вместе с ReSharper выдавали бы предупреждения, что код не совсем хороший, то можно было бы сэкономить время и нервы…

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

Исходный код можно посмотреть тут.

В заметке рассказано о настройке журналирования iptables в отдельный файл. Большинство руководств предлагают два подхода, но, к сожалению, у меня на Debian они так и не заработали. Точнее, логи писались в /var/log/iptables.log, но продолжали дублироваться в /var/log/messages и /var/log/syslog, что очень раздражало и задача была незавершенной. Найдя способ не дублировать сообщения в системные, решил опубликовать полученные результаты.

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

Итак, что же такое дождь или снег в реальном мире?

1 Введение

В статье мы сравним три популярных MV* фреймворка для веб-разработки: AngularJS, Backbone и Ember. Выбор подходящего фреймворка для проекта кардинально влияет на вашу возможность выполнять задачи вовремя и поддерживать ваш код в будущем. Вам нужен надёжный, проверенный фреймворк, но вы не хотите, чтобы он вас ограничивал. Веб быстро развивается, и старые методики уходят в прошлое. Займёмся же подробным их сравнением.

2 Познакомьтесь с фреймворками

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

AngularJS родился в 2009 как часть большего коммерческого продукта GetAngular. Вскоре после этого Миско Хевери, один из инженеров-основателей GetAngular, сумел воссоздать при помощи этого продукта веб-приложение, состоявшее из 17 тысяч строк кода и делавшееся в течение 6 месяцев, всего за 3 недели, и уложиться при этом в тысячу строк кода. В Google впечатлились таким фактом и стали спонсировать проект с открытым кодом AngularJS. Среди его возможностей – двустороннее связывание данных, инъекции зависимостей, простой для тестирования код и расширение возможностей HTML при помощи директив.

Backbone.js – легковесный MVC-фреймворк, родившийся в 2010. Популярность набрал в качестве альтернативы тяжёлым фреймворкам вроде ExtJS.

Ember родом из 2007 года. Он начинался как SproutCore MVC фреймворк, и сначала его разрабатывали SproutIt, затем – Apple. В 2011 году его форкнул Иехуда Кац, один из главных программистов в проектах jQuery и Ruby on Rails.

Всем привет, с вами команда Wiren Board!

Нас часто спрашивают: «Что можно подключать к вашему контроллеру? Как на нём собрать “умный дом”?»
Чтобы немного прояснить этот вопрос, мы покажем стенд, где к Wiren Board 4 подключены периферийные устройства. На его примере расскажем про типовые варианты подключения устройств и датчиков.

На стенд можно посмотреть на него через онлайн-трансляцию и зайти в демонстрационный веб-интерфейс.

Автомобили уже давно обросли всякой электроникой, так обросли, что просто жуть: в дверях контроллер, в фарах контроллер, в тормозах контроллер, ну и в двигателе, как без него. Обычно, когда речь заходит о блоке управления двигателем (ECU) представляется бензиновый мотор, обвешанный датчиками, исполнительными элементами и жгутами проводов. Блок управления чутко считывает параметры датчиков, корректирует смесь и начало искрообразования. Сложно! Но энтузиасты создают свои блоки управления, пишут альтернативные прошивки чтобы выжать лишнюю «пони», обойти какую-то неисправность или просто для повышения навыков. Причем, как правило, на такой шаг авторов толкают обстоятельства, к примеру недовольство контактной системой зажигания у бензиновых моторов, легкий некомплект электрики и так далее.

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

Итак, постановка задачи:

Дано:

• Дизельный двигатель с механическим насосом DW8, производства концерна PSA, 2000 г.в. Насос издох от времени.
• Новый топливный насос, приобретенный по случаю, с электронным управлением опережения впрыска от модификации мотора DW8B (Те самые обстоятельства).
• Полное отсутствие проводки под электронное управление, самого блока управления.
• Желание разобраться с нехитрой электроникой насоса, поднять навык, поглубже изучить работу таких насосов.

Требуется: исправный двигатель после «сращения».

Привет Хабр!

Предисловие

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



Внимание, под катом много фото.

• Игровой backend: из каких модулей он должен состоять?
• Расчет параметров персонажа: виртуальные методы или сложение массивов?
• Логика поведения: на каком уровне она должна находится?
• Перемещение персонажей: кто этим должен управлять?

        Сегодня мы продолжим знакомиться с разработкой и проектированием он-лайн игры на примере космической ММО RPG «Звездные Призраки». В этой статье речь пойдет о backend'е на С++ и она будет насквозь техническая.

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

        В статье мы сосредоточимся именно на архитектурных решениях применительно к backend'у MMO RPG в реальном времени. Исходного кода будет не много и он точно не будет содержать таких специфических для С++ вещей как множественное наследование или шаблоны. Задача данной статьи помочь в проектировании игрового сервера и ознакомить всех желающих со спецификой игрового backend'а.

        Описываемые решения достаточно универсальны и вполне подойдут для многих RPG. В качестве иллюстрации в конце статьи я приведу пример использования описанной архитектуры в игре «про эльфов».

Для кого эта статья

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

Ожидаемые результаты

Научиться создавать и встраивать VSPackage расширения в VS 2012, на примере расширения для запуска калькулятора прямо из студии.