Предисловие

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

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

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

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

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

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

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

Речь пойдет о прогнозировании движения цен на рынке акций. Идея проста: "те, кто осуществляет очень крупные сделки на покупку/продажу — ошибаются значительно реже. Почему бы нам не отслеживать и анализировать такие сделки ?". Именно поэтому, я свой рабочий прототип назвал «Прилипалой», вспоминая уроки биологии, где нам рассказывали про рыбу-прилипалу.

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

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

20 лет назад, в 1999 году, компания Kyocera выпустила первый мобильный телефон с цифровой камерой – Visual Phone VP-210. С тех пор, благодаря невероятно большому и растущему рынку мобильных устройств связи, ПЗС-матрицы цифровых камер совершили невероятный скачок по всем параметрам. Чувствительность, диапазон, размер, энергопотребление, но что ещё важнее – цена.

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

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

Хотите научиться добавлять в свою 3D-игру текстуры, освещение, тени, карты нормалей, светящиеся объекты, ambient occlusion и другие эффекты? Отлично! В этой статье представлен набор техник затенения, способных поднять уровень графики вашей игры на новые высоты. Я объясняю каждую технику таким образом, чтобы вы могли применить/портировать эту информацию в любом стеке инструментов, будь то Godot, Unity или что-то иное.

В качестве «клея» между шейдерами я решил использовать великолепный игровой движок Panda3D и OpenGL Shading Language (GLSL). Если вы пользуетесь таким же стеком, то получите дополнительное преимущество — узнаете, как использовать техники затенения конкретно в Panda3D и OpenGL.

Для удаленной работы есть миллион причин. Торчать по 8-9 часов в офисе вовсе не так здорово, как это показано в сериалах. В один прекрасный день, летом 2018-го, я просто решила, что мне нужно больше личного пространства и собралась увольняться, тем более на моей должности в то время я доросла до максимума и дальнейших перспектив не предвиделось.



Моя работа была чем-то средним между саппортом, тестировщиком, оператором SQL и Excel-ниндзя, а хотелось углубиться в тестирование.

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

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

Автор материала, перевод которого мы публикуем, недавно выпустил своё первое мобильное приложение, написанное на React Native. Так случилось, что это приложение стало и его первым проектом, который он создал как программист-фрилансер. Здесь он расскажет о том, с чем ему пришлось столкнуться в ходе работы — от инициализации проекта до его публикации в App Store и Google Play.

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

(ИЛИ каламбур типизации, неопределенное поведение и выравнивание, о мой Бог!)

Друзья, до запуска нового потока по курсу «Разработчик С++», остается совсем немного времени. Пришло время опубликовать перевод второй части материала, в которой рассказывается о том, что такое каламбур типизации.

Что такое каламбур типизации?

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



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

Представьте себе задачу: у вас есть игра, и вам нужно, чтобы она работала с частотой 60 fps на 60-герцовом мониторе. Ваш компьютер достаточно быстр для того, чтобы рендеринг и обновление занимали несущественное количество времени, поэтому вы включаете vsync и пишете такой игровой цикл:

while(running) {
    update();
    render();
    display();
}

Очень просто! Теперь игра работает с 60fps и всё идёт как по маслу. Готово. Спасибо, что прочитали этот пост.


Ну ладно, очевидно, что всё не так хорошо. Что если у кого-то слабый компьютер, который не может рендерить игру с достаточной для обеспечения 60fps скоростью? Что если кто-то купил один из тех крутых новых 144-герцовых мониторов? Что если он отключил в настройках драйвера vsync?

Новый год для игровых разработчиков начался с волны критики, обрушившейся в адрес комитета по стандартизации C++ после публикации Араса Пранкевичуса «Жалобы по поводу современного C++». Возник серьезный вопрос: действительно ли комитет стандартов потерял связь с реальностью, или все наоборот, и это игровые разработчики откололись от остального С++ сообщества?

Вашему вниманию предлагается перевод популярного поста Бена Дина, — ветерана игровой индустрии, проработавшего продолжительный срок в компаниях Blizzard, Electronic Arts и Bullfrog в качестве разработчика на C++ и тимлида, — в котором он отвечает на критику с позиции собственного опыта.

TL;DR: Комитет по стандартизации C++ не имеет скрытой цели игнорировать нужды игровых разработчиков, а «современный» C++ не собирается становиться «неотлаживаемым» языком.

На протяжении всей прошлой недели в Twitter шла активная дискуссия, в ходе которой многие программисты – особенно те из них, кто работает в сфере игровой разработки – высказались о том, что нынешний вектор развития «современного C++» не отвечает их потребностям. В частности, с позиции обычного игрового разработчика, все выглядит так, будто производительность отладки в языке игнорируется, а оптимизация кода становится ожидаемой и необходимой.

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

Для начала — небольшой экскурс в историю.

Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.

Пост возбудил мой интерес не потому, что я большой фанат Rust или WASM, скорее потому что я всегда интересовался фичами языков и оптимизациями, которых не хватает Javascript для того чтобы достичь аналогичной производительности.

Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.

«Он снова это сделал!», — вот, что первое пришло мне в голову, когда я посмотрел на оборотную сторону флаера Pixar ^[1], полностью заполненную кодом. Скопление конструкций и выражений была подписана в правом нижнем углу не кем иным, как Эндрю Кенслером. Для тех, кто его не знает, скажу: Эндрю — это программист, придумавший в 2009 году 1337-байтный трассировщик лучей размером с визитку.

На этот раз Эндрю придумал нечто более объёмное, но с гораздо более интересным визуальным результатом. Так как я закончил писать свои Game Engine Black Books про Wolf3D и DOOM, у меня появилось время на изучение внутренностей его загадочного кода. И почти сразу меня буквально очаровали обнаруженные в нём техники. Они сильно отличались от предыдущей работы Эндрю, основанной на «стандартном» трассировщике лучей. Мне было интересно узнать о ray marching, функциях конструктивной объемной геометрии, рендеринге Монте-Карло/трассировкой пути, а также множестве других трюков, которые он использовал, чтобы ужать код в такой небольшой кусок бумаги.

В темные века верстальщики строили сайты на таблицах. Потом они освоили float и flexbox, и тьма отступила. В 2017-м наступила эпоха Просвещения с приходом CSS Grid Layout.

Grid учитывает горизонтальное и вертикальное пространство, с ним можно менять раскладку, не трогая разметку, и все это без медиазапросов. С Grid можно забыть про магические числа, хаки, обходные пути и CSS-фреймворки.



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

Об этом расшифровка доклада Сергея Попова на Frontend Conf: про спецификацию, про то, почему верстальщики боятся Grid и как решиться применять сетку в своих проектах, чтобы «Make your website great again!».

Давно хотелось составить список навыков и инструментов, которыми, по моему мнению, должны входить в «джентльменский набор» любого программиста под Unreal Engine 4. Буквально на днях, в чатике по UE4 я встретил такое:

> blueprints, animation dev, tech art, ai, multiplayer, editor extensions. первое, что пришло в голову

> Что приходит на ум: blueprints, animations, AI, material editor, widgets, slate, editor extensions, ue4 plugins, physics, lighting, rendering, c++
+ Сколько времени работал(а) с движком и страна, всё :)

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

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

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

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

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

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

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

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

Сегодня мы представляем вашему вниманию перевод материала, в котором рассмотрены опенсорсные JavaScript-библиотеки для визуализации данных.

В этом туториале по Unreal Engine 4 вы научитесь рисовать цветами по мешу любого типа.

Рисование по мешу позволяет игрокам раскрашивать внутриигровые объекты. Примеры рисования по мешу: граффити (goop) в Super Mario Sunshine, гели в Portal 2 и чернила в Splatoon. Рисование может использоваться как геймплейний элемент или быть просто графическим оформлением. Как бы то ни было, рисование по мешу открывает новые возможности для дизайнеров геймплея и художников.

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

В этом туториале вы узнаете, как рисовать на скелетном меше. Для этого мы сделаем следующе:

• Развернём меш в его UV-форму
• Используем точку пересечения трассировки линии для создания сферической маски меша
• Отрендерим развёрнутый меш и сферическую маску в render target с помощью захвата сцены (scene capture)
• Используем маску для смешивания текстур в материале персонажа

Учтите, что этот туториал не посвящён рисованию вершин. Рисование вершин зависит от разрешения меша и его невозможно изменять в процессе игры. Используемый в этом туториале метод, напротив, работает вне зависимости от разрешения меша и его можно применять во время игры.