Программирование *

Здравствуй, уважаемый Хабр! Я являюсь участником разработки автоматизированных систем управления высокой надежности, которые применяются на электростанциях, космодромах, сложных производствах и т.п. Однажды передо мной встала задача придумать метод проверки работоспособности программ в условиях загруженности всяких железяк, а именно:

1. Загруженность процессора
2. Загруженность сети отправкой/приемом
3. Нехватка оперативной памяти
4. Загруженность жесткого диска запросами чтения/записи

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

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

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

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

Сразу оговорюсь, что под «башнями» в заголовке поста подразумевается игра-головоломка «Саровские башни», расположенная на сайте bashni.org, о существовании которой я узнал из хабрапоста Как построить башню.

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

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

«от нефиг делать / just for lulz» посвящается…



Змейка. Игра старая (как утверждает Wikipedia: середины или даже конца 1970х годов), но от того не менее интересная, по крайней мере в качестве примера несложного но интересного алгоритма для иллюстрации возможностей графического программирования на LabVIEW 2009.

Здравствуйте, дорогие хабравчане!

Я хочу поделиться с вами своим опытом использования паттерна проектирования visitor и его интересной модификацией, которую я назвал upcast visitor. К сожалению, непросто придумать простой короткий пример и описать как все работает, также эта статья может показаться сложной для начинающих, тем не менее я постараюсь максимально упростить задачу. Примеры кода приведены на языке С++ и обязательны к прочтению. Без понимания кода вникнуть в суть статьи будет затруднительно.

Предыстория

Представьте, что мы проектируем 2D игру, в которой фрукты падают с дерева, по пути ударяясь о ветки. Цель игры — поймать все фрукты, двигая корзину под деревом.
Строим следующую диаграмму классов:

Хотите использовать Observable Collections? Слышали про Reactive Extensions? Нравится LINQ? Не нравится писать спагетти-код? Нужны монады? И все это на JavaScript?

На хабре уже много статей об играх на bash, это Шахматы, Xonix, Sokoban, Морской бой и даже Шутер с псевдо-3D графикой. Но во всех этих играх управление происходит с помощью клавиатуры. Мы же пойдём дальше и напишем игру на bash, управление в которой будет осуществляться с помощью мыши. А заодно разберём как сделать игру устойчивой к изменению размера терминала. Итак, напишем игру Quadronix.

Можно ли простой и вроде невинной регуляркой убить систему? Да, можно.

Например:

>>> r = '(a+)*b'

Просто — да. Невинно — вроде да. Конечно неумно, потому что скобки и звездочка лишние, но должно работать. Попробуем:

>>> re.findall('(a+)*b', 'aaaaaab')
['aaaaaa']

Круто, работает, пошли пить пиво.

А нет…

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

Введение или зачем этот топик

Читая Хабрахабр, я натолкнулся на два топика, «выводящие на чистую воду» вычисления с плавающей запятой.
В одном из них достаточно подробно и качественно дана выжимка из стандарта IEEE754 и основные проблемы при вычислениях с плавающей запятой, другой — короткий топик-заметка про то, что не все так хорошо при вычислениях на ПК. При этом даются рекомендации в случае, когда важна математическая точность результата, использовать целочисленные вычисления, «фиксировать запятую» или как минимум проверять результаты, выдаваемые платформой (компилятор + процессор).
Несмотря на то, что советы дельные, понять, как использовать целочисленные вычисления там, где до этого была плавающая запятая, не так просто, особенно без математической подготовки. Достаточно занимательна в этом смысле попытка одного из «хабровчан» разобраться с фиксированной точкой методом экспериментов.
Данный топик — краткое введение, которое должно дать представление о вычислениях с фиксированной точкой. Математика в данной статье не должна никого напугать — все очень примитивно. Сразу прошу простить: среди моих знакомых устоявшимся выражением является именно «фиксированная точка» (от англ., fixed-point), а не «запятая», поэтому я буду придерживаться именно этого термина.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Судя по всему, неделя исключений на хабре успешно наступила :). Накопив достаточную «подушку» кармы чтобы не бояться уйти в минус, я, пожалуй, тоже выскажу свое мнение по данному вопросу. Сразу оговорюсь, что мнение сугубо личное, основанное на небольшом практическом опыте коммерческой разработки: C++, Objective-C, C#, Java, Python, Ruby.

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

В США в возрасте 70 лет скончался Деннис Ритчи (Dennis Ritchie), создатель языка программирования Си и один из разработчиков операционной системы UNIX.

О смерти Ритчи сообщил на своей странице в социальной сети Google+ его коллега Роберт Пайк (Robert Pike). Он указал, что программист умер у себя дома после продолжительной болезни. Портал CrazyEngineers в качестве даты смерти Ритчи называет 8 октября.

В эти выходные умер Деннис Ритчи, автор языка С и соавтор Unix. Об этом сообщил его друг и коллега Роберт Пайк.

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

volatile unsigned long int incremented;

«Полезная» работа — выполнить BIG_NUMBER инкрементов.
Цель теста — оценить затраты на синхронизацию, то бишь построить графики зависимость временных затрат от количества конкурирующих нитей для разных механизмов синхронизации.
Пучки нитей (1..N штук) выполняют одинаковое количество инкрементов, синхронизируясь разными способами.

Далее о структуре теста и результатах.

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

Основные возможности

Классы

Классы и интерфейсы представляют из себя простой и понятный механизм для создания всевозможных АПИ. Эти конструкции добавляют инкапсуляцию и повторное использование методов и данных.

Опциональные типы

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

Библиотеки

Разработчики могут создавать и использовать библиотеки, которые гарантированно не будут изменяться во время выполнения.

Инструменты

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

Достаточно большое название? Да? В этом посте я покажу Вам альтернативный подход в создании простого событийно-ориентированного HTTP-сервера на C#, используя мощь Reactive Extensions.

Эта статья является изложением в письменном виде моего личного восприятия программирования и Объектно-ориентированного программирования в частности. Здесь собраны и душевные негодования, и переживания за программистов всего мира. Всё, конечно же, подкреплено исходным кодом.