Привет, Хабр! Мы — Рома, Настя и Карина — бэкенд-разработчики Тинькофф, пишем код на Scala и горим желанием его популяризировать.
Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Свою мотивацию мы черпаем из желания развиваться и делиться полученными знаниями. Приветствуем любую обратную связь! (づ ◕‿◕ )づ
WebGPU — это мощный GPU-API для веба, поддерживает продвинутые рендеринговые конвейеры и вычислительные конвейеры GPU. WebGPU ключевым образом отличается от WebGL своей поддержкой вычислительных шейдеров и буферов хранения данных. В WebGL такие возможности отсутствуют, а WebGPU, в свою очередь, позволяет целиком выполнять в браузере мощные приложения, требующие вычислений на GPU. Речь может идти о самых разных приложениях, от GPGPU (напр., симуляции, обработка/анализ данных, машинное обучение, т.д.) до конвейеров рендеринга на основе GPU-вычислений — а также о многих других приложениях в этом спектре.
В этой статье мы оценим вычислительную мощность WebGPU, сравнив её с показателями Vulkan. Для этого мы реализуем классический алгоритм «марширующие кубы» (Marching Cubes) для WebGPU. Алгоритм марширующих кубов почти без оговорок относится к чрезвычайно параллельным, в составе этого алгоритма выполняется два глобальных шага редукции, необходимых для синхронизации местоположений рабочих элементов и вывода потоков. Поэтому данное решение — отличный вариант GPU-параллельного алгоритма, который стоит первым делом попробовать на новой платформе. Дело в том, что он достаточно сложен, чтобы API испытал давление сразу по нескольким направлениям сверх элементарных параллельных операций диспетчеризации в ядре. При этом он не столь сложен, чтобы на его реализацию требовалось существенное время, а также он не превращается в узкое место из-за ограничения производительности ЦП.
В этой статье, я хочу показать базовые приемы работы с HTML-таблицами при использовании библиотеки Symbiote.js и раскрыть на практике некоторые ее важные особенности.
На самом деле это нужно было сделать давно. Вот ровно тогда, когда вы поняли, что будете работать с базой данных. Сейчас, конечно, внедрить уже сложнее, чем на старте, но ещё не поздно.
Сегодня я буду навязывать своё субъективное, однобокое, единственно правильное мнение, зачем вам ORM.
Кто я такой, чтобы делиться своими суждениями и утверждениями? Мне почти 47, в сфере IT профессионально работаю около 25 лет, начав самообучение со школы, с папиного i386 с сопроцессором и модемного dial-up на зюхелях (ну... все же помнят.. да? ну да же? :-) Естественно, среди моего опыта и высшее образование, и технические сертификаты, и работа во множестве компаний самого разного масштаба и разных стран. Сейчас я обладаю как негативным, так и позитивным опытом в различных аспектах IT технологий, попробовав себя как в софте, так и в железе.
Этот опыт заставляет меня поделиться информацией из той самой негативной составляющей с целью предотвращения его повторения читателями. И да, тут будет много злобы и яда к тому дерьму тем технологиям, с которым приходится работать каждый день DevOps и даже системным администраторам. Однако статья наполнена реализмом, а вовсе не пессимизмом! :-D В ней будет раскрыта вся голая правда про лично Ваше будущее как DevOps инженера!
Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».
Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.
Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.
Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.
Привет, Хабр!
Axum была создана командой Tokio, которая уже получила свой +rep за создание асинхронной платформы Tokio для Rust.
Axum является микрофреймворком, ориентированным на упрощение задач, связанных с маршрутизацией и обработкой запросов в веб-приложениях.
Основная фича Axum заключается в его возможности обрабатывать тысячи запросов без значительных затрат на ресурсы.
Всем привет!
Хотел логически подвести к этому абзацу в конце предыстории, но побоялся, что не все до туда дочитают, т.к. статья техническая и душная.
ДИСКЛЕЙМЕР: это не бескорыстный акт передачи знаний с моей стороны. Я пытаюсь найти инвестиции для своего проекта и создал чат в тг, где буду постить обновления и какие-то мысли касательно его запуска. Так что если интересно, то подписывайтесь, а еще можете поделиться ссылкой с теми, у кого есть лишние бабки =)
Предыстория
Значит решил я создать сервис для одиноких мужчин, где они могут пообщаться с прекрасными дамами, aka вебкам. Соответственно встал вопрос, как организовать видеосвязь в браузере. Обычно для этого используется WebRTC, эта технология позволяет установить p2p соединение между браузерами для передачи видео, звука и прочих данных в реальном времени с минимальной задержкой. Однако была одна проблема: что делать, если приходит жалоба от пользователя, что ему показали не то (или не показали), что он хотел. Поскольку это p2p соединение напрямую между пользователями, у меня как у владельца сервиса нет возможности провалидировать жалобу. Первое, что пришло в голову это вместо WebRTC использовать MediaRecorder API для записи видео небольшими кусочками и отправки их по вебсокету через сервер, попутно сохраняя. Я набросал прототип и столкнулся с тем, что если получатель пропустил первый пакет (там где есть метаданные), то видео у него не воспроизводится. Пришлось поиском определенного набора байт в первом пакете вычленять эти самые метаданные и сохранять их отдельно для отправки первым сообщением только что подключившемуся получателю, и это даже сработало. Вторая проблема этого решения - это задержка в пару секунд, и это только в локальной сети, что приемлемо для односторонней связи, но для двусторонней уже сомнительно. И третья проблема это то что видео у получателя со временем все больше и больше отстает, и нужно регулярно проматывать видео ближе к концу. Костыльность такого решения меня не устраивала, и я решил использовать WebRTC для связи собеседников и параллельно использовать MediaRecorder для отправки записи от модели к серверу. Некоторое время оно так работало, пока я пилил другие фичи, но неэлегантность этого решения все еще не давала мне покоя, т. к. оно повышает требования к интернет соединению модели.
В этой статье мы рассмотрим процесс создания умной светодиодной системы под названием Smart LED. Этот проект основан на микроконтроллере ESP8266 и адресной светодиодной ленте.
Система Smart LED позволит вам не только наслаждаться красивой подсветкой, но и синхронизировать её с музыкой. Вы также сможете управлять системой с помощью голосового ассистента Алиса.
Проект на GitHub
Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.
Вот уже несколько месяцев я интересуюсь двумя технологиями: языком программирования Zig и криптовалютой Ethereum. Чтобы подробнее изучить обе, я написал на Zig интерпретатор байт-кода для виртуальной машины Ethereum.
Язык Zig отлично подходит для оптимизации производительности, а также предоставляет детализированный контроль над памятью и потоком операций. Чтобы было ещё интереснее, я проставил контрольные точки, по которым сравнил мою реализацию Ethereum с официальной реализацией на Go.
Я поработал в 3 известных IT-школах в разных ролях. При этом я не смог бы однозначно ответить – стоит работать в этой сфере или нет. Все зависит от роли: где-то я выгорел, а где-то достиг дзена. В этой статье хочу поделиться с вами своим опытом – в какой роли лучше работать, сколько можно на этом заработать и вообще стоит ли оно того
Привет, Хабр!
Мультиколлинеарность возникает, когда в модели множественной регрессии одна из независимых переменных может быть линейно предсказана с помощью других независимых переменных с высокой степенью точности. Это явление приводит к тому, что расчетные коэффициенты регрессии становятся нестабильными и их значения могут сильно изменяться в зависимости от включения или исключения других переменных в модель.
Высокая мультиколлинеарность может привести к значительному изменению коэффициентов при незначительных изменениях в данных или спецификации модели. Это усложняет интерпретацию коэффициентов, поскольку они могут значительно изменяться от одного анализа к другому.
Когда переменные сильно коррелированы, стандартные ошибки оценок коэффициентов увеличиваются. Это ведет к увеличению p-значений, что может ошибочно привести к заключению о том, что переменные не имеют значимого влияния на зависимую переменную, хотя на самом деле это не так.
В статье рассмотрим как обнаружить и устранить мультиколлинеарность с помощью Statsmodels в Питоне.
Все сталкиваются с индексами на самых ранних стадиях освоения языка, как правило, при изучении списков. Вероятно, вы и так знаете, что индексация в Python начинается с нуля. У нас есть список movies, тогда операция movies[0] вернёт первый элемент списка.
Для новичков считать от нуля до девяти при работе со списком из десяти элементов поначалу кажется немного странным. Python в этом не уникален — в большинстве языков программирования реализован такой же подход (C, C++, Java, C# и JavaScript).
Стоит обсудить не то, чем индексация в Python похожа на другие языки, а чем от них отличается.
Обрезка нейросетей или же, если вникать в термины, pruning — то, что помогает уменьшить размер нашей модели без потери ее эффективности. Да, это далеко не новинка — в стэнфордских лекциях еще в 2017 году об этом говорили!
Идея проста: мы просто убираем из модели все, что нам не нужно. Как в магазине, когда решил экономить: если в корзине лежат лишние товары, то почему бы их не убрать? Так и здесь — мы убираем избыточные нейроны и связи, которые только занимают место, но не приносят особой пользы.
Принцип обрезки можно применять в разных ситуациях. Например, если у нас есть модель, которая обучена для распознавания ста классов объектов, а нам на самом деле нужно только десять, то почему бы не убрать те девяносто лишних? Это позволит нам сделать модель поменьше, но не менее эффективной. А если мы создаем модель с нуля, то обрезка может помочь нам сразу сделать ее компактнее и эффективнее.
Короче, pruning — это для тех, кто хочет сделать свои модели легче и быстрее без потери качества.
Обратная польская нотация, что ты такое и как с тобой работать? Или как вывести производную сложной функции.
Постановка задачи: получать данные о заказах из базы данных 1С: Предприятие в формате JSON для отображения на сайте. Запросы должны обрабатываться максимально быстро, по возможности, не мешать работе локальных пользователей.
Задача, конечно, надуманная, но хорошо отражает целый класс задач из реального мира – обслуживание большого количества мелких запросов на чтение данных...
Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.
Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?
Привет, Хабр!
Identity Map — это паттерн проектирования, предназначенный для управления доступом к объектам, которые загружаются из базы данных. Основная его задача — обеспечить, чтобы каждый объект был загружен только один раз, что предотвращает излишние запросы к базе данных и повышает производительность приложения.
Identity Map можно реализовать в Golang и с помощью него можно управлять объектами более эффективней, сокращая задержки и нагрузку на сервера БД.
