«Цель этой книги — разобраться в разуме психопата и написать руководство для всех людей.»

Как распознать психопата

• У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
• В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.

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

На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

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

В большинстве случаев вся enterprise разработка сводится к выполнению одних и тех же требований: создается заявка, в зависимости от типа заявки у нее есть какой-то жизненный цикл, по завершению жизни заявки мы получаем (…или не получаем) желаемое. Под заявкой мы можем подразумевать все что угодно, начиная с покупки в интернет-магазине товара, денежного перевода или расчета траектории баллистической ракеты. У каждой заявки есть свой жизненный путь и что важно отметить - время жизни, и чем меньше это время, тем лучше. Иными словами, чем быстрее мой банковский перевод осуществится, тем лучше. Требования тоже схожи, побольше RPC operations per second, поменьше Latency, система должна быть отказоустойчивой, масштабируемой и должна быть готова вчера. Есть миллион инструментов, сотни баз данных, различные подходы и паттерны. И все уже давно написано, нам остается лишь правильно использовать готовые технологии в наших проектах. 

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

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

О чём, зачем и почему?

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

Здесь я расскажу, как развернуть сервисы для контроля финансов (FireFly3), заметок и чего покрупнее (BookStack) и контроля времени, уходящего на задачи в opensource проектах или на работе (Titra) — всё это на Vultr с защитой с помощью firewall групп и доступа только с нужных ip, например, домашней статики или vpn (ещё развернём для этого Pritunl).

Vultr я выбрал, так как достаточно давно с ним работаю и уже знаю, что он может, а что нет — в моём случае он подошёл идеально.

Надеюсь, что это окажется для кого-то полезным.

[...] Не надо размышлять, почему здесь нет оператора if. Важно посмотреть на задачу с другой стороны и переписать её так, чтобы особый случай исчез и стал обычным случаем, и это хороший код. — Л. Торвальдс

В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления. 

Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью. 

В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур. 

Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.

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

Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.