У России три пути.. И два из них мне точно не подходят.
Примерно такой логикой я руководствовался когда пришлось думать о
будущей профессии. В университете я начал изучать python, и практически все лабораторные работы и курсовые делал на нем.
Также я и познакомился с backend-разработкой. Для местного конкурса ctf я писал проект на django, и позже, писал курсовую работу на flask.
Тогда из механизмов для деплоя я знал только heroku, но задеплоить там получалось не всегда, например для того чтобы в итоге сдать курсач на flask я запускал сервер локально, и через специальную утилиту шарил порт на своем компе.
Когда я попал на стажировку, для меня открылся удивительный мир Docker, и по сути, тут и начался мой самостоятельный путь в айти.
Прежде чем выпустить меня на боевой проект, мне сказали:
- Учи Docker.
Окей, тогда я использовал Windows в качестве операционной системы, у меня был слабый ноутбук, я физически не мог запустить Docker под Windows.
Мне выделили небольшой сервер, с которым я мог делать все, что хочу, на нем я и разворачивал свой тестовый проект под докером прямо там, через ssh подключался и в nano писал все конфиги).
Первый проект на который меня выпустили можно охарактеризовать как "парсинговый ад". Идея приложения заключалась в том у нас был сервис, который собирал с популярных сайтов информацию о мероприятиях для детей и их родителей. Бек разделялся на две части:
1 - это был парсер, который отправлял свежие и обновленные мероприятия на основной сервер;
2 - основной сервер, который взаимодействовал с мобильным приложением. Все было написано на Django.
Парсеры, естественно, нужно было не только писать новые, но и поддерживать старые, если на каком-либо сайте меняется верстка, то информация будет собираться некорректно, собственно это научило меня находить быстрые решения, не только для фикса проблем, но и для удовлетворения бизнес требований.
В качестве положительных итогов можно выделить:
- Расширенный функционал приложения
- Написание и поддержка новых парсеров
- Успешный перенос прода с одного сервиса на другой
- Приобретение бесценного опыта
В качестве отрицательных итогов можно выделить:
- Отправка 1500 одинаковых писем на электронную почту заказчику за утро
- Уничтожение и последствующая реанимация прода, за 20 минут до демонстрации
Периодически были мелкие проекты связанные с парсингом, отчетами, и прочими бизнес задачами. Но однажды это должно было случиться, и случилось - я получил проект который нужно было делать с нуля.
Это было небольшое фитнес приложение, в котором было много текстовых и медиа данных, а также чат с заказчиком приложения)). Это было немного, но это честная работа. Чат был сделан с помощью django channels, это было интересно попробовать, однако сейчас я понимаю, что мое исполнение этой фичи нужно поставить в золотую рамку музея “Как не надо делать”.
Спустя 2-3 месяца мы стартанули проект, который стал рейд - боссом для всей команды. Там было необходимо применить все знания и умения нашей команды. Приложение для бронирования столика в ресторане с элементами соцсети! Огромное количество функционала, помимо бронирования, возможности добавиться в друзья к сидящим за соседним столиком, заказать блюдо, оплатить и разделить счет была возможность общаться в чатах и прочее…
Иногда на пути разработчика встречаются заказчики которые хотят "Одно приложение чтобы править ими всеми". Мне кажется диалоги с ними выглядят примерно так:
- Что вы хотите чтобы было в MVP?
- Всё.
Окей, мы начали. Чаты мы в итоге сделали с помощью Centrifugo - это сокет сервер, написанный на Go. В проекте была куча периодических задач - этим занимался Celery. Хотите нестрогий поиск? Вот вам алгоритмы на основе расстояния Левенштейна. Слишком много точек отображается на карте в большом масштабе? Значит добавляем кластеризацию объектов. За время этого проекта сложилось ощущение,что мы попробовали все... Но время показало как мы ошибались.
Были и другие проекты, но во всех них, я просто применял те знания, которые я получил до этого.
Далее мой первый аутстаф, прошел собеседование, вышел из родного гнезда компании - страшно, ничего непонятно, незнакомые люди и… openstack. Мы писали прослойку между фронтом и апи опенстека, за каждый логический модуль консоли управления виртуальными машинами отвечал отдельный микросервис на fastapi. На следующие два месяца моими друзьями стали Nova, Cinder, Glance, Keystone, Neutron и прочие компоненты Openstack, довелось поработать с s3, cockroach db и коллегами из других стран.
Перед тем как начать этот проект, я начал восстанавливать свои знания по английскому языку, занимаясь с преподавателем, и вот, не прошло и месяца как мне говорят, что нужно созвониться с одним человеком, но по-английски, ибо он из Индии.
Я читаю это сообщение... и делаю alt+tab из чата.
Я оттягивал этот момент до последнего. Но, как выяснилось в итоге, зря волновался. Мы поняли друг друга, я получил удовольствие от нового опыта, и научился тому, что нет смысла откладывать страшные на первый взгляд вещи на потом).
Тот проект вскоре мы сдали, и вдохновленный этим опытом, я хотел снова пойти на аутстаф, на проект побольше, в большую команду.
Такая возможность вскоре представилась, и встречайте:
- огромное количество чатов
- огромное количество людей в них
- неясный пока тебе флоу проекта
- два огромных репозитория с кодом
- особенности с запуском этого всего локально
По стеку это были те же Django, Fastapi, Docker, однако в комбинации с дополнительными технологиями, микро сервисами это было похоже на водоворот, который тянет тебя вниз, а как дышать под водой ты знаешь только в теории. Пришлось применять теорию на практике.
Хотите небольшой совет для тех кто первый раз попадает в подобную ситуацию и находится в замешательстве? Нужно найти человека который подробнее всех оставляет комментарии на код ревью, и спрашивать его). В конце концов если он не подскажет ответ на вопрос, то хотя бы направит к тому кто может это сделать. Проект был связан с персональными данными, однако скоуп задач был совершенно разный, от выявления рандомной ошибки в джанго админке, до рефактора частей проекта, написание новых микросервисов, и интеграция со сторонними сервисами.
И напоследок главное правило бойцовского клуба большого проекта - если ты задаешь вопрос в общем чате - ты будешь проигнорирован.
Мой путь в программировании наверное не такой, каким он наверное должен быть, с глубоким изучением программирования в университете (у нас все же кодинг не основная специальность) и последующей стажировкой в крупной компании с образцовым рабочим процессом, однако мой опыт может быть полезен кому-то, и поскольку меня еще не уволили, можно сказать, что в целом он удачный.
Примерно такой логикой я руководствовался когда пришлось думать о
будущей профессии. В университете я начал изучать python, и практически все лабораторные работы и курсовые делал на нем.
Также я и познакомился с backend-разработкой. Для местного конкурса ctf я писал проект на django, и позже, писал курсовую работу на flask.
Тогда из механизмов для деплоя я знал только heroku, но задеплоить там получалось не всегда, например для того чтобы в итоге сдать курсач на flask я запускал сервер локально, и через специальную утилиту шарил порт на своем компе.
Когда я попал на стажировку, для меня открылся удивительный мир Docker, и по сути, тут и начался мой самостоятельный путь в айти.
Прежде чем выпустить меня на боевой проект, мне сказали:
- Учи Docker.
Окей, тогда я использовал Windows в качестве операционной системы, у меня был слабый ноутбук, я физически не мог запустить Docker под Windows.
Мне выделили небольшой сервер, с которым я мог делать все, что хочу, на нем я и разворачивал свой тестовый проект под докером прямо там, через ssh подключался и в nano писал все конфиги).
Первый проект на который меня выпустили можно охарактеризовать как "парсинговый ад". Идея приложения заключалась в том у нас был сервис, который собирал с популярных сайтов информацию о мероприятиях для детей и их родителей. Бек разделялся на две части:
1 - это был парсер, который отправлял свежие и обновленные мероприятия на основной сервер;
2 - основной сервер, который взаимодействовал с мобильным приложением. Все было написано на Django.
Парсеры, естественно, нужно было не только писать новые, но и поддерживать старые, если на каком-либо сайте меняется верстка, то информация будет собираться некорректно, собственно это научило меня находить быстрые решения, не только для фикса проблем, но и для удовлетворения бизнес требований.
В качестве положительных итогов можно выделить:
- Расширенный функционал приложения
- Написание и поддержка новых парсеров
- Успешный перенос прода с одного сервиса на другой
- Приобретение бесценного опыта
В качестве отрицательных итогов можно выделить:
- Отправка 1500 одинаковых писем на электронную почту заказчику за утро
- Уничтожение и последствующая реанимация прода, за 20 минут до демонстрации
Периодически были мелкие проекты связанные с парсингом, отчетами, и прочими бизнес задачами. Но однажды это должно было случиться, и случилось - я получил проект который нужно было делать с нуля.
Это было небольшое фитнес приложение, в котором было много текстовых и медиа данных, а также чат с заказчиком приложения)). Это было немного, но это честная работа. Чат был сделан с помощью django channels, это было интересно попробовать, однако сейчас я понимаю, что мое исполнение этой фичи нужно поставить в золотую рамку музея “Как не надо делать”.
Спустя 2-3 месяца мы стартанули проект, который стал рейд - боссом для всей команды. Там было необходимо применить все знания и умения нашей команды. Приложение для бронирования столика в ресторане с элементами соцсети! Огромное количество функционала, помимо бронирования, возможности добавиться в друзья к сидящим за соседним столиком, заказать блюдо, оплатить и разделить счет была возможность общаться в чатах и прочее…
Иногда на пути разработчика встречаются заказчики которые хотят "Одно приложение чтобы править ими всеми". Мне кажется диалоги с ними выглядят примерно так:
- Что вы хотите чтобы было в MVP?
- Всё.
Окей, мы начали. Чаты мы в итоге сделали с помощью Centrifugo - это сокет сервер, написанный на Go. В проекте была куча периодических задач - этим занимался Celery. Хотите нестрогий поиск? Вот вам алгоритмы на основе расстояния Левенштейна. Слишком много точек отображается на карте в большом масштабе? Значит добавляем кластеризацию объектов. За время этого проекта сложилось ощущение,что мы попробовали все... Но время показало как мы ошибались.
Были и другие проекты, но во всех них, я просто применял те знания, которые я получил до этого.
Далее мой первый аутстаф, прошел собеседование, вышел из родного гнезда компании - страшно, ничего непонятно, незнакомые люди и… openstack. Мы писали прослойку между фронтом и апи опенстека, за каждый логический модуль консоли управления виртуальными машинами отвечал отдельный микросервис на fastapi. На следующие два месяца моими друзьями стали Nova, Cinder, Glance, Keystone, Neutron и прочие компоненты Openstack, довелось поработать с s3, cockroach db и коллегами из других стран.
Перед тем как начать этот проект, я начал восстанавливать свои знания по английскому языку, занимаясь с преподавателем, и вот, не прошло и месяца как мне говорят, что нужно созвониться с одним человеком, но по-английски, ибо он из Индии.
Я читаю это сообщение... и делаю alt+tab из чата.
Я оттягивал этот момент до последнего. Но, как выяснилось в итоге, зря волновался. Мы поняли друг друга, я получил удовольствие от нового опыта, и научился тому, что нет смысла откладывать страшные на первый взгляд вещи на потом).
Тот проект вскоре мы сдали, и вдохновленный этим опытом, я хотел снова пойти на аутстаф, на проект побольше, в большую команду.
Такая возможность вскоре представилась, и встречайте:
- огромное количество чатов
- огромное количество людей в них
- неясный пока тебе флоу проекта
- два огромных репозитория с кодом
- особенности с запуском этого всего локально
По стеку это были те же Django, Fastapi, Docker, однако в комбинации с дополнительными технологиями, микро сервисами это было похоже на водоворот, который тянет тебя вниз, а как дышать под водой ты знаешь только в теории. Пришлось применять теорию на практике.
Хотите небольшой совет для тех кто первый раз попадает в подобную ситуацию и находится в замешательстве? Нужно найти человека который подробнее всех оставляет комментарии на код ревью, и спрашивать его). В конце концов если он не подскажет ответ на вопрос, то хотя бы направит к тому кто может это сделать. Проект был связан с персональными данными, однако скоуп задач был совершенно разный, от выявления рандомной ошибки в джанго админке, до рефактора частей проекта, написание новых микросервисов, и интеграция со сторонними сервисами.
И напоследок главное правило бойцовского клуба большого проекта - если ты задаешь вопрос в общем чате - ты будешь проигнорирован.
Мой путь в программировании наверное не такой, каким он наверное должен быть, с глубоким изучением программирования в университете (у нас все же кодинг не основная специальность) и последующей стажировкой в крупной компании с образцовым рабочим процессом, однако мой опыт может быть полезен кому-то, и поскольку меня еще не уволили, можно сказать, что в целом он удачный.