Это статья достаточно древняя, но не потерявшая актуальности. Когда разговор заходит об async/await, как правило, появляется ссылка на неё. Перевода на русский найти не смог, решил помочь кто не fluent.

Асинхронное программирование долгое время было царством самых опытных разработчиков с тягой к мазохизму – тех, кто имел достаточно свободного времени, склонность и психические способности размышлять об обратных вызовах (callback) из обратных вызовов в нелинейном потоке выполнения. С появлением Microsoft .NET Framework 4.5, C# и Visual Basic принесли асинхронность всем нам, так что простые смертные теперь могут писать асинхронные методы почти так же легко, как синхронные. Обратные вызовы больше не нужны. Больше не нужна явная передача (marshaling) кода из одного контекста синхронизации в другой. Больше не нужно беспокоиться как двигаются результаты выполнения или исключения. Нет необходимости в трюках, которые искажают средства языков программирования для удобства разработки асинхронного кода. Короче говоря, больше нет мороки и головной боли.

От переводчиков

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы поговорим о новостях в мире Angular. Мы подготовили для вас наиболее интересные материалы и отобрали список вопросов, который вам должен понравиться. Отметим только, что если вы будете ждать от этой статьи ответа на вопрос "Чем Angular лучше других технологий?", то придется вас огорчить, у нас не будет ответа на него. Почему? Как правило, все мнения вида "Технология X лучше технологии Y" почти всегда не более, чем отражение точки зрения высказывающегося. Однако для тех, кто только начинает изучать этот фреймворк, мы постараемся объяснить, что дает вам эта технология и какую пользу она приносит. Также не проходите мимо и ответьте на опрос, самые популярные ответы будут отправлены Игорю Минару (ведущий разработчик команды Angular). Ну что же, приступим.

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

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

Он убежал по своим гейм-дизайнерским делам, а я — открыл IDE.

• ADB (Android Debug Bridge) (например, в составе Android SDK Platform Tools — загрузить можно здесь);
• драйвер для телефона (при необходимости, например, Google USB Driver можно загрузить здесь).

Скрытый текст

В «Диспетчере устройств» смартфон отображается, например, так:
в режиме «Фото» или «Файлы»

в режиме «USB-диск»

А вот так — в выводе команды lsusb:

adb devices

./adb devices

adb shell

while true; do ps `while ! (dumpsys media.camera | grep -E "PID") do  done | grep -o "[^PID: ][0-9]*$"` | grep -o "[^S ]*$" ; date; sleep 1; done

Однажды я готовился к Ludum Dare и сделал простую игру, где использовал пиксельные шейдеры (других в движок Phaser не завезли).

color = pixelShader(x, y, ...other attributes)

Потестировав, кинул ссылку другу, и получил от него вот такой скриншот с вопросом "а это нормально?"

Нет, это было ненормально. Посмотрев внимательно код шейдера, я обнаружил ошибку в вычислениях:

if (t < M) {
    realColor = mix(color1,color2, pow(1. - t / R1, 0.5));
}

Т.к. константа R1 была меньше чем M, то в некоторых случаях в первом аргументе pow получалось число меньше нуля. Квадратный корень из отрицательного числа — штука загадочная, по крайней мере для стандарта GLSL. Мою видеокарту ничего не смутило, и она как-то выпуталась из этого положения (похоже, вернув из pow 0), а вот у друга она оказалась более разборчивой.

И тут я задумался: а могу ли я избежать таких проблем в будущем? От ошибок никто не застрахован, особенно таких, которые не воспроизводятся локально. Юнит-тесты на GLSL не напишешь. В то же время преобразования внутри шейдера довольно простые — умножения, деления, синусы, косинусы… Неужели нельзя отследить значения каждой переменной и убедиться, что ни при каких условиях не происходит выхода за допустимые границы значений?

Так я решил попробовать сделать статический анализ для GLSL. Что из этого получилось — можно прочитать под катом.

Сразу предупрежу: какого-то законченного продукта получить не удалось, только учебный прототип.

Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.

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

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

Введение

Задача:

Введение

Что же такое «игровой ИИ»?

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

Введение

Cytomegalovirus (CMV)

Небольшое объяснение

Потребность делать железо периодически возникает у многих технарей. Иногда задача позволяет нафигачить всё проводами на макетке, а иногда, к сожалению, нужно нечто посерьёзнее. Вот и меня однажды настигла потребность делать печатные платы… Лазерно-утюжная технология кустарного изготовления плат по началу сильно отталкивает своей рандомностью (на чём печатать, как греть, с какой силой давить, как отдирать, и т.д.), но друзья поделились опытом, и оказалось, что это действительно не так уж сложно. ЛУТ бесспорно дешевле любого другого варианта, и (внезапно) вполне подходит для двухслойных плат.

Кому интересно посложнее, подороже и поточнее, можно делать фоторезистом, но наша методика (основным элементом которой является особая бумага) позволяет стабильно прорабатывать шины 0.3/0.3 мм, так что в нашем сообществе бытует мнение что тян фоторезисты не нужны.

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

Под катом я поделюсь детерминированной методикой изготовления двухслойных печатных плат по технологии ЛУТ с различными резервными схемами на случай косяков. От идеи до включения. Будем работать с KiCad, Inkscape, наждачкой, утюгом, персульфатом аммония и гравёром.

Приветствую всех и особенно тех кто интересуется задачами дискретной математики и теорией графов.

Предыстория

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