Senior Back-End Developer .NET Core C#
Когда речь заходит о многозадачности в .Net, то в подавляющем большинстве случаев предполагается вытесняющая многозадачность на основе потоков операционной системы. Но в этой статье речь пойдёт о реализации кооперативной многозадачности, с помощью которой можно создать видимость одновременной работы нескольких методов, используя всего один единственный поток.
Из этого поста вы узнаете, зачем добавлять в интеграционный слой бизнес-логику, что случается, когда «не летит» Service mesh, и почему иногда костыли — лучшее решение проблемы.
Привет Хабр, на связи Иван Большаков — архитектор интеграционных решений, эксперт департамента разработки ПО КРОК. Я расскажу, как мы делали интеграционный слой для CRM-системы группы контакт-центров торговой сети Пятерочка.
Всего в системе одновременно находятся десятки тысяч пассивных пользователей с открытыми интерфейсами и сотни активных, которые пишут в чаты, принимают звонки и нажимают на кнопки. Операторы одновременно работают с десятком различных систем…
Микросервис — это структурная единица, в которой все данные и функции, относящиеся к какой-нибудь одной конкретной бизнес-цели, объединены в один сервис.
Что ж, это достаточно общее понимание микросервиса, но что мы на самом деле под ним подразумеваем?
Для примера мы можем взять конструктор Lego, да, вы не ослышались, Lego.
Возможно, вы помните, что когда мы играем с Lego, мы начинаем сборку конструкции с одного отдельного кирпичика Lego.
Точно так же, как каждый кирпичик Lego обособлен от других, каждый микросервис независим, но является составным элементом, из которых создается нечто большее.
Здесь мы можем провести наглядную параллель между микросервисом и кирпичиком Lego.
Очень часто при обсуждении многопоточности на платформе .NET говорят о таких вещах, как детали реализации механизма async/await, Task Asynchronous Pattern, deadlock, а также разбирают System.Threading. Все эти вещи можно назвать высокоуровневыми (относительно темы хабрапоста). Но что же происходит на уровне железа и ядра системы (в нашем случае — Windows Kernel)?
На конференции DotNext 2016 Moscow Гаэл Фретёр, основатель и главный инженер компании PostSharp, рассказал о том, как в .NET реализована многопоточность на уровне железа и взаимодействия с ядром операционной системы. Несмотря на то, что прошло уже пять лет, мы считаем, что никогда не поздно поделиться хардкорным докладом. Гаэл представил нам хорошую базу по работе процессора и атомнарным примитивам.
Вот репозиторий с примерами из доклада. А под катом — перевод доклада и видео. Далее повествование будет от лица спикера.
У нас в TeamHood есть wiki. Там собралась коллекция рекомендаций, в том числе, по улучшению производительности тяжелого фронтенда на vue.js. Улучшать производительность понадобилось, потому что в силу специфики наши основные экраны не имеют пагинации. Есть клиенты, у которых на одной kanban/gantt доске больше тысячи вот таких вот карточек, все это должно работать без лагов.
В статье разобрано несколько редко упоминаемых техник из нашей wiki, которые помогут сократить излишний рендеринг компонентов и улучшить производительность.
С ростом популярности сервиса мы столкнулись с нереально большим количеством мошенников, которые регистрировали фейковые аккаунты и спамили других пользователей (порно, наркотики и вся остальная запрещёнка). Дошло до того, что таких регистраций стало в несколько раз больше, чем настоящих пользователей. Жалобы и отток нормальных посетителей положили начало нашей борьбе.
Часто в проектах возникает необходимость выполнения отложенных задач, таких как отправка email, push и других специфических задач, свойственных доменной области вашего приложения. Сложности начинаются, когда обычного crontab уже не достаточно, когда пакетная обработка не подходит и когда у каждой единицы задачи свое время выполнения или оно назначается динамически.
Для решения такой задачи было создано очередное решение под названием Trigger Hook. Принципиальная схема работы показана на рисунке 1. На схеме показано, что происходит с заданиями в течения всего их жизненного цикла. Смена цвета означает смену статуса задачи.
Живу в Германии с 2014ого.
От некоторых аспектов страны до сих пор в восторге. От других хочется лезть на стенку и выть "ну почему так?" Постараюсь раскрыть и те, и другие - и раскрыть, почему останусь здесь, скорее всего, до конца жизни.
Зарплаты программистов
Ну как же без этого? Решил вопрос оплаты вынести в самое начало, ведь если он вас разочарует, то ваш интерес к стране может сразу угаснуть.
Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions. На дворе 2020 год, а мы продолжаем обсуждать «нововведения» ES6-синтаксиса и преимущества MobX над Redux. Существует много причин использовать Redux в своем проекте, но так как я не знаю ни одной, расскажу о том, почему мы выбрали MobX.
Данная статья преследует цель рассказать о новом походе к авторизации в облачных решениях, в основе которого лежит использование интерпретируемого языка определения политики управления доступом — который называется языком моделирования PERM (PML). Данный язык можно использовать для выражения различных моделей управления доступом, таких как список управления доступом (ACL), управление доступом на основе ролей (RBAC), управление доступом на основе атрибутов (ABAC) и других. А также рассказать о практическом воплощении этого подхода в виде конкретной реализации кросс-языковой библиотеки авторизации Casbin
Мы уже публиковали свои внутренние документы с ожиданиями от инженеров и менеджеров продукта в плейбуке на Гитхабе. Пришло время поделиться ещё одним — кодексом тимлида.
Кристиан Вервейс: О сложности или зачем вам Скрам?
Предисловие переводчика
Предупреждение: Это лонгрид и это достаточно серьезный текст, далекий от большинства “простеньких” объяснений что вы могли прочитать на русском про Скрам и Эджайл.
Оригинал статьи находится тут. Статья входит в список scrum.org рекомендованного к изучению для подготовки к экзамену PSM III.
Важность таких статей сложно переоценить. Судя по ошибкам, которыми делятся команды, и некоторым комментариям, значительное количество людей, пытающихся применить Agile, на самом деле не пошло дальше материалов типа “строим Скрам за 5 дней”, которые больше сосредоточены на практике, а не на причинах и не на основополагающих принципах Скрам и Эджайл. Я сам, как руководитель, изначально столкнулся именно с такой, “от сохи”, реализацией Скрама, но, к счастью для себя, не сделал “обоснованный” вывод что весь этот ваш Скрам - это очередная подделка и модная глупость, а полез разбираться откуда и зачем есть пошел Эджайл и прочие Скрамы. Честно скажу - объем “открытий чудных” был намного больше ожидаемого, несмотря на годы опыта в управлении проектами, накопленные к тому моменту. Так что, надеюсь, что перевод достаточно важной для понимания Скрам статьи будет полезен почтенной публике, и, конечно же, я сам, как сертифицированный Скрам-мастер и человек преподающий Скрам и Эджайл, буду рад ответить на все вопросы.