В июле и августе 1991 года я, с подачи Гвидо Ван Россума, проводил технические интервью на позицию Middle Python Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.

Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Python». Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько дней — старый имел слишком жесткий закос под промышленное программирование.

И вот что я хочу сказать вам, коллеги: вы меня огорчаете.

• Именования переменных, классов и функций
• Вспомогательных функций
• Комментариев к коду
• Перечислений/словарей/запечатанных классов и так далее
• Упорядочивания и именования пакетов

Зависит ли эффективность от меньшего количества нажатий на клавиши?

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

Уже очень давно создана и работает программа, отображающая космонавтам движение МКС на карте земной поверхности.

МКС, конечно, двигается вовсе не по земной поверхности, а по орбите. Но если соединить станцию и центр Земли прямой, то точка пересечения этой прямой с земной поверхностью будет являться т.н. «подспутниковой» точкой. Совокупность этих точек составляет «трассу» полета. Другими словами, трасса – это проекция на земную поверхность плоскости орбиты. Если земная поверхность представлена схематичным изображением континентов в цилиндрической проекции, то трасса МКС (наклонение ее орбиты 51,8°) отобразится кривой, напоминающей синусоиду. И где-то на этой «синусоиде» обычно красным кружочком отображается текущее положение МКС...

JSON является одним из очень простых, но в то же время эффективных языков для хранения и передачи данных. Он настолько популярен, что, пожалуй, может считаться самым совместимым форматом представления данных в мире.

Одновременно с этим, JavaScript является одним из наиболее популярных языков программирования и применяется практически везде. Также, нужно понимать, что JSON появился напрямую из JavaScript и эти два языка просто созданы друг для друга.

Но что же может пойти не так, спросите Вы? Просто попробуйте распарсить этот JSON-документ…

Дочитав эту статью до конца, вы сможете решать точно задачу коммивояжёра на сотню элементов за считанные секунды!

Заинтригованы? Тогда, добро пожаловать под кат.

В предыдущих двух постах (раз, два) мы разобрали, какие проблемы решает гексагональная архитектура и как выглядит архитектура у нас в проекте. Теперь давайте посмотрим, как обстоят дела с кодом, который должен поддерживать описанную архитектуру.

Как я уже писал, мы взяли из DDD тактические шаблоны.

Если какое-то понятие предметной области является уникальным и отличным от всех других объектов в системе, то для его моделирования используется сущность.

Такие объекты-сущности могут сильно отличаться своей формой за весь цикл существования. Тем не менее, их всегда можно однозначно идентифицировать и найти по запросу.

Для этого используются уникальные идентификаторы.

Сущность в коде нашего проекта должна иметь:

Blade Runner 2049, Warner Bros. Pictures

Я видел не во сне, а наяву атакующие корабли, пылающие под четырьмя вложенными if-else, и лучи CI с кучей сканирований у ворот Тангейзера, вызывающие лютую боль разработчиков. Меня зовут Максим Морев, и я техлид в Газпромбанке.

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

Это вторая часть из серии статей про компонентный подход. Если вы не читали первую часть Компонентный подход. Боремся со сложностью в Android-приложениях, то рекомендую начать с нее.

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

Предлагаю опробовать этот подход на практике. Будем использовать библиотеку Decompose для создания простых и сложных экранов. Рассмотрим примеры из реальных приложений. Надеюсь, будет интересно.

Представьте, что вы начали разработку нового Android-приложения. Поначалу особых проблем не будет. Вы реализовали лишь самые базовые функции. Экранов немного, и все они простые. Вам легко ориентироваться в коде. Вы бодро добавляете одну фичу за другой. Но со временем разработка усложняется: кода становится много, главный экран обрастает большим количеством UI-элементов и логики, экраны образуют сложные цепочки переходов. Приходится ломать голову, чтобы добавить что-то новое, не сломав ничего из старого. Скорость разработки падает. Знакомая ситуация?

Существует эффективный способ борьбы со сложностью — компонентный подход. Мы в MobileUp применили его в трех крупных Android-приложениях и теперь не представляем, как жили без него раньше.

Меня зовут Артур, я тимлид в компании MobileUp. Я помогу вам освоить компонентный подход. Постараюсь сделать это как можно проще и увлекательнее.

Вас ждет серия статей. Это первая из них — теоретическая. В ней мы рассмотрим, какие сложности встречаются в Android-приложениях, и почему MVVM и Clean Architecture не панацея против них. Я расскажу, что такое компонентный подход и в чем его преимущества. А в конце статьи будут ссылки на материалы для углубленного изучения.

Низкий порог входа и строгость языка программирования — вещи обычно несовместимые. Потому что ты либо, как Rust, бьёшь по рукам borrow checker’ом — либо, как PHP, позволяешь не задумываться о типах и быстро прототипировать. 

На самом деле, если писать код грамотно, это становится неважным и язык перестаёт иметь значение. Архитектура важнее языка, и хороший код на PHP ничем не отличается от аналогичного кода на любом другом ООП-языке. Другое дело, что возможность «любой домохозяйке» писать на PHP сопровождается и риском наворотить полное неподдерживаемое безобразие. Поэтому нам нужны тайпхинты, линтеры, статические анализаторы и подобные инструменты. 

Но в PHP есть и ещё один изъян: в нём любой класс, функция или константа — глобальны. Можно создать класс из любого места в коде, и нет способа скрыть его или сделать деталью реализации где-то в отдельной папке. Иными словами, в PHP нет того, что в других языках называется модулями.

Наша новая open-source разработка называется Modulite и внедряет в PHP модули. Это сквозная технология: мы внедряемся в IDE, в PHPStan, в KPHP, в CI, в Composer — и делаем так, будто бы модули нативно есть в языке PHP.

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

Привет! Продолжим тему гексагональной архитектуры и DDD, первый пост — здесь. 

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

Гексагональная архитектура

Одна из самых исчерпывающих статей по гексагональной архитектуре подробно и с примерами раскрывает назначение этой архитектуры. 

Я приведу основные мысли.

Гексагональная архитектура имеет три фундаментальных блока:

{"__typename":"PageLikeAction","action_type":"LIKE","label":{"text":"Like"}

Каждая строка делает только одно действие

Привет, Хабр! Сегодня мне хотелось бы поговорить о такой интересной метрике, как Maintainability - возможность вести доработки и улучшения при создании сложных систем. Ведь при развитии любого программного продукта возникает вопрос, сколько будет стоить его поддержка и развитие. Мы в Киберпротекте разрабатываем линейку продуктов для защиты данных и сегодня это — миллионы строк кода, требующие ощутимых затрат как на поддержку, так и на расширение возможностей или исправление найденных ошибок. В этой статье я делюсь своими мыслями о том, как оценить Maintainability, из чего она состоит, можно ли ее измерить, и как принимать правильные решения при работе с кодом.

Contact us: [t.me/evaclick]

Подробнее с "eco-programming & VAOP", можно познакомиться здесь https://vaop.notion.site/eco-programming-VAOP-106f8ec4418d42bdbb5ec371e8ddada9

Когда в апреле 2021 года я опубликовал статью на хабре: Введение в v-agent ориентированное программирование, в которой сформулировал идеологию и заложил основной понятийный аппарат новой методологии программирования: v-agent, va-script, va-box, action, direction и т.п., то напомнил себе изобретателя радио - Сделал Маркони радио, включил, а слушать то нечего. Наверное подобное происходит со всеми пионерами новых методологий программирования.

Еще веселее было с отсутствием тогда убойных примеров применения новой методологии. Тут я, еще раз улыбнулся, вспомнив анекдот про ученого, выступившего на симпозиуме и заявившего, что он изобрел чудо лекарство и осталось только выяснить - от чего же оно лечит?

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

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