Про ИИ

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

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

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

Тот же 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.

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

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

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

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

Конечно, все люди разные, в жизни встречается больше 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

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

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