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

На работе я занимаюсь созданием PCIExpress устройств на ПЛИС. Некоторые из ПЛИС имеют встроенное PCIExpress ядро, позволяющее работать с этим интерфейсом на уровне пользовательского приложения. ПЛИС серии ECP5UM фирмы Lattice использует Soft-IP Core для реализации протокола, написанный на языке HDL, а в микросхему лишь встроен блок, отвечающий за работу физического уровня. Мне пришла в голову идея попробовать сделать PCIExpress анализатор на базе этой микросхемы.

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

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

Привет! Я Виталий, ведущий 2D-художник, аниматор и специалист по эффектам в мобильной tower-defence игре Rush Royale студии IT Territory. Сегодня я расскажу об одной довольно важной части нашего проекта — эмодзи. Именно благодаря ним игроки могут выразить эмоции в жарких боях за башни — что, на наш взгляд, очень немаловажно.

Чтобы достичь текущего качества эмодзи, мы проделали большой путь. Но обо всем по порядку.

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".

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

Что делать в такой ситуации?

Менять провайдера? Искать специалиста телефонии? Или есть более консервативные варианты решения?

Подробности под капотом.

Давно хотела порассуждать на тему нездорового культа «Токсичной эффективности», который часто становится причиной выгорания. Не единственной, но связь не заметить невозможно. 

Токсичная эффективность — нездоровое, извращённое понимание эффективности. Формализованное, бюрократизированное и антигуманное.

Рассуждаю на тему, откуда оно взялось, и что с этим делать.

Интересно было вбросить повод для дискуссии и, в идеале, получить обратную связь:

- кто сталкивался?

- как боролся?

- как вам видится будущее корпоративных культур и трудовых экосистем?

Информация, полезная интернет-маркетологам, контент-маркетологам, стартаперам и просто деловым людям, запускающим бизнес проекты.

Коммуникация правит миром. Взаимодействие необходимо и между людьми, и между программным обеспечением. Хотите адекватного ответа на ваш запрос к приложению?  API вам в помощь! Необходимость в реализации API возникает практически во всех проектах, и со временем мы задумываемся, можно ли улучшить текущий API? Последовательность конкретных шагов и реальные примеры – наш рецепт создания рабочего API-проекта.

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

Стивен Джонсон (Steven Johnson) — известный американский ученый и писатель, автор двенадцати книг о взаимодействии науки, техники и человеческого опыта, в том числе, бестселлера «Нет худа без добра: как современная массовая культура делает нас умнее».

Последние десять лет Джонсон изучает историю инноваций. Результаты его исследований и легли в основу бестселлера «Откуда берутся хорошие идеи». Стивен создал несколько сайтов, в том числе, «Магазин исчезнувшей еды», Plastic.com.

Напомню предысторию. Меня зовут Алексей Редозубов и я занимаюсь созданием сильного искусственного интеллекта. Мой подход крутится вокруг контекстно-смысловой модели работы мозга. Об этом был цикл статей на хабре и много видео на Youtube. Сейчас я хочу рассказать об основах контекстно-смысловой модели и о недавних исследованиях, которые позволили взглянуть на эту модель с новой, неожиданной стороны. Исследованиях невероятных настолько, что уверен — многие сочтут их безумием.

Есть два интересных и важных термина — “искусственный интеллект” (ИИ) и “сильный искусственный интеллект” (СИИ). В английской традиции Artificial intelligence (AI) и Artificial general intelligence (AGI). Первый подразумевает любую деятельность компьютера, имитирующую человеческий интеллект, второй — только такую, которая претендует на что-то универсально общее, похожее на то, как мыслит человек.

Точного определения СИИ нет. Лучшее, что есть — это знаменитый Тест Тьюринга. 

«Человек взаимодействует с одним компьютером и одним человеком. На основании ответов на вопросы он должен определить, с кем он разговаривает: с человеком или компьютерной программой. Задача компьютерной программы — ввести человека в заблуждение, заставив сделать неверный выбор».

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

Для написания данной статьи был изучен очень большой пласт материала, разбросанного по всему Интернету, по форумам, чатам, сайтам-блогам, stackoverflow. Я собрал все воедино, так как это пригодится и мне и очень надеюсь, что другие разработчики на Django, также, останутся довольны данным материалом. Если есть что добавить (улучшить) или поправить, пожалуйста, пишите в комментариях или в Диалоги ( личные сообщения ) Хабр.

Мы рассмотрим: "Тестирование handler 404" в окружении разработчика, "Формсеты и динамическое добавление форм", а также "Экспорт данных в PDF с поддержкой кириллицы (русских символов / букв)".

Недавно столкнулся с необходимостью написать REST API сервер на Dart. Оставим за рамками этой статьи почему и зачем это было надо, но первое с чем я столкнулся - выбор библиотек. Так уж сложилось, что я привык писать на NodeJS используя KoaJS в качестве веб сервера. Простая и удобная библиотека с кучей расширений для любой необходимости. А вот Dart в этом плане несколько подкачал. На момент поисков из "живых" пакетов на pub.dev был только shelf. Что-то отдаленно похожее, но по факту жутко неудобное. Неделю промучившись с оным, понял, надо писать свое, с блэкджеком... что-нибудь в стиле того же KoaJS.

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

Здравствуйте, коллеги.

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

Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в ~30% всего этого. От позиции middle я бы ожидал примерно ~50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.