ФРОНТ 🫥 БЕК
На мой взгляд, для работы в разработке сейчас стоит выбирать направление Веб-Бекенда. Но для этого нужно понимать, как работает веб. Разберём на примере.
У нас есть «фронт»:
🟣 Социальная сеть - лента картинок с подписями от других людей.
🟣 Лента со списком людей, на кого ты подписан.
🟣 Лента того, что ты публиковал.
Как это всё должно работать?
Мы используем REST-подход. Вообще есть альтернативы, но о них расскажу потом. REST проще и популярнее.
У нас есть клиент, который делает запросы к серверу. На сервере мы определяем роуты (маршруты, эндпоинты):
🟣 mysite.ru/posts
🟣 mysite.ru/subs
🟣 mysite.ru/my_posts
На фронте (клиенте), при нажатии на "посты", пользователь переходит по первой ссылке mysite.ru/posts. Бек (наш сервер) должен вернуть все данные, чтобы фронт их отрисовал.
В данном примере фронт нас вообще не интересует, поэтому разберём, что мы делаем на беке.
Бизнес приходит к нам с типичными задачами, все они описываются примерно так:
➡️ Запустить сервер, который будет отлавливать обращения с фронта
➡️ Научиться распознавать, какой роут был использован (posts, subs. my_posts)
➡️ На каждое действие возвращать клиенту данные в удобном виде
➡️ При обращении к subs, надо проверить кто текущий пользователь (значит, что нужна система авторизации). Для текущего пользователя сходить в БД и получить всех, на кого он подписан. Вернуть JSON со списком этих пользователей.
Этот пример можно бесконечно расширять, добавляя новую функциональность. Если вы можете справиться с таким (язык и фреймворк не важны, ведь это лишь инструмент), то вы готовы к собесам!👨💻
Пишите в комментарии, если хотите подробный пост про REST, JSON или клиент-серверное взаимодействие. Я как раз закончил записывать урок про это для курса.🔽
На мой взгляд, для работы в разработке сейчас стоит выбирать направление Веб-Бекенда. Но для этого нужно понимать, как работает веб. Разберём на примере.
У нас есть «фронт»:
Как это всё должно работать?
Мы используем REST-подход. Вообще есть альтернативы, но о них расскажу потом. REST проще и популярнее.
У нас есть клиент, который делает запросы к серверу. На сервере мы определяем роуты (маршруты, эндпоинты):
На фронте (клиенте), при нажатии на "посты", пользователь переходит по первой ссылке mysite.ru/posts. Бек (наш сервер) должен вернуть все данные, чтобы фронт их отрисовал.
В данном примере фронт нас вообще не интересует, поэтому разберём, что мы делаем на беке.
Бизнес приходит к нам с типичными задачами, все они описываются примерно так:
Этот пример можно бесконечно расширять, добавляя новую функциональность. Если вы можете справиться с таким (язык и фреймворк не важны, ведь это лишь инструмент), то вы готовы к собесам!
Пишите в комментарии, если хотите подробный пост про REST, JSON или клиент-серверное взаимодействие. Я как раз закончил записывать урок про это для курса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если вы еще не успели по-полной "вкатиться" в рабочий режим, предлагаю решить небольшую задачку.
Что выведет этот простой код на картинке?
Please open Telegram to view this post
VIEW IN TELEGRAM
Что выводит код выше?
Anonymous Quiz
34%
0
14%
10
10%
None
41%
Ничего, произойдёт ошибка / исключение
🤔1
Даже если вы уже читали книгу «Паттерны проектирования», вы можете не справится с одним популярным вопросом собеса. Если вас попросят привести примеры паттернов, вы можете подумать, что никогда не работали с ними.
Это не так! Если вы пишите код на Python, то вы используете паттерны каждый день. Привёл для вас 5 примеров, которые пришли мне на ум первыми.
* Замыкание — функция, которая создаётся каждый раз во время её выполнения.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Лучший показатель вашего уровня — это синдром самозванца. Согласно исследованиям Даннига и Крюгера:
Менее компетентные люди имеют более высокое мнение о своих способностях, чем более компетентные.
Схожее рассуждение встречается и у Лао-цзы, Сократа, Конфуция и других философов и учённых:
Зная мало мы считаем, что знаем много, а зная много мы скрываем это.
Исследование 1999 года сформировало эту гипотезу и подтвердило её исследованиями. Скорее всего вы замечаете это и на себе:
В момент получения первого оффера вы будете уверены в своих знаниях больше всего. Не поддавайтесь этому конгитивному искажению! Оно поможет вам пройти собеседования за счёт уверенности, но из-за него вам сложно будет признать свою неправоту. На диаграмме это "Пик глупости".
Устроившись в компанию вы подумаете, что ничего не знаете - сработает синдром самозванца. Именно в этот момент вы в среднем хорошо знаете сферу. Вы понимаете в чём слабы, но не забывайте, что есть то, в чём вы сильны. Зафиксируйте то, что вам кажется непонятным и изучайте. На диаграмме это "Долина отчания".
Почувствовав, что вы понимаете достаточно много, не останавливайтесь в изучении! Попробуйте расширить свои знания в других темах, возможно даже не в программировании. На диаграмме это "Склон просветления".
Согласно исследованию, дальше начинается "Плато стабильности", старайтесь не забывать, что зачастую специалисты развиты только в той сфере которой они заняты. Изучайте новые технологии и инструменты если хотите продолжать развиваться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Продолжаю раскрывать секреты тех-собесов. Обязательно прочитайте первую часть моего репортажа в посте.
Напомню, на выступлении раскрыл 3 секрета тех собесов:
В предыдущей части репортажа мы разобрали 2 реальных вопроса с тех-собеса, в этот раз разберём ещё 3.
👉 Читать репортаж
Please open Telegram to view this post
VIEW IN TELEGRAM
Мой ответ:
Если у вас меньше 5 лет коммерческого опыта, то: "Прокачивайте слабые стороны!". (Обычно это те технологии, с которыми вы работали мало).
Пример: вы хороши в работе в БД, но нет опыта с контейнерами.
Please open Telegram to view this post
VIEW IN TELEGRAM
Начиная разрабатывать веб, чаще всего мы выбираем архитектуру REST. Либо нам достаются проекты уже с таким подходом. Предлагаю разобраться, что же из себя представляет REST. Но сначала рекомендую почитать пост про то, как в целом работает веб.
Сразу определимся:
protected и private атрибутам класса. Вы можете это делать, но есть соглашение. Сам по себе этот архитектурный стиль не является протоколом, но обычно мы соблюдаем стандарты HTTP в RESTfull приложениях.
- Масштабируемость систем за счёт простого и систематизированного интерфейса
- Открытость компонентов к расширению
- Отдельные компоненты самостоятельны, а их взаимодействие структурировано
Читайте о 5 обязательных ограничений в REST в карусели:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня поговорим о том, как заполнить блок "опыт работы".
Тут всё просто. В нашем примере будет Sunflower Digital Group.
Первой строкой напишите чем занимается компания, так вы покажете сферу и архитектуру того, с чем вы работали.
RESTfull API для отдела продаж туристической компании на FastAPI
— нам уже понятно, что разрабатывался веб АПИ для внутреннего использования компанией, понятны примерные функции и стек.
Добавьте информацию о конкретных функциях приложения, это могут быть и достижения ваших коллег и ваши задачи. Описывайте всё как отдельные функции.
Ключевые проекты:
Микросервис для прогнозирования спроса
Интеграция с API бронирования отелей
Сбор и вывод статистики через Prometheus в реально времени c выводом в Grafana
CI/CD с линтером, тестированием и развертыванием на сервере
HR, который читает 1000 резюме в день, должен увидеть ключевые слова соответствующие вакансии, поэтому опишите функциональные возможности продукта.
Добавьте раздел с вашими достижениями отдельно, достаточно 2-3 пунктов.
Разработал два функциональных микросервиса
Улучшил сервис по обработке данных
Можно указать совершенно абстрактные вещи, просто покажите, что умеете рефлексировать и замечать свои достижения.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM