Теперь можно оставлять комментарии

Why reflection when generics

В C# очень мощный инструмент обобщённого программирования. Мощнее, чем в Java. Всю информацию о типовых параметрах, переданных в generic среду можно получить в runtime, и это нереально круто. Плюс к этому типобезопасность, строгие ругательства за несоблюдение выстроенных ограничений ещё в compile time. Но почему при всех имеющихся преимуществах могут прибегать к рефлексии? Давайте разберёмся.

#код

Думал, что пост выйдет короче раза в три, но не получилось. Менее интересным он от этого не стал

На хабре вышла статья, в которой по пунктам расписали, почему GitHub Copilot - провал.

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

Ну серьёзно, скомпилировали dataset из ответов на StackOverflow? Ха-ха, удачи 🤣

https://habr.com/ru/company/ispmanager/blog/683412/

#хабр

Про ИИ

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

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

Любые другие заявления - спекуляции с хайпом для непосвящённых.

Тот же GitHub Copilot весьма показательный пример. Злобные Гейтсы, Безосы и другие богатенькие рептилоиды предприняли очередную попытку уничтожить средний класс. Однако на выходе получился очередной объект насмешек и источник мемов для крупного сообщества людей.

Для тех, кто не верит, рекомендую ознакомиться с фундаментальным трудом Саймона Хайкина "Нейронные сети. Полный курс".

#мнение

Добавил к некоторым постам хештеги, чтобы их категоризировать и дать возможность навигации

Domain Driven Design

Бывает, на проектах случается, что разработчики твердят о том, как им нужен DDD, а остальная часть команды их не понимает. Чтобы понять идею и концепцию этого подхода к созданию ПО, советую ознакомиться с выступлением Алексея Мерсона на DotNext в 2019.

Современная классика докладов.

https://youtu.be/CR9mLGN9jh0

#доклады

Главная странность DDD

Чем больше я изучаю DDD, тем страннее эта история мне кажется.

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

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

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

#мнение

В рекомендованных попалось вот это…
Не понимаю, как такой доклад пустили на конференцию.
Похоже на проплаченную рекламу фонды для хомяков

https://youtu.be/ZMvhEXuDREc

Что такое cross-cutting concern?

Это термин из АОП. Однако прежде чем разобраться с его значением, необходимо выяснить, что такое concern.

Concern - это единица функциональности системы. Существует два вида функционала:
1. Ключевой функционал (core concern). Это тот функционал, который выполняет ключевые требования к ПО. Например: бизнес-логика приложения.
2. Сквозной функционал (cross-cutting concern). Это функционал, который необходим с точки зрения "обслуживающей инфраструктуры", но не относящийся напрямую к выполнению поставленной задачи. Например: синхронизация, обработка ошибок, валидация, управление транзациями, кеширование, логирование, мониторинг.

Cross-cutting concern является ключевым термином для парадигмы аспектно-ориентированного программирования, поскольку она выросла из потребности решить сложную задачу: отделить сквозную логику от ключевой.

DI vs. AOP: внедрение логгирования

Логгирование является одним из самых часто используемых примеров сквозной функциональности. Однако, каким образом внедрять этот функционал в приложение максимально просто и эффективно? Давайте разберёмся.

#код

Две главные ошибки при использовании MediatR

Написал на Хабр интересную статью, читайте и плюсуйте скорее)

Какие ошибки совершают при использовании этой библиотеки исходя из вашего опыта?

#хабр

Айтишники, поделитесь пожалуйста своими самыми смешными it-картинками за прошедшую неделю 🙏
Давайте поднимем друг другу настроение!

Не так давно я наткнулся на очень интересный доклад Дмитрия Нестерука о паттерне Visitor. Человек смог наглядно, последовательно на примере выстроить историю о чём вообще этот инструмент.

Очень огорчает, что многие люди используют его не по назначению. Даже столкнулся с этим у себя на проекте.

«Посетитель» в первую очередь не про плоские иерархии, а про обработку рекурсивными алгоритмами древовидных данных с циклическими ссылками. Хрестоматийный пример - синтаксический анализ.

#доклады

Также специально для вас прикрепил слайды, чтобы не искали.

#доклады

Поскольку моё профильное образование про разработку языков программирования, и мне интересна тематика, я так вдохновился этим докладом, что решил написать свою библиотеку!

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

У меня всегда было желание делать вклад в open-source, но скорее потому, что это база культурного кода программиста: обмен знаниями. Без него в it никуда, уж согласитесь)

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

И тогда мне в голову пришла мысль: «живём один раз!» Я загорелся идеей создать инструмент, решающий проблему и доступный для всех. Ну хотя бы сделать первую пробу пера на этом поприще. Так появилась моя интерпретация шаблона «Посетитель» - VisitorNET.

Может она никому никогда не пригодится, но факт в том, что я свой первый шаг сделал! И вам советую!

abstract override C#

Знаете ли вы, что в C# методы и свойства могут быть помечены одновременно и abstract, и override? Какие могут быть случаи применения такого двойного модификатора? Давайте разберёмся.

#код

Обходимся без регулярок

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

Задача звучит следующим образом: необходимо проверить, содержит ли строка от a до b цифр. Казалось бы, написал \d{a,b} и свободен. Но. Но. Но. Строка может состоять не только из цифр, но и других специальных и не очень символов. Ну ок, принято. Делаем replace([^\d], ""), возвращаемся к шагу 1. Однако, что-то всё ещё не так...

Давайте подумаем, а оптимально ли данное решение? Знаете ли вы вообще как работают регулярки, что это такое с точки зрения Computer Science? Если обратиться к курсам Теории Формальных Языков или Конструирования Компиляторов, то можно выяснить, что регулярное выражение это НКА. НКА превращается в ДКА и минимизируется. Встаёт вопрос, нужно ли нам всё это для задачи, решаемой за линию перебором символов строки?

Другими словами, два раза запустить сложный процесс с аллокациями и проверками или str => str.Count(char.IsDigit) is >= a and <= b ? Вопрос риторический. Вывод: учите базу.

Эта привычка прокачает тебя как программиста

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

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

Однако, как показывает практика, академические знания достаточно редко помогают разбираться в работе того или иного инструмента. Главным драйвером роста понимания является навык чтения исходного кода. И этот навык надо превратить в привычку.

Уметь читать сорцы полезно по многим причинам:

1️⃣ Ты видишь всё многообразие стилей написания кода. Способ программирования у каждого свой, это как почерк при письме. Соответственно, натренировав глаза, будешь разбираться и в том, что «доктор из поликлиники накорябал»

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

3️⃣ При исследовании подноготную популярных инструментов, можно увидеть какие решения прямо сейчас находятся в продакшене. С учётом твоего собственного опыта, опыта коллег и трендов индустрии, можно понять, какие подходы использовались при создании: вырвиглазные антипаттерны, устоявшиеся практики или новые веяния в мире технологий. Так можно подсмотреть много хорошего в копилку своих собственных методик.

4️⃣ Согласно «Королю Разработки», знание «откуда в либе баг» повышает тебя из рядового специалиста в ряды инженеров.

Лучший способ начать, на мой взгляд, это посмотреть в гитхаб своей любимой библиотеки. Увидеть, что сделало её такой крутой, что так приятно ей пользоваться. А потом просто взять и сделать также. Как говориться, fake it till you make it.