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

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

Можно, конечно, подучить Java или Kotlin (а заодно и Swift) или, на худой конец, освоить PhoneGap и написать своё приложение. Однако всё гораздо проще: под катом несложное решение этой задачи посредством HTML5 video/audio API.

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

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

Что ж, давайте поднимем наш WebSocket сервер, нам в этом поможет node.js;
Создадим файл sockets.js и запишем туда код сокет сервера:

const WebSocketServer = require('websocket').server;
const http = require('http');

const server = http.createServer(function(request, response) {
 //здесь мы ничего не пишем,потому что мы используем сокеты,а не http
});
server.listen(1337, function() {});

// создаем вебсокет сервер
const wsServer = new WebSocketServer({
  httpServer: server
});

wsServer.on('request', function(request) {
  let connection = request.accept(null, request.origin);
//принимаем подключение к сокету
})

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

У моего ShaderToy были три основные задачи:

1. Выполнение в реальном времени
2. Простота
3. Физическая корректность (… или типа того)

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

1. Трассировка лучей непрозрачных объектов. Все объекты являются примитивами с простыми пересечениями с лучами (1 плоскость и 3 сферы)
2. Для вычисления освещения используется затенение по Фонгу, а в трёх сферических источниках света применется настраиваемый коэффициент затухания света. Лучи теней не требуются, потому что мы освещаем только плоскость.

Вот как это выглядит:

Предисловие

Относительно недавно попалось мне на глаза хоть и студенческое, но все-таки, на мой взгляд, интересное видео из "Курилки Гутенберга" под названием "Психоакустика: звуковые иллюзии". Видео вдохновило меня порыться уже в своих студенческих конспектах и материалах…

Признаюсь честно, я не очень любил предмет Audio Coding, будучи студентом TU Ilmenau на программе Communication and Signal Processing — стресс и юношеский максимализм делали свое темное дело. Однако, со стороны чаще я слышал противоположную точку зрения: "Классный предмет, че ты жалуешься? Один из ваших лекторов — сам Карлхайнц Брандербург — лови момент!"

Один из главных разработчиков формата MP3, если вы не узнали, позирует в наушниках. (источник изображения)

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

И вот однажды мне пришла в голову очередная авантюрная мысль, и я сказал себе: "Почему бы не написать научно-популярную статью про аудиокодинг? Так сказать, "для самых маленьких" — для таких же студентов, коим был и я"?

Сказано — сделано.

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

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

Насколько это соответствует истине?

Доброго времени суток, друзья!

Сравнительно новыми дополнениями JavaScript являются асинхронные функции и ключевое слово await. Эти возможности в основном являются синтаксическим сахаром над обещаниями (промисами), облегчая написание и чтение асинхронного кода. Они делают асинхронный код похожим на синхронный. Данная статья поможет вам разобраться, что к чему.

Условия: базовая компьютерная грамотность, знание основ JS, понимание азов асинхронного кода и обещаний.
Цель: понять, как устроены обещания, и как они используются.

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

В октябре прошлого года я летал в Сибирь на TEDx Novosibirsk и в самолёте внезапно оказался рядом с другим спикером – Павлом Буковым. Он психотерапевт и собирался сделать доклад про профессиональное выгорание: как бы выгорать пореже и не дотла. Я, естественно, вспомнил, как год назад выгорел сам. Заодно вспомнил, сколько людей набивается в зал, когда на технологических конференция докладчик рассказывает про выгорание. В общем, пока мы летели в Сибирь, я записал с Павлом эпизод подкаста про стресс и выгорание и решил собрать из него статью.

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

В статье очень подробно объясняется, как работают Zip-файлы и схема сжатия: LZ77-сжатие, алгоритм Хаффмана, алгоритм Deflate и прочее. Вы узнаете историю развития технологии и посмотрите довольно эффективные примеры реализации, написанные с нуля на С. Исходный код лежит тут: hwzip-1.0.zip.

Доброго времени суток, друзья!

Промисы (обещания) — сравнительно новая особенность JavaScript, которая позволяет откладывать выполнение действия до завершения выполнения предыдущего действия или реагировать на неудачное выполнение действия. Это способствует правильному определению последовательности выполнения асинхронных операций. В данной статье рассматривается, как работают обещания, как они используются в Web API, и как можно написать собственное обещание.

Условия: базовая компьютерная грамотность, знание основ JS.
Задача: понять, что такое обещания и как они используются.

Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки!
Источник: XKCD, лицензия Creative Commons 2.5

Глюк мобильного приложения для подсчёта голосов на прошлой неделе добавил хаоса на Съезде фракций Демократической партии в Айове. Через несколько часов после открытия собраний по всему штату стало ясно: что-то пошло не так. Результаты неизвестны до сих пор. Появились сообщения с описанием технических проблем и недоразумений. Демократическая партия Айовы опубликовала заявление, в котором отрицает слухи о кибератаке, но подтверждает технические проблемы с мобильным приложением.

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

Существует класс приложений реального времени, для которых тяжело предсказать потребности в распределении памяти во время выполнения статически. В этот класс входят, например, встраиваемые реализации стеков некоторых коммуникационных протоколов, где поведение и распределение ресурсов определяется отчасти активностью других агентов в сети. Классический подход в таких случаях заключается в использовании блочных менеджеров памяти, выделяющих фрагменты фиксированного размера (как это сделано, например, в LwIP). Этот подход накладывает нежелательные функциональные и качественные ограничения на реализацию. В этой заметке я предлагаю точку зрения, что традиционные (не блочные) аллокаторы незаслуженно обделены вниманием разработчиков систем реального времени, делюсь соображениями по релевантным вопросам, жалуюсь на жизнь, и предлагаю улучшить положение дел.

(КДПВ – см. аннотацию к диаграмме в конце)

Накануне очередного запуска курса «Алгоритмы для разработчиков» мы провели открытый урок. На нём поговорили об известной идее дерева отрезков, обсудили, как его строить, обновлять и быстро O(log n) вычислять сумму чисел любого отрезка данного массива. Алгоритм очень простой и экономный: нужно O(n) памяти. Для закрепления материала решили олимпиадную задачу.

---

Вебинар провёл опытный программист и преподаватель, а также руководитель курса «Алгоритмы для разработчиков» Евгений Волосатов.

Перед вами обновляемый список самых замечательных «вкусностей» Юникода, а также пакетов и ресурсов

Юникод — это потрясающе! До его появления международная коммуникация была изнурительной: каждый определял свой отдельный расширенный набор символов в верхней половине ASCII (так называемые кодовые страницы). Это порождало конфликты. Просто подумайте, что немцам приходилось договариваться с корейцами, где чья кодовая страница. К счастью, появился Юникод и ввёл общий стандарт. Юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. И современные, и древние, и до сих пор не расшифрованные. Юникод поддерживает текст слева направо и справа налево, наложение символов и включает самые разные культурные, политические, религиозные символы и эмодзи. Юникод потрясающе человечен, а его возможности сильно недооцениваются.

Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?

В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.

А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
[səkˈsɪŋkt]?

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

Или рассмотрим эту статью, которую вы читаете. Вероятно, вы нашли её в социальной сети, скачали из компьютерной сети и в настоящее время расшифровываете смысл с помощью своей нейронной сети.

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

Это наша тема на сегодня: как, насколько хаотично всё движется и распространяется. Некоторые примеры, чтобы подогреть аппетит:

• Инфекционные заболевания, переходящие от носителя к носителю внутри популяции.
  
• Мемы, распространяющиеся по графу фоловеров в социальных сетях.
  
• Лесной пожар.
  
• Идеи и практики, проникающие в культуру.
  
• Каскад нейтронов в обогащённом уране.

Очередная глава из официальной документации Cypress про управление тактированием и сбросом. Как уже упоминалось в первой статье этого цикла, этот модуль обеспечивает выбор и разрешение тактирования, а также выбор сброса внутри UDB. Подробнее — под катом.

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

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

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

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

Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.

Статья поддерживается здесь:
[3] Caterpillar Implementation Based on Generated Code

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

При разработке игр нам часто нужно находить пути из одной точки в другую. Мы не просто стремимся найти кратчайшее расстояние, нам также нужно учесть и длительность движения. Передвигайте звёздочку (начальную точку) и крестик (конечную точку), чтобы увидеть кратчайший путь. [Прим. пер.: в статьях этого автора всегда много интерактивных вставок, рекомендую сходить в оригинал статьи.]


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