Первоначально python как язык с динамической типизацией не предполагал никакого явного описания типов используемых объектов и список возможных действий с объектом определялся в момент его инициализации (или изменения значения). С одной стороны это удобно для разработчика, поскольку не нужно беспокоиться о корректности определения типов (но в то же время осложняло работу IDE, поскольку механизмы автодополнения требовали анализа типа выражения в ближайшей инициализации). Но это также приводило к появлению странных ошибок (особенно при использовании глобальных переменных, что само по себе уже плохое решение) и стало особенно неприятным при появлении необходимости контроля типа значений в коллекциях и созданию функций с обобщенными типами. В Python 3.12 будет реализована поддержка нового синтаксиса для generic-типов (PEP 695) и в этой статье мы обсудим основные идеи этого подхода.

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

Для обнаружения аномально высокой длительности выполнения отдельных функций (а также избыточного выделения или утечек памяти) используются инструменты профилирования над виртуальной машиной (например, JProfiler или Visual VM для JVM) или интегрированные в выполняемый код, например встроенный механизм при компиляции Go-приложений. Альтернативой может стать использование универсальных механизмов профилирования, которые интегрируются со средой выполнения и отправляют результаты профилирования на сервер, который может анализировать аномальное поведение и визуализировать выделение памяти и время выполнения отдельных функций (и построить flame graph по результатам анализа приложения во время выполнения). В этой статье мы рассмотрим использование Pyroscope совместно с Go для обнаружения утечек памяти.

В этой статье Мудассар Хан (Mudassar Khan) продемонстрирует нам, как реализовать проверку Google reCAPTCHA V2 (версии 2.0) в ASP.Net Core MVC. 

Приведенный в этой статье пример демонстрирует, как Google reCAPTCHA V2 проверяет ответы с капчей от пользователей, получаемые из коллбэк-функций в JavaScript.

Глубокое обучение (Deep learning. DL) - это современное решение многих проблем машинного обучения, таких как компьютерное зрение или недостатки естественного языка, и превосходит альтернативные методы. Последние тенденции включают применение методов DL в рекомендательных системах. Многие крупные компании, такие как AirBnB, Facebook, Google, Home Depot, LinkedIn и Pinterest, делятся своим опытом использования DL для рекомендательных систем.

Недавно NVIDIA и команда RAPIDS.AI выиграли три соревнования с использованием DL: ACM RecSys2021 Challenge, SIGIR eCom Data Challenge и ACM WSDM2021 Booking.com Challenge.

Область рекомендательных систем сложна. В этом посте я сосредоточусь на архитектуре нейронной сети и ее компонентах, таких как эмбеддинг и полностью связанные слои, рекуррентные ячейки нейронной сети (LSTM или GRU) и блоки трансформеров. Я расскажу о популярных сетевых архитектурах, таких как Wide и Deep от Google и Deep Learning Recommender Model (DLRM) от Facebook.

Статья о том, как превратить конструкцию Figma в рабочий набор элементов управления без какого-либо кодирования.

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

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

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

В Unreal Engine 5, Блюпринты являются одним из основных инструментов для создания игровой логики без необходимости писать код на C++. Блюпринты позволяют разработчикам создавать, настраивать и контролировать многие аспекты игровых объектов и окружающей среды. Однако, чтобы полностью раскрыть потенциал блюпринтов, необходимо понять, как они могут взаимодействовать друг с другом.

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

Мы в Debricked уже достаточно давно используем Symfony на нашем веб-сервере. За все это время он очень хорошо послужил нам, и когда разработчики Symfony анонсировали компонент Messenger в Symfony 4.1, мы уже с нетерпением ждали, когда сможем опробовать его. С тех пор мы использовали этот компонент для отправки электронных писем в асинхронную очередь.

Однако недавно у нас возникла необходимость вынести обработку событий GitHub, которые мы получаем из нашей интеграции с GitHub, из нашего веб-сервера в отдельный микросервис (чтобы повысить производительность). Мы решили прибегнуть к паттерну производитель/потребитель (producer/consumer), который предоставляет компонент Messenger, поскольку он позволит нам асинхронно отправлять различные события в очередь, а затем немедленно подтверждать их прием в GitHub.

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

Качество рекомендательной системы часто измеряется с помощью экспериментов A/B-тестирования. Однако A/B-тестирование традиционно используется для измерения коэффициентов конверсии в статичных вариантах пользовательского интерфейса (например, синяя ссылка в сравнении с зеленой). Именно это натолкнуло меня на мысль об исследовании многоруких бандитов в качестве альтернативы A/B-тестированию в области рекомендательных систем.

Для начала мы рассмотрим классический мысленный эксперимент "многорукий бандит". Затем последует дискуссия о контекстном многоруком бандите с помощью формального определения и примера. Наконец, мы проведем сравнение традиционных экспериментов A/B-тестирования с многоруким бандитом.

В технических стартапах маркетинговые усилия на ранних этапах в основном направлены на взаимодействие с разработчиками — и это зависит от создателей. Для технических стартапов маркетинговые усилия на ранних этапах часто неотличимы от взаимодействия с разработчиками (DevRel). И именно создатели отвечают за это. Так что же такое DevRel и с чего начать?

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

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

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

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

Анализ выживаемости (Survival Analysis) - это статистический метод исследования времени, которое проходит до наступления события, такого как конец, разрушение или отказ. Он также называется анализом времени до события или анализом времени жизни. 

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

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

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

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

Сегодня я беру интервью у Майка Трахирна (Mike Trahearn), старшего инженера-программиста и чемпиона Qt 2022, живущего на светлом и солнечном Золотом побережье Квинсленда, Австралия.

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

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

В предыдущей статье, посвященной WAF мы рассмотрели отличия межсетевого экрана уровня приложений от средств обнаружения вторжений. Однако, на этом список новомодных сетевых средств защиты не исчерпывается.  В этой статье мы поговорим о межсетевых экранах нового поколения Next Generation Firewall, NGFW. Обычно NGFW называют межсетевой экран для глубокой фильтрации трафика, интегрированный с IDS/IPS и обладающий возможностью контролировать и блокировать трафик на уровне приложений. Под такое, достаточно емкое определение подпадает целый ряд решений, обладающих различным функционалом.

Поэтому предлагаю для начала разобрать по порядку, от каких угроз и каким образом NGFW и песочницы защищают сеть.