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

В перерывах между полетами на реактивном ранце и переводами материалов Y Combinator, я делаю проект «Ontol» — такое место в сети, где максимальная концентрация полезного, апгрейдящего мировоззрение материала (ценного на горизонте 10+ лет, например, такого), которым можно делиться бесплатно в 1 клик. (канал в телеграм: t.me/ontol)

Вот мои предыдущие бесплатные образовательные подборки:

• 75 лекций на русском от Y Combinator (из 172)
• Подборка 143 переводов эссе Пола Грэма (из 184)
• Все статьи Тима Урбана (Wait But Why) на русском [46 из 99]
• 450 бесплатных курсов от Лиги Плюща
• Онтол от DeepMind: самые полезные материалы по искусственному интеллекту от мирового лидера
• Лучшее в мире видео-объяснение нейронных сетей, глубокого обучения, градиентного спуска и обратного распространения
• 70 офигенных видеокурсов от мировых звёзд

Хотите разобраться в компьютерной или мобильной криминалистике? Научиться реагированию на инциденты? Реверсу вредоносных программ? Проактивному поиску угроз (Threat Hunting)? Киберразведке? Подготовиться к собеседованию? В этой статье Игорь Михайлов, специалист Лаборатории компьютерной криминалистики Group-IB, собрал топ-11 книг по компьютерной криминалистике, расследованию инцидентов и реверсу вредоносных программ, которые помогут изучить опыт профессионалов, прокачать свои скиллы, получить более высокую должность или новую высокооплачиваемую работу.

Доброго времени суток, Хабр!

В этой статье я бы хотел поговорить с вами о недавно вышедшем Unreal Engine 4, который на данный момент набирает все большую популярность среди разработчиков игр. И хотя статья о UE4, однако она совсем не про игростой, хоть и связана с ним.



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

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

Основные задачи художников визуальных эффектов

Если говорить только о визуальных эффектах, то их можно разделить на два основных типа задач: геймплейные эффекты и природные эффекты (или эффекты окружений). Принцип их разделения зависит от конкретного проекта. Например в такой игре, как Castlevania (жанра hack'n'slash), 90% визуальных эффектов состояло в умениях персонажа и магии, сильно влиявших на геймплей. Такие задачи требуют серьёзного понимания механик игры и постоянного общения с командой дизайнеров, с которой нужно постоянно договариваться. Для примера давайте возьмём огнемёт. Дизайнеры геймплея подбирают область урона атаки, а затем вам необходимо создать эффект поверх отладочного цилиндра. Постепенно уменьшающийся огонь не полностью соответствует области урона, и дизайнеры начинают на это жаловаться. Вот один из примеров «конфликтов» между двумя дисциплинами, потому что если придерживаться строгих правил, огонь не будет похож на огонь. Поэтому приходится искать альтернативы и убеждать дизайнеров, что игрок не заметит, что небольшой исчезающий огонь не нанёс никакого урона.

Среди прочих жанров, геймплейные эффекты более «важны» в файтингах и RPG.

Существуют и другие игровые жанры, например, шутеры (в особенности это касается реалистичных), в которых природные эффекты так же важны, как и геймплейные. В этом случае художник, ответственный за природные эффекты, становится практически художником по окружениям и в основном сотрудничает с этой командой. Примерами природных эффектов являются водопады, туман, дождь и т.д. Больше всего природных эффектов я создал в Gears of War 4, где мы работали над многопользовательскими картами и должны были заботиться о влиянии эффектов на производительность, потому что от игры требовалось работать в 1080p при 60 fps.

Светлана Шаповалова, редактор «Нетологии», перевела статью Тайлера МакГинниса, в которой он перечислил основные моменты озарения, которые возникают при изучении React.



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

Продолжение этой статьи об очень простом алгоритме генерации прямоугольных лабиринтов. В этой статье я приведу мою реализацию алгоритма на С++, а также покажу несколько дополнительных функций, которые породил мой скучающий мозг. Если осмелитесь продолжить читать, убедитесь, что ознакомились с моей предыдущей статьей. Глянули? Молодцы, продолжаем.

Good news everyone!
Futurama

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

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

В начале марта в американском городе Кона завершилась встреча международной рабочей группы WG21 по стандартизации C++ в которой участвовали сотрудники Яндекса.

Заседания, как обычно, занимали целый день плюс дополнительно заседала подгруппа по работе с числами.

Основное время было посвящено полировке черновика C++17, но несколько небольших и интересных нововведений все же успели проскочить в C++17.

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

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

JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.

От переводчика: не торопитесь, прочитав заголовок, бурчать что-то вроде «Спасибо, капитан», и скроллить дальше. Название статьи не совсем отражает её содержание, сама она несколько о другом: о творческом процессе и возможности выразить себя в создании нового. Ну и немного об одиночестве, конечно.

По какому-то безумному совпадению, которое я никогда не пойму, моя игра Pinstripe (над ней я работаю уже почти 4 года) была показана на церемонии Game Awards 2015. Было чрезвычайно странно наблюдать, как Марк Хэмилл и Кифер Сазерленд обсуждают игры, в то время как моё лицо крупным планом показывают на всех проекторах. Я очень доволен, не поймите неправильно, но я также хочу быть откровенным: это стало первым за четыре года реальным подтверждением того, что да, работа над проектом в одиночку стоила того. Кроме ощущения счастья и возможности рассказать свою историю «одинокого волка» тысячам людей в Лос-Анджелесе, есть ещё несколько преимуществ работы в одиночку.

Ни для кого уже не секрет, что Flash Player 11 имеет поддержку GPU ускорения графики. Новая версия вводит Molehill API, позволяя работать с видеокартой на достаточно низком уровне, что с одной стороны даёт полную волю фантазии, с другой требует более глубокого понимания принципов работы современной 3D графики.

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Постановка задачи

Цель этого цикла статей — показать, как работает OpenGL, написав его (сильно упрощённый!) клон самостоятельно. На удивление часто сталкиваюсь с людьми, которые не могут преодолеть первоначальный барьер обучения OpenGL/DirectX. Таким образом, я подготовил краткий цикл из шести лекций, после которого мои студенты выдают неплохие рендеры.

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



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

Это первая часть истории о том, как маленькая команда веб-разработчиков разработала мультиплеерный 3d-шутер без опыта в геймдеве, больших денег и штата сотрудников.

Дисклеймер: некоторые описанные в статье решения могут вызывать фейспалм.

2011 год. С чего все началось

В 2011 году мы были маленькой питерской веб-студией из 4 человек. Тимлид/сеошник, программист (вернее считал себя программистом), дизайнер и менеджер по продажам. На тот момент тимлид и программист занимались сайтами уже 3 года, но особых успехов на этом поприще не достигли. Хотя мы имели уже несколько постоянных клиентов на продвижении и обслуживании, но львиную долю дохода съедали налоги, аренда офиса и прочие расходы. Оставшихся копеек на четырех человек явно не хватало. Хроническое безденежье и отсутствие перспектив угнетали. Дизайнер уже навострил лыжи, да и остальные члены команды едва держались. Вот в такой обстановке и пришла в голову потрясающая по наивности мысль: «чего это мы все для всяких дядь делаем проекты, а давайте свое что-нибудь сделаем, например, игру браузерную и запилим её во вконтакте». Все, кроме дизайнера, восприняли идею с воодушевлением.

Через серию статей попробую разобрать движок на webgl.

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

Первое. Описание задачи на пальцах

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

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Развиваемая в недрах корпорации технология позволит компилировать код на C, C++, Java, Python, и Ruby в ActionScript. Это позволит интегрировать в свои разработки компоненты, написанные на других языках.

Например, альтернативный PDF-renderer может быть кросс-компилирован таким образом, что Flash Player сможет использовать его для отображения PDF. В настоящий момент разработчики должны писать всё на самом ActionScript.

from Ajaxian.com

Даже и не знаю в какой блог поместить…

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

Собссно вот и вся идейка, как всегда окажется, что не новая.

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

P.P.S. Кстати мысль пошла дальше, можно сделать капчу на флеше. Например пустить волной (анимация) нормально написанные цифры…

Технология Flash оставила свой след в истории сети Интернет и стандартах дизайна всего за несколько лет, но столь серьезные вещи появляются не каждый день. И так: откуда же появился Flash? Что лежало в его основе? Данная статья отвечает на эти и многие другие вопросы.

JavaScipt RIA приложения проигрывают по своим мультимедийным возможностям приложениями созданным с помощью Flash или Java. Например, в AJAX приложениях не существует простого способа интегрировать Видео или Аудио, так же реализация элементов управления, уступает по своей зрелищности. Несмотря на это AJAX имеет свои преимущества, которые несомненно делают его конкурентно способным. Поэтому прежде чем начать разработку с помощью той или иной технологии проведите короткий анализ того, что Вам нужно получить в итоге.
Далее приводится несколько фактов которые необходимо учитывать:

1. Размер приложения.
В данном случае явное приемущество у AJAX приложений. За красоту необходимо платить! Цена — это десятки лишних килобайтов. На медленных каналах подобная роскошь доступна не всем. Прежде чем делать выбор, решите на каких каналах будут работать Ваши клиенты.

2. Надежность разработчика используемых технологий
Несмотря на то, что мы живем в мире где авторские права ничего не стоят, подобная ситуация может измениться очень быстро. Достаточно вспомнить последнии радикальные действия в отношении пользователей нелегальной копии Windows. Напомню, что XMLHttpRequest — это API, который тоже принадлежит компании Майкрософт. С другой стороны у Flash-а, тоже есть правообладатель — Macromedia. Кому Вы больше доверяете с тем и работайте!

3. Интеграция с потоковым видео или аудио.
Если Ваше приложение будет работать с мультимедиа, то, по сути, выбора у Вас не остается. На данный момент приемлемых решений под JavaScript я не знаю (буду рад если в комментариях оставите ссылки на интересные мультимедийные AJAX приложения, использующие потоковое аудио и видео).

4. Есть ли квалифицированные разработчики для Вашего проекта.
Очень трудно найти разработчиков работающих только на JavaScript, обычно JavaScript — это дополнения к какому то серверному языку. А вот разработчиков на Java или Flash имеющих дело только с этими технологиями гораздо больше. Даже не знаю, что выгоднее. Ведь скорее всего Вашему проекту понадобится не только клиентская сторона, но и серверная!

5. Проблемы совместимости
Возможно, этот пункт было необходимо поставить на первое место. В случае JavaScript поддержка в различных браузерах одного и того же приложения, может превратиться в сущий ад! В случае Flash-а, все гораздо проще, существует плеер, который одинаково хорошо работает во всех браузерах (даже проблема с Linux-ом отпала с выходом Flash Player 9.0 под эту платформу). Правда чтобы работать с Flash-ем, нужна среда разработки, а с JavaScript можно работать даже в блокноте.

6. Наличие GUI библиотек
На самом деле, данный факт на данный момент не имеет решающего значения, хороших бесплатных, библиотек очень много! Под любую из платформ! Главно найти себе по душе.

7. Поддержка браузером.
Огромным плюсом при использовании JavaScript является то, что он поддерживается в каждом из современных браузеров, а вот для Flash придется ставить Player!

И все же, что выбрать? Flash или JavaScript? Для себя я выбрал JavaScript, по одной очень важной причине, которую коротко можно сформулировать так — DOM. Только не надо закидывать меня камнями и говорить, что во Flash тоже есть объектная модель документа.
Для меня важно управлять именно HTML документом! И иметь возможность легко встроить свой код в любую страницу. Открытость! Вот, что важно.

codeart.ru