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

Теперь это НЕ перевод. Это моя интерпретация тех частей содержания первой половины Поста: Как на самом деле Async/Await работают в C#, которые мне показались заслуживающими внимания в этой работе, с моими пояснениями относительно того почему у меня возникла именно такая интерпретация материала.

Судя по количеству просмотров, работа вызывает интерес, но пробиться сквозь нагромождение терминов трудно даже для подготовленного читателя, как мне кажется. Я хочу попробовать перевести не с английского на русский, а с некоторого кулуарно-профессионального на какой-то более доступный язык. Не знаю, насколько доступный, надеюсь получить некоторый отклик, который поможет мне понять, насколько у меня это получилось. Заранее хочу сказать, что автор действительно изложил как или во что компилируются конструкции Async/Await и, соответственно, как они работают изнутри. Проблема в том, что автору пришлось написать большую подготовительную часть чтобы подвести к изложению этого внутреннего устройства Async/Await. И мне, волей неволей, придется пройтись по всему что предваряет, собственно, основную идею в реализации Async/Await. Поэтому запаситесь терпением либо начинайте читать сразу последнюю часть.

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

Дисклеймер 1

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

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

Также до недавнего времени корпорации всеми силами продвигали идею ремонта выпущенных ими гаджетов в корпоративных же сервисных центрах. Так делали Apple, Microsoft, Samsung и другие компании. Но сторонники идеи «права на ремонт» смогли это изменить, и сейчас она вовлекает всё больше участников. Например, Samsung Electronics объявила о расширении программы самостоятельного ремонта Samsung Self-Repair. Не отстают и другие компании, о чём расскажем под катом.

Дисклеймер: в данной статье используется материал из разных источников, статей и блогов. Ссылки на полезные материалы можно найти в конце статьи – в разделе Источники.

В данной статье кратко разбирается понятие распределенной сети (distributed networks), чем она отличается от других видов организации сети. Также в статье рассказывается про децентрализованные приложения (decentralized applications), в сравнении с классическими приложениями.

Для личных нужд я использую bare-metal сервер от Hetzner, порезанный на виртуалки и, с недавних времен, VPS на HostHatch для мониторинга и резервирования. Также есть маленькая ВМка у TietoKettu (для ВПН, экспериментов и прочее).

Так как IPv4-адресов мало, то хостинги обычно дают дополнительные айпишки за дополнительные деньги, а вот IPv6-сети выделяют щедро. Изначально, я объединил все виртуалки, у которых был публичный IPv4-адрес в Wireguard mesh сеть, но потом когда выяснилось, что надо бы присоединить ещё одну ВМку, пришлось переделать mesh на IPv6-адреса и тут понеслось...

Сначала выяснилось что у HostHatch нет связности с ElmoNet (TietoKettu использует их адреса), после недели-двух бодания с техподдержкой HostHatch-a связность появилась. Однако недели две назад от них приходит письмо, о техобслуживании нод, где живут мои ВМки. И что вы думаете? После обслуживания туннель до этих ВМок так и не восстановился. В итоге, оказалось что обе вмки исчезли их IPv6-интернета. На этот раз связность починили только через 3 дня, хотя я создал срочный тикет.

В итоге, я перевёл туннели обратно на IPv4 и переключился на DN42, но в один выходной мне на глаза попалась статья на Reddit и я решил воскресить идею о "своем" куске Интернета. Масла в огонь подбавил Vultr, который наглухо заблокировал доступ на свои ресурсы (даже IP calculator) с Hetzner.

В одном из комментов, к вышеупомянутой статье, была ссылка на IPv6-сообщество в Discord. Я присоединился и стал задавать много вопросов в канале #asn-newbies.

Думаю, что кому-нибудь мой опыт и набитые шишки будет полезен. Если это так, то прошу под кат.

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

Буквально два года назад, имея базовые знания навигации в консоли Linux, написание несложных batch-файлов и небольшой опыт VBScript открыл для себя PowerShell, и после этого я уже в прямом смысле этого слова, не мог остановиться реализовывать свои идеи, правда, такое дело очень затягивает. В один момент решился завести канал на GitHub и там же по сей день виду работу с заметками, где за это время накопилось более 6 тысяч строк из описания работы cmdlet (PowerShell-команд) и утилит для Системного Администратора (AD, Exchange, VMWare, MSSQL и т.д.) с примерами, ведь далеко не все получалось найти в интернете, порой, только изучая на практике свойства и методы объектов, можно получить желаемый результат. Так же набралась небольшая коллекция модулей и тестовый стенд WinForms с примерами работы различных методов, на котором я в дальнейшем базировался для написания приложений с графическим интерфейсом. Все работы писал по большей части для себя с целью автоматизировать и разгрузить текущий рабочий процесс, иногда помочь коллегам, именно по этому мне хочется поделиться своими наработками, возможно кому-то это еще сможет пригодиться.

Когда я ищу информацию о принципе KISS в Интернете, я натыкаюсь на множество сайтов, определяющих его в паре строк: важна простота, давайте быть простыми, конец. Они часто не объясняют, что такое простота, почему простота важна и как ее достичь.

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

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

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

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

Мы все были там: Вы работали над множеством изменений одновременно, некоторые из которых не имели ничего общего. Для удобства вы решили объединить все эти изменения в один коммит и на этом закончить. Но хотя это может показаться заманчивым, на самом деле это может привести к большим проблемам в дальнейшем. Большие коммиты могут:

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

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

Предисловие

Вечерком воскресенья в середине марта мне поступил телефонный звонок, суть которого заключалась а том, что 200+ человек не приедут в понедельник в офис, а переводятся на «удалёнку». Фраза: одни на «удаленку», а админы на «продлёнку», завертелась у меня в голове.

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

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

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

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

Это перевод первой главы из поста How Async/Await Really Works in C#

Этот пост .Net блога является продолжением исходного поста, глубоко погружающим в историю, приведшую к созданию конструкций async/await и стоящие за этим дизайнерские решения и детали реализации async/await в C# и .NET.

Исходный пост What is .NET, and why should you choose it? предоставляет обзор платформы на высоком-уровне, перечисляя различные компоненты и решения на уровне дизайна, и предваряя последующие посты в глубину обозначенных тем.

Ссылки в развитие темы:

1. Часть 2 Артефакты от EAP шаблона, SynchronizationContext

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

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

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

Привет, Хабр! Меня зовут Саша, я Full-Stack разработчик и последние 7 лет пишу фронтенд, 6 из которых я работаю в американском стартапе. 

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

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

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

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