Представляю вашему вниманию перевод статьи The Magical Methods in C# автора CEZARY PIĄTEK.

Есть определенный набор сигнатур методов в C#, имеющих поддержку на уровне языка. Методы с такими сигнатурами позволяют использовать специальный синтаксис со всеми его преимуществами. Например, с их помощью можно упростить наш код или создать DSL для того, чтобы выразить решение проблемы более красивым образом. Я встречаюсь с такими методами повсеместно, так что я решил написать пост и обобщить все мои находки по этой теме, а именно:

• Синтаксис инициализации коллекций
• Синтаксис инициализации словарей
• Деконструкторы
• Пользовательские awaitable типы
• Паттерн query expression

Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.

Для чего нужен CMS

Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.

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

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

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

А теперь посмотрим, что происходит, когда мы эту идею пытаемся реализовать.

Прим. перев.: Jaana Dogan — опытный инженер из Google, которая в данный момент занимается вопросами наблюдаемости production-сервисов компании, написанных на Go. В этой статье, снискавшей большую популярность у англоязычной аудитории, она в 17 пунктах собрала важные технические детали, касающиеся СУБД (а иногда — распределённых систем в целом), которые полезно учитывать разработчикам крупных/требовательных приложений.



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

Хочу поделиться с сообществом своим недавним опытом поиска работы, сообщить, так сказать, вести с передовой. Несмотря на то, что все написанное – абсолютно субъективно, заметка будет полезна для других IT-шников. Особенно – если они интроверты и редко ходят по собеседованиям.

А еще, полагаю, многим будет любопытно, какая метаморфоза произошла с рынком работы в связи с последними событиями.

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

В программировании очень много вещей, в которых я разбираюсь очень плохо. Настолько много, что меня иногда спрашивают — а в чем ты вообще разбираешься?

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

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

Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.

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

И конечно, поскольку это Хабр — предложу open-source библиотеки для решения проблемы.

В CSS существует несколько способов представления цветов. Один из них — система HSL. В этой статье я покажу вам, какие возможности она открывает для верстальщика.

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

Со стороны кажется, что задача — проехать на комбайне по полю «змейкой» и «перемолоть» всю пшеницу или другую культуру. На деле всё далеко не так. Оператор должен следить за сотнями вещей и при этом постоянно смотреть на кромку поля, чтобы двигаться ровно. Представьте себе, что вы едете 12–14 часов по трассе на скорости 120 км/час за человеком, который раз в полчаса неожиданно тормозит. Примерно то же чувствует оператор: работа невероятно монотонная, но при этом постоянно нужно быть готовым к сюрпризу.


Сюрприз может выглядеть так. Пока мы ездили «в поля», не видели ни одного целого комбайна без следов сварки.

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

Часть работы легко автоматизируется. Сейчас расскажу, что именно мы сделали и как мы модифицируем даже довольно старые комбайны своими роботами.

В мире бушует пандемия, народ скупает туалетную бумагу и гречку в промышленных масштабах, а ИТ компании в большинстве своем переводят сотрудников на удаленку. Так поступил и мой работодатель — немецкая полугосударственная контора.

В основном проблем не возникло, но одна из наших сотрудниц с месяц назад, когда все выглядело еще не так страшно, поехала в отпуск к родне в Египет и благополучно застряла там из-за закрытия границ. Ну, сама-то здорова, рабочий ноут с ней — сидит себе на карантине и работает через VPN. Неделю работает, две… На третью неделю VPN перестал подключаться. Саппорт первой линии проверил банальности навроде перезагрузки — не помогло. Вторая линия стала диагностировать: соединение уходит в вечный таймаут на стадии TLS Handshake. Отключили локальный фаерволл — не помогло. Попробовали другую машину — не работает. Другого провайдера — не работает. На этом моменте саппорты сдались и радостно спихнули проблему на меня по старому доброму принципу «во всем виноват сетевик».

Привет, друг.

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

Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Конечно подобный пост найдет голосовательное одобрение только в пламенных сердцах ИТ-подрядчиков, и бойцов прифронтовой кибернетической полосы — но думаю опубликовать будет не лишне!

Работаю АйТишником в крупной компании. В общем, все нормально и замечательно. Как-то однажды наше руководство решило идти в ногу со временем и возникли мысли автоматизироваться. Выбирали довольно долго Электронный документооборот, но либо денег жалко было много платить, либо разработчики какие-то липовые, короче, времени заняло все это переговорно-презентационное безобразие предостаточно. В конечном итоге остановились на некотором решении. Продукт адекватный, разработан под Microsoft Sharepoint 2013 Worklite Docs (я в силу некоторых обстоятельств с этой системой хорошо знаком). В общем выбор пал на него.

Мы собрали воедино все наши корпоративные хотелки, заказали, внедрили — запустили. Все нормально, все работает. Но суть не в этом. Это была присказка.

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

Важно понимать, что существует два вида документооборота — внутренний (СЭД) и внешний(ВЭДО). В России его принято называть ЭДО, но я считаю что правильнее называть его ВЭДО и СЭД так разделяют в принципе эти понятия в РФ. То есть если вы ищете систему для обмена с контрагентами, то вам нужно искать ЭДО, если для внутреннего документооборота то СЭД.

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

Я уже несколько лет занимаюсь внедрением систем электронного документооборота (СЭД). Начинал свой профессиональный путь в небольшой IT-компании, в которой работало около 10 человек. Компания внедряла коробочные решения СЭД в различных органах государственной власти. После этого я работал еще в нескольких компаниях, какие-то из них были очень даже серьезными, с серьезным подходом к проектам и серьезными бюджетами. Но независимо от масштабов компании и «раскрученности» внедряемой платформы, большинство моих проектов были нецелесообразными.
Это не значит, что все проекты были убыточны. Какие-то из них имели технико-экономическое обоснование, а какие-то даже ему соответствовали, и были действительно экономически выгодными. Но экономическая эффективность это не единственная величина определяющая целесообразность проекта.

Эта статья написана как ответ на статью «Собеседование в Додо Пиццу» со стороны разработчика с опытом синьора. Я не претендую на истинность суждений, мне хотелось бы выразить довольно популярное среди моих знакомых мнение о процессе найма в частности и жизни разработчика в целом.

Этим постом я начну небольшой цикл статей, посвящённых различных аспектам разработки приложений в системе электронного документооборота. Сегодня все более или менее мощные и современные СЭД/ECM-платформы содержат набор компонентов и инструментов для их реализации, и именно приложения, создаваемые на базе платформы, позволяют автоматизировать все разнообразие рабочих процессов клиента. Я расскажу о модели приложения платформы Docsvision, о компонентах и средствах разработки (настройки) этих приложений, о том, какие проблемы возникали у нас при реализации инструментария для их разработки, и о том, чего ждём в дальнейшем. Это будет интересно не только тем, кто плотно работает с Docsvision, но и позволит почерпнуть опыт тем, кому предстоит внедрять или развивать свою корпоративную СЭД.

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