Хочу рассказать о своей попытке создать простой однострочный клиент Dropbox под Linux, используя только бесплатные компоненты с открытым исходным кодом, в том числе rclone, entr и systemd.

Контекст

Недавно проприетарный клиент Dropbox под Linux отказался от поддержки всех файловых систем Linux, кроме незашифрованной ext4. А мой домашний каталог, «к сожалению», зашифрован.

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

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

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

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

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

Поиск по документам представляется достаточно просто. Но что делать с поиском по мультимедиа контенту? Для полноценного сервиса пользователя надо обязать заполнить описание, дать название видеоролику или картинке, не помешает несколько тегов. К сожалению, далеко не все хотят тратить время на подобные улучшения контента. Обычно пользователь загружает ссылку на youtube, сообщает что это новое видео и нажимает сохранить. Что же делать сервису с таким “серым” контентом. Первая идея — спросить у YouTube? Но YouTube тоже наполняют пользователи (часто это один и тот же пользователь). Часто видеоматериал может быть и не с Youtube сервиса.
Так мне пришла идея научить наш сервис “слушать” видеоролик и самостоятельно “понимать”, о чем он.

Доброго времени, Хабр-сообщество.

Много лет назад, натолкнулся на пост (1). Тогда меня озадачила возможность создать интересные элементы для геймплея в roguelike (2). Допустим противник может находиться за стеной, мы его не видим, пока мы не столкнёмся с ним в зоне прямой видимости. Но более мне по душе ситуация, когда мы, путешествуя по коридорам подземелья, раскрываем особенности расположения объектов постепенно на основе области видимости.

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

В этой статье мы будем экспериментировать с «настоящей» моделью авиационного двигателя. Обвесив ее «реальными» моделями аппаратуры и алгоритмов управления от атомной станции.

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

Как только модель превратилась из листинга Fortran в структурную схему, с ней стало просто и удобно работать, проводя любые, самые «изощренные» эксперименты. Совершенно не случайно у меня оказались реальные алгоритмы управления АЭС. Что позволило быстро собрать модель для экспериментов, не используя при этом никаких формул, да да, только картинки.

У меня были все преимущества. Я уже был внутри сети. Я был вне подозрений. Но они обнаружили мой взлом, выкинули из сети… и выследили физически.

Для записи трёхмерных поворотов программисты графики используют кватернионы. Однако в кватернионах сложно разобраться, потому что изучают их поверхностно. Мы просто принимаем на веру странные таблицы умножения и другие загадочные определения, и используем их как «чёрные ящики», поворачивающие векторы так, как нам нужно. Почему $$ и $$? Почему мы берём вектор и превращаем его в «мнимый» вектор, чтобы преобразовать его, например $$? Да кому это интересно, если всё работает, правда?

Существует способ описания поворотов под названием ротор, который относится к области и комплексных чисел (в 2D), и кватернионов (в 3D), и даже обобщается до любого количества измерений.

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

Кроме того, для визуализации и понимания трёхмерных роторов не нужно использовать четвёртое пространственное измерение.

Было бы здорово, если бы начали вытеснять использование и изучение кватернионов, заменяя их роторами. Заменить их очень просто, а код останется почти таким же. Всё, что можно делать с кватернионами, например, интерполяцию и устранение блокировки осей (Gimbal lock), можно сделать и с роторами. Но понимать мы начинаем гораздо больше.

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

Это не столько инструкция, сколько объяснение, что должно быть сделано, так как каждое подключение по сути индивидуально. В любом случае необходима консультация с учетом реальной ситуации.

Если вы считаете консистентность важной составляющей качественного кода — эта статья для вас.

Вас ждут:

• Разные способы сделать одно и то же в Go (эквивалентные операции)
• Менее очевидные факторы, влияющие на однородность вашего кода
• Способы увеличения консистентности вашего проекта

Привет!

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

Для разминки — небольшая задачка. Представьте себе беспроводную сеть Wi-Fi, состоящую из точки доступа (AP) и двух одинаковых клиентских устройств (STA1 и STA2).

Читаем надписи на коробках:
AP: 1733,3 Мбит/c
STA1, STA2: 866,7 Мбит/c

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

Привет!

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

Шаг 0. Подготовка

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

Узкая специализация и разработка любителями

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

Давай просто не будем обсуждать эту тему. Полное раскрытие: мне доводилось работать в Google. Это было первое (но, к сожалению, не последнее) место, где я когда-либо использовал Protobuffers. Все проблемы, о которых я хочу поговорить, существуют в кодовой базе Google; это не просто «неправильное использование протобуферов» и тому подобная ерунда.

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

Рано или поздно в организациях возникают проблемы с распространением js модулей между проектами, настало то время когда в нашей компании встал этот вопрос.

Копировать и вставлять код это путь на темную сторону, поэтому было принято решение писать не просто js код, а создавать из него npm пакеты чтобы распространять между своими проектами.

Поиск бесплатных, частных npm репозиториев завел в тупик, а использование частных репозиториев на npm требует платы (а это не наш менталитет).

Поскольку в офисе есть сервер, который работает всегда(почти), было решено развернуть локальный npm.

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



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

Всем привет! Целых 4 года я не писал на Хабр. Последняя моя серия постов была о различных инструментах и приемах, которые мы применяли на нашей прошлой игре (разрабатывая ее на Unity). С тех пор игру ту мы благополучно выпустили, а также выпустили и новую. Так что теперь можно немного выдохнуть и написать несколько новых статей, которые могут быть кому-то полезны.


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

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

Для начала, кратко перечислю из чего собирается картинка в нашей игре:

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



Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

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

В ISPsystem на текущий момент три front-end команды разрабатывают три крупных проекта: ISPmanager для управления веб-серверами, VMmanager для работы с виртуализацией и BILLmanager для автоматизации бизнеса хостеров. Команды работают одновременно, в режиме сжатых сроков, поэтому без оптимизации не обойтись. Чтобы сэкономить время, мы применяем единые решения и выносим общие компоненты в отдельные проекты. Такие проекты имеют собственные репозитории, которые поддерживают участники всех команд. Об устройстве этих репозиториев, а также работе с ними и будет эта статья.

Часть 1. Математика

Введение

Мы так привыкли к взаимодействию с окружающим нас миром, что не задумываемся о том, насколько сложно двигаются наши руки и ноги. В академической литературе задача управления манипулятором робота называется инверсной кинематикой. Кинематика обозначает "движения", а понятие "инверсная" связано с тем, что обычно мы не управляем самой рукой. Мы управляем «двигателями», поворачивающими каждую отдельную часть. Инверсная кинематика — это задача определения того, как перемещать эти двигатели, чтобы сдвинуть руку в конкретную точку. И в своём общем виде эта задача чрезвычайно сложна. Чтобы вы понимали, насколько она сложна, то можете вспомнить о таких играх, как QWOP, GIRP или даже Lunar Lander, в которой вы выбираете не куда двигаться, а какие мускулы (или ускорители) приводить в действие.

Задача управления подвижными приводами распостраняется даже на область робототехники. Вас не должно удивлять то, что на протяжении веков математики и инженеры смогли разработать множество решений. В большинстве 3D-редакторов и игровых движков (в том числе и в Unity) есть наборы инструментов, позволяющих выполнять риггинг человекоподобных и звероподобных существ. Для различных схем (манипуляторов роботов, хвостов, щупалец, крыльев и т.д.) встроенных решений обычно не существует.

Для трассировки лучей (ray tracing) настали удивительные времена. Компания NVIDIA реализует ускоренное с помощью ИИ шумоподавление, Microsoft объявляет о нативной поддержке в DirectX 12, а Питер Ширли продаёт свои книги по свободной цене (pay what you want). Похоже, что трассировка лучей наконец получила шанс быть принятой при дворе. Возможно, говорить о начале революции ещё слишком рано, но уже определённо стоит начать изучать и накапливать знания в этой области.

В этой статье мы напишем с нуля в Unity очень простой трассировщик лучей с помощью compute shaders. Скрипты мы будем писать на C#, а шейдеры — на HLSL. Весь код выложен на Bitbucket.

В результате у нас получится отрендерить нечто подобное:

Почему мы воспринимаем background-color: #9B51E0 как этот конкретный фиолетовый цвет?



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

Инстансинг

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