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

#доклады

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

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

У меня всегда было желание делать вклад в 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. Она открывает миллион возможностей не только для научных инструментов и расчётов, но и для неожиданных, ранее неизвестных, архитектурных решений.

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

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

Неожиданно, но ожидаемо

Вопреки всеобщим воплям о конце русского IT и другому подобному популярному мнению, зарплаты не падают.

А вполне даже растут. Новые условия == новые возможности. Держите руку на пульсе

Refit

Делюсь с Вами, мои дорогие подписчики, крутой находкой из мира .NET!

Постоянно забывал об одной интересной библиотеке, и вот вспомнил. Мне кажется, она должна быть особенно популярна сейчас, в эпоху микросервисов и распила монолитов. В общем, встречайте - Refit.

С помощью Refit можно пилить интеграции с апишками, просто объявляя интерфейсы. Весь бойлерплейт реализации Refit сгенерирует сам в рантайме. Кроме этого, там есть:

▪️Поддержка XML, JSON

▪️Гибкая настройка HttpClient

▪️Поддержка Polly

▪️Интеграция с DI и HttpClientFactory

▪️и многое многое другое

Ссылочка на GitHub проекта

Command Line Parser

Если вы пишете консольные утилиты и не знаете, как быстро и эффективно разработать API для CLI, то обязательно приглянитесь к библиотеке Command Line Parser.

Благодаря проекту, у CLR приложений есть возможность ясно и выразительно решать задачи по работе с аргументами командной строки:

▪️определение параметров (обязательных/необязательных, именованных, позиционных)

▪️создание команд (в том числе со своими собственными параметрами)

▪️гибкая настройка сообщения со справочной информацией и сообщения об ошибке

CommandLineParser прост в использовании, не имеет никаких сторонних зависимостей и позволяет пользоваться всей мощью ООП при проектировании параметров своего консольного приложения.

Ссылка на GitHub

System.IO.Abstractions

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

Тогда обратите внимание на пакет System.IO.Abstractions. И тогда проверка операций ввода/ввода станет проще!

Его суть довольна проста: статические методы из System.IO по типу File.WriteAllText теперь доступны через ряд специальных абстракций. Код под капотом тот же самый, только теперь он внедряемый и тестируемый.

И конечно, ссылка на GitHub

Техдолг в pet project

Последние две с лишним недели потел над pet project. Хотел выпустить киллер фичу, но, когда начал копать, просто выпал в осадок…

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

Сначала рефакторинг инфраструктуры: избавился от сторонних файлов в поставке, и разбил гигантский Main на тестируемые модули.

Потом рефакторинг доменки и вообще попытка её описания: в PR изменёнными оказались почти все файлы проекта.

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

Параллельно с этим настроил CI/CD через GitHub Actions - сижу и радуюсь жизни. А также пишу все свои мысли, замечания и выводы в issues и pull requests.

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

Опыт правильной коммерческой разработки показал, как можно писать код клёво и удобно. Я сделал выбор в пользу собственного комфорта и не прогадал.
Правда к фиче ещё даже не приступил)

Немного о pet project

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

Отвечаю.

Сейчас мой основной open source contribute - это попытка создать JavaScript без изъянов. Точнее TypeScript без изъянов.

Для описания мотивации, цели, причин и следствий нескольких абзацев telegram поста не хватит. Но, небольшой спойлер: готовлю материал об этом для новой медиа-площадки.

Если коротко, то основная проблема существующего языка - парадигмальная каша, возникшая из-за наличия конструктов номинативной типизации, когда by design она структурная.

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

В общем, чтобы проникнуться кодом и поднять мне мотивацию продолжать его писать, вы можете зайти на GitHub и поставить звёздочку!