Пользователь
Привет! У нас в Спортмастере очень большая экспертиза в части работы с инструментами JIRA. Про доски, спринты и все прочее все наверняка знают и часто применяют. Мы хотим рассказать о других интересных плагинах, которые мы используем в рамках управления продуктом, начнем с JIRA Structure.
Зачем это нужно?
Structure — плагин для Jira, позволяющий гибко настраивать и управлять Jira-задачами любого типа.
Основные возможности:
Привет всем Хабр-читателям. Про развертывание и настройку HA кластера PostgreSQL с помощью Patroni написано много полезных статей, однако я не нашел описания алгоритма его работы. В этой статье я хочу поделиться своим исследованием по данному вопросу.
Прочитав по диагонали статью гражданина @Winseven«ICMP открывашка портов для сервера», я сдержался. Все-таки велосипединг — это весело. Но вчитавшись, я опешил. Зачем запускать отдельное приложение для отслеживания нужных пакетов? Правильно ли, что достаточно один раз попасть пальцем в небо, чтобы порт был открыт? По мне, как-то не по фэншую.
Душа все это не вынесла, и я решился на статью.
В этом году исполняется 18 лет моей работе в IT. Волей судьбы (и немного моими собственными усилиями) я умудрился побывать на разных концах пищевой цепочки производства продукта. Это и просто программист и фрилансер, успел поплавать на галерах и в жёстких стартапах. Был (а кое-где остаюсь) и менеджером, и владельцем, и инвестором. И каждый раз, в каждой новой ипостаси я продолжал анализировать процессы в ИТ и в работе в целом, постоянно находя улучшения и делая дебаг тех мест, которые не работают так, как хотелось бы. Поэтому весь нижеследующий текст - исключительно мой опыт работы. Я разделил его на две части: как управляющий проектом видит и желает видеть программистов ("взгляд сверху") и наоборот - как подчинённые хотели бы, чтобы с ними взаимодействовал руководитель и что они от него ждут ("взгляд снизу").
Мы решили внести свой скромный вклад в развитие комьюнити и перевели оригинальную статью. Статья опубликована на сайте Simplilearn.
Мы все больше полагаемся на данные для выполнения задач в работе и повседневной жизни. Приложения, сервисы, ПО, мобильные устройства и другие элементы объединяются в сложную и разветвленную паутину, которая затрагивает большинство сфер нашей жизни.
В результате возрастает потребность в обработке потока информации между элементами этой системы. Устройства и приложения должны четко и безошибочно взаимодействовать друг с другом. Именно поэтому программисты используют брокеры сообщений и аналогичные инструменты для обмена информацией и коммуникации.
Предупреждение: в статье присутствуют заголовки реальных новостей. Я отношусь к ним исключительно как к рабочему материалу, не представляю какую-либо точку зрения на политическую или экономическую ситуацию в какой бы то ни было стране.
https://fakt309.github.io/thisisthewall/
В языках программирования строки сравниваются очень просто, если строка отличается хотя бы на один символ, то возвращает false.
Но вот что если мы хотим не просто получать дискретное значение (true / false), а дифференцированное, например в процентах. Ведь согласитесь строки test и testing гораздо ближе к друг другу, чем test и abcd. Для данной проблемы существует множество решений, мы поговорим о самый популярных алгоритмах (также об их модификациях):
Расстояние Хэмминга
Расстояние Левенштейна
Сходство Джаро — Винклера
Коэффициент Сёренсена
Привет! Это пост-отчёт с митапа «Быстрый бэкенд», который прошёл в офисе Joom. С коллегами из Джум Лабс и Авито обсудили, как живётся с большим кластером MongoDB, как битмап-индексы помогают быстро искать по каталогам и как анализировать большие объемы Jaeger-трейсов. В этом посте — видеозаписи докладов, презентации спикеров и несколько фотографий со встречи.
Привет, друзья!
Данная серия статей представляет собой мои заметки о NestJS — фреймворке для разработки эффективных и масштабируемых серверных приложений на Node.js. NestJS использует прогрессивный (что означает текущую версию ECMAScript) JavaScript с полной поддержкой TypeScript (использование TypeScript является опциональным) и сочетает в себе элементы объектно-ориентированного, функционального и реактивного функционального программирования.
Под капотом Nest по умолчанию использует Express, но позволяет переключиться Fastify.
Первая статья представляет собой обзор основных возможностей, предоставляемых NestJS, во второй рассматриваются основы работы с этим фреймворком, в третьей — техники и рецепты по интеграции NestJS с некоторыми популярными библиотеками, используемыми при разработке приложений на Node.js, наконец, четвертая статья представляет собой туториал по разработке относительно полноценного React/Nest/TypeScript-приложения.
При рассказе о Nest я буду придерживаться структуры и содержания официальной документации.
Это вторая часть руководства.
Привет, друзья!
В этой серии из 3 статей я расскажу вам о Nest (NestJS) — фреймворке для разработки эффективных и масштабируемых серверных приложений на Node.js. Данный фреймворк использует прогрессивный (что означает текущую версию ECMAScript) JavaScript с полной поддержкой TypeScript (использование TypeScript является опциональным) и сочетает в себе элементы объектно-ориентированного, функционального и реактивного функционального программирования.
Под капотом Nest использует Express (по умолчанию), но также позволяет использовать Fastify.
В первой статье рассматриваются основы работы с Nest, во второй — некоторые продвинутые возможности, предоставляемые этим фреймворком, в третьей — приводится пример разработки простого React/Nest/TypeScript-приложения.
При рассказе о Nest я буду в основном придерживаться структуры и содержания официальной документации.
Это первая часть руководства.
Аутентификация и авторизация — неисчерпаемые бесконечные темы. И как раз именно про них всегда забывают на старте разработки. У нас MVP и обойдемся без всех этих сложностей. Именно на этом умирает огромное количество хороших начинаний в крупных компаниях, поскольку масштабирование от лабораторного проекта до промышленной среды - самая сложная часть в любом проекте. Под катом история нашей эволюции от «авторизовался в ДБО — доверяем!» до «а у вас нет доступа к данным при этом значении атрибута», расширения GraphQL и прочая магия в популярном изложении.
Использовать Guid.NewGuid() в качестве первичного ключа в базе данных — плохая с точки зрения производительности идея. Это связано с тем, что в SQL Server, MySQL и некоторых других БД для первичных ключей создаются кластерные индексы, которые определяют, как строки будут храниться на диске. GUID — это по сути случайное значение, поэтому новая строка может попасть в начало, середину или конец таблицы. Серверу БД в этом случае придётся перемещать другие строки, что приведёт к фрагментации данных, а их извлечение может занять больше времени, если вам нужно извлечь несколько добавленных последовательно записей (например, когда вы добавляете набор связанных сущностей, которые потом будут извлекаться вместе — БД понадобится прочитать данные из разрозненных страниц вместо последовательного чтения набора данных).
Поэтому, чаще всего, лучше пользоваться сгенерированными БД первичными ключами. В SQL Server, например, есть функция NEWSEQUENTIALID(), которая генерирует последовательные GUIDы. Зачем может понадобиться генерировать ключи именно на клиенте и как это правильно сделать?
DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
На конференции FrontedConf 2021 Андрей Старовойт показал плюсы и минусы TypeScript. Если вы сомневаетесь, стоит ли его использовать — эта статья для вас, чтобы вы смогли для себя всё решить. Если вы уже любите и используете TypeScript, то надеюсь, вам тоже будет интересно.
Все преимущества и недостатки языка описаны, конечно, через призму опыта Андрея. Несмотря на то, что последние 7 лет он работает в компании JetBrains над продуктом WebStorm на Java Kotlin, пишет он и на TypeScript. Попутно много смотрит на код других людей, пытаясь понять, что с ним можно сделать внутри WebStorm и почему типы выбились неправильно. А также — какие инспекции можно применить так, чтобы люди стали счастливы, а их код — лучше.
В прошлой статье я рассказал, как мы пришли к DDD и про его очень важную особенность — единый язык, на котором легче и дешевле разговаривать с бизнесом. Еще мы рассмотрели разработку, ведомую моделью. Когда вначале стоит не выполненная по требованию фича, а абстрактная модель, созданная по требованиям и имеющая отражения в различных представлениях. Все эти области оперируют терминами единого языка и реализованы максимально похожими, чтобы каждый, кто будет работать с проектом, смог разобраться в любой из них.
Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.
В этом посте будет описано практическое применение semantic-release для terraform модуля terraform-yandex-compute (Модуль Terraform, который создает вычислительные ресурсы в облаке Яндекса) c Github action.
А так же будет рассмотрено использование Pre-commit в Github action.
Современная ИТ-инфраструктура – это живая экосистема, которая пребывает в динамическом состоянии. Она расширяется, меняется, обрастает новыми элементами и связями. Это полноценный организм, за которым нужно следить и ухаживать, не забывая при этом учитывать все его изменения.
Представим ситуацию: решили вы повысить производительность информационной системы. Команда девелоперов для этой цели развернула новые ноды, добавила элементы ИС, зарелизила изменения, система работает эффективнее, и, казалось бы, все счастливы. Да только от радости забыли поставить новые элементы на мониторинг. Так и будете вы спокойно пить кофе, любуясь зелеными огоньками на экране рядом с каждым компонентом системы, пока разъяренные пользователи не cымитируют DDoS атаку на внешний интерфейс вашего хелпдеска, когда один из новых элементов откажет.
Привет, Хабр! Меня зовут @killinem, и я работаю ведущим экспертом отдела анализа защищенности компании Angara Security. В этом посте я хочу рассказать о своем опыте прохождение курса AWAE и сдачи экзамена OSWE от Offensive Security. Это, пожалуй, ведущая на текущий момент международная сертификация, подтверждающая навыки и знания в области практического анализа защищенности веб-приложений.
В этом посте я расскажу:
* какие знания и скиллы нужны для сдачи экзамена,
* как к нему готовился лично я,
* о процессе прохождения самого экзамена,
* является ли сертификат пунктом, после которого можно сказать «я знаю о веб-хакинге все».
Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:
• состояли из 3-10 JOIN-ов по коррелирующим запросам;
• уielded от 10 до 1,000,000 строк;
• должны были выполняться в течение времени, определенного UX-ом;
• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;
• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.
Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.
У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.