.NET разработчики знают, что такое ждать сборки кода. Работать при этом невозможно: пока не увидишь, как обновится приложение, — не перейдешь к следующему шагу. А переключиться на другую задачу за это время не успеешь. Получается, если в день переписать код 5 раз, можно потерять полчаса при сборке, а то и больше.

Теперь на примере платформы автоматизации маркетинга Mindbox. Основное программное решение — это монолит на C#: несколько миллионов строк, 50 проектов, над которыми одновременно работают десятки команд. Даже сэкономленная при сборке минута выливается в кучу продуктивных человеко-часов. Поэтому, когда речь зашла о переходе всей компании на MacBook в будущем, мы решили выяснить, как это отразится на производительности.

Люди на Земле уже многие века как-то решают свои внутренние конфликты. Да что там говорить - это умеют делать даже обезьяны. Хотя у людей получается лучше: нам помогают не только инстинкты и развитый неокортекс, но и чужой опыт: мифы, религии, философские учения, нормы культуры, а порой даже и книги об "успешном успехе".

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

В этой статье вас ждёт:

• Дизассемблирование структуры внутреннего конфликта до атомарных инструкций
• Путешествие в джунгли legacy-кода, хранящегося в чертогах подсознания.
• Разрешение внутренних конфликтов как выплата техдолга,
• Формирование эффективных промптов для бионейросети (той, которая между ушами)
• Простота: фреймворк, который подходит для решения доброй половины внутренних конфликтов
• Глубина: экстремальное погружение во внутренний мир человека.

• Цикл событий
  　Задачи, тики и Web API
  　Очередь задач
  　16,6 миллисекунды на задачу
  　Обработка больших задач
  　Микрозадачи
  　requestAnimationFrame
  　requestIdleCallback
  　Сравнение очередей
  　Цикл событий в Node.js
• Функции обратного вызова
  　Ад обратных вызовов
  　Не выпускайте Залго
  　Жёсткая сцепленность
  　Проблема доверия
• Обещания
  　Цепочки обещаний и проброс отказа
  　Неявное поведение
  　　Возвращение нового обещания
  　　Спрятанный try/catch
  　Thenable-объекты
  　Статические методы
  　　Promise.all
  　　Promise.race
  　　Promise.any
  　　Promise.allSettled
  　Промисификация
  　Обещания или функции обратного вызова?
  　Корутины
• Async/await
  　Верхнеуровневый await и асинхронные модули
  　Обработка ошибок
  　Не все await одинаково полезны
• Заключение

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

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

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

Welcome!

Сегодня мы рассмотрим SOA и даже сравним его с Monolith-архитектурой!

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

До последнего времени у отдела менеджеров не было такой системы и это вызывало непредсказуемые решения в управлении кадрами и распределении проектов.

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

Ещё около 30 лет назад никто не мог бы с уверенностью сказать, имеются ли у других звёзд планеты. В настоящее время количество известных экзопланет превышает 5000, а с учётом планет-кандидатов, которых в 2021 насчитывалось 7913, общее количество таких внесолнечных миров приближается к 15000.

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

Соответственно, данные об экзопланетах отчасти неполные, а отчасти косвенные, поэтому классификация экзопланет затруднена. Тем не менее, уже открытые экзопланеты гораздо разнообразнее, чем миры, имеющиеся в нашей Солнечной системе. По некоторым источникам, самый распространённый класс планет – это «суперземли».  Примерно из 4000 экзопланет, достоверно известных к концу 2021 года, к числу суперземель относится примерно 1500. Возможно, это крупные скалистые планеты с атмосферой и гидросферой, превышающие по размеру Землю в 3-10 раз. Но почему, в таком случае, подобной планеты нет в нашей системе, ведь это противоречит принципу заурядности? Ниже мы обсудим, что нам сейчас известно о суперземлях и других экзотических классах планет, как образуются суперземли, и существуют ли они вообще.      

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

• препятствование прямому общению между объектами для уменьшения связности;

• нацеливание на Message-Oriented архитектуру;

• поддержка асинхронного внутреннего обмена сообщениями;

• ориентирование на переиспользование объектов.

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

Существует множество статей о MediatR, но лишь их малая часть фокусируется на недостатках и помогает определить случаи, когда использование инструмента не имеет смысла. Этот пост один из таких.

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

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

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

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

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

В первый месяц стажировки ментор мне говорил: «В жизни каждого уважающего себя менеджера должен быть один легендарный факап». А что скажете насчёт пяти? 

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

Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.

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

После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".

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

Введение

Всем привет. Все мы пользовались консольными приложениями. Да и наше первое приложение "Hello, world!" - консольное. Я решил сделать свое + с поддержкой аргументов. Столкнулся с тем, что я не знал как правильно их создавать. В этом посте я расскажу как шаг за шагом проектировал самую сложную на мой взгляд часть - работу с аргументами командной строки.

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

Между делом она обозначила, что воспитательные приёмы – а детей мы тоже затронули (в целом – своих нет) – это не что иное как манипуляция. А раз так, то и со взрослыми есть некоторая градация допустимости «грязных трюков». 

Чтобы оспорить позицию «приём = манипуляция», я поспрашивал знакомых педагогов, есть ли какой-то справочник, с которым можно было бы свериться

Я уж и забыл про крепостных в ИТ, но сегодня обратился знакомый и всколыхнул воспоминания пятилетней давности. Симптомы один в один: деревенский ИТ-директор решил сменить работу, но никак не может найти предложение с зарплатой, даже близко похожей на текущую. Потому что никому не нужны крепостные крестьяне.

Крепостными становятся, обычно, ИТ-специалисты, работающие в штате клиентов. Соответственно, это ИТ-директора, программисты (обычно 1С) и сисадмины. Есть ли такое в ИТ-компаниях – не знаю, тут интересно вас послушать.

Кратко напишу, что это за дичь.

When you have an IT, which supports all aspects of your organization automated performance and you have a firm confidence that IT executes well, there is always a chance that something could go wrong in technology or in related IT processes. Depending on complexity of IT environment varieties of risks scenarios could arise. This article as a summary of different faithworthy sources aims to help you in getting high level understanding on what could go wrong and how you can predict it in a more conscious way.

My name is Maxim Tornov and I have been working in various IT areas for a long period of time. Since then, for over 14 years I am working in the area of IT/IS risk management with focus on in IT/IS audits, internal control implementation and assessment.

I am sure that at the present the topic of Information Technologies risk management became more vital. Organization’s efficiency in IT risk management directly affects the achievement of various organization’s goals, goals which have dependency on IT, those goals may include reliability and efficiency of business processes, the organization's compliance with regulatory requirements, the integrity of financial reporting, and many others.

I sincerely hope that this material will be useful to you and may give you some new ideas that you can contribute to the benefit of your personal development and the development of your organization's risk management culture.