Безопасность во многих компаниях стоит особняком. Вместо того чтобы беспокоиться о качестве вашего продукта, безопасники твердят о ГОСТах и ISO, о разных сертификациях и авторизационных протоколах — вещах важных, но вне фокуса основного архитектора. При этом их деятельность «подрывает» производительность, debugability, да вообще все.



Однако есть способы сделать безопасность своим союзником на пути к качеству. В этой статье — о дихотомии разработки и безопасности. О том, что, вообще говоря, миры информационной безопасности и архитектуры ИТ-систем не столь далеки друг от друга, как может показаться. И что на самом деле практики безопасности пересекаются с практиками повышения качества кодовой базы, а ПО можно сделать безопасным без потери качества. Поскольку я сама довольно долго занималась системной разработкой, после чего ушла в безопасность и сейчас работаю в команде собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS, то отлично знаю, что хотела бы услышать еще тогда, когда ИБ была для меня другой стороной :)

Тимлид — это, как известно, глава команды, то есть руководитель подразделения. У успешного тимлида есть специфические компетенции, повышенные хард-скилы и множественные софт-скилы. Однако нужно ли, имея весь этот позитивный багаж, идти на роль тимлида? И можно ли со всеми этими качествами нанести пользу компании и себе, не занимая позиции тимлида?



‎Я расскажу, зачем не быть тимлидом, обладая при этом всеми необходимыми компетенциями. Расскажу о методе двух императоров, чтобы описать модель, когда в команде помимо настоящего тимлида есть «как бы» тимлид, человек с тимлидскими навыками. А также, поскольку тимлид не бывает бывшим, отдельно пройдусь по особенностям найма экс-тимлидов на синьорные позиции.

Переход к микросервисной архитектуре требует пересмотра подхода к разработке, тестированию, сопровождению, проектированию – иными словами, ко всем аспектам жизненного цикла программных компонентов. В этом посте мы расскажем о практиках, к которым пришла команда архитекторов Acronis на пути к лучшим API компонентов. Рассказ будет включать как постановку задачи, так и анализ ее решений. Возможно, кому-то этот пост покажется “капитанским”, кому-то будет неясно почему упустили супер-решение Х, но надеемся, что вам он будет интересен и полезен. Строителей микросервисов приглашаем под кат – почитать и оставить свои комментарии.

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

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

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