Привет, Хабр! Меня зовут Сергей Соловьев, я разрабатываю интерфейсы международных платежей в Тинькофф Бизнесе. Уверен, многие хотят писать надежный, поддерживаемый, но при этом лаконичный код. Как найти баланс?

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

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

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

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

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

Привет! Я — Алексей Бондаренко, работаю в команде Платформа Банки.ру. Сегодня хочу рассказать о semantic-release и его практическом применении на примере упрощения разработки и внедрения библиотеки в проект. 

Технологическая индустрия, СМИ, якобы независимые эксперты, как правило, рекомендуют покупать самые новые, самые продвинутые гаджеты: смартфоны, телевизоры, ноутбуки. А что делать, если обновиться нужно, а денег на топовое устройство нет? Ну, или просто не хочется тратить слишком много денег.

Брать новое дешёвое устройство? Такой себе вариант. Вполне вероятно, что хороший подержанный ноутбук сможет закрыть ваши задачи лучше. Если его немного подшаманить.

Открываю исходники очередного enterprise-проекта: о да-а-а, вот они, старые знакомые, лучшие друзья разработчика — first name и last name.

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

Когда речь идет о личной продуктивности, то как правило имеется в виду управление действиями - задачами и проектами, временем.

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

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

Рассказываю о своем воркфлоу, который объединяет оба эти компонента и о продукте, который для него использую.

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

Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.

Итак, продолжим.

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

Именно кастомные шаблоны и бонусом, кастомная конфигурация, будут раскрыты в текущей статье. Поехали!

Artem Zakharchenko, автор библиотеки для тестирования MSW с 15К звезд на GitHub, поделился мыслями о Test Driven Development.

TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.

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

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

Привет! Я Виталий, DevOps в LEADS.SU, в этой статье хочу рассказать как мы внедряли Sentry self-hosted и приводили к продакшен состоянию, которое должно отвечать требованиям высокодоступности - нельзя терять события ошибок. При этом не хотелось заморачиваться с кластеризацией для разных инструментов (вроде redis, postgresql, clickhouse, kafka и прочее). И тут мы вспомнили про распределенную сеть доставки логов из нескольких узлов td-agent и решили попробовать.

Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

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

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

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

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

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

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

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

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

Введение

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