ВоITи и выITи

 Это репост моей статьи на Habr: https://habr.com/ru/post/534422/     Картинка взята из Barcelona Supercomputing Center В статье я расскажу, как можно просто, быстро и дёшево собрать свой пакет моделирования задач гидродинамики в облаке. Сделаю я это с помощью комбинации двух инструментов: средства численного моделирования механики сплошных сред OpenFOAM, а также набора инструментов визуализации массивов данных ParaView. Я обычный разработчик, и не являюсь специалистом в данной научной области. С этим видом задач я столкнулся впервые в рамках недавно прошедшего хакатона FIT-M 2020 , где мне посчастливилось поучаствовать в качестве со-организатора и ментора. Опыт мне показался интересным, в частности из-за возможности прикоснуться к области высокопроизводительных вычислений (англ. High Performance Computing), которые часто запускают на суперкомпьютерах . Я разобрался как можно довольно быстро наладить запуск вычислений на сервере в облаке и посмотреть на результат прямо чер

 Это репост моей статьи, опубликованной на TProger: https://tproger.ru/books/obzor-knigi-roberta-martina-chistaja-arhitektura/. Вариант на английском Вариант русского перевода Не секрет, что одним из самых сложных в разработке программного обеспечения, является вопрос « как успешно вести разработку в условиях изменяющихся требований ?» Изменяющиеся требования среди многих разработчиков принято считать чем-то очень плохим и даже в какой-то мере неадекватным. Тот факт, что пожелания клиентов менялись в процессе разработки системы, принято считать основной причиной плохой архитектуры, нестабильного поведения, множества неисправностей и жалоб клиентов, а также снижающаяся с каждым годом скорость разработки, и в то же время всё возрастающая стоимость добавления новой функциональности. Понятие Чистой архитектуры впервые Роберт Мартин (или, дядюшка Боб) опубликовал у себя в блоге ещё в 2012 году. В книге же, он подводит к этому понятию последовательно, в первую очередь развеивая ми

  Image copyright © Max Degtyarev   Эта статья опубликована на habrahabr: https://habr.com/ru/post/530330/ Тема методологий и процессов разработки, как правило, не особо интересна разработчикам. Абсолютно нормально услышать: "Должен быть менеджер, который этим занимается." Как мне кажется, большинство разработчиков попросту не видят достаточно ценности в том, чтобы понимать процессы компании. Однако, по моему опыту, это крайне важный компонент, который позволяет программистам становиться сильнее именно с технической точки зрения, а также двигаться по карьерной лестнице вверх. Эту связь я и попытаюсь показать. Если спросить программиста, то как правило, его будут заботить в основном знание какого-либо языка программирования, платформы, фреймворка, алгоритмов и структур данных, паттернов и принципов проектирования. В мире это принято называть Hard Skills . Что до Soft skills , то, к сожалению, это считается чуть ли не лишним ингредиентом, пустой тратой времени,

  Intro Существует множество подходов написания API документации, и большинство из них автоматизированные: от сбора XML комментариев из кода до создания API из документации с ноля в Swagger или таких инструментах, как Stoplight . Но я бы хотел сделать шаг назад и посмотреть на «картину» в целом, то есть сконцентрироваться не на том КАК мы создаём документацию, а всё-таки ЧТО мы в ней предоставляем. Смотрите шире Последние 8 лет я являюсь разработчиком API и потребителем API одновременно. Мне приходилось реализовывать интеграцию одних продуктов в другие через API множество раз: интеграция с ГИС, интеграция поиска и бронирования тревел-услуг, интеграция множества всевозможных ФинТех сервисов, и т.д. Всего я видел не менее 200 различных документаций публичного API и не менее 100 из них мне приходилось непосредственно использовать. Я видел много способов описания API: Описания в виде 5 двухсот-страничных PDF документов, каждый из которых в деталях описывал