Что такое 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.

Про общительность программистов

Какое-то время назад в головах людей прочно засел стереотип о коммуникативных навыках специалистов в сфере айти.

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

Мало того, такое мышление стимулировало и самих программистов в какой-то степени потакать общепринятым установкам толпы.

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

Например, со мной всё наоборот: люди, с которыми имел общение, всегда удивлялись: «Стёпа, ты программист? Не поверю, что ты такой активный и за компом сидишь!»

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

Конференции, митапы, доклады - вот где происходит твоё личное информационное обогащение, и именно за счёт общения.

Соотвественно, специалист со слабо развитыми навыками коммуникации просто не может нормально развиваться. Поэтому, необщительный программист == плохой программист.

На Хабре написали про набирающий обороты тихий уход

Вкратце: «делай самый минимум, лишь бы не уволили и платили оклад»

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

В этом ничего постыдного. Даже есть что-то интересное. Например, в этом подкасте с ним, можно услышать следующие тезисы (применительно к IT):

▪️В компании, чей продукт давно зарабатывает деньги можно вырабатывать самый минимум

▪️Разработчик получать больше не за то, что он делает больше, а по факту роста, который происходит сам по себе

И дальше обрисовалась интересная финансовая стратегия. Не работать амбициозно в крутой компании, а устроиться в два места, позволяющих «тихо уходить».

Например, вы два раза middle: делаете работы по принципу «тихого ухода» не больше чем один, а получаете больше чем senior.

Конечно, встаёт вопрос о том, как это отражается на вашем росте, как профессионала. Но с точки зрения заработка, подход интересный.

Что думаете?

#хабр

Изобретать велосипеды плохо?

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

На самом деле, всё не так однозначно. В первую очередь, программирование - это творческая профессия. Нельзя творить, ничем не вдохновляясь.

Например, большая часть современной музыки состоит из заимствования, семплирования и переработки переработанного. Даже в классической музыке есть такие примеры: «Кармен» Жоржа Бизе сочинялась на основе малоизвестной кубинской авторской песни.

Вернёмся обратно в мир битов и байтов. Можно вспомнить много разных инструментов, которые решают одну и ту же задачу, а значит являются по отношению друг к другу велосипедами. Например, React PropTypes, Flow, Typenoscript - все добавляют статическую типизацию в JavaScript на этапе компиляции.

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

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

А вот что делать с устареванием документации?

Бизнес-процесс поменяли, выпилили, распилили и всё - она запутывает ещё больше.

В коммерческой разработке, на мой взгляд, самая крутая документация - это история изменений: внятные коммиты, overview [pull|merge] реквестов, fsd в confluence, комменты в jira и так далее

А jsdoc/xmldoc/комментарии круче смотрятся в личных проектах, чтобы как минимум самому не запутаться

https://news.1rj.ru/str/java_kabal/133

На этой неделе посты будут выходить чуть реже, потому что в планах статьи на Хабр и весь фокус смещается туда.

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

Использование MediatR - это одна из самых острых и горячих тем в .NET разработке.

Сам пока не пришёл к единому мнению по этому вопросу. С одной стороны инструмент даёт много возможностей, с другой приносит много проблем.

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

Бегите на Хабр, читайте и ставьте плюсы!

#хабр

abstract class vs interface

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

Фишка в том, что вопрос риторический. Ответ «одно лучше другого, потому что…» будет неправильным, ведь цель вопроса узнать ваше понимание инструмента.

Если прислушаться к постановке вопроса интервьюером в том видео, ссылку на которое оставлена, то можно услышать подсказку: «а зачем нам и то, и другое, если это одно и тоже?»

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

Суть различия даже не в том, что в класс можно засунуть данные, а в интерфейс - нет. Это как раз сделать можно с помощью свойств или get/set методов.

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

Когда мы проектируем интерфейс, то подразумеваем, что существует набор никак не связанных друг с другом сущностей, похожих по выполняемым действиям. Например, объект, который может говорить: человек, робот, попугай, инопланетянин и так далее.

C# vs Java

Как много в этом звуке для сердца энтерпрайзера слилось…

Все знают, что Java вышла и раньше, да и у её создателя большая борода. Значит она круче!

Хотя в C# была проведена большая работа над ошибками (устройство памяти, дженерики, value types), потом вообще LINQ завезли. Значит он круче!

Так в Java завезли stream API, в конце концов, может она круче? Да нет же, TPL + async/await - киллер фича C#, он вне конкуренции!!!

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

Поэтому, в последнее время популярны вопросы и публикации: «Что есть в C#, чего нет в Java?»
Я же вам скажу, что есть очень крутые вещи, которые подчинённые Гейтса ещё не успели перенести и, в некоторых случаях, очень зря.

Об этом мой новый пост на Хабре. Скорее туда - читать, ставить плюсы и повышать рейтинг!

Если кто-то до сих пор думает идти в Я

Настоятельно рекомендую посмотреть вот этот подкаст.

Рекорд Гиннесса по уходам от ответа на вопрос и переобуванию на скорость. Феноменально раздражающая личность.

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

Очень жду C# 11

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

Раньше я сам пытался ступить на поле этих открытий в своих статьях на Хабре «Абстрактная алгебра в действии» и «Властелин Структур».

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