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

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

Я сколько лет на заводе козловой кран вожу, ни разу не выгорел! А эти, прям неженки! 

Знакомо?

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

Ишь какие, депрессия у него! Работать не может! Дури вам в голову напихали, вот и оправдываете свою лень!

За свои скромные семь лет на руководящей позиции мне довелось управлять разными людьми. Был опыт тимлидства над командой разработчиков. Не претендую на истину и уж тем более на какое-то серьезное научное исследование. Но все же хочу систематизировать свои наблюдения и сделать цикл статей «команда глазами начальника».

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.

Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.

Иногда причины депрессии очевидны, а иногда неуловимы. Особенно если все хорошо — работа нравится, личная жизнь тоже, СВО еще не началась, солнышко светит, а на душе тошно. В чем может быть причина? А вот в чем.

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Большинство разработчиков, с которыми мне доводилось общаться, понимают только вторую часть определения. Мол "ну а что тут такого, надо завязывать классы не на конкретную реализацию а на интерфейс". И вроде бы верно, но только кому должен принадлежать интерфейс? Да и почему вообще этот принцип так важен? Давайте разбираться.

Всем привет! Меня зовут Дядиченко Григорий, и я технический продюсер. В своём блоге в телеграм я периодически публикую задачки по Unity. Решение одной задачки получается слишком длинным, чтобы писать про него в блог. Поэтому я решил это оформить в статью. Задачка звучит так.

Вы решили сделать с друзьями свой скайрим. У вас пока в игре есть два вида оружия: молот и меч. Они отличаются уроном, прочностью и скоростью атаки. Плюс логикой атаки. Атака молота аое в круговой зоне. Атака меча бьёт до 3 ближайших противников. К вам пришёл катжит и за лунный сахар предложил купить у него схему архитектуры на картинке выше. Предложите решение лучше. В чём проблема данной схемы?

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

Владельцы компаний часто жалуются на сложности ведения бизнеса: людишки уже не те, кредиты дорогие, страна тоже не та. Так ли это на самом деле? Частично да, но есть и другие нюансы. Главная проблема – совокупность негативных факторов: общество зацементировалось и развивается не потому что, а вопреки.

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

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

Welcome!

Сегодня мы рассмотрим SOA и даже сравним его с Monolith-архитектурой!

Поводом для написания этой статьи послужил случай, когда сотрудники нашего HR-отдела предложили мне взять в нашу проектную группу Департамента разработки программного обеспечения ЛАНИТ на производственную практику выпускника одного из московских техникумов.  Кандидат обучался четвертый год по специальности «Прикладная информатика» и, судя по резюме, претендовал на должность «стажера-разработчика SQL, С#, HTML, CSS». Он уже прошел предварительные собеседования и, по словам наших кадровиков, показал себя наиболее адекватным из 15 других претендентов. Поскольку у меня это был не первый случай руководства практикой у студентов и предыдущие прецеденты имели положительный результат, я согласился.