“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”

Мысли автора статьи во время чтения и рефакторинга чужого кода

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

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.

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

Можно сказать, что вышеперечисленный набор программ — это самые нужные программы, которыми пользуется человек в цифровую эпоху. Этот список покрывает все базовые потребности человека-пользователя. Или не все? Есть ли еще одна базовая потребность, которая не учтена в вышеприведенном списке самых необходимых программ? Является ли эта потребность самой важной из тех, что должен автоматизировать компьютер? Для меня такая потребность есть, но в списке самых используемых программ ей места не нашлось. Что же это за потребность?

0. Присказка

В некотором царстве, в некотором государстве жил-был программист. Звали его, как полагается, Иван. Был он настоящим спецом, обладал всеми Тремя Великими Добродетелями Программиста, то есть был ленив, спесив и нетерпелив. Случилась в том царстве печаль великая: кризис. И выгнали Ваню с работы без выходного пособия. Горевал Ваня долго, а потом собрался с духом и разослал резюме по всему белу свету. Долго ли, коротко ли, вызвали Ваню на собеседование. Требований к соискателю было много, но главное — требовалось хорошо владеть регулярными выражениями. До собеседования — почти месяц, готовься — не хочу. Будучи человеком серьёзным, готовиться Иван решил обстоятельно. 3 недели и 3 дня он лежал на печи, почитывал Хабр и думал, как же неслыханно обстоятельно он будет готовиться. До собеседования остался 1 день. Ванюша мысленно обругал работодателей, которые назначают собеседование так скоро, что совсем подготовиться не успеваешь, слез с печи, сдал пивные бутылки и на вырученные деньги купил книжку по регексам. Читал он её до полного изнеможения, пока не отключился. Утром мы найдём сонную физиономию Ванюши лежащей, как на подушке, на этой самой книжке под Хабракатом.

Мой рекорд скорости написания кода «на C» был в консоли Quake II. Причем абсолютно без ошибок. В темноте, не глядя, трясущимися руками надо было набрать примерно такое:

bind SHIFT "+snipe"
alias +snipe "sensitivity 2.5; fov 30"
alias -snipe "fov 90; sensitivity 4"

Боги умели прописывать RocketJump.


Под катом — подборка дюжины проектов, которые заточены на то, чтобы играючи повысить кодерское мастерство.

Уже в течение трёх лет я веду блог разработки моего нового roguelike-проекта. Истории игры в нём уделено довольно мало обсуждений, что отражает её малую информативную роль и важность в процессе разработки альфа-версии. На самом деле за посредственной и избитой научно-фантастической историей 7DRL, изложенной в версии для гейм-джема, последовал перезапуск проекта в 2013 году, и первое растягивание сроков разработки произошло только из-за воплощения уникальной детализированной истории. Всё, происходившее позже, тем или иным образом служит для поддержки нарратива.

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

          — Ну, если ты смотришь такого рода спили, то знаешь про них больше меня, — сказал я.
          — Мне как-то попалась такая бойкая формулировка: мол, риторы умели менять прошлое и делали это с удовольствием; инкантеры могли изменять будущее, но прибегали к своему умению крайне неохотно.…
          — Им приходилось менять будущее в ответ на действия риторов.
 
         Нил Стивенсон «Анафем»

Странные книги побуждают меня делать странные игры. «Анафем» Нила Стивенсона не исключение. Моя статья — один большой спойлер на это произведение. Если вы собираетесь читать её, прежде прочитайте книгу! Я вас предупредил…

Результат: информация о цвете занимает 1/64 от исходной площади при достаточно высоком качестве результата. Тестовое изображение взято с этого сайта.

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

Разработчики и неразработчики мыслят совсем по-разному. Поэтому то, что кажется всем остальным нормальным (вопросы, комментарии и просто фразы для поддержания разговора), может довести специалиста до белого каления. Менеджерам на заметку: если у программиста нервно задергался глаз после вашего вопроса, возможно, следует его переформулировать или вообще больше не задавать.

Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.

Итак, встречайте топ-7 фраз менеджеров, которые не оставляют выбора программистам.

Что побудило меня написать это статью?

Первое. Зачем художнику рассказывать о тяготах жизни и о трудном пути, если у него вроде как все хорошо? Во-первых не так уж и хорошо (потому что всегда может быть лучше), а во вторых, для того чтобы идущие следом – не повторяли ошибок, стало быть не тратили свое драгоценное время. Сколько бы нам не было отпущено – все равно на все не хватит. Стоит постараться выделить важные вещи, и опустить незначительные.

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

Третье, но далеко не последнее. Еще одним «чиркашом» для моей сегодняшней спички послужила эта статья. Имею свой особый взгляд на игровую индустрию, игровые конторы, не имеющий ничего общего с изложенной точкой зрения. Хочу предложить тем кто решился идти в игровую индустрию нечто более осязаемое. Конкретику. То, что может быть использовано для достижения цели. Не будет волшебных пилюлек, ласковых Розовых оттенков еще не разбитых очков, политеса и прописных истин. Там где Истины все же отметятся – зайдут по делу, выпьют чарку рому и пойдут дальше.

Поскольку я кое-что знаю об арте, графическом контенте и других горшочках с дегтем и медом, — излагать буду взгляд в первую очередь на игровую индустрию и поиск работы в ней со своей колокольни. Артовой. Отмечу также, что могу оказаться донельзя субъективным. Насколько мне помешал мой субъективизм – решать вам.

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

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

Все начиналось довольно обыденно… Зачитывался Рихтером и усиленно штудировал Шилдта. Думал, что буду заниматься разработкой под .NET, но судьба на первом месяце работы распорядилась иначе. Один из сотрудников неожиданно покинул проект и во вновь образовавшуюся дыру докинули свежего людского материала. Именно тогда и началось мое знакомство с SQL Server.

С тех пор прошло чуть меньше 6 лет и вспомнить можно многое…

Про бывшего клиента Джозефа из Англии, который переосмыслил жизнь, за время отпуска в Таиланде, и в моем скайпе стал подписываться Жозефиной. Про веселых соседей по офису, с которыми приходилось сидеть в одной комнате: один страдал от аллергии на свежий воздух, а другой маялся от неразделенной любви к С++ дополняя это аллергией на солнечный свет. Один раз по команде свыше пришлось на время стать Александром отцом двух детей, чтобы изображать из себя обросшего скилами сениора по JS.

Довелось как-то раз отлаживать вот такой код на C#, который «на ровном месте» падал с NullReferenceException:

	public class Tester {
		public string Property { get; set; }
		public void Foo() {
			this.Property = "Some string"; // NullReferenceException
		}
	}

Да, вот на этой самой строчке с присвоением свойства падал NullReferenceException. Что за дела, думаю — неужели рантайм перестал проверять наличие экземпляра перед вызовом экземплярных методов?

Как оказалось — в некотором роде да, перестал. Правда, и компилятор оказался не тем, за кого себя выдаёт, да и проверки вовсе не гарантированы рантаймом… Подробнее — под катом.

Развлекаемся, «распутывая» код на языке Си

Вызов: Прежде чем лезть под кат, скомпилируйте в голове заголовок статьи, что он дает на выходе?


Когда я в очередной раз просматривал книгу «Expert C programming», я вдруг наткнулся на раздел «light relief» в международном конкурсе на самый запутанный код на Си (IOCCC). Это соревнование по написанию как можно более нечитабельного кода. То, что такие конкурсы устраиваются для Си, наверное, говорит что-что об этом языке. Мне хотелось увидеть работы участников этого соревнования. Не найдя никакой информации в интернете, я решил поискать их самостоятельно.

IOCCC был придуман Стивеном Борном, когда он решил использовать препроцессор Си и написать Unix shell как бы на языке Си, но больше похожем на язык Algol-68, с его явными окончаниями операторов, например:

if
  ...
fi 

Он добился этого, сделав:

#define IF if(
#define THEN ){
#define ELSE } else {
#define FI ;}

Что позволило ему писать так:

IF *s2++ == 0
THEN return(0);
FI

Первая статья цикла

Интро

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

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Mathematical Notation: Past and Future (2000)".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации

---

Содержание

Резюме
Введение
История
Компьютеры
Будущее
Примечания
— Эмпирические законы для математических обозначений
— Печатные обозначения против экранных
— Письменные обозначения
— Шрифты и символы
— Поиск математических формул
— Невизуальные обозначения
— Доказательства
— Отбор символов
— Частотное распределение символов
— Части речи в математической нотации

---

Стенограмма речи, представленной на секции «MathML и математика в сети» первой Международной Конференции MathML в 2000-м году.

---

Резюме

Большинство математических обозначений существуют уже более пятисот лет. Я рассмотрю, как они разрабатывались, что было в античные и средневековые времена, какие обозначения вводили Лейбниц, Эйлер, Пеано и другие, как они получили распространение в 19 и 20 веках. Будет рассмотрен вопрос о схожести математических обозначений с тем, что объединяет обычные человеческие языки. Я расскажу об основных принципах, которые были обнаружены для обычных человеческих языков, какие из них применяются в математических обозначениях и какие нет.

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

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

Традиционная математическая нотация представляет математические объекты, а не математические процессы. Я расскажу о попытках разработать нотацию для алгоритмов, об опыте реализации этого в APL, Mathematica, в программах для автоматических доказательств и других системах.

Обычный язык состоит их строк текста; математическая нотация часто также содержит двумерные структуры. Будет обсуждён вопрос о применении в математической нотации более общих структур и как они соотносятся с пределом познавательных возможностей людей.

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

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

Тогда я написал пост «Заблуждения программистов относительно „времени“», в котором указал 34 ошибочных представления и заблуждения, относящихся как к календарному, так и к системному времени. С большинством из них я столкнулся сам, занимаясь дебаггингом программ (как рабочих, так и тестовых).

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

Друг наших образовательных программ Михаил Пименов,  CEO компании Wonder Games и Team Lead инди-проекта "Guard of Wonderland" сам не раз задававший себе эти вопросы, создал для себя выборку всевозможных материалов по индустрии геймдева. От полезных ресурсов, до сообществ, подкастов, книг и фильмов, которые призваны помочь понять, с чего начинается и чем заканчивается разработка игрового проекта. Объединив наши силы, мы с Мишей сделали эту статью с подборкой полезных материалов по игровой индустрии. Вы найдете подборку под катом.

Речь пойдёт о картографии, имеющей дело с фантастическими мирами.

Положение дел с процедурной генерацией карт

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

Будучи высококвалифицированным исследователем, я потратил немало времени на продвижение науки вперёд. Но я родился на Юге и искренне убеждён, что прогресс — это выдумка, и что нужно готовиться к Судному дню, к жатве того, что мы посеяли и к появлению быстрых зомби, медленных зомби, и даже вежливых зомби, которые обращаются к вам «сэр» или «мадам», но в итоге пытаются съесть ваш мозг дабы заполучить ваши навыки. Когда нагрянет революция, нужно быть готовым; поэтому в моменты тишины и покоя, когда я не произвожу очередной прорыв в науке, я размышляю над тем, что же я буду делать, когда прогноз погоды изменится на «РЕКИ КРОВИ ЦЕЛЫЙ ДЕНЬ ДО СКОНЧАНИЯ ВРЕМЁН».

В основном я думаю о тех, кто будет прикрывать мою спину, поскольку шансы на выживание в постапокалиптическом мире напрямую зависят от размера и качества того сброда, который вы будете называть своей командой. Очевидно, мне понадобятся: слесарь (чтобы двери вскрывать), эксперт‐подрывник (если уж у слесаря закончатся идеи) и конечно же тот парень, что отловит, выдрессирует и затем будет швырять змей в моих врагов (потому что в мире умершей надежды бросок змеёй — это разумный способ урегулирования разногласий). В сией антиутопии они помогут мне прослыть воинствующим философом.

Но! Но… Самым важным членом моей банды будет системный программист, ибо в гоббсовском кошмаре невероятных масштабов умеющему отладить драйвер устройства или распредёленную систему человеку можно доверять; системный программист видел ужасы Вселенной и понимает безысходность бытия. Системный программист писал драйверы для устройств, прошивку которых создавал то ли пьяный ребёнок, то ли трезвый карась. Системный программист отлавливал проблему с сетью через восемь машин, три часовых пояса и с дружеским визитом в Омск, откуда ее перенаправили в левое переднее копыто той лошади, что избавила Трою от перенаселения.¹ Системный программист читал исходники ядра для лучшего понимания процессов мироздания и видел комментарий «И ЭТО РАБОТАЕТ ЛОЛ» в коде планировщика, и не смеялся он, но плакал; и отправил он патч ядра для восстановления баланса Силы и устранения инверсии приоритетов, что приводила к зависанию MySQL. Системный программист знает, что делать, когда общество падёт, потому что он уже живет в мире, где царит беззаконие.

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

Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!