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

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

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

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

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

Добрый день/вечер/ночь/утро! Есть один экспериментальный курс по операционным системам. Есть он в Стэнфордском университете. Но часть материалов доступно всем желающим. Помимо слайдов доступны полные описания практических занятий.

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

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

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

Это перевод статьи профессора Бертрана Мейера из блога Communications of the ACM.

Статья относительно недавняя (по сравнению с предыдущим переводом).

Кроме того, что Бертран Мейер известен большинству специалистов как создатель языка программирования Eiffel и идей контрактного программирования (design by contract), он является почетным доктором и заведующим кафедрой ИТМО, преподает в университете Иннополис. И прекрасно владеет русским языком. ;)

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

Но так было в давние времена. За некоторыми исключениями, одно из которых будет упомянуто ниже, если кто и продолжает изучать методологии программирования, занимается он этим уже в мире agile, там, где решающие доводы часто начинаются с фразы «Я всегда говорю…» (Пример со страницы консультанта: «я всегда говорю команде: ‘Мне хотелось бы, чтобы [пользовательские] истории были небольшими, умещались в одну итерацию, однако такой путь не всегда приемлем»). Дейкстра, бывало, апеллировал к интуиции, однако подтверждал ее строгими концептуальными доказательствами.

При поиске этого словосочетания англоязычный Гугл выдает 104 000 000 результатов. По статистике, боязнь публичных выступлений входит в топ-5 человеческих страхов. Каждый выступавший признается в интервью, что хотя бы раз испытывал страх перед выступлением.

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

В сентябре 2016 года мы стали замечать случайно происходящие ошибки при сборке Хрома — 3 билда из 200 провалились из-за крэша процесса protoc.exe. Это один из бинарников, который при сборке Хрома сначала собирается сам, а затем запускается для генерации заголовочных файлов других компонентов. Но вместо этого он падал с ошибкой «access violation».

Это вторая часть статьи про искусственный интеллект Total War. В первой части статьи я рассказал об игре Creative Assembly 2000 года Shogun: Total War — игре, изменившей лик стратегий реального времени. В Shogun существует три отдельных слоя систем ИИ: ИИ юнитов, управляющий отдельными отрядами и сохраняющий их построение и расположение, боевой ИИ, группирующий и задающий построения юнитов, а также ИИ кампании/дипломатии, ведущий пошаговую стратегию и стремящийся к захвату контроля над феодальной Японией. Я закончил первую часть на Medieval: Total War 2002 года: игре, переопределившей и улучшившей фундаментальные системы, созданные Shogun. Но она стала только самым началом длинного пути улучшеий и перестройки систем ИИ франшизы, как со стороны Creative Assembly, так и руками фанатов Total War. Поэтому давайте рассмотрим следующие релизы серии и понаблюдаем за тем, как происходила эволюция войны.

Об авторе. Алекс Ирпан — разработчик из группы Brain Robotics в Google, до этого работал в лаборатории Berkeley Artificial Intelligence Research (BAIR).

Здесь в основном цитируются статьи из Беркли, Google Brain, DeepMind и OpenAI за последние несколько лет, потому что их работы наиболее заметны с моей точки зрения. Почти наверняка я что-то упустил из более старой литературы и от других организаций, так что прошу прощения — я всего лишь один человек, в конце концов.

Введение

Однажды в Facebook я заявил следующее.

Когда кто-то спрашивает, может ли обучение с подкреплением (RL) решить их проблему, я сразу отвечаю, что не может. Думаю, что это верно как минимум в 70% случаев.

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

К сожалению, в реальности эта штука пока не работает.

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

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

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

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

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

В конце 2016 года была опубликована аналогичная статья. С тех пор список был обновлен на основе наблюдений и анализа нескольких ресурсов (постов в популярных блогах, обсуждений на Quora, поисковых запросов в Google и обсуждений на форумах, таких как reddit/learnprogramming и Hacker News).

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

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

Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

Представляем вам перевод статьи человека, который несколько лет воровал имена пользователей, пароли и номера кредитных карт с различных сайтов.

То, о чём я хочу рассказать, было на самом деле. Или, может быть, моя история лишь основана на реальных событиях. А возможно всё это — выдумка.

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

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

Математика — это «язык, который ни читать, ни понять невозможно без инициации» (Эдвард Ротштейн, «Эмблемы ума»)

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

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

В типичной реализации генетический алгоритм оперирует параметрами какой-то сложной функции (диофантовые уравнения в статье "Генетический алгоритм. Просто о сложном" mrk-andreev) или алгоритма ("Эволюция гоночных автомобилей на JavaScript" ilya42). Количество параметров неизменно, операции над ними тоже изменить невозможно, как генетика не старается, потому что они заданы нами.

Хьюстон, у нас проблема

Сложилась странная ситуация — прежде чем применять генетические алгоритмы (ГА) к реальной задаче, мы сначала должны найти алгоритм, которым эта задача в принципе решается, и только потом его попытаться оптимизировать с помощью генетического алгоритма. Если мы ошиблись с выбором «основного» алгоритма, то генетика не найдет оптимум и не скажет, в чем ошибка.

Часто, а в последнее время и модно, вместо детерминированного алгоритма использовать нейронную сеть. Тут у нас тоже открывается широчайший выбор (FNN, CNN, RNN, LTSM, ...), но проблема остается той же — выбрать нужно правильно. Согласно Википедии "Выбирать тип сети следует, исходя из постановки задачи и имеющихся данных для обучения".

А что, если...? Если заставить ГА не оптимизировать параметры, а создавать другой алгоритм, наиболее подходящий для данной задачи. Вот этим я и занимался ради интереса.

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


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

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

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

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

Привет! В этой статье я хотела бы рассказать вам о своем участии в соревновании по написанию игровых ботов Russian AI Cup CodeWars, на котором мне удалось занять 2 место, и что и как для этого было сделано.

Из всех моих разговоров с коллегами о разных аспектах разработки программного обеспечения одна тема всплывает чаще других. Да что там «чаще» — она повторяется снова и снова, как заезженная пластинка — это беседы на тему того, чем плох GitFlow и почему его стоит избегать.

Статья "Удачная модель ветвления для Git" описывающая метод, получивший в последствии название «GitFlow» стала де-факто стандартом того, как нужно начинать использовать Git в вашем проекте. Если поискать в Google что-то типа "git branching strategy" то вот как раз этот метод будет описан по первой ссылке (а скорее всего и по нескольким следующим).

Лично я ненавижу GitFlow и за последние годы убедил много команд разработчиков перестать его использовать, чем, как мне кажется, сохранил им уйму времени и нервов. GitFlow заставляет команды организовывать управление изменениями кода хуже, чем оно может быть реализовано. Но поскольку это такой популярный метод (по крайней мере в результатах поисковика), то команды без достаточного опыта, которые ищут «что-то, хотя бы как-то работающее» находят именно его при быстром поиске, да ещё и видят слово «успешный» прямо в заголовке статьи с его описанием — ну и начинают бездумно использовать. Я хочу хотя бы немного изменить этот паттерн поведения, описав в этой статье более простую и не менее успешную стратегию использования веток Git, которую я внедрил во многих командах. Часто эти команды пробовали использовать GitFlow, но испытывали проблемы, которые, пропали с переходом на ThreeFlow.

Я называю эту стратегию ThreeFlow потому, что в ней есть ровно три ветки. Не четыре. Не две. Три.