Техника автоматического выбора нужного тайла из тайловой карты.

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

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

Тайлы, учитывающие своих соседей

Тайлы в Super Mario не учитывают своих соседей: каменный блок всегда выглядит одинаково, и как отдельный фрагмент, и как часть стены.



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

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

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


Послушать можно вот тут.

Юристы — это вообще песня. Их профессия, пожалуй, наиболее близка к разработке кода, разве что в роли кода выступают люди.

Хорошо размахнувшись, инженер производил мощный удар кулаком сверху монитора. Раздавался треск и… монитор оживал! Тогда, 30 лет назад, когда в свои десять лет я посещал вечерние занятия школы юных программистов в университете, только инженер имел право так чинить мониторы. Только он знал, в какое место и с какой силой приложить компьютерную технику, чтобы она ожила и мы, дети, которым повезло попасть в школу программистов, продолжили, счастливые, писать свои строчки кода.

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

Написание хорошего кода

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

function add(numA, numB) {
  return numA + numB
}

Полезным свойством чистых функций является то, что их легко тестировать.

test.equals(add(2, 2), 4)

Компонуемость тоже является их сильной стороной.

test.equals(multiply(add(4, 4), 2), 16)

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

const totalPoints = users
  .map(takePoints)
  .reduce(sum, 0)

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

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

Открываем папку "/Логика/ИТ", создаём в ней директорию «двоичные технологии», прописываем «проблему останова» вместо когерентного критерия логической истинности, предельным решением которой можно считать возможность полного тестирования программы на предмет корректности её реализации, и идём дальше.

Я в течение десятилетий программировал на объектно-ориентированных языках. Первым из них стал С++, затем был Smalltalk, и наконец .NET и Java. Я фанатично использовал преимущества наследования, инкапсуляции и полиморфизма, этих трёх столпов парадигмы объектно-ориентированного программирования. Мне очень хотелось воспользоваться обещанным повторным использованием и прикоснуться к мудрости, накопленной моими предшественниками в этой новой и захватывающей сфере. Меня волновала сама мысль о том, что я могу мапить объекты реального мира в классы и думал, что весь мир можно аккуратно разложить по местам.

Я не мог ошибаться сильнее.

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

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

Ниже список наших фреймворков:

• Polymer
• Aurelia
• Meteor
• Webix
• React

Теперь, пришло время взглянуть на них поближе.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

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

Идея для написания этой статьи возникла прошлым летом, когда я слушал доклад на конференции BigData по нейронным сетям. Лектор «посыпал» слушателей непривычными словечками «нейрон», «обучающая выборка», «тренировать модель»… «Ничего не понял — пора в менеджеры», — подумал я. Но недавно тема нейронных сетей все же коснулась моей работы и я решил на простом примере показать, как использовать этот инструмент на языке JavaScript.

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

Перевод поста Майкла Тротта (Michael Trott) "Aspect Ratios in Art: What Is Better Than Being Golden? Being Plastic, Rooted, or Just Rational? Investigating Aspect Ratios of Old vs. Modern Paintings".
Код, приведенный в статье, можно скачать здесь.
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации

---

Содержание

Предисловие: золотое сечение — красивая математическая концепция
Работа Фехнера 1876 года об эстетичности прямоугольников и соотношениях сторон в картинах
Легкий старт: анализ «Artwork» — области базы знаний Wolfram Knowledgebase
Первая часть: особенности вероятностного распределения соотношений сторон
Соотношения сторон для разных веков, жанров и художников
Анализируя пять старых немецких музейных каталогов
Коллекция Кресса: четыре больших PDF файла
У нас представлены коллекции следующих галерей: Метрополитен (Metropolitan), институт искусств Чикаго, Эрмитаж, Национальная Галерея (National Gallery), Рейксмюзеум (Rijks) и Тейт Британия
Исключение в соотношениях сторон: Национальная портретная галерея
Веб-галерея изящных искусств: удобная база данных, готовая к использованию
Примечание II: важность точности в измерениях
WikiArt: еще один крупный веб-ресурс
Коллекция Французского государственного музея
Картины в итальянских церквях: высота есть всё
Смитсоновская коллекция
Большая коллекция картин в Великобритании
Нынешний рынок изящных искусств: рациональней чем когда-либо
Проданные картины: большинство написаны недавно, а у распределения длинный хвост
Восток: все показатели отличаются
Пропорции пакетов, автомобилей, этикеток, логотипов, эмблем, бумаги, банкнот, почтовых марок и фильмов
— Продукты из супермаркета
— Винные этикетки
— Этикетки немецких сортов пива
— Логотипы продуктов питания
— Банкноты
— Размеры автомобилей
— Бумажные листы
— Марки
— Эмблемы команд NCAA (Национальной ассоциации студенческого спорта)
— Эмблемы немецких футбольных клубов
— Форматы фильмов
Заключение: так какое соотношение самое «лучшее»?

---

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

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

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года:

The best way to predict the future is to invent it.
Лучший способ предсказать будущее это изобрести его.

У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой объектно-ориентированного программирования. Он был одним из первопроходцев в области персональных компьютеров и графического интерфейса, он разработал Smalltalk — один из первых самых влиятельных языков программирования всех времен.

У нас в Хекслете, особенно в чате, постоянно поднимается вопрос «что такое ООП» и «что имел ввиду Алан Кэй на самом деле». В этой заметке собраны интересные цитаты Алана о состоянии современной разработки, ООП и языке Лисп.

Примечание от переводчика:

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

---

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

За последние несколько лет стало ощущаться, как качество программного обеспечения и услуг по всей отрасли стало падать, а не расти. Все и всегда находится в стадии Беты (как исходя из названия, так и из качества). Товары отправляются потребителям тогда, когда этого хотят маркетологи, а не когда они реально готовы к продаже, а все потому, что «мы всегда сможем легко все пофиксить». Конечный потребитель превратился из покупателя в бета-тестера, но это уже норма, потому что в разработке используется Agile. В программировании мы стали считать, что ошибки и неудачи — это нормально, поэтому нам теперь не нужно прикладывать так много усилий для их избежания. Поддержка миллионов клиентов — вещь сложная, поэтому волноваться не стоит. Зачем вообще тратить время на ознакомление с фидбеком и репортами от пользователей, если их просто можно отправить в бесконечный лабиринт под названием «саппорт» и «обратная связь»?

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

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

Предыдущая статья серии была посвящена теории парсинга исходников с использованием ANTLR и Roslyn. В ней было отмечено, что процесс сигнатурного анализа кода в нашем проекте PT Application Inspector разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат (Unified AST, UAST);
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена второму этапу, а именно: обработке AST с помощью стратегий Visitor и Listener, преобразованию AST в унифицированный формат, упрощению AST, а также алгоритму сопоставления древовидных структур.

Содержание

• Обход AST
  
  • Visitor и Listener
  • Различия в Visitor в ANTLR и Roslyn
  • Грамматика и Visitor в ANTLR
  • Альтернативные и элементные метки в ANTLR
• Типы узлов унифицированного AST
• Тестирование конвертеров
• Упрощение UAST
• Алгоритм сопоставления древовидных структур
• Заключение

Компания Hola объявляет начало весеннего конкурса по программированию! Призовой фонд увеличен:

1. Первое место: 3000 USD.
2. Второе место: 2000 USD.
3. Третье место: 1000 USD.
4. Возможно, мы решим отметить чьи-то чрезвычайно оригинальные решения двумя специальными призами в 400 USD.
5. Если Вы отправите кому-то ссылку на этот конкурс, поставив наш адрес в CC, и этот человек займёт призовое место, Вы получите половину суммы приза (разумеется, не в ущерб награде победителя). За одного победителя такую награду может получить только один человек — тот, кто отправил ссылку первым.

Мы ищем талантливых программистов, поэтому авторы интересных решений будут приглашены на собеседования.

Опубликовано дополнение: Тестовая программа, часто задаваемые вопросы, типичные ошибки.
Опубликовано дополнение: О ходе тестирования.

Правила

На этот раз мы решили попробовать что-то новенькое: для разнообразия, этот конкурс — не на производительность кода.

Условия конкурса на английском языке размещены на GitHub. Ниже — перевод на русский язык.

Метод Монте-Карло это алгоритм принятия решений, часто используемый в играх в качестве основы искусственного интеллекта. Сильное влияние он оказал на программы для игры в Го, хотя находит свое применение и в других играх, как настольных, так и обычных компьютерных (например Total War: Rome II). Так же, стоит отметить, что метод Монте-Карло используется в нашумевшей программе AlphaGo, победившей го-профессионала 9-го дана Ли Седоля в серии из 5 игр.

В данной статье хотелось бы рассказать про версию алгоритма Монте-Карло под названием Upper Confidence bound applied to Trees (UCT). Именно после публикации этого алгоритма в 2006-м году, программы для игры в Го сильно усилили свои позиции и достигли значительных успехов в игре против человека.

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

В этой статье я кратко рассмотрю некоторые популярные архитектурные паттерны в среде iOS и сравню их в теории и на практике. Больше информации вы найдете при переходе по ссылкам, указанным в тексте.

Привет, Хаброжители! Мы издали долгожданную книгу:

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