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

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

Привет, меня зовут Алексей Лобзов, я руководитель направления развития компетенции системного анализа в Альфа-Банке. В прошлом году мы в банке проводили Analyze IT Meetup. Кроме интересных докладов у нас был круглый стол, куда мы пригласили Лидера компетенции из Сбера, Solution архитектора из СИБУР Digital и Product Owner’а из Альфа-Банка.

Что их всех объединяет? Они все в прошлом были системными аналитиками. Наши герои поделились тем, как из системных аналитиков (СА) перешли на новую позицию. Тема оказалась животрепещущей — было много вопросов как на митапе, так и после, поэтому позже мы той же компанией и на ту же тему записали подкаст в СИБУР Digital.

И если для вас вопрос «А куда расти дальше, если я уже сеньор?» стоит «на повестке дня», то приглашаю почитать статью, подготовленную по материалам круглого стола. 

Итак, мы с вами добрались до третьей, самой «хардовой» части цикла. Сегодня поговорим про gRPC.

Что такое gRPC? 

Сам RPC — удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры других программ, делая это так, как если бы они находились в одном адресном пространстве. Буква g в названии — это гугловая реализация этих технологий.

Разберем это все на примере.

Допустим, что вы — программист и сидите в монолитной репе. У вас одно приложение. Сам проект открыт в IDE и вы в нем работаете. В репе реализован определенный класс (например, на Kotlin), у которого есть метод, возвращающий вам данные по пользователю.

Однажды один мудрый DevOps сказал мне: «DevOps’ы — это люди, способные сделать всё, лишь бы не делать ничего». Привет, Хабр, я Алексей Подольский, лидер направления инструментов безопасной разработки в Cloud.ru. Сегодня я расскажу, как сделать жизнь чуть легче, если кластеров кубера в проектах развелось столько, что за всеми не уследить. Будем объединять кластеры в один, да так, чтобы падали затраты, а не прод. Будет полезно админам, DevOps’ам, прикладным архитекторам, и всем, кто работает с Kubernetes. Поехали!

Введение

1. Введение
2. Что такое MDM
3. Типы корпоративных данных: что такое справочные и транзакционные данные
4. Зачем оно нужно?
   
   • Зоопарк ИТ-систем и консолидированная отчетность
   • Интеграция систем
   • Единая база контрагентов
   • Очистка и нормализация данных
   • Случаи из жизни
5. Методы решения
   
   • Административное решение
   • Внедрение MDM-системы
6. Типы MDM-систем
   
   • Централизованная система
   • Аналитическая система
   • Гармонизированная система
   • Примеры реализации MDM-систем
7. Индикаторы необходимости внедрения СУ НСИ
8. Выводы

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

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

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

Изучив основы gRPC в первой части нашей серии, мы теперь погрузимся в практическую реализацию gRPC сервиса на Python с использованием FastAPI и Piccolo ORM, чтобы показать, как это работает на примере тестового приложения.

Всем привет! Меня зовут Бургомистренко Кристина и я — системный аналитик в компании заказной разработки Rubius. В этой статье я рассказываю про свой опыт проектирования и сравниваю несколько популярных инструментов для создания вайрфреймов, которые может использовать в своей работе бизнес/cистемный аналитик.

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

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

Итак, давайте разберемся с базовой информацией.

Модель OSI (Open Systems Interconnection) — это эталонная модель, разработанная для описания функций телекоммуникационных или вычислительных систем, необходимых для сетевого взаимодействия. Она разделяет процесс сетевого взаимодействия на семь взаимосвязанных уровней. Каждый уровень выполняет специфические функции и взаимодействует с уровнями непосредственно выше и ниже.

Важно писать не только сервисы, которые хорошо работают, но и сервисы, которые хорошо ломаются.

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

Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.

В прошлой статье я представил шаблон, а теперь заполнил его для фичи «Экспресс-доставка товара в маркетплейсе». Моя цель – показать, как можно вести документацию и как правильно заполнять этот шаблон.

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

TL;DR

На работе:

1. Учиться с желанием и вне зависимости от возраста, позиции, опыта.
2. Сначала всегда пытаться найти ответ/решение самостоятельно, потом обязательно обращаться к коллегам, начальству. 
3. Ставить себя на место пользователя продукта, который вы делаете.
4. Подмечать проблемы и говорить о них с коллегами и начальством, особенно, если есть решение.
5. Извлекать опыт как из положительных, так и отрицательных ситуаций.
6. Делиться своими знаниями и опытом с другими.
7. Вставать пораньше, чтобы сделать какую-то работу для души (это может быть подработка или контент для блога, например).
8. Делать сложные задачи в начале дня («глотать лягушек» до обеда).
9. Плотно работать в часы своей продуктивности.
10. Записывать всё — задачи, идеи, планы, не пытаться удержать в памяти. 

Глобально:

1. Поддерживать баланс между работой и личной жизнью, чтобы не выгореть.
2. Высыпаться и вообще регулярно качественно отдыхать.
3. Максимально делегировать в быту то, что можно. 
4. В течение дня выделять время на физическую активность (прогулка, спорт, танцы), чтобы дать мозгу расслабиться. 
5. Читать книги, слушать аудиокниги и музыку, чтобы переключиться и отдохнуть.
6. Путешествовать, жить в разных местах, знакомиться с другими людьми, объектами, концепциями, чтобы создавать новые нейронные связи.

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

Дисклеймер:
Если вы совсем не поняли, что означают эти наборы букв, ничего страшного. Ниже мы расскажем о реалиях работы с адресами в России. Если вам это неинтересно, почитайте про топографические каламбуры.

Меня зовут Якупов Азат, я дата-архитектор Quadcode. В индустрии я больше 20 лет, из них больше 6 лет — в архитектуре. Эта статья — немного сокращенный пересказ моего выступления на митапе по теме «Heap Table в PostgreSQL». 

Речь в тексте пойдет об обычных таблицах, с которых начинается вся дата-инженерия. Посмотрим на то, как метаданные располагаются в Postgres, разберемся, что такое table page и fillfactor, а также поближе познакомимся с TOAST-таблицами.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).

Мало написать "программное обеспечение", - права на него надо ещё уметь защищать!

В российском праве "программное обеспечение" именуется "Программами для ЭВМ".

А термины "Программное обеспечение", "Софт", "Программный продукт" и т.д. - это сленг.

Программы для ЭВМ охраняются наравне с литературными произведениями, и поэтому программы для ЭВМ являются объектами права интеллектуальной собственности (точнее: авторского права).

Статья 1261 Гражданского кодекса РФ гласит, что "Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения".

При этом, по общему правилу, словосочетание "совокупность данных и команд" пока понимается именно как последовательность букв и иных символов в программном коде.

И поэтому пока что главным критерием для сравнения программ для ЭВМ является установление фактов идентичности исходных текстов (исходных кодов) этих программ.

Однако, как говорится "Гладко было на бумаге, да забыли про овраги".

Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.

Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.