Этой весной в чатах и сообществах dotnet (не забываем #DropTheDot) обострились анти-медиаторные настроения. Поначалу меня это забавляло, потом удивляло: люди подхватывают лозунги, не пытаясь разобраться в вопросе. Квинтэссенцией обострения стал доклад Андрея Парамонова "MediatR не нужен”, шокирующий своей категоричностью аргументов. В докладе были зерна истины, но они к концу так и не проросли.

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

Небольшая подборка интересных докладов с конференций для C# и .NET разработчиков за последние несколько лет.

Tarantool и Redis по большей части — два очень разных продукта. Начиная от заложенной в них функциональности и заканчивая протоколом, репликацией и кластерными решениями. 

Тем не менее в них много схожего. И в статье мы хотим рассмотреть: что, если взять Tarantool как замену Redis? Просядет ли производительность из-за всех «дополнительных» фичей в Tarantool? Насколько хорошо или плохо справится дисковая подсистема с нагрузкой?

Мы взяли типичные кейсы работы с Redis и реализовали такие же механики на Tarantool, начиная от простых K-V операций и заканчивая вторичными ключами и производительностью кластерных решений: для Tarantool это Tarantool Cartridge, для Redis — Redis Cluster.

18 месяцев.

400 развернутых интервью с "входящими в IT".

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

~30 курсов, на первые занятия которых автор ходил или общался с организаторами (7-8 курсов предложили полностью бесплатное обучение).

10 Хабр-статей, включая эту (набравшие более 300'000 просмотров).

В результате:

• Получен ответ на главный вопрос жизни, Вселенной и всего такого: "Какой процент студентов QA-курсов после выпуска в действительности начинает работать тестировщиком?"

• На основании собранной статистики выявлен список худших QA-курсов в обитаемой части галактики с точки зрения самого объективного параметра. А именно - способности выпускников трудоустроиться.

• Составлен гайд “Как способным войти в IT с гарантией трудоустройства” (но он не всем понравится)

• Первый — возможность получить обратную связь есть только тогда, когда код готов и пользователь может проверить решение, кликая разные кнопочки в GUI. Это часто приводит к тому, что реализованную часть системы приходится писать заново.
• Второй, что хуже — CODE FIRST предполагает каскадную модель разработки: нет возможности настроить параллельно несколько потоков работ.
• Третий недостаток — отсутствие документации и часто слишком детализированное API. Такое API невозможно переиспользовать. 
• И ещё один, четвёртый, минус — отсутствие адаптации к изменениям. А изменения обычно происходят уже во время разработки.

• Дефицит бизнес-навыков и аналитического мышления у дизайнеров.
• Маршруты, положенные в основу архитектуры системы и UI, часто не совпадают с картой бизнес-процессов пользователя. Проще говоря, дизайнер может изобразить любой вариант UI, но возникает вопрос: а можно ли реализовать ту или эту фичу как функционал?
• Ну и та же проблема, как и с CODE FIRST: нет возможностей для быстрой и эффективной адаптации к изменениям. 

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

В 2022 / 2023 году, возник массовый, довольно новый для налоговиков РФ и налоговиков стран ЕАЭС тренд, при котором физическое лицо в статусе индивидуального предпринимателя осуществляет аналогичную деятельность в РФ и еще где-то, то есть как ИП в РФ (на УСН, ПСН, НПД) и как ИП образованное по законам зарубежного государства, при этом такое физическое лицо, может не иметь статус налогового резидента ни в одном из этих государств, административная и судебная практика по таким кейсам только формируется.

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

Почему, например, даже образованные разумные люди нередко поддаются на классические схемы очередных мошенников, верят заманчивым рекламным обещаниям, участвуют в сомнительных конкурсах или, скажем, выкатывают непротестированную сборку прямо в прод?

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

Несколько недель назад в блоге «.NET Blog» появилась статья «Что такое .NET, и почему вы должны выбрать его?». В нем был представлен высокоуровневый обзор платформы, кратко описаны различные компоненты и архитектурные решения, а также обещаны более подробные посты по затронутым темам. Этот пост является первым таким продолжением, в котором подробно рассматривается история создания, архитектурные решения и детали реализации async/await в C# и .NET.

Браузеры стали частью нашей повседневной жизни. Но задумывались ли вы когда-нибудь о том, как они на самом деле работают?

Эта статья приоткроет завесу магии, скрывающуюся за кулисами веб-браузеров.

Давайте начнем!

Если вам о чём-то говорят фамилии Зив, Хомченко и Рымкевич, иди сюда, дай обниму, бедолага-олимпиадник, то вы наверняка знаете, как важно прорешивать задачи для полноценного, осознанного и глубокого понимания изученного материала. Когда нет или совсем мало реальной практики, задачи дают возможность покрыть практикой все теоретические знания, погрузиться в неожиданные выводы, сложности, баги, препятствия. Более того, даже если практики достаточно, задачи помогают относительно быстро, комплексно и глубоко проработать типичные и нетипичные ситуации, возникающие в разработке (любой другой науке). Это всегда безопасный (никто не взрывает лабораторию и не роняет прод), доступный и удобный способ подробно разобраться в предмете. Определённо, программирования это касается в первую очередь.

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»

В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.

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

Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech. 

Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.

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

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

я Андрей Поснов, переехал из Москвы в Барселону с женой и собакой: въехал по туристической визе, получил студенческую, а как только появилась digital nomad visa, подался на нее. Я работаю инжиниринг-менеджером в американском стартапе удаленно и веду свой ютуб и телеграм каналы

Я получил сначала студ резиденцию а потом внж номада потому что раньше внж номада не было, а теперь можно въехать по шенгену и податься на внж цифрового кочевника

PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.