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

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

Помните: если что-то не компилируется, это псевдокод. 

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

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

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

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

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

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

В предыдущих статьях "PostgreSQL Antipatterns: навигация по реестру", "PostgreSQL 13: happy pagination WITH TIES" и "SQL HowTo: курсорный пейджинг с неподходящей сортировкой" я уже рассматривал проблемы навигации по данным, представленных в виде плоского реестра.

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

Придумывать интерфейс интересно. Похоже на головоломку. Вот что получается для Dgrm.net.

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

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

В качестве прототипа статьи был выбран доклад Федерико Луиса, основателя компании Corvalius (они занимаются R&D). Работая над движком базы данных для одного из клиентов, они посвятили около четырёх лет задачам оптимизации. Такое количество времени требуется для того, чтобы применить разного рода техники и достичь хороших показателей оптимизации. Требуется выявить все проблемы и узкие места, проследить поведение софта в соответствии со всеми имеющимися метриками и так далее. Примеры из этой статьи основаны на работе над RavenDB 4.0 (известная NoSQL база для .NET), которую компания Федерико тюнила до уровня наносекунд во всевозможных сложных кейсах.

Все примеры, которые встретятся вам в ходе рассказа (плюс некоторые дополнительные), доступны в специальном репозитории на GitHub.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p. На слайдах присутствует важный для понимания статьи код.

Музыкальный строй, основанный на последовательности шагов чистой квинтой, в Европе известен, как пифагорейский строй, а в Китае он получил название музыкальной системы 12 люй. Оба древних музыкальных строя абсолютно идентичны в плане математических пропорций всех образуемых интервалов.

Как известно, двенадцать ступеней древнего китайского строя образованы последовательностью 11 квинтовых шагов. При этом все нечетные ступени, включая первую, считаются мужскими (Ян), а все четные ступени, включая двенадцатую, считаются женскими (Инь). Стартовой ступенью строя в рассматриваемой модели выбрана ступень A первой октавы. В таблице даны результаты расчета частотных значений 12 люй при стандарте частоты ступени Ля = 440 Гц. Частотные значения всех ступеней приведены в границах первой октавы. 

За несколько недель до 14 февраля системе Dodo IS немного поплохело под нагрузкой. Одной из причин стало то, что в backend’ах мобильного приложения и сайта не совсем корректно работали политики поверх HttpClient’а (Retry, Circuit Breaker, Timeout). В этой статье я хочу поделиться с вами потенциальными проблемами, которые могут возникнуть при неправильном использовании таких политик.

Эта статья будет полезна, если вы начинаете проект, который может перерасти в HL (HighLoad) или у вас уже есть проект, который имеет высокую нагрузку. Каждый пункт этого чек-листа поможет избежать определенных проблем, возникающих в процессе эксплуатации таких систем. И хотя некоторые пункты могут показаться довольно очевидными, а иные даже лишними, я рекомендую ознакомиться со всем списком, т.к. судя по статьям на хабре, периодически с некоторыми из этих проблем встречаются компании, которые уже обрели некоторую популярность. Дополняя систему каким то компонентом довольно просто забыть о таких вещах, как KeepAlive между двумя сервисами, а процессы изменения и дополнения в IT происходят постоянно.

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

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.

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

Нет, я не болен. По крайней мере так говорит голос в моей голове. Я наркоман. Вот уже более 15 лет я сижу на игле. Употребляю много, жёстко, до обморочного состояния. Докатился до того, что в последнее время не стесняюсь ни друзей, ни жены, ни детей… Двоих детей! Не люблю бадяженый, люблю чистый, без примесей. За годы перепробовал многое, но в последнее время остановился в поисках. Забавно осознавать, что от одного и того же получаешь одновременно и боль, и радость. Мне бы в лечебку, я даже хочу, я даже знаю в какую. Знаете такие, где продолжаешь употреблять, но под присмотром?

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

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

Теперь «фриланс» становится новым трендом. И поскольку многие начинают к нему присматриваться, первый вопрос, который возникает: «Где можно найти хорошие предложения по удаленной работе?»

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

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

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

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

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

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

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