Трехдневный андерхуд с бэкенд-разработчиком Меркури

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

Удачи, Паша!

Всем привет!
Меня зовут Паша. Я .NET-разработчик в компании Mercury Development. Несколько дней я буду вести этот канал.

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

Далее планирую делать посты по следующему плану:

[Среда] - Расскажу чем занимаюсь на работе, про проект и написание кода
- С чего начинаю и как заканчиваю свой рабочий день.
- Что происходит, когда я работаю с кодом и почему замечания по код-ревью не должны вас огорчать.
- О проекте, над которым сейчас работаем и что используем в серверной части.

[Четверг] - Как backend разработчик может покрыть клиентскую и серверную часть приложения
- Full stack приложение на .Net и причем тут Blazor.
- Плюсы и минусы Blazor по сравнению с другими веб фреймворками/библиотеками.
- Потенциал, дальнейшее развитие Blazor.

--
Подписывайтесь на наш канал, с̶т̶а̶в̶ь̶т̶е̶ ̶л̶а̶й̶к̶и̶, чтобы не пропустить следующие посты и пишите в комментариях, чтобы вы хотели узнать от .NET разработчика. Если тема найдет отклик, то обязательно расскажу.

#underhood #backend

How it started

У меня нет какой-то красивой истории, как я стал программистом. Мол, в детстве уже знал 3 языка программирования и мог на любом из них написать алгоритм быстрой сортировки, не глядя в интернеты. Да и сейчас, наверное, тоже не смогу :) Наоборот, я был очень далек от IT и считал программирование чем-то сложным и непонятным. Однако, я был довольно любознательным парнем 😅

Моим первым языком программирования стал Pascal ABC (да простят меня любители Turbo Pascal). Кстати, будет круто, если напишете, какой первый язык программирования был у вас - устроим батл)

В 10 классе за умение выводить в консоль “Привет мир!” и складывать цифры меня сослали на региональную олимпиаду по программированию, где я занял предпоследнее место. И то, один из участников просто не пришел.

Школа закончилась, и пришла пора решать, куда поступать. В целом мне нравилось и̶г̶р̶а̶т̶ь работать за компьютером, а ещё вспомнил, что неплохо умею складывать числа в Pascal. Сложив 2+2 выбор пал на “Факультет информатики” Самарского университета (бывш. СГАУ (бывш. КУаИ)).

Небольшой перекур в виде правок по ревью и напишу про университет, оставайтесь с нами! 😉

#underhood

Как я получал вышку, а главное зачем?

И вот, спустя 6 лет (в этом году) я заканчиваю Самарский Университет и понимаю, что если бы уже 3 года не работал разработчиком, то вряд ли бы хватило знаний и умений устроится куда-то.

К сожалению, наше образование (в большей степени) ориентировано на оформлении отчетности и заучивание информации для сдачи очередных экзаменов, а не на понимание материала и оттачивание навыков для освоения профессии. Но сказать, что в университете я не получил вообще никаких знаний по программированию тоже было бы неправильным, ведь работаю сейчас по специальности. Другой вопрос, стоило ли оно 6 лет обучения?

Иногда после очередного курса, я задавался вопросом, “A что это вообще было?”, “Зачем?”, “Как эти эльфийские символы (это не матан, с ним было все прилично) можно будет применить на практике?”
Конечно, к концу обучения появились предметы (Нейронные сети, параллельное программирование, разработка клиент-серверных приложений и написание тестов), напоминавшие мне, что я учусь все-таки на инженера программного обеспечения.

И когда я пришел на свой первый рабочий день оказалось, что все, чему учили тебя в университете, как-то не очень пересекается с теми задачами, которые пришлось решать на работе…

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

А пока важный опрос: кто как относится к высшему образованию?

#underhood

Работа не волк, но тоже оказалась в овечьей шкуре

Месяц назад я получил свою “корочку” о высшем образовании и при этом уже имею 3 года стажа работы в IT. Вот, что понял: чтобы к концу универа иметь какой-никакой релевантный опыт, нужно совмещать работу с учебой.

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

Там нам рассказывали про процессы, agile, scrum, систему контроля версий, CI/CD, тестирование ПО. Я же сидел и не понимал ничего из того, о чем шла речь. Только задавался вопросом, почему нам не рассказывают про это в университете?

Первым заданием было написать небольшую программку на C# по технике TDD (написание программного кода через тестирование), настроить автоматическую сборку через Teamcity, и, конечно же, оставить после чистый, красивый и читаемый код. С заданием я справился, но на каждом шагу выполнения чувствовал себя чуваком с кубиками из мема.

Тех кто хорошо показали себя во время практики пригласили работать в компанию. Так я и получил свой первый оффер. В первый свой день я узнал про такие слова, как SOLID, Jira, IIS, AngularJS, конечно же, я добавил эти слова в блокнот к остальным непонятным словам-сокращениям, чтобы потом узнать, что они значат. Делитесь, какие непонятные слова в первый день вам пришлось услышать? Фраза “Вы уволены” не участвует 🙂

В начале вопрос был скорее не в заработке, а в знаниях и возможностях развития. Успеть все (работа, учеба, хобби, сон) казалось невозможным. Первое и самое главное чему научился - это умение разделять важное от того, чем можно пожертвовать. К слову, жертвовал я обычно сном)

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

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

#underhood

How it's going

Обстоятельства так сложились, что прежняя работа перестала удивлять и давать мне развитие. Я начал задумываться, что надо, что-то менять и эти мысли привели меня на собеседование в Mercury Development. Нужно было знать технологию .NET и язык программирования C#. Как же здорово, что именно эти знания у меня имелись.

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

Но чтобы оставаться в “теме” нужно постоянно что-то изучать, читать, кодить. Вот несколько моих источников, в которые я заглядываю, чтобы поддерживать свои знания в .NET:

Code Maze - блог, где публикуются статьи по .NET. Там можно оформить еженедельную подписку (это бесплатно) и в пятницу будет прилетать выпуск статей, который можете почитать за б̶‌̶у̶‌̶т̶‌̶ы̶‌̶л̶‌̶к̶‌̶о̶‌̶й̶‌̶ ̶‌̶п̶‌̶и̶‌̶в̶‌̶а кружкой чая.

Medium (нуждается ли в представлении?) - блог, где публикуются статьи на любой вкус, начиная от обзора возможностей языка программирования, заканчивая разбором арт-объектов. Так же, там есть персональные рекомендации.

Канал на youtube про .NET - много туториалов, обзоров и видео с конференций.

Теперь ваша очередь. Признавайтесь, как остаетесь в тренде технологий, что читаете/смотрите? Возьму на вооружение! 🙂

--
Это был последний пост на сегодня. Завтра поговорим про проекты, технологии и чем-занимается Backend разработчик в течении дня. До завтра!

#underhood

Hello world!

На связи снова рубрика Underhood. Сейчас расскажу про свои проекты, над которыми успел поработать в Меркури.

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

Следующий проект, он же текущий - стримминговый сервис для независимых музыкантов. По техническому стэку там всего хватает: .NET5, микросервисы, Docker, Apache Kafka, Saga, Terraform/Terragrunt, AWS, а также различные интеграции со сторонними сервисами вроде отправки писем, сервиса оплаты и еще много всего.

Многое пришлось изучать практически с нуля. Вот, например, как я пришел к пониманию Apache Kafka на примере жизни выдр.

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

Ну и по традиции прошу вас делиться, какие интересные штуки вам приходилось доучивать на проектах?

#underhood #backend

Работа! Работа! Работа!

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

Бывает, что проходишь без единого замечания, а бывает 50 сообщений - целая дискуссия на тему как назвать переменную, и 20 коммитов, чтобы все поправить. Поэтому любопытно, какой у кого максимум замечаний по ревью был?) Может есть какой-то лимит 😂

Еще раньше я очень расстраивался из-за большого количества замечаний. Они всегда навеивали мысли, что со мной что-то не так, что, наверное, программирование, это не мое. Сейчас я научился смотреть на это как на бесценный опыт, который передает тебе более опытный разработчик. Главное понимать, почему возникло такое замечание и сделать из этого выводы, а если не понятно, то обязательно спросить, уточнить, чтобы стало понятно. Это тоже постоянный процесс обучения.

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

Вот так каждый день начинается мое утро ☕️

#underhood

Чем я занимаюсь в рабочее время?

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

- баг-фикс;
- реализация фичи;
- исследование стороннего сервиса/библиотеки/технологии для возможного использования в дальнейшем.

Теперь по порядку.

1. Баг-фикс. Здесь все просто, есть ожидаемое поведение, есть актуальное поведение. Когда эти два мира не сходятся, где-то на просторах проекта рождается баг. Причины могут быть разные, начиная с того, что разработчик не до конца реализовал задачу и, заканчивая тем, что тестировщики стучатся не в тот метод. С багами обычно есть правило: баг чинит тот, кто его нашел на чьей фиче его поймали. Самый простой способ понять, что пошло не так, если сразу не понятно, это пойти и почитать логи. Но учтите, чтиво не для слабонервных и может занимать до нескольких часов, так что советую вам быть осторожным 🙂

2. Реализация фич. Здесь тоже все просто: есть задача и есть требования к ней, как говорится, бери и делай. Если вы тоже так думаете, то представьте, что требований к задаче нет, а есть примерный набросок того, что нужно сделать. Что, например, вы обычно в таких случаях делаете? Я обычно забиваюсь в угол и начинаю плакать иду к аналитикам, к своей команде, выяснять хотя бы какие-нибудь требования и исхожу из пользовательского опыта. А уже после вступает правило "глаза боятся, руки делают")

3. Исследование стороннего сервиса/библиотеки/технологии. Это мое любимое. Я люблю, в меру своей любознательности, покопаться в чем-то новом, так еще и платят за это, что может быть лучше? Как раз так я узнал про фреймворк Blazor - о нем мы поговорим завтра. После исследования необходимо описать результаты, сделать выводы, а опыт в написании отчетов у меня большой 😉

#underhood

Как заканчивается мой рабочий день?

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

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

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

Но сегодня, кажется, я уйду вовремя, потому что отключил все нотификации)

—
Это последний пост на сегодня. Завтра как и обещал буду писать про Blazor✌️

#underhood

Всем привет! Сегодня завершаем андерхуд интенсив прекрасной темой про Blazor.

В 2018 году Microsoft анонсировала новый веб-фреймворк, который позволяет создавать браузерные приложения, используя, помимо HTML и CSS, также язык C# и синтаксис Razor. Назвали Blazor (не путать с напитком).

Да, да, это тот самый Razor, который раньше запускал представления (view) Razor на сервере, формируя таким образом HTML-код, который мог быть выведен браузером. Теперь же представления Razor можно выполнять на стороне клиента.

Он дает все преимущества богатых современных одностраничных приложений (SPA), позволяя при этом использовать .NET везде, вплоть до общего кода на сервере и клиенте.

Далее расскажу про основные подходы, который предлагает Blazor. Пишите, что бы вам хотелось про новый веб-фреймфорк от Microsoft?

#underhood #backend #frontend

Что нам предлагает Blazor?

Для создания приложения с использованием Blazor у нас есть 2 сценария:
1. Blazor WebAssembly
2. Blazor Server

Blazor WebAssembly позволяет размещать наши клиентские компоненты Blazor с помощью WebAssembly.

WebAssembly (WASM) - это бинарный формат, который позволяет запускать код в браузере. Результат компиляции с языка высокого уровня. Если проще, то это низко-уровневная виртуальная машина, как у Java. Вот тут ссылка на языки, которые умеют в WASM. Также стоит сказать, что WASM является частью JavaScript: он загружается, запускается и вызывается из JavaScript. В свою очередь WASM умеет вызывать JavaScript.

Все современные браузеры сейчас поддерживают WASM, кроме IE11, но кому он нужен 🙂

Что загружается при старте приложения на Blazor WASM:

- всякие js bootstrap.
- mono.js - связывает WASM с JavaScript
- mono.wasm - CLR .NET
- и приложение в виде dll с зависимостями.

Вот тут можно потыкать "Hello world" проект на Blazor WASM.

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

Что по ограничениям? Ограничение накладывает сам WASM. Нельзя создавать всякие сложные объекты связанные с многопоточностью, например, мютексы - код просто не скомпилируется.

—
Наверное, немного вас подгрузил. Пишите ваши вопросы относительно Blazor WASM, в следующих постах постараюсь ответить.
Далее также расскажу про Blazor Server.

UPD: Мне тут подсказывают, что WebAssembly является низкоуровневым языком программирования. А также окружение может предоставлять API для вызова методов, которые экспортируются WASM-модулем при помощи JavaScript 🙂

#underhood #backend #frontend

Blazor Server

В какой-то степени это похоже на подход, применявшийся в ASP .NET WebForms.
При загрузке JavaScript устанавливает SignalR соединение с сервером. Все файлы приложения уже лежат на серверной части нашего приложения.

При активности пользователя (например, при клике на какой-то компонент) он уходит через JavaScript, через вызов SignalR и отрабатывает на сервере, где есть виртуальное DOM-дерево. По binding происходит изменение DOM-дерева и разница отправляется на клиент и через JavaScript применяется на HTML.

При использовании такого подхода клиент становится тонким и мы можем использовать все возможности .NET, такие как доступ к файлам, многопоточные объекты и так далее. Загрузка приложения пободрее, чем у подхода с WASM, но не переживайте, IE11 тут тоже особо не работает 😂 (хотя я видел несколько статей, где применяют polyfill и все начнет работать😉)

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

—
Далее посмотрим, что общего у Blazor WebAssembly c Angular и чем они различаются.

#underhood #backend #frontend

Blazor WebAssemly и Angular?

При обзоре и первом опыте, мне показалось, что Blazor чем-то напоминает Angular. Также можно сделать 3 файла (верстка/стили/код) для компонента или держать все в одном файле. И на этом их сходство, к сожалению, закончилось) Как кому, кстати, больше нравится: разделять верстку, стили и код или держать все в одном файле?

Далее я столкнулся с проблемой подключения сторонних библиотек, потому что, в Angular это делается очень просто через npm. Для того, чтобы подключить библиотеку в Blazor, недостаточно как обычно в приложении написать команду установки пакета: dotnet add package MatBlazor. Иногда необходимо сделать дополнительное действие - пойти еще что-то куда-то добавить.

Вот например инструкция, как добавить Material Design компоненты для Blazor:
To Install:

dotnet add package MatBlazor

For client-side and server-side Blazor - add noscript section to index.html or _Host.cshtml (head section):

<noscript src="_content/MatBlazor/dist/matBlazor.js"></noscript>
<link href="_content/MatBlazor/dist/matBlazor.css" rel="stylesheet" />

Кстати, будьте осторожными с подключением пакетов в Blazor WASM, потому что если библиотека будет использовать что-то, что не может использовать WASM, то ваше приложение не скомпилируется.

Что кстати по HotReload в Blazor WASM?
Он есть, необходимо запустить приложение через dotnet watch и тогда после каждого нажатия CTRL+S веб страница в браузере будет перезагружаться.

В общем, на первый взгляд, Blazor выглядит слегка сыроватым, но пригодным к применению веб-фреймворком и однозначно пришелся мне по вкусу. Надеюсь, что когда-нибудь он встанет на ряду с Angular, Vue и React.

#underhood #backend #frontend

Что еще интересного?

Вот тут уроки, статьи, best practices, библиотеки, примеры проектов на Blazor, книги, подкасты и много чего еще.

Насчет больших, громких проектов, мне, к сожалению, не известно. Как мне кажется, еще слишком рано, ведь Blazor WASM зарелизился только в прошлом году и думаю, что люди еще только присматриваются к этой технологии.

В Меркури мы пока не используем Blazor. Но технология развивается и, возможно, в будущем мы попробуем фреймворк на подходящем проекте. Было бы круто услышать историю, как .NET-команда целиком затащила проект, как у нас делали фронтендеры с помощью React и React Native 💪

Пишите в коменты под этим постом, что думаете насчет Blazor? Возможно, я бы даже подготовил серию постов-ответов) Конечно же, если смогу ответить.

А это был последний пост на сегодня и на этом андерхуд - интенсив все) Это был отличный опыт, спасибо, что читаете, оставляете коменты, задаете вопросы и поправляете. Надеюсь, вам тоже было интересно) Успехов, всем пока ✌️

DevTools на Android

Вышла новая версия Kiwi Browser, основанная на Chromium 93.

На данный момент это единственный браузер на Android, который имеет инструменты разработчика (DevTools) и поддерживает расширения, прям как на настольных компьютерах.

Теперь, чтобы отладить веб-страницу или веб-приложение, не нужно на Android-устройстве включать настройки разработчика, активировать режим ADB (Android Debug Bridge), подключать его к настольному компьютеру по USB или Wi-Fi и т.д. Можно даже вообще не иметь настольного компьютера и сделать всё прямо на смартфоне, планшете, телевизоре или любом другом Android-устройстве. 🛠

Наш ведущий фронтенд-разработчик Алексей Родионов уже протестировал DevTools на Android. Говорит, есть мелкие проблемы — например, некоторые элементы интерфейса не оптимизированы для сенсорных экранов, но в целом это прорыв и в некоторых случаях просто незаменимый инструмент.

Twitter тестирует кнопки дизлайков, а также апвоуты и даунвоуты как на Reddit.

В США разрушили монополию производителей на сервисное обслуживание

Как было раньше

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

Как будет теперь

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