Я рискну все таки продолжить изложение своего понимания Поста: How Async/Await Really Works in C#, которое в предыдущей статье получило название “ортогональный взгляд”. Также, недавно мы познакомились (возможно несколько преждевременно) с изначальным определением концепции SynchronizationContext на которую ссылается автор этого Поста.

Это не перевод. Это изложение содержания Поста на разных уровнях раскрытия сущностей и их взаимодействия по мере развития (эволюции) моего понимания тех мыслей и идей, которые, как мне кажется, хотел донести до читателя автор Поста Stephen Toub.

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

В этот раз попробуем сформулировать задачу, которую решает компилятор, то есть те разработчики, которые разрешили нам пользоваться конструкциями Async/Await в C#.

Насколько я понял из комментариев к своим предыдущим статьям по этой теме:

1. Часть 1. Проблемы модели асинхронного программирования (APM)

2. Уроки по асинхронному программированию из первой половины работы

3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)

4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас

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

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

В этот раз я достаточно внимательно прочитал перевод главы про задачи(Tasks) из этого Поста, чтобы выяснить, что он не очень точно передает смысл исходного текста. Я попробую пересказать содержание так, как я его понял, в том числе полагаясь на свой практический опыт программирования многопоточных приложений и embedded приложений с множеством прерываний.

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

Пару ссылок на предыдущие работы по этой теме вы тоже найдете под катом.

Фото Florencia Viadana, Unsplash.com

После почти пятилетних разработок протокол HTTP/3 наконец приближается к окончательному выпуску. Предыдущие итерации уже доступны как экспериментальная функция, но в 2021 году мы ждём широкого распространения протокола. Что такое HTTP/3? Зачем выпускать его так рано после HTTP/2? Как его можно или нужно использовать? Как он влияет на производительность?

Ежедневно на просторах сети появляются и исчезают тысячи сайтов. Создание сайта уже давно является неотъемлемой частью успешного бизнеса. Однако содержание сайта должно соответствовать законодательству. В противном случае сайт может быть оказаться в Едином реестре запрещенных сайтов и заблокирован Роскомнадзором.

По данным Роскомсвободы, по состоянию на 30 марта 2021 года Единый реестр запрещённых сайтов содержит 442357 заблокированных доменов и указателей страниц. С каждым днем этот список становится масштабнее.

Блокировка сайтов осуществляется в порядке, предусмотренном Федеральным законом от 27.07.2006 №149-ФЗ "Об информации, информационных технологиях и о защите информации", который можно представить следующим образом:

Категория защиты персональных данных тесно связана с таким фундаментальным правом человека, как право на защиту неприкосновенности частной жизни, что прямо указывается в ст. 2 Федерального закона от 27 июля 2006 г. N 152-ФЗ «О защите персональных данных». Хотя не всегда право на защиту персональных данных по своему объему совпадает с правом на защиту неприкосновенности частной жизни, положения его закрепляющие, а также некоторые положения гарантирующие иные основные права и свободы в Конституции РФ по существу включают и право на защиту персональных данных. Учитывая положения международных документов в области прав человека, опыта ЕС и других государств, в качестве примера таких положений Конституции охватывающих право на приватность и защиту персональных данных можно назвать ст. 23, 24, ч. 1 ст. 26. 

При анализе текста Конституции, помимо отсутствия явно выраженного права на защиту персональных данных, обнаруживается непоследовательность в соответствующих положениях. Так, в случае ч. 2 ст. 23 Конституция предоставляет широкую защиту коммуникаций человека – «право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений». А в ч. 1 ст. 24 закреплено требование получения согласия лица при обработке информации о его частной жизни (Сбор, хранение, использование и распространение информации о частной жизни лица без его согласия не допускаются), пределы которой не являются объективными: как неоднократно указывал Конституционный Суд РФ в своих решениях: «лишь само лицо вправе определить, какие именно сведения, имеющие отношение к его частной жизни, должны оставаться в тайне». Похожая на положение ч. 1 ст. 24 Конституции РФ формулировка возведена также и в принцип регулирования отношений в сфере информации, информационных технологий и защиты информации (п. 7 ст. 3 Федерального закона от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации»).

22 ноября 2021 года президент Владимир Путин подписал закон № 377-ФЗ, который внес в Трудовой кодекс три новые статьи (ст. 22.1 — 22.3). Они регулируют правила электронного документооборота в организации. Давайте разберемся, что стало причиной их принятия и как теперь организации и индивидуальные предприниматели обязаны будут вести кадровое делопроизводство в цифровом виде.

Зачем вообще понадобилось принимать эти изменения?

Дело в том, что долгое время вопрос о законности применения электронных документов в вопросах кадрового делопроизводства вызывал самые противоречивые мнения как у специалистов, так и у органов власти. До начала пандемии, например, даже Минтруда России в своем письме указывало, что право работодателя, какую форму ведения документации ему выбирать — бумажную или электронную — не распространяется на те документы, которые либо предоставляются под роспись работнику, либо прямо предусмотрены ТК: такие документы могут быть исключительно бумажными (письмо от 06.03.2020 N 14-2/ООГ-1773). Подобная же точка зрения имела место быть и у многих региональных судов — в Белгороде, Екатеринбурге, Омске и других городах.

Во время весеннего локдауна позиция министерства начала постепенно меняться. Чиновники начали допускать возможность обмена электронными документами между работодателем и работником, при условии того, что потом они будут оформлены нормативно в надлежащем порядке (см. например, п. 3 письма Минтруда РФ от 27.03.2020 N 14-4/10/П-2741, информацию Роструда от 27.04.2020 (п. 12) и т.д.)

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

Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.

Согласно 15-му ежегодному отчету State of Agile, опубликованному в июле 2021 года на digital.ai, за последний год объем внедрения гибких методологий значительно вырос. В командах разработки программного обеспечения использование Agile выросло с 37% в 2020 году до 86% в 2021 году. Такой стремительный рост может означать, что многие сотрудники, работающие в рамках гибкой методологии, не проходили формальных обучающих тренингов, что формирует идеальную среду для распространения некорректной информации. В статье приведем несколько примеров наиболее распространенных заблуждений о скраме.

В преддверии старта курса "Enterprise Architect" подготовили для вас текстовую версию демоурока, который провел эксперт OTUS - Петр Подымов.

В рамках урока поговорили:

- об обоснованных структурных изменениях в компании в быстро меняющихся условиях;

- о применении архитектурного подхода в вопросах трансформации;

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

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

Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества.

Статья не раскрывает лучшие практики использования микросервисов и не разоблачает их излишнюю популярность. Основная цель - описать технологию и процесс работы с ней с точки зрения системного аналитика.

Привет, Хабр! Мы в Dodo Pizza Engineering очень любим данные (а кто их сейчас не любит?). Сейчас будет история о том, как накопить все данные мира Dodo Pizza и дать любому сотруднику компании удобный доступ к этому массиву данных. Задача под звёздочкой: сохранить нервы команды Data Engineering.

Дисклеймер: на момент написания статьи мы думали так, но время расставило всё по своим местам. Сейчас всё иначе. Если хотите узнать, как именно, — приходите к нам на собеседование на позицию дата-инженера.

В одном романе для того, чтобы подчеркнуть бесспорную красоту и поразительную сексуальность одной из героинь, автор использовал фразу: "She was a such kind of woman, that every man look at twice". Что в литературном переводе можно понять: "Одна была такой женщиной, что каждый мужчина оборачивался ей в след".

И точно такую же фразу я могу применить к бесподобной книге "Предметно-ориентированное проектирование (DDD)" Эванса Эрика. К ней хочется возвращаться каждый раз, когда ты садишься за проектирование системы в незнакомой тебе области. Словно маяк во время шторма, она помогает вести вашу галеру через сложности, чтобы все гребцы увидели землю, а проект увидел успешный старт.

И в этом обзоре, я расскажу, почему, по моему мнению, это MUSH HAVE книга для каждого middle+ разработчика.

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