Привет! Меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon: пишу микросервисы на Go для личного кабинета продавца. В прошлом году мы запустили новый процесс регистрации продавцов, в котором задействовано сразу несколько микросервисов. В нём стало больше шагов, при этом каждый из них выполняется в разных микросервисах. Поэтому мы задались вопросом: «А что будет, если один из шагов упадёт?».

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

.NET Foundation – независимая организация, основанная Microsoft с целью поддержки open source проектов на платформе DotNet. Под их крылом на данный момент собралось множество библиотек, некоторые из которых уже проходили проверку анализатором PVS-Studio. Следующим проектом для проверки анализатором будет LINQ to DB.

Меня зовут Артём Сусеков, я менеджер разработки в Miro. Расскажу, как мы пришли к справедливой оплате и прозрачному обсуждению эффективности сотрудников команд продуктовой разработки.

Статья будет полезна, если вы задаётесь вопросами: 

•Как оценить вклад каждого сотрудника в результаты компании?
•Как сформировать понятные ожидания?
•Как оценить грейд сотрудника и понять, что ему нужно сделать, чтобы вырасти в компании?
•Как проводить оценку сотрудника, не перегружая этим процессом всех остальных?
•Как сделать процесс оценки прозрачным?

Поймал как-то программист золотую рыбку, а она ему и говорит человеческим голосом: «Отпусти меня в синее море, я исполню любое твоё желание». Программист ЦПУшечкой поскрипел, да и выдал техзадание. «Построй мне», – говорит, – «систему обработки неидемпотентных запросов, да чтоб она была высокопроизводительной, масштабируемой, гибкой и отказоустойчивой!». Охнула сперва золотая рыбка, но взяла себя в плавники и молвила: «Не печалься, ступай себе домой, код написан, система развёрнута. Отпускай меня уже». Удивился программист: «Да ладно? Ну, сейчас проверю и отпущу». «Нет», – возражает рыбка – «пока ты проверяешь, я уж засохну, и всё волшебство исчезнет». Программист задумался: «Что же делать: сначала отпустить, а потом проверить, или сначала проверить, а потом сушёную рыбу к пиву получить?».

Мечты о золотой рыбке не раз посещали умы даже опытных разработчиков. В погоне за оптимальной системой обработки запросов многие отдают недели и месяцы своей жизни, а некоторые готовы отдать и душу, чтобы всё работало без сбоев.
Но нужны ли такие жертвы? Нет... Ведь у вас есть мегабыстрая Apache Kafka, супергибкий Python и возможности NoSQL баз данных. Все эти решения прекрасны по отдельности, но как из них собрать один конвейер для обработки данных, не растеряв их преимущества? Рассмотрим под катом.

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

Еще 8 октября селлер маркетплейса обнаружила в личном кабинете странную находку. В графе «Сотрудники», которая прячется в настройках, она увидела нового пользователя и удивилась: она сама не заводила нового сотрудника, а коллеги сделать не могли это, просто потому, что их не существует.

А дальше логичный вопрос, прямо как в сказке - "Кто спал на моей кроватке?". Свое негодование селлер сразу поспешила выразить в официальном сообществе Ozon. Новость не понравилась никому.

"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.

Английский язык — далеко не самый простой из существующих. А по количеству лексики он вообще один из лидеров. По исследованию Google и Гарвардского университета, на 2000 год в английском языке было уже около 1 022 000 слов.

В мировой истории был целый ряд попыток популяризовать английский язык в мире путем его упрощения и использования ограниченного словарного запаса. Самой современной попыткой можно считать Simple English Wikipedia, статьи в которой поймет даже студент с уровнем Pre-Intermediate. 

Сегодня расскажем вам, как исторически складывались попытки упростить английский, к чему они приводили и что из себя на самом деле представляет Wiki на простом английском.

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

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

Поразмышляв, я сделал этот прыжок, и в данной статье поделюсь полученным опытом. Душераздирающей истории здесь не будет. Статья задумана как полезная, и, надеюсь, такой она и получилась.

​Почему у многих возникают проблемы с этим принципом? Если ли более простое объяснение?

​️В данной статье мы НЕ будем рассматривать общие примеры данного принципа, о которых уже есть много материалов (пример с квадратом и прямоугольником или управления термостатами). Здесь мы немного подробнее остановимся на таких понятиях как «Предусловия», «Постусловия», рассмотрим что такое ковариантность, контравариантность и инвариантность, а также что такое «исторические ограничения» или «правило истории».

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

Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc

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

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

Предисловие

Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?

Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.

Содержание:

• Что такое JWT?
  
  • Заголовок
  • Полезная нагрузка
  • Подпись
  • Что такое SECRET_KEY?
• Атаки на JWT:
  
  • Базовые атаки:
    
    1. Нет алгоритма
    2. Изменяем алгоритм с RS256 на HS256
    3. Без проверки подписи
    4. Взлом секретного ключа
    5. Использование произвольных файлов для проверки
  • Продвинутые атаки:
    
    1. SQL-инъекция
    2. Параметр поддельного заголовка
    3. Внедрение заголовка ответа HTTP
    4. Прочие уязвимости

Что такое JSON Web Token?

Веб-токен JSON обычно используется для авторизации в клиент-серверных приложениях. JWT состоит из трех элементов:

• Заголовок
• Полезная нагрузка
• Подпись

Заголовок

Это объект JSON, который представляет собой метаданные токена. Чаще всего состоит из двух полей:

• Тип токена
• Алгоритм хэширования

Официальный сайт предлагает два алгоритма хэширования:

• «HS256»
• «RS256»

Существует более 30 игр с дополнительным пространственным измерением (список на википедии), которые разнообразными способами визуализируют и пытаются сделать доступной для понимания наличие четвёртой координаты. Но среди тех игр, с которыми я ознакомился, не нашел для себя такой, которая сочетала бы в себе следующие факторы:

- вид от первого лица

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

- простая и привычная графика, с текстурами и освещением

- отсутствие лишних геймплейных элементов и бóльшая направленность игры на исследование четырёхмерного мира

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

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

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

Если вдруг вся эта история прошла мимо вас, Let's Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let's Encrypt уже используются на более чем 10 миллионах доменов.

Кроме очевидной бесплатности у сертификатов от Let's Encrypt есть особое, отсутствующее у любых других коммерческих сертификационных центров, достоинство: если вы однажды получили сертификат от Let's Encrypt, то, при прочих равных, это навсегда. Не нужно раз в год-два вручную обновлять сертификаты. Не нужно вообще вспоминать что сертификаты где-то есть. Получил, настроил и забыл!

Внимательный читатель сразу захочет возразить: как же так, ведь известно что сертификаты выдаются со сроком действия в три месяца? Всё дело в автоматическом обновлении сертификатов, которое возможно при полном отсутствии действий со стороны человека.

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let's Encrypt.

Некоторые ограничения

• На достаточно высоком уровне в архитектуре х86_64 есть всего два режима адресации.
• Все регистры в обоих режимах адресации должны быть строго одинакового размера. Другими словами, мы не можем странным образом смешивать 64, 32 и 16-битные регистры и получать актуальный адрес — в кодировании х86_64 для подобного маневра попросту нет места.