Наша команда занимается развитием корпоративной системы электронного документооборота. В команде часть приложений разрабатывается на текущей LTS версии .NET Core 3.1, в частности, бэкэнд для SPA, а также ряд Worker Service’ов, которые с определенным интервалом взаимодействуют с СЭД.

Со временем, возникла необходимость использования этими приложениями общих мастер-данных. Для их хранения решили использовать БД PostgreSQL, так как имели свежий опыт и почти готовое окружение для его развертывания. Непосредственно для получения (а в будущем – и для записи) данных приложениями, решили реализовать Web API на .NET Core 3.1, чтобы инкапсулировать взаимодействие с БД в одном приложении и заложить возможность взаимодействия с любой системой. В качестве ORM, исходя из сложившихся практик и опыта, использовали EF Core. При этом, нужна была возможность фильтрации и получения связанных данных. Чтобы не придумывать велосипед в этой части, пришли к необходимости реализации API на основе стандартов OData.

В сети есть ряд хороших статей по реализации API OData на .NET Core, однако информация в них весьма разрозненна и зачастую авторы упускают важные нюансы, имеющиеся в реализации. В первой статье нами описана общая реализация API OData с использованием EF Core. Особое внимание при этом уделено неочевидным моментам при реализации типа связи «многие-ко-многим».

Всем привет!

Я работаю в Тинькофф, в проекте «Тинькофф Телефония». Наша основная задача — организация IP-телефонии внутри компании и за ее пределами. В день через нас проходит несколько миллионов звонков. Всей этой кухней занимаются около 10 сервисов. 

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

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

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

В этой статье хочу рассказать о том, какой интересный подводный камень таит в себе CancellationTokenSource и как это связано с нашими «утечками» памяти.

Задача линейного программирования (ЗЛП) состоит в определении значений упорядоченной совокупности переменных x_j, j=1(1)n при которых линейная целевая функция достигает экстремального значения и при этом выполняются (удовлетворяются) все ограничения (они также линейные) в форме равенств или неравенств. Требуется найти план  Х _<n> = <x₁, x₂, ..., x_n>, который обеспечивает получение целевой функцией с экстремальным значением.

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

Как выглядят номограммы и как они работают

Номограмма, что часто используется при перегонке с вакуумом приведена на рисунке ниже.

Допустим, вы провели реакцию в растворителе, а теперь собираетесь его удалить (выпарить), чтобы собрать продукт реакции. Растворитель улетучивается изнурительно медленно, а чтобы ускорить процесс, вы решаете его нагреть, но вот беда — греть раствор нежелательно, так как продукт реакции от нагревания может испортиться. Создав пониженное давление, вы уменьшите температуру кипения растворителя и сумеете его отделить не причинив вреда растворенному в нем веществу. При нормальном атмосферном давлении 760 мм ртутного столба вода кипит при 100 С, однако, при давлении 40 мм кипит уже при 34 С.

В этой статье поделюсь опытом, как уменьшить размер приложения, написанное на C# и независящее от сборки, в 2 – 4 раза.

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

Как выглядит захват рынка конкурентоспособным продуктом, можно видеть на примере, например, Chrome: за 10 лет рост на 70%. Или Android: за 5 лет рост на 75%. А вот у Linux рост пол-процента в год, несмотря на то, что он, например, лучший из существующих вариантов для использования в качестве национальных/государственных ОС.

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

Причины этой ситуации, как ни странно, те же, что сыграли роль в популярности Linux на серверах: unix-way, "Философия Unix": "Пишите программы, которые делают что-то одно, и делают это хорошо, и имеют возможность получать и принимать данные через текстовый интерфейс (потому что он универсален)".

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

В чём проблема и как решить?

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

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

• Собирает исходный код и установщик приложения
  
  • проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
  • В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
• Сразу после сборки запускает автотесты (xUnit) и анализирует покрытие тестами (OpenCover),

Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:

• отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
• публикация файлов в систему автообновления ПО.

Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

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

Недавно прошла приуроченная к выходу .NET 5 конференция .NETConf 2020. На которой один из докладчиков рассказывал про C# Source Generators. Поискав на youtube нашел еще неплохое видео по этой теме. Советую их посмотреть. В них показывается как во время написания кода разработчиком, генерируется код, а InteliSense тут же подхватывает сгенерированный код, предлагает сгенерированные методы и свойства, а компилятор не ругается на их отсутствие. На мой взгляд, это хорошая возможность для расширения возможностей языка и я попробую это продемонстрировать.

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