В PostgreSQL существует очень удобный механизм рекомендательных блокировок, они же — advisory locks. Мы в «Тензоре» используем их во многих местах системы, но мало кто детально понимает, как конкретно они работают, и какие проблемы можно получить при неправильном обращении.

Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?

Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.

Привет! Меня зовут Александр Денисов, я из команды мобильного Яндекс.Браузера в Санкт-Петербурге. В этом посте расскажу вам, как мы справляемся с циклическими крешами на старте.

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

В качестве примера будет выступать приложение Яндекс.Браузер для iOS: более 100 тысяч исходных файлов, тысячи коммитов в год и около тысячи модулей без учёта ядра (Swift + Objective-C). Кстати, не так давно мы рассказывали, как помогли команде Swift ускорить отладчик.

Циклический креш на старте

Представьте, что в вашем приложении есть баг, приводящий к крешу. Несложно, правда? Причём возникает баг из-за редкого сочетания факторов, и происходит это на старте. С некоторой вероятностью баг останется незамеченным во время тестирования и попадёт в версию для App Store. А дальше пострадавшие пользователи столкнутся с приложением, которое крешится прямо на старте, и перезапуск уже не помогает — только переустановка.

Однажды днем у нас обрушился сайт. Сразу после ребута он падал снова. Мы знали, что это не DDOS, а органический трафик: к нам поступали типичные запросы, но сервера не справлялись. Увеличение мощности железа не помогало. Стало ясно, что пора оптимизировать нашу систему.

Молодым стартапам может быть интересно, как справляться с возросшими нагрузками на еще неокрепшее серверное ПО.

Осенью прошлого года в московском офисе Яндекса прошла первая Школа бэкенд-разработки. Мы сняли занятия на видео и сегодня рады поделиться на Хабре полным видеокурсом Школы. Он позволит вам научиться промышленной разработке на Python. Авторы лекций — опытные разработчики в Яндексе. К каждому видео приложены ссылки на примеры и полезные материалы.

Для изучения курса нужно знать основы Python и понимать, как приложения развёртываются на серверах. Мы ждём, что вы умеете делать запросы к базам данных и знаете, как создаются веб‑приложения, — хотя бы на начальном уровне.

Привет!

Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.

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

Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.

История меняется прямо сейчас на ваших глазах!

Иногда бывает любопытно подсмотреть, что пересылают туда-сюда разные Android-приложения по HTTP и HTTPS протоколам. Иногда даже при разработке собственного ПО удобно видеть весь трафик в реальном времени. Для реализации этих задач давно придумано много хороших программ, таких, к примеру, как Charles или Fiddler2. На самом деле их намного больше, вот только две вышеуказанные дают возможность нормально просматривать не только HTTP, но и HTTPS.

Трудности начинаются тогда, когда речь заходит о перехвате трафика между Андроид-устройством и внешним сервером. В случае незашифрованного (HTTP-протокол) трафика всё весьма тривиально (вот и инструкция есть) — разрешаем Fiddler2 внешние соединения, в Андроиде устанавливаем прокси сервером адрес нашей машины с Fiddler2 — и вуаля, всё работает. А вот на настройку перехвата HTTPS-трафика у меня ушло чуть больше времени.

Главное в платежной системе — взять денежки, перевести записи из одной таблички в ту же самую табличку со знаком «минус». Звучит не очень сложно, пока не пришли юристы. Платежные системы во всем мире облагаются огромным количеством всевозможных отягощений и указаний. Поэтому в рамках разработки платежной системы приходится все время балансировать на грани между тяжелым enterprise и вполне нормальным масштабируемым web-приложением.

Под катом рассказ Филиппа Дельгядо (dph) на Highload++ про опыт, накопившийся за несколько лет работы над платежной системой для российского легального букмекерского бизнеса, про ошибки, но и про некоторые достижения, и про то, как грамотно смешать, но не взбалтывать, web с enterprise.

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

Для минимизации ручного труда мы решили воспользоваться одним из инструментов трассировки. О том, как и для чего можно использовать трассировку и как это делали мы, и пойдет речь в этой статье.

В настоящее время нет недостатка во фреймворках для создания микросервисов на Java и Kotlin. В статье рассматриваются следующие:

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

Пример 1. Тестовый

Ничего не работает

Тестирование в нашем отделе ― это синтетика на продуктовом железе, а позже ― тесты прикладного ПО. К нам на тестирование поступил диск Intel Optane. Ранее о тестировании дисков Optane мы уже писали в нашем блоге.

Диск был установлен в сервер стандартной комплектации, собранный относительно давно под один из облачных проектов.

Иллюстрация “Waiting” by Nataly Zhuk

Два года назад автор этой статьи Майкл Линч (Michael Lynch) уволился с должности инженера-программиста в Google, чтобы начать собственный бизнес (см. статью «Почему я ушёл из Google и начал работать на себя», 443 комментария на Хабре, +216). Вместо «Google» в заголовок можно поставить название любой крупной компании — фабрики программного обеспечения, где каждый программист считается винтиком в большой машине, будь то Microsoft, EPAM, etc…

Мы решили перевести вторую часть статьи — посмотрим, что получилось у автора в качестве независимого разработчика. В первой части он упоминал о проекте Indie Hackers: это онлайн-сообщество для основателей маленьких предприятий по разработке ПО. Ключевое слово «маленьких». Это не будущие цукерберги, не основатели стартапов, а те, кто хочет построить скромный прибыльный бизнес, дающий средства к существованию.

Интересно, что стало с его проектами. Об этом ниже в оригинальном тексте автора.

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

Если вы разрабатываете собственный сервис, то часто хотите обеспечить его работу одновременно на нескольких платформах. Проверенные временем принципы ООД (объектно-ориентированного дизайна) сделают ваш код более отказоустойчивым и упростят расширяемость.

В этой статье мы изучим один конкретный подход к проектированию, который называется SOLID (это акроним). Используем его на практике в написании сервиса с интеграцией Slack, а затем расширим для использования с Twilio.

Сколько может рассказать о человеке профиль в соцсети? Фотографии, посты, комментарии, подписки – непаханное поле для анализа. Сегодня поговорим о том, как мы определяем интересы пользователей на основе их подписок в сети Instagram.

Источник

Java еще не умерла — и люди начинают это понимать.

Добро пожаловать в ведение по Java 8. Этот материал шаг за шагом познакомит вас со всеми новыми фичами языка. Вы научитесь использовать методы интерфейсов по умолчанию (default interface methods), лямбда-выражения (lambda expressions), ссылки на методы (method references) и повторяемые аннотации (repeatable annotations). Все это будет сопровождаться короткими и простыми примерами кода. В конце статьи вы познакомитесь с наиболее свежими изменениями в API, касающихся потоков, функциональных интерфейсов, расширений для ассоциативных массивов, а также с изменениями в API работы с датами.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.