Не секрет, что при формировании новой команды руководители (Team Leader, Tech Leader) сталкиваются с проблемой формирования единого стиля написания программ, так как все члены команды новые, и у каждого из них свой подход к организации кода и выбору используемой практики. Как правило, в большинстве случаев это приводит к длинным диспутам на ревью, которые в итоге перетекают в различные толкования известных практик, таких как SOLID, KISS, DRY, и т.д. Принципы использования этих практик довольно размыты и, при должном упорстве, легко найти парадокс, когда одна из них противоречит другой. Например, рассмотрим Single Responsibility и DRY.

Одна из вариаций определения принципа единой ответственности (Single Responsibility - буква S из аббревиатуры SOLID) гласит, что каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью инкапсулирована в класс. Принцип DRY (Don’t repeat yourself) предлагает избегать дублирования в коде. Однако, если у нас в коде есть один набор данных (DTO), который может использоваться в разных слоях/сервисах/модулях, какому из этих принципов нам следовать? Безусловно, во многих книгах по программированию разбираются похожие ситуации, как правило, в них говорится, что если речь идет о разных объектах/функциях с одинаковым набором свойств и логики, но принадлежащим разным доменным областям, то дублированием это не является. Но как доказать что эти объекты ДОЛЖНЫ принадлежать разным доменным областям, и, главное, готов (и уверен ли в своих силах) руководитель доказывать это утверждение?

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

Рассказываю, какие ошибки при работе с API допускают не только новички, но и профессионалы, и как сделать, чтобы эти ошибки возникали как можно реже или не появлялись вовсе.

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

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

Рано или поздно каждый продуктовый дизайнер сталкивается с вопросом: нужно ли ему уметь программировать? Есть краткий ответ: дизайнеру не обязательно уметь программировать, но давайте копнём глубже.

Под продуктовым дизайнером в статье имеется в виду дизайнер цифровых продуктов, UI/UX-дизайнер, и остальные подходящие названия, которые сейчас в ходу на рынке.

Обзорная статья о QPR Enterprise Architect. Основные возможности и преимущества данного инструмента.

Привет, дорогие пользователи мира IT!

В эпоху активного развития веб-технологий и интерактивных приложений, 3D-графика становится всё более актуальной и востребованной. Но как создать 3D-приложение, не теряя преимуществ веб-разработки? В этой статье мы рассмотрим, как сочетать мощь Three.js с гибкостью React, чтобы создать собственную игру прямо в браузере.

В статье вы познакомитесь с библиотекой React Three Fiber и научитесь создавать интерактивные 3D-игры.

Всем привет! Недавно я на практике применил одно интересное решение, которое давно хотел попробовать, и теперь готов рассказать, как своими руками такое можно сделать для любой другой аналогичной задачи. Речь пойдет о создании своей кастомизированной версии ChatGPT, которая отвечает на вопросы, учитывая большую базу знаний, которая по длине не ограничивается размером промта (то есть вы бы не смогли просто добавить всю информацию перед каждым вопросом к ChatGPT). Для этого будем использовать контекстные эмбеддинги от OpenAI (для действительно качественного поиска релеватных вопросов из базы знаний) и сам СhatGPT API (для оборачивания ответов в натуральный человеческие ответы). При этом, также предполагается, что ассистент может отвечать не только на прямо указанные в Q&A вопросы, но и на такие вопросы, на которые смог бы отвечать человек, который ознакомился с Q&A. Кому интересно научиться делать простых ботов, отвечающих по большой базе знаний, добро пожаловать под кат.

Let’s imagine you need access to the real-time data of some smart contracts on Ethereum (or Polygon, BSC, etc.) like Uniswap or even PEPE coin to analyze its data using the standard data scientist/analyst tools: Python, Pandas, Matplotlib, etc. In this tutorial, I’ll show you more sophisticated data access tools that are more like a surgical scalpel (The Graph subgraphs) than a well-known Swiss knife (RPC node access) or hammer (ready-to-use APIs). I hope my metaphors don’t scare you ?.

Всем привет! В предыдущих статьях (1 и 2) я рассказывал про концепцию индексирования данных смарт-контрактов на блокчейне в общем и в частности через средства The Graph, а также про то, как использовать готовые "сабграфы" на The Graph Hosted Service, чтобы, не написав ни строки кода, делать к ним GraphQL запросы и получать данные популярных децентрализованных приложений. Однако, если вы присматриваетесь к Web3 разработке, то вероятно вам и самим придется разрабатывать такие сабграфы для своего приложения. Эту тему (разработка собственных сабграфов стандарта The Graph) я бы и хотел осветить в данном материале. Чтобы пример был не сферический и в вакууме, будем рассматривать существующий смарт-контракт проекта TornadoCash.

Привет, хабр! Все знают, что Android использует ядро Linux. В этой статье мы разберёмся как современные (12+) версии Android позволяют Google обновить ядро Linux без участия вендора устройства, и как при помощи этого же механизма Google может обновить ядро с Linux на Fuchsia.

Picture this: A thriving e-commerce platform faces a constant battle against fake reviews that skew product ratings and mislead customers. In response, the company employs cutting-edge algorithms to detect and prevent fraudulent activities. Solutions like these are crucial in the modern digital landscape, safeguarding businesses from financial losses and ensuring a seamless consumer experience.

The industry has relied on rules-based systems to detect fraud for decades. They remain a vital tool in scenarios where continuous collecting of a training sample is challenging, as retraining methods and metrics can be difficult. However, machine learning outperforms rules-based systems in detecting and identifying attacks when an ongoing training sample is available.

With advancements in machine learning, fraud detection systems have become more efficient, accurate, and adaptable. In this article, I will review several ML methods for preventing fraudulent activities and discuss their weaknesses and advantages.

Всем привет! Представим, что вам нужен доступ к данным каких-либо смарт-контрактов на Ethereum (или Polygon, BSC и т.д.), например, Uniswap, SushiSwap, AAVE (или даже PEPE-coin) в реальном времени, чтобы анализировать их с помощью стандартных инструментов дата-аналитиков: Python, Pandas, Matplotlib и т.д. В этом туториале я покажу инструменты для доступа к данным на блокчейне, которые больше похожи на хирургический скальпель (сабграфы The Graph), чем на швейцарский нож (доступ к RPC ноде) или, скажем, молоток (готовые API от компаний-разработчиков). Надеюсь, мои неумелые метафоры вас не пугают. Кому интересно научиться, добро пожаловать под кат.