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

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

Во времена, когда .NET был закрытой технологией только для Windows, за ним и языком C# закрепилась репутация платформы, которая отлично подходит для решения бизнес-задач, но непригодна для соревновательного программирования и написания высокопроизводительного кода.

Часто приходится слышать, что "шарпы медленные", особенно в контексте алгоритмических задач, например с timus.online и codeforces.com. И, увы, не только слышать, но и сталкиваться с реальными проблемами, связанными с особенностями платформы, получая Wrong Answer, Runtime Error, Memory Limit, Time Limit при корректном алгоритме.

Большинство этих проблем кроется в особенностях консольного ввода и вывода. Да и часто куда проще написать cin >> nили sc.nextInt(), чем int.Parse(Console.ReadLine()) или Console.ReadLine().Split().Select(int.Parse).ToArray(), из-за чего выбор падает на другой язык.

Далее я расскажу о распространённых проблемах с консольным вводом-выводом в .NET, и о том, как сделать ввод быстрым и удобным.

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

Когда я говорю о простоте, то это не фигура речи. Если бы вы сидели напротив меня я уверен, что за 15 минут я научил бы ЛЮБОГО из вас. Ни знаний физики, ни знания математики не требуется. Это похоже на магию. Вы делаете простые операции с натуральными числами и ... в конце получаете все необходимые параметры схемы. В этом сила, красота и, возможно, проклятие этого подхода.

Если бы вы сидели напротив меня... но вы не сидите, и не так-то просто изложить всё это письменно. Я постарался. Если у меня получилось, то через 20 - 30 минут вы сможете рассчитать ЛЮБОЙ пассивный четырёхполюсник с линейными элементами.

Итак, засекаем время.

Некоторые IDE и текстовые редакторы парсят исходный файл целиком при каждом изменении, что может тормозить на больших файлах, а некоторые делают это построчно с помощью регулярных выражений, что тоже тормозит и не даёт качественной подсветки кода, т.к. теряется контекст. Для решения этих проблем в недрах GitHub был создан tree-sitter - инкрементальный парсер, который используют всё больше и больше проектов. Давайте разбираться зачем и почему.

В статье я хотел бы поделиться своим опытом написания инсталлятора для Windows с использованием инструмента Windows Installer XML Toolset (далее - Wix). К сожалению, несмотря на всю мощь данного инструмента, его использование сильно осложняется куцей документацией, старенькими кукбуками, вялыми ветками форумов и вытеснением .msi и .exe пакетов контейнеризацией. Однако, сегодня продолжают активно развиваться и создаваться программные продукты требующие развертывания на виндовой машине с использованием традиционных установочных пакетов.

Привет, Хабр!

Сегодня я хотел бы рассказать о генерации идеального лабиринта - алгоритмом Эллера. Статья подойдёт всем любителям алгоритмов.

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

14 февраля 2022 года GitHub объявила о старте нативной поддержки диаграмм Mermaid.js в README-файлах GitHub. Нововведение помогло быстрее и эффективнее оформлять блок-схемы и графики для документации. До этого диаграммы вставлялись в виде изображений и если содержимое менялось, то надо было сначала нарисовать новое изображение, а потом вставлять его. Сейчас же можно просто исправить несколько строк в коде и система сгенерирует новый график.

Проблема традиционных цветовых пространств

RGB

• градиент красного — это цвета #000, #100, #200, #FEE, #FFFи т.д.;
• градиент зеленого — это цвета #000, #010, #020и т.д.;
• градиент синего — это цвета #000, #001, #002и т.д.;
• градиент желтого — это цвета #000, #110, #220и т.д.;
• градиент голубого — это цвета #000, #011, #022и т.д.;
• градиент пурпурного — это цвета #000, #101, #202и т.д.

• Яркость цветов увеличивается неравномерно: чем оттенок ближе к белому цвету, тем изменение яркости меньше;
• Яркость разных цветов различается: синий намного темнее остальных;
• Насыщенность также неравномерна: синий и красный выглядят «ненасыщенными» в правой части градиента.

Можно читать и не понимать, можно читать и понимать, а можно читать и понимать даже то, что не написано. Всё зависит от того, как, в какой форме и с каким настроением автор создал текст, передал ли он смысл, поделился ли ценной информацией или крутой историей. Ежедневно на Хабре выходит около 60-70 статей, не считая новостей — какие-то набирают десятки тысяч просмотров, какие-то еле дотягивают до тысячи. Иногда причины очевидны, а иногда даже мы, опытная команда Хабра, теряемся в догадках, что же не понравилось (или понравилось) читателям. Анализ чужих и собственных публикаций подтолкнул меня к этому лонгриду. Читать — не перечитать.

Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.

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

Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.

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

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

Напишите функцию, выводящую список целых чисел от 1 до 100, но вместо каждого числа, кратного 3, она должна выводить «Fizz», а вместо каждого числа, кратного 5, выводить «Buzz». Вместо чисел, кратных и 3, 5, программа должна выводить «FizzBuzz»; все остальные числа должны выводиться без изменений.

1. Имеющие делитель 3, но не 5
2. Имеющие делитель 5, но не 3
3. Имеющие делитель и 3, и 5
4. Не имеющие делитель 3 и 5

• «Fizz», если $$ и $$ является взаимно простым с 5
• «Buzz», если $$ и $$ является взаимно простым с 3
• «FizzBuzz», если $$ и $$
• $$ во всех остальных случаях.

[(lambda n: { 1: n, 6: "Fizz", 10: "Buzz", 0: "FizzBuzz" }[n**4%15])(n+1) for n in range(100)]

(1..100).map{|n| {1 => n, 6 => "Fizz", 10 => "Buzz", 0 => "FizzBuzz"}[n**4%15] }

Привет, меня зовут Григорий Бизюкин, я преподаватель Школы разработки интерфейсов и фронтенд-разработчик в Яндексе. Давайте поговорим о функциональном программировании в мире JavaScript. Мы все про ФП что-то слышали, нам всем оно интересно, но у меня, когда я искал полезные материалы для подготовки к лекциям, сложилось такое впечатление: есть куча статей, каждая из которых либо говорит об ФП общими словами, либо раскрывает отдельный маленький кусочек темы, чего, конечно, недостаточно.

^{Добавим функционального света}

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

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

Будет рассказано о декораторах, стратегиях, Entity Component, Entity Component System, деревьях, State Machine, частично о хранении хуков в React.

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

В этой статье мы поговорим о мышцах, о том какие они бывают и за счет чего растут