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

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.

— Привет! Мы решили нанять тебе помощника на текущий проект, нашли подходящего кандидата. Кстати, он выходит в понедельник.
— Эммм, окей.

Диагональный буфер — это часть решения по управлению проектами в Теории Ограничений Голдратта (ТОС). Это только часть решения, части проблем. Решения не бывают хорошими или плохими вне контекста. В предыдущей заметке я описала проблему, которую решает диагональный буфер, время прочтения — 4 минуты. Посыл — срок задачи в проекте не работает как хотелось бы.

Решение ТОС для проектного управления называется метод Критической цепи. Отличается от метода Критического пути тем, что мы уходим от срока задачи.

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

Пишем подробный план

Мы начинаем с того, что строим обычную диаграмму Ганта. Выписываем задачи и распределяем их в порядке выполнения. Чем подробнее будет ваш план, тем лучше. Что такое подробный план? Если, например, нам нужно написать ТЗ, то нельзя отделаться одной задачей: «Написать ТЗ«. И даже если вы добавите «Согласовать ТЗ», этого тоже будет недостаточно. Подробный: написать ТЗ, показать, доработать, показать, доработать и т. д. Чем лучше такой план? Тем что задача «написать ТЗ» будет оценена мной в 2 недели. А набор из 6 мелких задач будет оценён мной в 3.5 дня. Это не значит, что я оставлю себе на это 3.5 дня, но это значит, что дальнейшие мои расчёты будут реалистичнее.

В какой-то степени, данная статья является дополнением идей, описанных в цикле "Что в голове у программиста?", а также раскрывает инструмент "выбивания почвы из-под ног", который использовали сотрудник ТяньШи из статьи про секты . Но сегодня хочется поговорить про поддержку и ответить на вопрос - а почему иногда от нашей поддержки (логичной, верной, адекватной, статистически безупречной) нашему собеседнику становится только хуже?

Слишком абстрактно, да? Наверное, вы правы, поэтому задам еще один вопрос и попрошу вас быть честными с собой, звучит он так: Как часто вы поддерживаете своих близких, которым плохо, фразами, вроде "Стоит ли из-за этой фигни переживать?", "Ты уже завтра об этом не вспомнишь!" и, моё любимое, "Да у тебя еще миллион таких будет!". Если вы узнали себя или вам просто интересно, как можно "убить поддержкой", то эта статья будет вам полезна.

Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.

Итак, четыре проблемы начинающего тимлида.

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

Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ). 

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

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

Давайте посмотрим, на что она способна.

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

Приветствую!

В этой статье рассмотрим какой путь проходит простой SELECT запрос. От стадии сырой строки до отправки ответа клиенту.

А еще:

• Работу со статистикой приложения через API Linux.

• Реализацию динамического списка.

• «Наследование» в C.

• Как ведется работа с диском в БД.

• Немного легаси.

--- Обновление статьи 9 Августа 2023 ---

В течении последнего полугода в сфере текстовых нейронок всё кипит - после слитой в сеть модели Llama, aka "ChatGPT у себя на пекарне" люди ощутили, что никакой зацензуренный OpenAI по сути им и не нужен, а хорошие по мощности нейронки можно запускать локально.

Основная проблема в том, что всё это требует глубоких технических знаний.

Но в этой статье я расскажу, как запустить добротную нейросеть на домашнем ПК с 16ГБ ОЗУ в несколько кликов. Буквально в несколько кликов - копаться в консоли не придётся.

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

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

Привет, Хабр!

В прошлой статье я рассказывал об ускорении копирования элементов одного слайса в другой с помощью средств Go. В этот раз я решил пойти дальше и посмотреть, что можно достичь, начав разговаривать с процессором на его языке. Я выбрал одну из оптимизированных версий функции Copy в качестве объекта исследования из решения задачи VK Cup'22/23, которая копирует только синий компонент RGBA в Paletted картинку. Если интересно узнать как её ускорить почти в 10 раз, прошу под кат.

В этой статье мы разберём несколько аномальных случаев высокой нагрузки в СУБД PostgreSQL. Что это такое? Обычно PostgreSQL хорошо показывает себя под нагрузкой и оправдывает ожидания в отношении производительности — она остаётся высокой. Но при определённых профилях нагрузки СУБД может вести себя не так, как мы ожидаем. Это и есть аномалии, на которых мы сосредоточимся в данной статье (для тех, кто предпочитает видео, эта информация доступна в виде записи доклада на HighLoad++).

Наша компания помогает обслуживать мультитерабайтные базы данных в крупных проектах, поэтому мой рассказ об аномалиях основан на реальном опыте промышленной эксплуатации СУБД в Postgres Professional — порой мы сталкиваемся с тем, что СУБД ведёт себя не так, как мы ожидали.

Также в рамках статьи мы рассмотрим следующее:

Добавление дженериков (generics) в Go (ранее Golang) — самое значительное изменение, которое он претерпел, с момента его релиза. Сообщество Go просило добавить дженерики с самых первых дней языка, и мы, наконец, дождались.

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

Я вот именно тот, иногда ненавистный работодатель, в сфере ИТ. У нас компания разработчиков ~25 человек, кто-то уехал в Европу после начала СВО, но весь костяк команды в Питере. Мне 49, а ребятам в массе своей до 25 — студенты, учатся (магистратура, бакалавриат). Расскажу свой свежий опыт найма, а уж там дальше выводы делайте сами… Пишу по итогу справедливых опасений "взрослею и боюсь что будет дальше, найду ли работу?".