Когда мы говорим о команде, мы говорим об объединении людей, и, чаще всего с лидом во главе. Но, возникает вопрос, а что же в голове у лида? И тут я предлагаю вам обратиться к докладу Жени Кузовлева с TeamLead 2024, где он провел исследование среди более чем 100 лидов, чтобы понять, а что из себя представляет этот мир!

И оказалось, что мир состоит из ловушек и блокеров — искажений восприятия реальности нашим мозгом! Это не что-то страшное или редкое, с этим сталкивается каждый из нас!

Есть три ключевых ловушки:
1️⃣ Ретроспективное искажение — мы уверены, что прошлый успех гарантирует будущее.
2️⃣ Самобичевание — внутренний критик, который мешает двигаться дальше.
3️⃣ Расхождение ожиданий — недопонимание того, куда бежим и зачем.

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

Эти внутренние блокеры и ловушки — часть нашего мышления, нашего отношения к себе и к окружающим. Они заставляют нас застревать, сомневаться, тянуть с решениями или бежать не в ту сторону.

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

Год назад мне пришлось взять на себя курс лекций по теории компиляторов. Вы встречались некомпетентными преподавателями? Это я, здравствуйте! Прежде чем учить других, я всё-таки решил заглянуть в учебник сам, и это вылилось в серию статей "компилятор за выходные" (да, я помню, что за мной должок с описанием лексера/парсера). В итоге я уложил компилятор со мной придуманного си-подобного языка на GNU ассемблер в шестьсот строк кода, причём без внешних зависимостей, включая парсинг.

Всё бы хорошо, вроде работает, но кажется, самое веселье осталось за бортом. Мой компилятор, по факту, это простой pretty print вокруг синтаксического дерева, подумаешь. А как работают оптимизирующие компиляторы? И поставил я себе задачу попробовать уложить игрушечный, но всё же рабочий оптимизирующий компилятор в тысячу строк кода. Как думаете, получится?

Итак, тема сегодняшнего разговора - вынос переменных из памяти в регистры, оно же оптимизационный проход mem2reg, см. кпдв.

В этой статье будет показан пример создания небольшого многопользовательского чата с помощью сокетов. Для его реализации вам понадобиться Java и Maven.

Да будет Хабр снова торт! Да приидут на него статьи о программировании! И да пребудут на нем всегда технические обсуждения. А теперь к делу... Каждый развивающийся программист, рано или поздно сталкивается с тем, что ему нужна облачная база данных для своего проекта. Между тем, ваш проект может быть не денег ради, а души для, друзей, знакомых, небольшой аудитории, и посему платить деньги за настоящее облачное хранилище данных жалко. Предлагаю вам простое в подключении, проверенное мной лично, хакерское решение, в котором не потребуется указывать никаких платежных или личных данных...

Аудитории Хабра наверняка интересно, какие вопросы задают на техинтервью в мультинациональных корпорациях. Ведь ИТ-индустрия была и остается глобальной, несмотря на геополитику и разные другие сложности. Как минимум, такая информация об интервью «из первых рук» — это ориентир по уровню сложности собеседования на позицию Java Lead в любых других компаниях, включая крупные российские банковские и промышленные структуры. Именно поэтому эта статья в нашем блоге SSP SOFT.

В СМИ много говорят о том, что разработчики ПО скоро потеряют работу из-за ИИ. Я в это не верю.

Это не конец программирования. Это конец программирования в том виде, в котором мы его знаем сегодня.

Во время разработки ПО мы сталкиваемся с выбором между удобством языка и его производительностью. 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.