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

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

Браузеры стали частью нашей повседневной жизни. Но задумывались ли вы когда-нибудь о том, как они на самом деле работают?

Эта статья приоткроет завесу магии, скрывающуюся за кулисами веб-браузеров.

Давайте начнем!

Техника кеширования позволяет создавать более масштабируемые приложения, запоминания результаты некоторых запросов в быстрое in-memory хранилище. Однако, некорректно реализованное кеширование может сильно ухудшить впечатление пользователя о вашем приложении. Эта статья содержит некоторые базовые понятия о кешировании, различные правила и табу, которые я извлек из нескольких прошлых своих проектов.

Не используйте кеширование.

Ваш проект работает быстро и не имеет никаких проблем с производительностью?
Забудьте о кешировании. Серьезно :)

Оно сильно усложнит операции чтения из базы без каких-либо бенефитов.

Правда, Мохамед Саид в начале этой статьи делает некоторые вычисления и доказывает, что в некоторых случаях оптимизация приложения на миллисекунды способна сэкономить кучу денег на вашем AWS счету. Так что, если прогнозируемая экономия на вашем проекте больше, чем 1.86 долларов, возможно, реализация кеширования — неплохая идея.

• мы выберем для него актуальный http-роутер,
• позаботимся о логах,
• напишем тесты: unit-тесты, тесты хэндлеров и функциональные,
• настроим автоматический деплой через GitHub Actions и др.

В настоящий момент выходит не так много книг по PHP, поэтому я решил прочитать свежее переиздание книги PHP Cookbook от 2023 года, которую в России переводят, как "PHP. Рецепты программирования". Хотелось бы «УЗНАТЬ», что можно написать не про какую-то сферу, где применяется PHP, а именно про сам язык.

Об авторе

Эрик Манн - инженер-программист с опытом почти в два десятилетия. Он создавал масштабируемые проекты для стартапов на ранней стадии и для компаний из списка Fortune 500. Эрик часто рассказывает о архитектуре программного обеспечения, технике безопасности и передовом опыте разработки. Он регулярно уже более пяти лет пишет статьи в журнале php[architect], и больше всего ему нравится помогать новым разработчикам избегать многих ошибок, которые он совершил в своей карьере программиста.

Или как обзавестись красивыми бейджиками для своего проекта за один вечер ненапряжного кодинга

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

В статье будет рассмотрена базовая настройка непрерывной интеграции и поставки для проекта библиотеки классов на .Net Core в GitLab, с публикацией документации в GitLab Pages и отправкой собранных пакетов в приватный фид в Azure DevOps.

В качестве среды разработки использовалась VS Code c расширением GitLab Workflow (для валидации файла настроек прямо из среды разработки).

Всем привет! Меня зовут Алексей Половинкин, и я отвечаю за Python в AGIMA. За последние 2 года мне повезло запускать сразу 2 крупных MVP‑проекта: классифайд автомобилей для Казахстана и проект в сфере телемедицины. За это время у меня и моей команды накопилось много опыта по запуску подобных проектов, и им хотелось бы поделиться. В этой статье рассказываю, как не допускать ошибок на этапе MVP и какие практики полезно внедрять сразу.

Приятно познакомиться, мы битриксоиды. Да-да, те самые которые:
- вообще не модные,
- пишут НЕ на Laravel и Symphony,
- возятся с кучей мягко говоря “неидеального” кода под названием “1С-Битрикс: Управление сайтом”,
- проходят Академию 1С-Битрикс и сдают платные экзамены для подтверждения компетенций,
- умеют дорабатывать обмен с 1С без истерики,
- берут с заказчика "тонну денег" за то что любой php-джун сделает на вордпрессе одной левой,
- но при всем этом почему-то делают сложные проекты переживающие тысячи доработок без потери товарного вида и управляемости.

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

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

Можно ли с помощью GitHub анализировать работу, не заглядывая в монитор сотрудника — без скриншотов и тайм-трекеров?

Я Александр Кириллов, технический директор компании Evrone. Больше 20 лет я посвятил разработке. В этой статье поделюсь с вами опытом, который собрал за время работы с распределенными командами. Расскажу о том, как, не нарушая приватность разработчиков, следить за качеством работы на проектах и отслеживать нежелательные паттерны с помощью метрик в Jira и Git.

Zero Storage Captcha работает локально (возможно, в виде дополнительного класса в коде приложения), не обязывает хранить информацию на стороне сервера о сгенерированных картинках и в тот же момент позволяет проверить ответ любого пользователя со стопроцентной вероятностью.

Demo | GitHub

Эксперименты с созданием редактора диаграмм на Blazor Webassembly (Blazor WebAssembly: Drag and Drop в SVG, Blazor WebAssembly: соединительные линии в SVG) показали что технология не годится для интенсивных манипуляций с DOM.

То что будут проседания было известно заранее: WebAssembly не имеет доступа к DOM, любые изменения только через вызовы JavaScript. Задержки оказались такими большими, что перетаскивание на мобильном тормозило уже после добавления третьей фигуры.

Самое важное — отказ от поддержки старых браузеров в 2021. Майки окончательно убили IE, поэтому разработчикам станет проще использовать классные технологии. Гриды (83%) и флексбоксы (99%) захватили всё. TypeScript есть в 70% вакансий для мидлов. 2022 будет годом TypeScript. 

Container Queries — переосмысление подхода к медиавыражениям. Если медиавыражение зависит от размера экрана, то Container Queries опирается на размер блока. С Cascade Layers мы можем лучше управлять всеми слоями отрисовки на сайте. Это самое большое изменение в CSS на уровне флексов и гридов.

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

Эти и другие прогнозы о технологиях, зарплатах, вакансиях и навыках в 2022 ждут под катом.

Предлагаю читателям "Хабрахабра" перевод статьи "Хорошая практика в сообщении коммитов от OpenStack".

1 Git Commit Лучшая практика

Следующий документ основан на опыте разработки кода, устранении ошибок и просмотре кода в ряде проектов, использующих Git, включая libvirt, QEMU и OpenStack Nova. Рассмотрение других проектов с открытым исходным кодом, таких как Kernel, CoreUtils, GNULIB а также других, предполагает, что все они следуют достаточно распространенной практике. Это мотивировано желанием улучшить качество истории Git проекта Nova. Качество — это абстрактный термин для определения в разработке; когда для одного человека некий код «Красивый» (Thing of Beauty) — то для другого это «Костыль» (Evil Hack). Тем не менее мы можем сформулировать некоторые общие рекомендации о том, как и что делать, или, наоборот, чего не делать, когда отправляют Git коммиты для слияния с проектами в OpenStack.

Эта тема может быть разделена на две области:

1. Порядок объединения или разбиения на несколько коммитов
2. Информация в сообщениях коммитов

Глубокой ночью ничто не предвещало беды… Но в четыре утра от фрилансерской биржи Upwork пришло письмо с радостным, выделенным полужирным начертанием сообщением:

Чем больше вы работаете с клиентом на Upwork, тем больше из заработанного вы оставляете себе!

Казалось бы, радоваться надо, но если вчитаться, то обнаруживаются некоторые детали: комиссию Upwork не уменьшил, а увеличил. Если раньше на все контракты распространялась комиссия 10%, то сейчас она становится ступенчатой: 20%, 10% и 5% при порогах в $0, $500 и $10 000.

Я множество раз слышал о том, что дизайн Generic типов в Java является неудачным. По большей части претензии сводятся к отсутствию поддержки примитивных типов (которую планируют добавить) и к стиранию типов, а конкретнее — невозможности получить фактический тип параметра в рантайме. Лично я не считаю стирание типов проблемой, как и дизайн Generic-ов плохим. Но есть моменты, которые меня порядком раздражают, но при этом не так часто упоминаются.

1

Например, мы знаем, что метод Class#getAnnotation параметризован и имеет следующую сигнатуру: public <A extends Annotation> A getAnnotation(Class<A> annotationClass). Значит, можно писать вот такой код:

Deprecated d = Object.class.getAnnotation(Deprecated.class);

Тут я решаю вынести Object.class в отдельную переменную и код перестаёт компилироваться:

Class clazz = Object.class;
// incompatible types:
// java.lang.annotation.Annotation cannot be converted to java.lang.Deprecated
Deprecated d = clazz.getAnnotation(Deprecated.class);

Где я ошибся?

Предисловие