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

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

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

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

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


2D Свёрточная нейронная сеть

Ну или почти вся...

Я считаю, что проблема в современном интернете — это переизбыток информации разного качества. Найти материал по интересующей теме не проблема, проблема отличить хороший материал от плохого, если у вас мало опыта в данной области. Я наблюдаю картину, когда очень много обзорной информации "по верхам" (практически на уровне простого перечисления), очень мало углубленных статей и совсем нет переходных статей от простого к сложному. Тем не менее именно знание особенностей того или иного механизма и позволяет нам сделать осознанный выбор при разработке.

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

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии :)

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

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах :)

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall: она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными —

На днях под Linux тихо и почти незаметно вышел новый CAD продукт от компании Bricsys, таким образом Linux пополнился еще одним must-have инструментом для виртуального прототипирования.

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

Дополнено: хорошая дискуссия на Hacker News

Дэвид Ю на GitHub разработал интересный тест производительности для вызовов функций через разные внешние интерфейсы (Foreign Function Interfaces, FFI).

Он создал файл общего объекта (.so) с одной простой функцией C. Затем написал код для многократного вызова этой функции через каждый FFI с измерением времени.

Для C «FFI» он использовал стандартную динамическую компоновку, а не dlopen(). Это различие очень важно, так как действительно сказывается на результатах теста. Можно спорить, насколько честно такое сравнение с фактическим FFI, но всё равно его интересно измерить.

Самый удивительный результат бенчмарка — то, что FFI от LuaJIT существенно быстрее, чем C. Он примерно на 25% быстрее, чем нативный вызов C для функции общего объекта. Как смог слабо и динамически типизированный скриптовый язык обогнать в бенчмарке C? Точен ли результат?

На ныне покойном Geektimes есть (или был) блог Gearbest и он был (или есть) уныл. Их маркетологи зачем-то раз за разом втюхивают одни и те же телефоны и планшеты, тогда как на сайте (впрочем, как и на Ali) есть куча других отличных товаров для гиков. Поэтому, можно я поделюсь своими маленькими китайскими открытиями?



У меня есть дети. Дети = выброшенные батарейки. Т.е. там есть еще промежуточные звенья типа больших роботов, мечей, орущих робокошек, которые катаются по дому и мерцают как мечта эпилептика и так далее. Но все приводит к одному — выброшенным батарейкам.

Благодаря Алексею Надежину мы уже знаем, что лучшими по соотношению цена/емкость являются либо батарейки Ikea и Ашан, либо GP Super. Тем, собственно и жили.
UPD: в комментариях указали, что Алексей провел новое исследование. С учетом обновления цен до текущих, получается, что лучше выглядят батарейки Pairdeer и Lexman из Леруа Мерлен. Ну и опять же Ашан.
Однако, вывалив в специальный контейнер очередную порцию дохлых батареек и испытав на себе полуночный плач ярославны о том, что любимая кукла не работает, пришел к простому выводу — пора переходить на аккумуляторы. Причем, если будут аккумуляторы, неплохо бы их как-то еще и заряжать. Полез гуглить простые зарядки и тут мне открылся “о дивный новый мир”.

Первая часть статьи здесь.

Часть 6. Избегание коллизий

Для правильной навигации NPC часто требуется способность избегать препятствий. В этой части мы рассмотрим steering behavior collision avoidance (избегание коллизий), позволяющее персонажам благополучно уворачиваться от препятствий в окружении.

---

Введение

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

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


Анализируются препятствия перед персонажем и выбирается ближайшее (наиболее угрожающее).

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

Хватит тратить время на скучные академические фолианты! Изучение Computer Science может быть веселым и увлекательным занятием.

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

Привет, хабражители!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…

Поскольку основное предназначение QML — это создание интерфейсов, то в соответствии с шаблоном MVC, на нем реализуются представление и контроль. Для реализации же модели, совершенно логично напрашивается C++. Здесь у нас будет гораздо меньше ограничений и мы сможем реализовать модель любой сложности. Кроме того, если значительная часть программы написана на C++ и данные поступают именно оттуда, то лучше всего там же поместить и модель.

От использования такой модели может отпугнуть кажущаяся сложность реализации. Я не стану спорить с тем, что C++ не самый простой язык. Он посложнее QML и требует больше осторожности, чтобы не выстрелить себе в ногу, это факт. Несмотря на это, на практике не все так уж и страшно.

Во-первых, не будем забывать, что мы пишем не на чистом С++, а с использованием Qt. Такие вещи как parent-child в QObject, implicit sharing для контейнеров, сигналы и слоты, QVariant и многое другое очень сильно упрощают и автоматизируют работу с памятью, чем избавляют разработчика от массы головной боли и повышают надежность. Иногда даже создается впечатление, что пишешь на динамическом языке программирования. Это же сокращает пропасть между QML и C++, делая переход между ними более-менее плавным.

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

В общем, освоить C++-модели очень даже стоит. В особенности это касается QAbstractItemModel, с которой мы и начнем.

Model-View в QML:

• Model-View в QML. Часть нулевая, вводная
• Model-View в QML. Часть первая: Представления на основе готовых компонентов
• Model-View в QML. Часть вторая: Кастомные представления
• Model-View в QML. Часть третья: Модели в QML и JavaScript
• Model-View в QML. Часть четвертая: C++-модели

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

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

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

Так что, если вам интересно, как мы делали сеть для нашей Armored Warfare: Assault, добро пожаловать под кат.

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

• Некоторые делают это для самообучения: берут класс стандартной библиотеки, пишут его сами с нуля, сравнивают то, что получилось, с тем, что есть в стандартной библиотеке — в процессе узнают для себя что-то новое.
  
• Некоторые проекты имеют особое требования к коду. В embedded-разработке принято работать без RTTI и без exception, поэтому части стандартной библиотеки, которые используют RTTI и exception, необходимо переписать без них.
  
• Редко, но бывает, когда велосипед пишут, потому что могут написать лучше, чем в стандартной библиотеке. Как правило, такие нововведения рано или поздно попадают в стандартную библиотеку.
  
• Другим только кажется, что они могут написать лучше, и таких людей больше. Но в процессе они обучаются, выясняют для себя что-то новое и что-то интересное открывают.
  
• Могут быть другие причины.
  

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

• бездумно переносить устаревшие технологии 20-30-летней давности в современные проекты;
  
• пользоваться «вредными» бенчмарками и оптимизациями.
  

А также затронем «вредные» советы, обсудим новейшие практики программирования (C++ 11 и позднее), подумаем, что делать с «идеальным» велосипедом.

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

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

Это все розовый

Я думаю многие сталкивались с ситуацией, девушки пытаются убедить нас, что совершенно очевидно, что цвет ее белья вовсе не черный, а очевидно ониксовый или обсидианово-дымчатый. При том, что там явно #000000ff или максимум #080808d5, если белье слегка прозрачное. Или вдруг та же девушка внезапно решает перекрасить стены и начинает мечтательно описывать всю красоту оттенков, которые она хотела бы получить. И вы погружаетесь вместе с ней в чудесный мир лавандовых стен и пытаетесь определиться со шторами. То ли цвет пенящейся морской волны, то ли кораллово-бирюзовый. Где-то на этом этапе вы начинаете тоскливо смотреть на стену, размышляя о том, какой оттенок придаст ей ваш мозг после хорошего разбега.



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

Добрый день/вечер/ночь/утро! Есть один экспериментальный курс по операционным системам. Есть он в Стэнфордском университете. Но часть материалов доступно всем желающим. Помимо слайдов доступны полные описания практических занятий.

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

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

Предыдущие публикации:

→ Пудра для мозга или как сделать порошок для посудомойки в 9,7 раз дешевле
→ DIY порошок для посудомойки: разбираем промышленные средства и улучшаем рецепт

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

Привет, харб! Примерно год назад я выкладывал статью о том, как я в прямом эфире создал выживалку за 150 часов. На этот раз хочу представить вам сетевой шутер, который я создал за 25 заходов по 3 — 4 часа. Всего вышло около 90 часов и в итоге мы создали онлайн шутер, в который сыграли вместе со зрителями.



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

Несмотря на чистое время, данный проект занял примерно 10 месяцев. Я делал большие перерывы в стримах, но тем не менее, закончил разработку и теперь он доступен всем бесплатно и без смс.
Если вас интересуют подробности, записи стримов, исходники или билд игры с сервером в комплекте, предлагаю прочитать дальше под катом!