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

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

В этой статье я хочу рассказать о том, как интегрировать C-расширения с использованием библиотеки Python.h. Я также расскажу как создать свою python-библиотеку с C-расширениями. Также мы исследуем, как устроен Python — например, вспомним, что все является объектами. Я буду использовать poetry как менеджер рабочего окружения.

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

Не буду тянуть, начнем!

Я являюсь действующим PHP middle разработчиком в одной средней компании. Занимаемся разработкой highload микросервисов в B2B сфере. Клиентами являются крупные интернет‑магазины, в 5 странах, которые на слуху у каждого. Суммарно обрабатываем около 50к запросов в секунду, храним миллиарды записей и отвечаем за качество и жизнеспособность около тысячи интернет‑магазинов.

Имею опыт в техническом собеседовании, в том числе и других middle php разработчиков. За свою карьеру провёл пару десятков таких собеседований, по результатам которых было нанято около 5 разработчиков и 2 аутсорс компании.

Делюсь с опытом собеседования на позицию middle php разработчика во «ВКонтакте».

Каждый админ хотя бы раз сталкивался с ситуацией, когда сервер внезапно начинает тупить: подвисают процессы, появляются странные задержки, что-то перестаёт работать. И первая остановка в таком случае — это журналы событий. В Linux системные логи хранятся в systemd-journald, а его главный инструмент для работы — journalctl. Но просто читать логи — это скучно. Разберем, как фильтровать, искать ошибки, анализировать данные и автоматизировать разбор логов с помощью grep, awk, sed и других утилит.

Привет, Хабр! Меня зовут Александр, Системный администратор в компании Барс Груп Сегодня хочу поделиться своим опытом использования новых возможностей Docker Compose, которые значительно упростили мне работу. Эти изменения касаются автоматического обновления контейнеров, работы с профилями, использования GPU, а также улучшенного управления сборкой и секретами. На практике заметил, что эти фичи мало используются, и надеюсь, что после прочтения статьи, вы будете чаще использовать эти фичи в своей повседневной работе. Давайте разбираться!

Друзья! Многие из вас, возможно, как и я, интересовались изучением и использованием в работе очень эффективного и востребованного языка программирования Rust но, как и я, оставляли свои попытки из-за сложности, запутанности и многослойности доступного материала и книг по этой теме.

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

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

Agile — бог управления проектами последних лет. И неужели он умер? Или многочисленные прожект- и продакт-менеджеры убили его? Разбираемся, почему прозрачность Agile зачастую приводит к хаосу и анархии, а не гибкости и высокой ценности продукта. 

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

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

TLDR: видео с результатом в конце статьи

Библиотека browser-use невероятно стрельнула практически в день релиза, на текущий момент это около 16 тысяч звезд на Гитхабе, и сотни восторженных отзывов на Reddit, в Твиттере, и так далее. Команду, создавшую browser-use даже приняли в YC. У неё революционная точность по сравнению с другими "ИИ агентами использующий браузер" (89% против Runner H с 67%).

Я очень удивился, что на Хабре всё ещё нет статьи с описание того, что это, и как это использовать. Сегодня мы это исправим: мы сделаем ИИ, который будет читать статьи на Хабре, и писать комментарии о том, почему продукт, описанный в статье, никому не нужен.

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

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

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

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

Давайте разберем основные аргументы фанатичных сторонников этого бессмысленного действа.

В свое время FastAPI прогремел как гром среди ясного неба - тут тебе и минималистичный API аля-Flask (все устали от Django, диктующего свои правила), и OpenAPI документация из коробки, и удобное тестирование, и хайповая асинхронность. Буквально все, что нужно для свободы творчества, и никаких ограничений! Да еще и Depends завезли! В тот момент это был культрурный шок - Dependency Injection в Python? Разве это не что-то из Java?

Но дьявол кроется в деталях. А вы уверены, что те самые Depends == Dependency Injection? Уверены, что пишете код на FastAPI правильно?

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

Доброго времени суток, хабр! В этой статье мы создадим свой веб-фреймворк на Python с использованием gunicorn.

Он будет легким, иметь базовый функционал. Мы создадим обработчики запросов (views), простую и параметизированную маршрутизацию, Middleware, i18n и l10n, Request/Response, обработку html-шаблонов и генерацию документации.

В этой статьи мы построим наиболее важные части фреймворка, изучим работу WSGI и создание веб-приложений. И также нам будет легче в последующем понимать логику других фреймворков: flask, django.

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

Привет! Меня зовут Максим Соколов, я — аналитик в команде “Управление доступностью товаров и категорий”. В нашей команде была выделена отдельная подгруппа, которая создавалась специально под новый продукт-фичу для селлеров. Сразу стало понятно, что для реализации нового функционала требуется разработка нового микросервиса. Командой разработки было принято решение интегрироваться по gRPC, но мне до конца не было понятно, почему выбор именно такой. И тут я решил разобраться подробнее!

До этого я занимался анализом доработок по уже существующему функционалу, поэтому не задавался вопросом, почему выбран тот или иной путь реализации API. Но здесь-то всё с нуля, а специалисту, который дебютирует в этом выборе, становится ещё трудней.

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

На свете много статей про проектирование API, в которых описаны архитектурные стили, протоколы, технологии. Информации — огромное количество, иногда она даже противоречивая, поэтому новичку тяжело подступиться к теме.

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

Также по ходу статьи буду оставлять ссылки на хорошие (по моему мнению) статьи для более глубокого погружения в поднимаемые темы.

Команда VK Cloud перевела интервью с Эйданом Гомесом, генеральным директором и соучредителем компании Cohere. Cohere — один из самых обсуждаемых стартапов в сфере ИИ на данный момент, но его ориентир чуть отличается от многих других. В отличии, например, от OpenAI, он вовсе не производит потребительские продукты. Вместо этого Cohere сосредотачивается на корпоративном рынке и создает ИИ-продукты для крупных компаний. Из интервью вы узнаете, в чем особенности такого подхода, что ИИ может, а чего не может, и что происходит на корпоративном рынке искусственного интеллекта.